design-doclisted

# design-doc — How it is built, and what was decided Bridges the PRD's capabilities to the code's structure. Two mechanical outputs, and the skill is not finished until both exist: - **`.steering/structure.md`** — where code belongs. Every later spec uses it to name affected files, and the reviewer uses it to judge whether a change landed in the right place. - **ADRs** — one per decision that was genuinely contested. The reviewer's reconciliation clause escalates *to* an ADR when its rulebook and the repo conflict; without ADRs that clause points at nothing. ## Where it goes `<docs>/DESIGN.md`, with one file per decision under `<docs>/decisions/ADR-<n>-<slug>.md` — and `.steering/structure.md` written from it. `<docs>` is the `- Docs:` line in `.steering/tech.md`, which defaults to `docs/`. In a multi-repo product it points at the shared documentation repository instead, so product-level truth has one home rather than one per repo. ## Steps 1. **Read the PRD.** The design serves capabilities. A component serving no capability is either infrastructure that should say so, or scope that arrived without being agreed. 2. **Draw the components and the seams between them.** The seams matter more than the boxes: a seam is where two parts must agree, and every integration failure lives at one. 3. **For each seam, say what crosses it** — the shape of the data, who produces it, who consumes it, and what happens when they disagree about the shape. In a multi-repo product, give the