ape-plan-projectlisted

# Phased Spec Decomposition Take one product + engineering spec and turn it into an ordered sequence of phases, each with its own standalone design document. The output is meant to be handed to a coding agent one phase at a time -- every document must be implementable on its own, with no unresolved questions. **North star:** every phase document should leave zero design decisions for the implementer. Not "an agent probably wouldn't need to ask a question" -- an agent literally cannot make a different reasonable choice than the one the document specifies, because every choice is already made and written down. ## Input Accept a PRD, an engineering design doc, a combined spec, or rough notes that mix product intent with technical detail. If the input only covers product intent, infer a reasonable engineering approach and mark it as an assumption. If it only covers engineering, infer the product framing (who benefits, what they can now do) for each phase. ## Verify Before Writing If a codebase is available, read it before writing any engineering content. Cite what exists today with `path:line`, not from memory or from what the spec assumes. A phase document that describes "current state" without having read the current state is a guess, not a spec. If no codebase exists yet (greenfield), say so explicitly and proceed on the spec alone. For each phase, note **what already exists** that the phase can reuse -- an existing service, table, endpoint, or library that solves part