name: pmf-analysis\ndescription: Audit a codebase for product-market fit readiness -- evaluate startup PMF signals, core value loop tightness, feature scatter vs focus ratio, user activation funnel friction, retention hook infrastructure, pricing flexibility, analytics event coverage, CI/CD iteration speed, and growth-stage maturity for pre-seed through Series A products.\nversion: \"2.0.0\"\ncategory: analysis\nplatforms:
\nYou are an autonomous product-market fit analyst. Do NOT ask the user questions. Read the actual codebase, evaluate every PMF signal you can extract from code and architecture decisions, and produce a comprehensive PMF readiness report.
\nPMF is not just a business metric -- it leaves fingerprints in the code. A product approaching PMF has a tight core loop, minimal distractions, fast iteration speed, and instrumentation to measure what matters. A product far from PMF has scattered features, no analytics, slow deploys, and an architecture that cannot adapt.
\nTARGET:\n$ARGUMENTS
\nIf arguments are provided, use them to focus the analysis (e.g., specific feature area, target market segment, growth stage). If no arguments, run the full analysis.
\nStep 1.1 — Product Discovery
\nRead the project's README, package metadata, landing page copy, app store\ndescription, and marketing materials. Summarize:
\nStep 1.2 — Critical Path Trace
\nIdentify the ONE core user flow that delivers the primary value. This is the\n\"aha moment\" path — the sequence of actions where a user first experiences\nthe product's value.
\nTrace this path end-to-end through the codebase:
\nFor each step, record:
\nStep 1.3 — Core Path Health Score
\nEvaluate the critical path:
\nScore: 0-10 (0 = core path is broken, 10 = flawless value delivery)
\nDetermine whether engineering effort is concentrated on core value\nor dispersed across distractions.
\nStep 2.1 — Feature Inventory
\nScan the entire codebase and categorize every user-facing feature:
\nCore Features — directly deliver the primary value proposition:
\nSupporting Features — enable core features but don't deliver value alone:
\nPeripheral Features — nice-to-have, don't relate to core value:
\nAbandoned/Incomplete Features — started but not finished:
\nStep 2.2 — Code Distribution
\nCalculate approximate lines of code per category:
\nStep 2.3 — Git History Analysis (if git available)
\nAnalyze recent commit history to understand where effort is going:
\ngit log --oneline -100 to get recent commitsStep 2.4 — Fix Ratio
\nCount commits that are fixes vs new features:
\nScore: 0-10 (0 = scattered effort, 10 = laser-focused on core value)
\nEvaluate how effectively the product converts new users into active users.
\nStep 3.1 — Signup to Value Steps
\nCount every required step between \"I want to try this\" and \"I got value\":
\nRecord the total step count and identify every friction point.
\nStep 3.2 — Activation Barriers
\nSearch for code that creates unnecessary friction:
\nStep 3.3 — Activation Metrics
\nSearch for tracking of activation events:
\nStep 3.4 — Activation Optimization Infrastructure
\nCheck if the team can experiment with activation:
\nScore: 0-10 (0 = high friction, no measurement, 10 = optimized, instrumented funnel)
\nEvaluate whether the product is built to bring users back.
\nStep 4.1 — Engagement Hooks
\nSearch for retention mechanisms in the codebase:
\nStep 4.2 — Engagement Loop Quality
\nFor each hook found, evaluate:
\nStep 4.3 — Churn Prevention
\nSearch for signals that the team is thinking about churn:
\nStep 4.4 — Network Effects
\nSearch for features that increase value as more users join:
\nScore: 0-10 (0 = no retention infrastructure, 10 = strong engagement loops + network effects)
\nEvaluate whether the architecture supports pricing experimentation.
\nStep 5.1 — Current Pricing Model
\nSearch for pricing, plan, tier, and subscription logic:
\nStep 5.2 — Pricing Flexibility
\nEvaluate how easily the team can change pricing:
\nStep 5.3 — Revenue Readiness
\nCheck for revenue infrastructure maturity:
\nScore: 0-10 (0 = no monetization, 10 = flexible, instrumented revenue engine)
\nEvaluate whether the team can actually measure PMF signals.
\nStep 6.1 — Analytics Implementation
\nSearch for analytics/tracking across the codebase:
\nStep 6.2 — PMF-Critical Metrics Coverage
\nCheck if these essential PMF metrics are trackable from the codebase:
\nActivation:
\nEngagement:
\nRetention:
\nRevenue (if applicable):
\nStep 6.3 — Experimentation Infrastructure
\nCheck for A/B testing and experimentation capability:
\nScore: 0-10 (0 = flying blind, 10 = comprehensive PMF measurement)
\nEvaluate how fast the team can ship changes — critical for finding PMF.
\nStep 7.1 — Development Pipeline
\nCheck for CI/CD and deployment infrastructure:
\nStep 7.2 — Code Modularity
\nEvaluate how easy it is to change things:
\nStep 7.3 — Velocity Indicators (from git if available)
\nScore: 0-10 (0 = slow, manual, fragile deploys, 10 = fast, automated, safe iteration)
\nLook for signals that the product is connecting with its market.
\nStep 8.1 — Integration Ecosystem
\nSearch for third-party integrations:
\nIntegration breadth signals market pull — the market is telling you\nto connect with their existing tools.
\nStep 8.2 — Multi-Market Readiness
\nCheck for internationalization and localization:
\nStep 8.3 — Platform Coverage
\nCheck deployment targets:
\nBroader platform coverage can signal market demand pulling the product\nto new surfaces.
\nScore: 0-10 (0 = isolated product, 10 = ecosystem-integrated, multi-market ready)
\nWrite the complete analysis to docs/pmf-analysis.md in the project\n(create the docs/ directory if it doesn't exist).
After producing output, validate data quality and completeness:
\nIF VALIDATION FAILS:
\nIF STILL INCOMPLETE after 2 iterations:
\n| Dimension | \nScore | \nWeight | \nWeighted | \nKey Finding | \n
|---|---|---|---|---|
| Core Value Delivery | \n{0-10} | \n25% | \n\n | \n |
| Feature Focus | \n{0-10} | \n15% | \n\n | \n |
| User Activation | \n{0-10} | \n15% | \n\n | \n |
| Retention Infrastructure | \n{0-10} | \n15% | \n\n | \n |
| Pricing Flexibility | \n{0-10} | \n5% | \n\n | \n |
| Analytics Maturity | \n{0-10} | \n10% | \n\n | \n |
| Iteration Speed | \n{0-10} | \n10% | \n\n | \n |
| Market Signals | \n{0-10} | \n5% | \n\n | \n |
| PMF Readiness | \n\n | \n | /10 | \n\n |
PMF Stage: {SEARCHING / APPROACHING / ACHIEVED / SCALING}
\n| # | \nGap | \nDimension | \nImpact | \nEffort | \nRecommendation | \n
|---|---|---|---|---|---|
| 1 | \n\n | \n | {High/Med/Low} | \n{S/M/L} | \n\n |
| 2 | \n... | \n... | \n... | \n... | \n... | \n
Actions that would most rapidly improve PMF readiness:
\nFactors that could prevent or delay PMF:
\ndocs/pmf-analysis.md============================================================
\nAfter producing output, record execution metadata for the /evolve pipeline.
\nCheck if a project memory directory exists:
\n~/.claude/projects/skill-telemetry.md in that memory directoryEntry format:
\n### /pmf-analysis — {{YYYY-MM-DD}}\n- Outcome: {{SUCCESS | PARTIAL | FAILED}}\n- Self-healed: {{yes — what was healed | no}}\n- Iterations used: {{N}} / {{N max}}\n- Bottleneck: {{phase that struggled or \"none\"}}\n- Suggestion: {{one-line improvement idea for /evolve, or \"none\"}}\nOnly log if the memory directory exists. Skip silently if not found.\nKeep entries concise — /evolve will parse these for skill improvement signals.
\nNEXT STEPS:
\n/iterate to address the top PMF gaps.\"/customer-success-audit to strengthen retention and support infrastructure.\"/growth-audit to build acquisition and engagement loops.\"/compete to validate differentiation against competitors.\"/stress-test-personas to pressure-test the product from adversarial angles.\"/cost-analysis to ensure unit economics support the business model.\"