spec-driven-developmentlisted

# Spec-Driven Development with Reconciliation Author an ordered design chain — BRIEF → RESEARCH → SPECS → DESIGN → TASKS — before or alongside writing implementation code, then keep those specs reconciled onto the code that actually shipped. The chain is not ceremony: each phase feeds the next, and the specs stay alive as versioned artifacts after launch. ## When to use Reach for this when: - You are starting a non-trivial feature, service, or project — anything beyond a one-file change. - Docs and code have drifted, and you no longer trust the design docs to describe what runs. - A workstream is large enough that "what it should do" and "how it does it" deserve separate scrutiny. Red-flag thoughts that mean STOP and apply this skill: - "I'll just start coding and write up the design after — I already know what to build." - "The spec is basically right, no need to update it for this change." - "What and how are the same thing here, one doc is enough." - "We settled that in review already, but let me reopen it now that I'm building." - "That open question is stale, I'll just delete it." ## The rule 1. **Write the chain in order, before implementation code.** Produce BRIEF (the problem and goal) → RESEARCH (what exists, constraints, options) → SPECS (the *what*: requirements, behaviors, acceptance criteria) → DESIGN (the *how*: architecture, mechanism, trade-offs) → TASKS (the implementation plan derived from SPECS + DESIGN). State explicitly how each phase consumes the