design-review

# /design-review — catch it while it is still cheap Code review finds defects in an implementation. It cannot find that the implementation should never have been built this way. By the time a diff exists, the expensive decisions — the migration strategy, the contract shape, the deploy order — are already made, and the review that follows is scoped to whether they were executed correctly. This skill reviews the decisions themselves. **This skill never writes code and never edits the plan.** It reports findings. Revising the plan is a separate act, done deliberately. ## Preconditions | Condition | If unmet | |---|---| | A plan, spec, or design document is identified | **Stop.** Ask which document to review. Never review an imagined plan. | | The document describes changes to a codebase you can read | Continue, but say in 🔎 that you could not ground the claims in code | ## Position in the workflow | Upstream | This skill | Downstream | |---|---|---| | `/grill-me`, `/writing-plans`, `/brainstorming` | `/design-review` | revise the plan, then `/executing-plans` | ## Files to read ### Always read | File | Why | |---|---| | the plan or spec under review | the subject | | `${CLAUDE_SKILL_DIR}/reference/finding-discipline.md` | posture and reporting rules; passed to every subagent | | `${CLAUDE_SKILL_DIR}/reference/design-checklist.md` | the review dimensions | ### Read only if | File | Trigger condition | |---|---| | `${CLAUDE_SKILL_DIR}/reference/report-format.md` | whe...