/feature

description: Add or change a feature in an existing codebase. Research, a plan you validate, a prototype you try, then the integration build.
argument-hint: "[the change you want]"

Superlite feature mode. Request: $ARGUMENTS

First, read `${CLAUDE_PLUGIN_ROOT}/assets/flows/feature.txt` (if the variable is not expanded, it is `assets/flows/feature.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/feature-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. Ask the orchestrator choice (human or AI) unless the user already said; run `superlite-cli orchestrator set human|ai`. Check `superlite-cli agent_specs status` (opt-in pre-impl specs; default off). When **on**, load `superlite:writing-specs`: a **spec** is what done looks like and why (durable); a **plan** is how (replaceable). Write `docs/plans/<date>-<topic>.spec.md` before or with the feature plan, and open it in the harness when status shows `open_in_harness: on` (`open_in_harness` covers the spec and the feature plan). Then six steps:

1. **Feature plan.** If the request is thin, ask for the feature in the user's words (at most one batched question, the `superlite:inventing` rule). Write `docs/plans/<date>-<topic>.feature.md` in the shape of `superlite:drafting` ("Feature plan"): goal and who it is for, what the user will see or do differently (screens, commands, endpoints or outputs, by target kind), `## Acceptance checks` a human can try. When agent_specs is on, acceptance checks must match the feature `.spec.md` (spec wins if they drift). Add "Run the whole test suite at finish?" (`No, affected tests only (Recommended)` / `Yes, once at finish`) to that same batch. 2. **Research the code.** Read before designing; research is read-only, as parallel Explore agents, one per area, each returning a short summary. Offer Graphify only if `superlite-cli graphify_gate` allows, and never install it without the user's yes. Add to the plan the `## Code map` (entry points and how the app is stood up, the files and tests the feature touches and their seams, the interfaces that must not change, the project's own conventions and toolchain; for a web UI, the repo's UI component set, or the fact that there is none), the prototype scope and an outline of the integration build. Then run the `superlite:inventing` **Grill** on that completed plan (up to 2 rounds): record `## Decisions` and edit the plan sections it changes in place. 3. **The human validates the plan.** Human mode: when `open_in_harness` is on (`superlite-cli agent_specs status`), open the plan for the user first (`superlite:drafting`, After writing). Then show the path and a five-line summary, ask in plain text "Reply approve to start, or tell me what to change", end your turn; after the reply, if you understand it as approval, run `superlite-cli orchestrator approve --review docs/plans/<date>-<topic>.feature.md`. Do not pass their words through. AI mode: when `open_in_harness` is on (`superlite-cli agent_specs status`), open the `.feature.md` after research (`superlite:drafting`, After writing) and do not wait; no approval; open choices become `Ruling:` lines. 4. **Prototype build.** `superlite-cli proto start --topic <topic> --run "<run command>" [--level L2]` makes the sandbox folder `.superlite/sandboxes/<session>/<topic>/` (`host` without a session) inside the checkout: no worktree and no branch, and the user's tracked files are never touched. Load `superlite:feature-prototype` to cut the smallest container of the app (keep the entry point and what the feature touches, stub the rest; for a web UI, keep the repo's UI component set and compose the new screen from it, and use one-off markup only when the code map says there is no UI component set; L1 stubs by default, L2 only when the plan says real data shapes matter). Write a small agent-format plan in the sandbox (`<sandbox>/docs/plans/<date>-<topic>.proto.md`, every `Owns` path inside the sandbox, at most 8 tasks, about a quarter of the integration estimate), its tests written against the acceptance checks and run by path (`superlite-cli run_tests --fast <sandbox>/tests`), then `lint --stable` and `superlite:swarm` on it. While it builds, draft the integration plan from the code map. 5. **The human tries it.** `superlite-cli proto tryout [--reach "<url, command or example calls>"] [--start]` prints how to run and reach the prototype and the acceptance checks; show it where the harness can (a preview pane for a web app). Human mode: ask the human, in plain text, to reply "it works" or list changes, end your turn; after the reply run `superlite-cli proto tryout --approve`. Changes go back to step 4 as a fix round (`superlite-cli proto start --topic <topic>` reopens it), not to a new plan unless they change the scope. AI mode: run the acceptance checks against the stood-up prototype and record the result with `superlite-cli proto tryout --approve --