/mvp-plan

name: mvp-plan
version: 0.1.0
description: Turn a locked north star into a scoped, gated MVP plan. The riskiest assumption, the smallest product that tests it, numeric success metrics and kill criteria set by the founder, and phase gates that keep build work behind explicit approval. Runs after north-star locks; refuses to run without one.

/mvp-plan — from locked identity to a scoped, gated MVP plan

When to use

Immediately after `north-star` locks, before any design-system, mockup, architecture, or build work. Re-run only when the founder explicitly reopens scope (same one-way ratchet as north-star's drift rule).

Skip for: products without a locked north star (run `north-star` first — this skill refuses to proceed without `docs/00-north-star.md`), features on an existing product, pure technical decisions.

What it produces

1. **`<project>/docs/002-mvp-plan.md`** — the MVP plan, whose spine is a CHECKLIST from idea to launch: every step as a checkbox — finalize features, market research, design guidance, actual design and screenshot approvals, architecture, build, money, launch — including steps already done at writing time (listed unchecked with a done-date annotation; the founder checks them off themselves when they review the list in the repo). Around the checklist: riskiest assumption, MVP scope in/out, success metrics and kill criteria in the founder's numbers, open-decisions table. Numbered-doc convention is inherited from the reference project — confirm the next free number in the target project's `docs/` folder rather than assuming `002` verbatim (the reference project reserved `001` for a still-undetermined doc between north-star and mvp-plan). 2. **`<project>/docs/build-logs/mvp-plan-v{N}.md`** — session record: founder's verbatim answers, draft evolution with rejection reasons, review findings and items acted on. 3. Counter increment in `<project>/docs/eval-runs/mvp-plan.md` (`runs_total`, and `runs_surgery` when Phase 1 detects surgery mode — mirrors north-star's `runs_total`/`runs_drift` split).

Hard rules

1. **A locked north star is a precondition.** Read `docs/00-north-star.md` and the north-star build log's positioning context before the first question. If `docs/00-north-star.md` is missing, stop and say so. (North-star has no on-disk unlocked/draft state — the file's presence means it's locked.) 2. **The plan stays DRAFT until the founder flips it.** Writing the document is not approval. The header says DRAFT and names the founder as the only one who changes that. Never mark it approved yourself. 3. **Success metrics and kill criteria are the founder's numbers.** The skill may cite research-derived calibration ranges (with source) anywhere in the plan. It NEVER invents the founder's specific commit numbers for the success-metrics/kill-criteria section; those ship as labeled blanks until the founder gives them — blanks are honest, invented numbers are not. 4. **Kill criteria are written while emotionally neutral** — before build, before sunk cost. Present this as the reason the question is asked now, not later. 5. **Founder's verbatim language in the build log.** Same as north-star: quotes are quotes, summaries are marked as summaries. Ask consent before recording sensitive disclosures, and before fixing spelling in quoted text. 6. **No old rulings carried silently.** Decisions from prior plans or superseded products enter as inputs to re-decide at a named phase, never as standing authority. 7. **Review findings are triaged by the founder, never auto-applied.** Present a concise punch list; apply only what the founder picks. 8. **Cross-model review at lock is required** — a fan-out (Sonnet + Opus + Haiku) on the final draft with a must-fix-only mandate ("SHIP or FIX, don't relitigate settled style"); cap the punch list at 3 only when reviewers converge on 3 or fewer — surface all consensus must-fix items if there are more. Mid-flight single-model reviews are optional and founder-triggerable at any point. 9. **Every phase gate in the plan opens with a plain-language brief and the founder's explicit yes.** The plan encodes this; the skill models it in miniature by not handing off the draft until the founder has confirmed in chat that v1 reads right (Phase 4) — that confirmation is not the DRAFT-to-approved flip, which stays the founder's separate later act per Hard rule 2. 10. **The founder edits the file directly once a draft exists.** Iterate v1 conversationally; then open `docs/002-mvp-plan.md` in their editor and hand it over.

The interview (one question at a time; reflect back in the founder's words; move on only when they confirm)

1. **The riskiest assumption.** *"If this product dies, what killed it? Not what could go wrong — the one assumption everything else rests on."* Test the answer against the research if a corpus exists (demand? acquisition? retention? willingness to pay? the tech?). The MVP is whatever tests THIS cheapest. 2. **The bar.** *"What number makes this a win, by when? Revenue, subscribers, whatever you actually care about. And what's the smallest version of that number that keeps you going?"* Calibrate everything downstream (scope, channel expectations, kill criteria) to the founder's bar, not to startup folklore. 3. **The kill line.** *"Decide now, while it's cheap: what result by what date means stop or change course? You're allowed to change this later — but write the calm version down today."* (Hard rule 4 is the why.) 4. **The cut.** Walk the candidate scope and force each item into: tests-the-riskiest-assumption, launch-blocking-plumbing (legal, billing, operator tooling — use a product-surface sweep if one exists in the research corpus, else run one), or explicitly-out-with-a-reason. The out-list is as load-bearing as the in-list; anchor each exclusion to an ADR or a decision, so future sessions don't helpfully add it back. 5. **The gates.** Propose phase gates shaped to the project (research picks → design syst