outlinelisted

# design-doc-review:outline Structural check only — this skill does not touch prose quality (see `design-doc-review:readability` for that). It answers one question per section: **is the topic covered, and covered well enough to make a decision from?** **Target**: {{args}} — a file path, or a doc already in context. ## Framework — Three-Layer Onion Adapted from [[Design Documents]] / `eng-design-review`. A design doc has three layers; a flaw in a lower-numbered layer makes the ones above it moot, so check in this order and stop escalating severity once a layer is broken. **Layer 1 — Problem** - Problem statement: specific, not generic ("latency is bad" vs "p99 write latency exceeds 400ms under X load") - Stakeholders / affected systems named - **Non-goals stated explicitly** — not just "things we won't do" but things that could reasonably be in scope and are deliberately excluded. A doc with goals but no non-goals almost always scope-creeps in review. - Functional and non-functional requirements present (throughput, latency, availability, retention — whatever applies) **Layer 2 — Functional spec** - Describes how the system behaves from the outside, before describing how it's built - Alternatives considered, with a rejection rationale each — not just "we chose X" but "we considered Y and Z, rejected because..." - The functional spec visibly satisfies the Layer 1 requirements (traceable, not asserted) **Layer 3 — Technical spec** - Implementation plan demonstrates feasib