Specs to Plan

Stage 2 of 4. Consumes a spec, its ADRs, and the glossary. Produces one plan. Downstream, plan-to-code executes that plan one task per session.

Announce at start: "Using specs-to-plan to turn this spec into an implementation plan."

Write the plan assuming the implementer has zero context for this codebase and questionable taste. They are a skilled developer who knows almost nothing about this toolset or problem domain, and who does not know good test design. Document everything: which files to touch, the actual code, how to test it, what a pass looks like. DRY. YAGNI. TDD. One commit per task.

1. Find the spec, or refuse

A plan is an argument from a spec. Without one there is nothing to argue from, and inventing requirements is the single worst failure this skill can produce.