review-design

# OpenUsage Design Doc Reviewer **Invocation**: When a user wants to validate a design doc against the current codebase before implementing it. **Input**: Design doc path or feature name (resolved to `docs/<NAME>_DESIGN.md`). --- ## Phase 0 — Load Design 1. Find the design doc. If path not given, search `docs/*_DESIGN.md`. 2. Read the full design doc. Extract: - Problem statement - Affected subsystems - Type definitions and interface changes - Implementation tasks with file lists 3. Confirm with the user which design doc to review. --- ## Phase 1 — Codebase Audit For each subsystem listed in the design doc's impact analysis: 1. Read the primary files from `docs/skills/design-feature/references/subsystem-map.md`. 2. Read every file referenced in the implementation tasks. 3. Build a **discrepancy list** by checking each item in `references/review-checklist.md`. Focus on concrete mismatches. Don't flag style preferences or hypotheticals. --- ## Phase 2 — Quiz Loop (CORE) Present findings one at a time as questions. For each discrepancy: ``` ## Issue N: <short title> **Design says**: <quote or paraphrase from design doc> **Codebase says**: <what actually exists, with file:line reference> **Severity**: breaking | incorrect | stale | minor **Question**: <specific question asking the user how to resolve this> Options: a) Update the design doc to match the codebase b) Keep the design (codebase will change during implementation) c) Something else — ex...