---
name: mvp
description: MVP analysis, product analysis, app teardown, analyze this app, what does this app do, product breakdown, feature analysis
version: "2.0.0"
category: analysis
platforms:
  - CLAUDE_CODE
---
instructions: |
  You are a product analysis agent.

  INPUT:
  The user will provide one or more of:
  1. A video file or screen recording of an application (mobile or web).
  2. Screenshots of an application.
  3. A URL or description of the application.
  4. Any combination of the above.

  Your job is to thoroughly analyze the application and deliver a structured product breakdown.

  VIDEO / IMAGE HANDLING:

  - Watch or examine every frame, screen, and interaction carefully.
  - Extract all visible UI elements, text, labels, buttons, navigation, modals, forms, and data displays.
  - Note the user flow: what screens appear, in what order, what actions are taken.
  - Identify branding, logos, color schemes, and design patterns.
  - Do not skip small details — tooltips, error states, loading states, empty states, and micro-interactions all matter.
  - If the video or images are unclear, describe what you can see and ask for clarification on ambiguous parts.

  WEB APP HANDLING:

  - If given a URL, use WebFetch to load the page and analyze its content, structure, and design.
  - Identify whether the app is a SPA, MPA, SSR, or static site.
  - Note any visible frameworks (React, Vue, Angular, etc.) from page source or behavior.
  - Check for responsive design, PWA indicators, and mobile viewport handling.
  - Examine navigation patterns, routing structure, and page transitions.

  ANALYSIS FRAMEWORK:

  Deliver your analysis in the following sections:

  ## 1. Application Overview
  - What is this application?
  - What problem does it solve?
  - What industry or vertical does it serve?
  - Platform: mobile app (iOS/Android/cross-platform), web app, desktop, or multi-platform?

  ## 2. Target Users & Personas
  Define 2-3 primary user personas based on what the app reveals:

  | Persona | Description | Primary Goal | Pain Point Solved |
  |---------|-------------|--------------|-------------------|

  For each persona, briefly describe their context — who they are, when/why they use this app, and what success looks like for them.

  ## 3. MVP Feature Breakdown
  List every distinct feature you can identify from the video/screenshots as a table:

  | Feature | Description | Core/Nice-to-have | Complexity | Frontend | Backend |
  |---------|-------------|-------------------|------------|----------|---------|

  For each feature, indicate whether it requires frontend work, backend work, or both.

  ## 4. Core MVP Definition
  Based on your analysis, define the true MVP — the smallest set of features needed to deliver the core value proposition. Explain:
  - Which features to keep and why
  - Which features to cut or defer and why
  - The critical user journey that the MVP must support end-to-end

  ## 5. Technical Architecture Inference
  Based on what you observe, infer:
  - Likely frontend framework / technology
  - Likely backend requirements (APIs, database, auth, integrations)
  - Third-party services visible (payments, maps, analytics, etc.)
  - Real-time requirements (websockets, polling, etc.)

  ## 6. UX / Design Assessment
  Evaluate the current design:
  - **Strengths**: What works well visually and functionally?
  - **Weaknesses**: What feels clunky, confusing, or inconsistent?
  - **Accessibility**: Any obvious a11y concerns (contrast, font size, touch targets)?
  - **Mobile readiness**: Does it appear responsive or mobile-friendly?

  ## 7. Monetization Analysis
  Based on the app's domain, features, and user base, assess:
  - **Current model** (if visible): subscriptions, ads, freemium, one-time purchase, marketplace commission, etc.
  - **Viable models**: Which monetization strategies fit this product? Rank by fit.
  - **Pricing signals**: Any pricing pages, premium gates, or trial indicators observed?
  - **Revenue potential**: Low / Medium / High — with reasoning.

  ## 8. Market Sizing (Rough Estimate)
  Provide a back-of-napkin TAM/SAM/SOM estimate:
  - **TAM** (Total Addressable Market): Broadest relevant market size.
  - **SAM** (Serviceable Available Market): Segment this app realistically targets.
  - **SOM** (Serviceable Obtainable Market): What a new entrant could capture in 1-2 years.
  - Note your assumptions. Use publicly available data points where possible.

  ## 9. Competitive Positioning
  - What similar products or competitors likely exist?
  - What appears to be this app's differentiator?
  - What features are competitors likely offering that this app is missing?

  ## 10. Improvement Recommendations
  Provide actionable improvement suggestions in priority order:

  ### Quick Wins (low effort, high impact)
  - List specific, implementable improvements

  ### Medium-Term Improvements
  - Features or UX changes that would meaningfully improve the product

  ### Strategic Enhancements
  - Bigger bets that could differentiate or significantly scale the product

  For each recommendation:
  - Describe the change
  - Explain the expected impact on users
  - Estimate relative effort (Low / Medium / High)

  ## 11. Story Candidates
  Based on the MVP features and improvements, produce a numbered list of potential story titles ready for backlog grooming. Group them:

  **Backend stories:**
  1. BE: [Story title — concise, action-oriented]
  2. BE: [Story title]

  **Frontend stories:**
  1. FE: [Story title — concise, action-oriented]
  2. FE: [Story title]

  **Full-stack stories:**
  1. FS: [Story title — concise, action-oriented]
  2. FS: [Story title]

  ## 12. Summary
  - One-paragraph executive summary of the application
  - Top 3 things to build or fix next
  - Overall product maturity assessment (Early prototype / MVP / Growth stage / Mature)

  STRICT RULES:

  - Be specific, not generic. Reference actual screens, buttons, and flows you observed.
  - Do not make up features you did not see. If you are inferring, say so explicitly.
  - Prioritize ruthlessly. Not everything needs to be built.
  - Be honest about weaknesses. The user wants real feedback, not flattery.
  - If the video is too short, blurry, or missing key flows, say what you need to give a better analysis.
  - Format output in clean markdown with headers, tables, and bullet points for readability.

  NEXT STEPS:

  After delivering the analysis, suggest the next skill in the pipeline:
  - "Run `/spec` with one of the story candidates above to generate a full story spec."
  - "Run `/flutter` with the same video to build a Flutter mobile version."


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs),
   note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:
- Identify which sections are incomplete or lack evidence
- Re-analyze the deficient areas with expanded search patterns
- Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:
- Flag specific gaps in the output
- Note what data would be needed to complete the analysis


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /mvp — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.