Spec

Three jobs, one stage, in order of invocation:

Spec — capture WHAT/WHY before planning: user stories, acceptance criteria, [NEEDS CLARIFICATION] markers, seam sketch. No tech stack.
Plan — write an actionable implementation plan consuming the spec: bite-sized tasks, exact paths, interfaces, the test cases each task must pass, complete production code where the HOW isn't obvious, no placeholders.
Tickets — slice a settled spec or plan into tracer-bullet tickets with blocking edges (see references/ticket-slicing.md).

Do the job the user invoked — specifying only, or planning only. The grill stage hardens the plan first if decisions are unresolved.

By complexity (orchestrator/references/risk-routing.md): S0 skips this stage. S1 skips the spec turn — the plan header carries an assumptions line and 3-6 acceptance criteria written as step → verify: check (format in orchestrator/references/coding-principles.md § Plan format for S0/S1), and the plan is one task. S2/S3 run all turns. Review depth (the risk-derived T-tier) does not select spec turns: an S3/R1 change still gets the full spec with T1 review.

Test cases, not test code. For each task the plan names its test cases: behavior, seam (with its seam note), inputs, expected value and where that value comes from. The test-evals stage writes the test code and runs it RED; the build implementer makes it GREEN.

When to Use

User says "write a spec for X", "plan X", "plan mode", "break this into tickets", "slice this up", "create tickets", "what are the work units"
Starting a non-trivial build from scratch — pin intent first; or a spec exists and you need the HOW
The work would lose track in one context window, or you want parallelizable work units with dependency edges