Add /speckit.review as a final, constitution-aware quality gate #1323

Introduce a new slash command, /speckit.review, that acts as a final review and quality gate for a feature or project. This command would:

• Validate that the implementation adheres to the project’s constitution (principles and guidelines defined via /speckit.constitution).
• Run a comprehensive quality sweep to detect unused code, duplicate code, obvious code smells, and spec drift.
• Aggregate key checks (tests, linting, coverage, docs, etc.) into a single, human-readable report that can be used before merging / shipping.

Background & Motivation

Spec Kit already provides a structured, multi-step workflow:

• /speckit.constitution – project principles and development guidelines.
• /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement – the core execution flow.
• /speckit.analyze – cross-artifact consistency & coverage analysis.
• /speckit.checklist – custom quality checklists for requirements.

These are great for creating and executing high-quality specs, but there’s currently no single “last mile” command that:

1. Treats the constitution as a binding quality contract, and
2. Performs an opinionated, end-to-end code & project health review right before merge.

A dedicated /speckit.review could serve as the canonical final pass in the Spec-Driven Development flow, especially useful for teams that want predictable quality gates and repeatable standards.

Proposed Behavior: /speckit.review

High-level goal:
Run a final, consolidated review of the current feature or project, verifying:

1. Constitution alignment

• Parse the latest /speckit.constitution and check:
  • Coding standards (naming, patterns, error handling, logging).
  • Testing standards (unit/integration/e2e expectations, coverage thresholds).
  • UX, performance, or accessibility requirements where applicable.
• Highlight specific files/sections where the implementation appears to diverge from these principles.

2. Unused & duplicate code

Identify:

• Unused functions, classes, variables, and modules.
• Dead feature flags / branches where applicable.
• Obvious code duplication across modules (near-duplicate blocks / copy-paste).

Suggest refactors or consolidations with concrete file/line ranges where possible.

3. Spec & plan alignment

Compare:

• /speckit.specify (requirements & user stories).
• /speckit.plan and /speckit.tasks.
• Implemented code (and tests).

Flag:

• Tasks in the plan that appear unimplemented.
• Implemented behaviors not described in the spec (potential scope creep).
• Requirements with no test coverage or incomplete coverage.

4. Quality & hygiene checks

Run or summarize:

• Test status and coverage summary if configured.
• Linting status and key issues.
• Formatting consistency.

Scan for:

• TODO, FIXME, and similar markers, categorized by severity.
• Obvious security issues (e.g., hard-coded secrets, unsafe patterns) when feasible.
• Large or complex files that violate constitution rules (e.g., “functions should be under N lines”).

5. Review report

Output a structured summary, for example:

• Status: ✅ Ready / ⚠️ Needs attention / ❌ Blocked
• Constitution compliance: Summary + key violations
• Spec & plan coverage: What’s missing or over-implemented
• Code health: Unused/duplicate code, major smells
• Tests & coverage: Overall status + notable gaps
• Docs & UX notes (optional): Missing docs or UX constraints violated
• Recommended next steps: Concrete actions to reach “Ready to merge”

Example Usage

/speckit.review