Scope MVP

Take the PRD or feature list the founder points at and produce a version one that can ship: every feature sorted into keep, cut, or later with a reason, plus the smallest thing that would test whether anyone wants the product. This command runs the mvp-scope-cutter procedure and saves the result to docs/mvp-scope.md. It is normally run right after /prd, and before opening the builder session described in Build an MVP with Claude Code.

Scope

Interpret $ARGUMENTS in this order:

1. If it is a path and Read succeeds (docs/prd.md, notes/features.txt), that file is the input.
2. Otherwise treat $ARGUMENTS as an inline feature list, one feature per line or comma-separated.
3. If $ARGUMENTS is empty, Glob for docs/prd.md and use it if present. If it is absent too, ask "Which PRD or feature list should I cut?" and stop.

Step 1 — Flatten the features

Extract every capability from the input into a numbered list. From a PRD, take the Scope section plus anything in the body that reads like a feature. Split compound items into one feature each and merge duplicates. The table refers to features by these numbers.

Step 2 — Name the core job and the riskiest assumption

Write the core job in one sentence: who does what, to get what outcome. Use the PRD's first jobs-to-be-done statement if there is one; otherwise write your best reading and tag it [ASSUMPTION].

Then write the riskiest assumption as "We believe [users] will [behavior] because [reason]." Prefer a demand or behavior assumption over a technical one; technical risk is usually cheaper to test and less often fatal.

Step 3 — Sort every feature

For each numbered feature, answer two questions: is it required for a user to complete the core job once, end to end, and does it produce evidence about the riskiest assumption? Keep if either is yes. Later if it is useful but the job completes without it. Cut if it serves a different user, a different job, or exists only because a competitor has it.

Unless the feature is the core job itself, admin panels, settings, roles and permissions, integrations, notifications, dashboards, billing tiers, onboarding tours, dark mode, and native mobile go to later. For any expensive keep, propose the manual substitute (a spreadsheet, a hand-sent email, a form plus an automation) and mark it "manual for v1".

Write the reason column in one line that references the core job, the assumption, or a default. "Nice to have" is not a reason. If more than seven features are kept, sort again more strictly or state in one sentence why this product needs more.

Step 4 — Write docs/mvp-scope.md

Write a document with this structure, creating docs/ if needed:

# MVP scope — <product name>
 
Core job: <one sentence>
Riskiest assumption: We believe <users> will <behavior> because <reason>.
 
| # | Feature | Verdict | Reason |
| --- | --- | --- | --- |
 
## Smallest thing that tests the riskiest assumption
<what to put in front of people, who, the pass and fail signal as observable behavior, and how long>
 
## Version one in one sentence
<a sentence a user would understand>
 
## Kept features
<the keep rows again, as a plain list, ready for a task tracker or a build prompt>

If docs/mvp-scope.md already exists, Read it first and ask whether to overwrite before writing.

Output

Report the path written, the keep, cut, and later counts, the riskiest assumption, and the one-sentence version one. Suggest the next step: /breakdown-task on the kept list, or, if an AI builder has already produced an app, running the technical-cofounder agent over it before adding anything. The full founder sequence is described in Claude skills for founders.