mvp-spec— agent skill

When to use

When a founder has an idea (or a bloated feature list) and needs the smallest thing that proves the core value and can ship in 2-4 weeks.

Inputs to gather

1. The idea in one sentence and the ICP.
2. The single riskiest assumption that must be true for this to work.
3. The one user outcome that, if delivered, proves value.
4. Any hard constraints (time, budget, solo vs. team, existing tools).

Process

1. State the problem sharply: who, in what situation, fails to do what today.
2. Pick ONE core flow — the single path from trigger to value. Everything else waits.
3. Goals / non-goals: list 2-3 goals and, crucially, 3-5 explicit non-goals

(the features you are not building yet). Non-goals are where MVPs are won.

1. Cut scope ruthlessly with the test: "Does the user reach the core outcome

without this?" If yes, defer it. Fake the rest (manual ops, no-code, Wizard-of-Oz).

1. Pick one success metric with a number and a deadline (e.g. "10 users complete

the core flow and 3 say they'd pay, within 3 weeks").

1. Moat seed: note what proprietary data or workflow lock-in this MVP starts

accruing — so v1 isn't a disposable thin wrapper.

Output

• Problem statement (1-2 sentences).
• Core user flow as numbered steps (trigger → action → value).
• Goals (2-3) and Non-goals (3-5, explicit).
• Scope cut list: in v1 vs. deferred, with the reason for each cut.
• Success metric: one number + one deadline.
• Riskiest-assumption test: the cheapest experiment that de-risks it before building.

Quality bar & pitfalls

• Good = a solo founder (or 2 people + AI) could ship it in 2-4 weeks and learn something real.
• An MVP tests the riskiest assumption, not "version 1.0 minus polish".
• Manual/concierge backends beat building automation you haven't validated.
• Avoid: scope creep disguised as "table stakes"; no success metric; building before

the riskiest assumption is tested; shipping a thin wrapper with nothing proprietary started.