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

[PitamberTiwari]

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

[mnriem]

Extensions support is now available. See https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-DEVELOPMENT-GUIDE.md for more information on how to use it. Would love to see this delivered as an extension.

[ismaelJimenez]

Hi @PitamberTiwari. I've built a spec-kit extension called verify that may be relevant here. It's a read-only, post-implementation gate that validates the implementation against spec.md, plan.md, tasks.md, and constitution.md, producing a structured findings report with severity levels and next actions. It stays focused on spec-alignment rather than code-quality concerns like dead code or linting, as these code-quality concerns are tool-specific (ESLint vs Clippy vs Tidy vs Pylint, etc.) and already well-served by dedicated tooling.

As @mnriem suggested, I have just filled a PR (#1726) to add it as a community extension.

[mnriem]

Thanks for the detailed proposal, @PitamberTiwari — and great to see the community interest (28 upvotes!).

Since this was filed, the community has built several extensions that collectively cover the capabilities described here:

• review — Post-implementation comprehensive code review with 7 specialized agents covering code quality, comments, tests, error handling, type design, and simplification
• cleanup — Quality gate that reviews changes, fixes small issues (scout rule), creates tasks for medium issues, and generates analysis for large issues
• verify-tasks — Detects phantom completions: tasks marked done with no real implementation
• docguard — Documentation validation, scoring, and traceability enforcement with automated checks and hooks
• doctor — Project health diagnostics across structure, agents, features, scripts, and git
• speckit-utils — Resume interrupted workflows, validate project health, and verify spec-to-task traceability

Install with:

specify extension add review
specify extension add cleanup

Run specify extension search quality to discover more.

Closing as the community extension ecosystem now provides sufficient coverage for this use case. If you find specific gaps not addressed by the existing extensions, we'd love to see you build an extension to fill them — the Extension Development Guide can help you get started, and then please file an issue to add it to our community extension catalog.