/mvp

description: Plan the smallest working version, assess it on a clickable HTML prototype, then build it with the orchestration flow.
argument-hint: "[what to build] [--review]"

Superlite MVP mode. Request: $ARGUMENTS

First, read `${CLAUDE_PLUGIN_ROOT}/assets/flows/mvp.txt` (if the variable is not expanded, it is `assets/flows/mvp.txt` in the superlite plugin directory) and print it verbatim in one ```text block, before anything else. It is stored, so never redraw or edit it. Skip it only when it was already printed this turn.

Design: `docs/mvp-flow.md`. If the request is empty, ask for it in one line. Once the request is known, and BEFORE `superlite-cli orchestrator set`, run `superlite-cli session ensure --slug <topic>` (`<topic>`: a short slug of the request, a-z, 0-9, `-`; reuse it for plan file names). On a `SESSION worktree=<path>` line that differs from the current checkout, under Claude Code on `session: create EnterWorktree name=<n>` call `EnterWorktree name=<n>` and rerun the same command inside it, on `session: enter EnterWorktree path=<p>` call `EnterWorktree path=<p>`, on `ASK branch-name` ask the user once and rerun with `--branch-name worktree|superlite|PATTERN`, elsewhere `cd` to `<path>`; on `REDIRECT worktree=…`, do the same for that worktree. If ensure prints an `ASK` line (`ASK untracked=...` or `ASK move ...`, exit 4, nothing changed), ask exactly what the `ask:` line after it says, then rerun as it says. If the hook printed `superlite sync:`, ask the same way; sync is fast-forward only. Then:

1. Ask the orchestrator choice (human or AI) unless the user already said; run `superlite-cli orchestrator set human|ai`. Add "Run the whole test suite at finish?" (`No, affected tests only (Recommended)` / `Yes, once at finish`) to that same question batch; AI orchestrator does not ask it (`Ruling: full suite no`). 2. Write the MVP plan, `docs/plans/<date>-<topic>.mvp.md`. It can be extensive but is organised around features, because the goal is to agree on the MVP features. Open it with an ASCII diagram of how the product is used, in the form that fits the target, never a faux screen for a non-UI product: web, a screen wireframe plus main navigation; cli, a command tree plus one sample session; library, a box per module with its main calls plus a usage call flow; api or service, an endpoint table plus a request and response sequence; pipeline, bot or other, a data-flow diagram. Combine forms when the product needs it. Draw feature ids on the parts they add, so the plan reads as an experience first. Then the goal, the target kind (web, cli, library, api, other), and for each feature: id, title, what the user gets, how it is used, dependencies, size, priority (must/should/could) and an in-or-out recommendation with the reason. List the features considered and left out. Show screens, data and architecture only as far as a feature needs them. Load `superlite:inventing` only for what is unclear. 3. Load `superlite:mvp-prototype` and make ONE self-contained file, `.superlite/mvp/prototype.html` (raw HTML and JS, no build step, no network, fake data): write only the mock fragment `.superlite/mvp/mock.html` in the pattern for the target, then `superlite-cli mvp_check build --plan <mvp.md> --mock .superlite/mvp/mock.html` fills the page template (side panel of features and tasks, Save feedback) and checks it. Then show the page to the user, by whatever means your harness offers (your choice: an in-IDE view, a browser tool, or `superlite-cli mvp_check open` for the default browser); skip that in a headless run. In either orchestrator mode, when `open_in_harness` is on (`superlite-cli agent_specs status`), also open the plan for the user (`superlite:drafting`, After writing), without waiting. Cutting a feature in the panel removes it from the mock. For cli, library and api targets, mock the usage (a terminal session or example calls with sample output). Write no product code in this step. With `--review` in the request, also write `docs/plans/<date>-<topic>.review.md` from the same features; approval still names the `.mvp.md`. 4. Human orchestrator: Show the path and a five-line summary, ask the user to open the page, edit, press Save feedback (`mvp-feedback.json`), and reply approve. END THE TURN. Before approval the hook blocks orchestration only (agents, dispatch, assign, wave0, build_prime, checkpoint, finish), never file writes. AI orchestrator: `superlite-cli mvp_check check --plan <mvp.md>` until ok, then `superlite-cli mvp_check ai --plan <mvp.md>` writes the feedback with `source: ai`; log a Ruling and continue. 5. Human orchestrator: after the approving reply, if you understand the reply as approval, run `superlite-cli orchestrator approve --review docs/plans/<date>-<topic>.mvp.md` first (the MVP plan and the prototype are the review plan), then `superlite-cli mvp_check fetch` and `superlite-cli mvp_check check --plan <mvp.md> --require-feedback`. From here the human is not asked again: a scope change is recorded as `Ruling: [scope] <decision> - <why> - <cost if wrong>`, and `superlite-cli finish` lists it under "Changed from the approved plan". Then read `.superlite/mvp/mvp-feedback.json` and write the agent-format plan as `docs/plans/<date>-<topic>.md` with the header `**Review plan:** docs/plans/<date>-<topic>.mvp.md`: cut features go to "Out of scope", kept features become tasks in the user's order, screens and flows become FROZEN interfaces, fake data becomes EXAMPLE blocks, click paths become CHAINs. Then `lint --stable` and `superlite:swarm`. AI orchestrator: no `approve`. 6. Discard `.superlite/mvp/` at finish, unless the target is web and the feedback says `keep_as_frontend`; then the first producer task converts the page to the plan's framework. 7. Every gate still applies (lint, tests, final review). MVP changes the scope, not the checks. List what was left out in the final report.