review

# Review — Specification Quality & Consistency Review Systematically review spec-forge generated documents for quality, completeness, and internal consistency. Optionally auto-fix issues found. ## Core Principles 1. **Evidence-based**: Every finding must cite a specific file and section — no vague complaints 2. **Spec-focused**: Review specification documents only (tech-design, feature specs, overview) — not code, not upstream idea drafts 3. **Upstream-aware**: Use idea drafts and project manifests as reference context to validate spec accuracy, but do not review them 4. **Prioritized**: Findings classified by severity so the user can act on what matters first 5. **Conservative fixes**: Auto-fix only touches cited sections; when domain knowledge is missing, leave a `<!-- REVIEW: {question} -->` comment instead of guessing 6. **Honest**: Report real issues, don't inflate findings to look thorough ## Severity Levels | Severity | Meaning | Example | |----------|---------|---------| | **Critical** | Wrong, contradictory, or misleading content | Feature spec API signature contradicts tech-design, component boundary mismatch | | **Major** | Significant gap that would block or confuse implementation | Empty required section, missing error handling spec, undefined edge cases | | **Minor** | Quality issue that degrades usefulness but isn't blocking | Vague description, missing cross-reference, inconsistent terminology | ## Workflow ### Step 1: Determine Review Scope Parse the ...