feat: add /speckit.critique command — dual-lens strategic & technical review

[arunt14]

Description

Problem

Spec-Kit currently has no mechanism to challenge a specification or plan before committing to implementation. The existing /speckit.analyze command checks cross-artifact consistency (spec ↔ plan ↔ tasks), but it does not question whether the right problem is being solved or whether the technical approach is sound. This means teams can invest significant effort implementing a well-structured but fundamentally flawed plan — discovering strategic misalignment or architectural risks only after code is written.

Industry context: Garry Tan (Y Combinator President) demonstrated with GStack that separating product review (/plan-ceo-review) from engineering review (/plan-eng-review) catches blind spots that a single-pass review misses. This PR brings that same dual-lens discipline to Spec Kit.

Solution

Adds /speckit.critique — a new core command that performs a structured critical review of spec.md and plan.md through two distinct expert lenses before implementation begins:

Product Lens (CEO/Product Lead perspective):

• Problem validation — is this solving a real user pain point?
• User value assessment — does every user story deliver tangible value?
• Alternative approaches — could a simpler solution achieve 80% of the value?
• Edge cases & UX — error states, accessibility, discoverability
• Success measurement — are criteria measurable and time-bound?

Engineering Lens (Staff Engineer perspective):

• Architecture soundness — patterns, boundaries, testability
• Failure mode analysis — degradation strategies, blast radius, retry/circuit-breaker patterns
• Security & privacy — threat model, trust boundaries, compliance implications
• Performance & scalability — bottlenecks, caching strategies, data volume projections
• Testing strategy — coverage planning, testability concerns, test data strategy
• Operational readiness — observability, alerting, rollback, deployment strategy
• Dependencies & integration risks — third-party stability, API versioning

Output: Structured critique report with severity classification (🎯 Must-Address / 💡 Recommendation / 🤔 Question) and verdict (PROCEED / PROCEED WITH UPDATES / RETHINK).

Business Value

• Reduces costly mid-implementation pivots by catching strategic and technical blind spots before a single line of code is written
• Closes the gap between analyze (consistency) and implement (execution) — critique validates direction, not just consistency
• Completes the pre-implementation workflow: constitution → specify → plan → critique → tasks → implement
• Aligns with GStack's proven model that has demonstrated 10K+ LOC/day productivity by enforcing review discipline at every phase

Workflow Position

/speckit.constitution → /speckit.specify → /speckit.plan → /speckit.critique ⭐ → /speckit.tasks → /speckit.implement

Files Added

File	Purpose
templates/commands/critique.md	Command template with YAML frontmatter, prerequisite scripts, extension hooks (before_critique, after_critique)
templates/critique-template.md	Structured output report template

Testing

• Tested locally with uv run specify --help
• Ran existing tests with uv sync && uv run pytest — 878/972 pass (44 failures are pre-existing, unrelated to this change)
• Verified YAML frontmatter is valid and parseable
• Verified command file is auto-discovered by specify init through the existing templates/commands/ discovery mechanism
• Confirmed no changes to Python source code — template-only addition

AI Disclosure

• AI assistance was used in this PR
• How: GitHub Copilot CLI (Claude) was used to draft the command template and output template content, following the existing patterns established by implement.md and analyze.md. All content was reviewed and validated against the project's template conventions.

---

Note: Happy to discuss the scope and approach with maintainers. This is one of five related-but-independent PRs that add post-plan and post-implementation lifecycle commands inspired by GStack's role-based development workflow.

[Copilot]

Pull request overview

Adds a new /speckit.critique command template and a corresponding critique report template to introduce a pre-implementation, dual-lens (product + engineering) review step in the Spec-Driven Development workflow.

Changes:

• Added templates/commands/critique.md defining the critique command workflow (including extension hooks).
• Added templates/critique-template.md as the structured output format for critique reports.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
templates/commands/critique.md	New command template describing how to run and structure the dual-lens critique workflow.
templates/critique-template.md	New markdown template for the critique report saved under FEATURE_DIR/critiques/.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The frontmatter prerequisite script currently uses --require-tasks, which will hard-fail unless tasks.md already exists. This contradicts the intended workflow position of /speckit.critique (before /speckit.tasks) and makes the command unusable at the right time. Drop --require-tasks (keep --include-tasks if you want tasks.md listed when present).

Suggested change

	sh: scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
	ps: scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
	sh: scripts/bash/check-prerequisites.sh --json --include-tasks
	ps: scripts/powershell/check-prerequisites.ps1 -Json -IncludeTasks

[Copilot]

The "STRICTLY READ-ONLY" constraint says not to modify spec.md, plan.md, or any other files, but the outline later requires writing FEATURE_DIR/critiques/critique-{timestamp}.md and (optionally) applying approved edits to spec/plan. Please clarify the constraint wording (e.g., read-only for existing artifacts; creating the critique report is allowed; spec/plan edits only after explicit user approval).

Suggested change

**STRICTLY READ-ONLY**: Do **not** modify `spec.md`, `plan.md`, or any other files. Output a structured critique report. Offer to apply approved changes only after the user reviews findings.

**STRICTLY READ-ONLY FOR EXISTING ARTIFACTS**: During this command, do **not** directly modify existing project files such as `spec.md`, `plan.md`, or other source/docs. You **may** create a new critique report under `FEATURE_DIR/critiques/critique-{timestamp}.md`. Propose, but do not apply, edits to `spec.md`/`plan.md`; applying any changes requires explicit user approval in a follow-up step or command after the user reviews the findings.

[Copilot]

In step 7, the instructions don't mention ensuring FEATURE_DIR/critiques/ exists before writing the report, so the workflow can fail on first run. Also "using the critique report template" is ambiguous—other commands reference the canonical template path (e.g., templates/tasks-template.md); consider explicitly pointing to templates/critique-template.md as the required structure source.

Suggested change

	Create the critique report at `FEATURE_DIR/critiques/critique-{timestamp}.md` using the critique report template. The report must include:
	Ensure the directory `FEATURE_DIR/critiques/` exists (create it if necessary), then create the critique report at `FEATURE_DIR/critiques/critique-{timestamp}.md` using `templates/critique-template.md` as the required structure. The report must include:

[Copilot]

The command template requires a consolidated "Findings Summary Table" listing all items with ID/lens/severity/category/finding/suggestion, but critique-template.md only has a metrics/count summary plus per-section tables. Add the consolidated findings table section (matching the format described in /templates/commands/critique.md) or relax the command requirements so the template and command stay in sync.

Suggested change

	### Consolidated Findings Table
	| ID | Lens | Severity | Category | Finding | Suggestion |
	|----|------|----------|----------|---------|------------|
	| [ID] | [Product / Engineering / Cross-lens] | 🎯/💡/🤔 | [category] | [finding] | [suggestion] |

[mnriem]

Please deliver this as an extension. See https://github.com/github/spec-kit/tree/main/extensions

[arunt14]

Thanks for the review! All 4 comments addressed in the latest push:

1. Prerequisite script: Dropped --require-tasks (kept --include-tasks). Critique runs after /speckit.plan but before /speckit.tasks, so requiring tasks.md would make the command unusable at the right time.
2. READ-ONLY constraint: Clarified to STRICTLY READ-ONLY FOR EXISTING ARTIFACTS — existing files (spec.md, plan.md, etc.) are not modified, but creating the new critique report is explicitly allowed. Spec/plan edits are proposed only and require explicit user approval in a follow-up.
3. Step 7 template reference: Now ensures FEATURE_DIR/critiques/ directory exists and explicitly references templates/critique-template.md as the required structure source.
4. Consolidated findings table: Added the full consolidated findings table section to critique-template.md with ID/Lens/Severity/Category/Finding/Suggestion columns, matching the command template's requirements.

[mnriem]

Please review https://github.com/github/spec-kit/blob/main/extensions/EXTENSION-PUBLISHING-GUIDE.md for publishing a community hosted extension

[arunt14]

Thanks @mnriem! I've reviewed the Extension Publishing Guide. Will restructure this as a community extension following the extension.yml manifest pattern and resubmit as an extension contribution to catalog.community.json.

[arunt14]

Closing in favor of PR #2049 — restructured as a community extension per maintainer feedback. Extension repo and v1.0.0 release are available.