incremental-build

The developer builds in baby steps: agile, not waterfall. Scope is already settled — it lives in the brief, the discussion above, or whatever the developer points you at. Do not re-open scoping and do not interview the developer. No grilling.

Adopt the following posture for the whole implementation and hold it until the developer releases you from it.

The rules

1. High-level plan only. Show which modules you will touch, the rough architecture, and how the modules talk to each other. Do not define types, classes, interfaces, or data shapes up front. Do not create a "types" or "contracts" phase. A shape defined before the code that needs it is waterfall in miniature.
2. Vertical slices, not horizontal layers. Lay out the work as a sequence of thin slices. Each slice cuts through every layer it needs, compiles, and runs on its own, producing something the developer can launch and observe. A slice is never "the types" or "the service layer" or "the UI" — it is "this one behaviour, end to end, minimally". Do not build the pieces separately and integrate them at the end.
3. Shapes arrive when needed. Introduce a type, class, or interface only inside the slice whose code first needs it, and only as much of it as that slice needs. When a later slice needs more, grow the shape then. Never design the full shape in advance.
4. One slice at a time. Build one slice, run it, see what happens, and only then decide the next. Do not rush ahead with the details of later slices. The plan can change once the first slice runs.
5. Stop and let the developer look. After each slice, stop so the developer can launch and review it. Do not begin the next slice until the developer says to continue. If a slice turns out bigger than expected, stop and say so — do not silently absorb the extra work into the current slice.
6. The developer owns the code. The developer may take the keyboard at any time. If the developer says "I am driving", show the code in the chat and explain what to do; do not write to files until told. If they want you to stop volunteering the next step and act as a reference desk only while they build, that is /practice-mode — invoke it and this slice rhythm still holds.

How to start

Show the high-level plan and the ordered list of slices — for each, a title and what runs at the end of it. Then offer the optional progress plan below (one short question), and stop. The developer says which slice to begin.

Optional: a high-level progress plan

After presenting the slice list, ask once whether to write a small plan file (for example PLAN.md at the project root) that tracks high-level progress, so a later session can resume without re-deriving context.

(Recommended for work that will span more than one session; skip it for a small change that finishes in one sitting. A plain "no" skips it.)

If the developer accepts, write the file with only high-level content, so it stays valid as the code changes. It is a journal, not a specification — never put types, class names, function signatures, or code shapes in it. Suggested sections:

• Goal — what the work achieves, in prose.
• Chosen design — the architecture at module altitude, and the alternatives rejected and why (one line each). Optional for small work.
• Working principle — a reminder that the build is vertical slices, not horizontal layers; shapes are born in the slice that first needs them.
• Slices — one entry per slice, each with a status marker and a one-line "verify" (what runs when it is done). Use the legend [ ] not started · [~] in progress · [x] done.
• Decisions deferred to their slice — open choices, each tagged with the slice that will settle it and a proposed default. Do not resolve them early.
• Current status — the last line: what is done and the single next action. This is what a resumed session reads first.

Maintenance rule: as each slice lands, flip its status marker and update the Current status line. Do not rewrite the plan or add code-level detail to it — if you find yourself editing the plan on every code change, it has become too low-level. Keep it at the altitude where the first code change cannot make it obsolete.

What this skill is not

• Not a heavyweight planner. The slice list lives in the conversation; the only file it may produce is the opt-in high-level plan above, and only if the developer asks for it.
• Not a state machine. There is no fixed-shape report, no per-turn protocol, no filename convention beyond the single optional plan file. The discipline is the posture, nothing more.
• Not a scoping session. If scope is genuinely unclear, say so and point the developer at /brief-chat or /grill-me — do not start interviewing.