| name | spec-critique |
| description | Self-critique specification documents using extended thinking — surfaces hidden assumptions, contradictions, missing edge cases, and scope creep before implementation |
| version | 1.0.0 |
| model | opus |
| extended_thinking | true |
| invoked_by | both |
| user_invocable | true |
| tools | ["Read","Write","Edit","Glob","Grep"] |
| agents | ["planner","architect","developer"] |
| category | Planning & Architecture |
| tags | ["spec","critique","validation","requirements","extended-thinking","review"] |
| verified | true |
| lastVerifiedAt | "2026-02-22T08:50:52.090Z" |
| best_practices | ["Use extended thinking for deep analysis","Compare spec against requirements and research","Fix issues directly, don't just report"] |
| error_handling | graceful |
| streaming | supported |
| source | builtin |
| trust_score | 100 |
| provenance_sha | ae8aa9a72a7360f5 |
Specification Critique Skill
Overview
Critically review specification documents for accuracy, completeness, and feasibility. Use extended thinking to find issues BEFORE implementation begins.
Core principle: Use extended thinking (deep analysis). Find problems BEFORE implementation.
When to Use
Always:
- After spec writing is complete
- Before implementation planning begins
- When spec involves external integrations
- For complex features with multiple components
Exceptions:
- Simple specs for trivial changes
- Specs already reviewed by another agent
The Iron Law
NO IMPLEMENTATION WITHOUT SPEC CRITIQUE FOR COMPLEX TASKS
Complex tasks (external integrations, multi-service changes) must have spec critique.
Inputs Required
Before critiquing, ensure you have:
- spec.md - The specification to critique
- Requirements document - Original user requirements
- Project context - Tech stack, patterns
Workflow
Phase 1: Load All Context
cat .claude/context/specs/[task-name]-spec.md
cat .claude/context/requirements/[task-name].md
cat .claude/context/tech-stack.md
Understand:
- What the spec claims
- What the user originally requested
- What patterns exist in the codebase
Phase 2: Deep Analysis (USE EXTENDED THINKING)
CRITICAL: Use extended thinking for this phase. Think deeply about:
Technical Accuracy
Compare spec against requirements and codebase:
- Package names: Does spec use correct package names?
- Import statements: Do imports match API patterns?
- API calls: Do function signatures match documentation?
- Configuration: Are env vars and config options correct?
Check for common spec errors:
