readabilitylisted

# design-doc-review:readability Prose-quality check only — this skill does not evaluate whether the right topics are covered (see `design-doc-review:outline` for that). It answers: **can a reviewer extract the decision and its risk from this text without excess effort?** **Target**: {{args}} — a file path, or a doc already in context. ## Framework Adapted from `docs:review-clarity` (cognitive-load theory / decision-focused writing), narrowed to design docs specifically and reconciled with the Proportionality rule in CLAUDE.md — **this check must not penalize a doc for putting rigor where it belongs.** ### The Three Questions 1. **Decision Focus** — what decision is the reader being asked to make? 2. **Obstacle Identification** — what would stop them making it confidently? 3. **Minimum Viable Information** — is that, and only that, in the main body? ### What to flag in the MAIN BODY - **Buried decision/ask** — the thing the reader must decide is not in the first third of the doc, or is stated as narrative rather than named as a decision (compare to the "Decision requested" pattern: numbered asks, one owner, one default-if-silent, each per row) - **Filler and hedge padding** — "very", "basically", "in order to", "it should be noted that", "due to the fact that" — cut-and-replace, not a style nit - **Show-my-work** — investigation narrative left in the main body where a conclusion would do. (Exception: if the doc's own convention — e.g. an evidence/appendix split — alrea