Workflow

One route, eight phases. The question this answers: what do I do next, and how do I know this phase is finished?

Phases are ordered. Skip one only when it has genuinely nothing to do — not because it feels slow.

Full per-phase detail, including the exit questions and the failure each phase prevents: PHASES.md.

The rules that make the route hold

1. Never guess a specification. Underspecified scope, criteria, naming, or surface is a Phase 1 trigger, not a licence to pick a plausible default. Ask the questions; an assumption nobody confirmed is not a decision.
2. Facts are the agent's job; decisions are the user's. Look up what the code says. Ask what the human wants.
3. Plan before the work. A scope or approach change lands in writing before the work that implements it — code, prose, or a restructure.
4. Proof before "done". Every completion claim names the layer it was verified at — see skill verify-change.
5. Retro is manual, and proposes only. Phase 8 runs on the user's request — never automatically at the end of a task, a session, or a worktree teardown. The session that made the mistakes cannot accept the lessons either: findings go to the user, who decides.
6. Know where the work lands before you start it. Branch topology is decided once per repo — which branch mirrors production, which mirrors staging, which exists only for prose — and every task then runs on a working branch cut from the one it targets. Never author on a permanent branch: the edit is valid code in the wrong place, and nothing catches it. The topology, the questions to ask the user, and the way to explain why a permanent branch exists at all are in BRANCHES.md.

Which skill runs at each phase

This table is a router, not a dependency. With none of the right-hand skills installed, the route still runs. What you lose is the packaging, not the discipline.

Routing by situation

The eight phases are the default. Three other shapes are legitimate:

• Something is broken → skip to a diagnosis loop: one command that goes red on this bug, then fix, then a regression test. Do not theorise until the loop exists. Rejoin at Phase 6.
• The way forward is not visible (greenfield, foggy, too big for one session) → decide first, build later. Resolve the open questions one at a time, record each as a decision, then rejoin at Phase 3.
• A one-line fix with an obvious answer → Phases 1–4 collapse into one sentence in your reply. Run 5–7. Say which phases you skipped and why.

Context hygiene

Keep Phases 1–3 in one unbroken context window — the sharpening, spec, and tickets build on the same thinking. Each Build run then starts fresh from its ticket.

At a phase boundary, you have five options, in this order of preference: continue (costs nothing), clear (context is disposable), hand off (something must travel: new harness, directory, or person), subagent (work can run AFK), compact (relevant context, same harness, and you must stay in the loop). Compact is the default, not the first reach.

The failure mode is compacting mid-phase: the summary flattens a decision, and the next session is confidently wrong about it.

When to skip the route entirely

• A question with a factual answer. Answer it.
• A README typo. Fix it.
• The user asked for one specific edit. Do that edit.

Declaring eight phases for a one-line change is the same failure as shipping without them — the process stops meaning anything.

Related

• Every phase's exit criteria and failure mode → PHASES.md
• Which branches are permanent, and where a task runs → BRANCHES.md
• Proving a phase's output → skill verify-change
• Where decisions and rules get written down → skill agent-rules
• Bootstrapping the layer a repo needs first → skill repo-init