speckit-superb-review
Verify the generated tasks.md covers every requirement in spec.md before implementation begins. Produces a spec-coverage matrix and a gap report. Catches missing or under-specified tasks at planning t
SKILL.md.claude/skills/speckit-superb-review/SKILL.md
GitHubTask Coverage Review — After Task Generation
Invocation: Optional post-hook for
speckit.tasks. Fires aftertasks.mdis generated. Purpose: Prevent "all tasks done, feature incomplete" — the most expensive form of rework.
Why This Matters
tasks.md is generated from plan.md and spec.md, but it is a mechanical
transformation. Requirements can fall through the cracks when:
- A user story has implied behaviors that were not written down
- Edge cases in
spec.mdwere noted but not translated into tasks - A data-model constraint was discussed in
research.mdbut never became a task - Task granularity is uneven — one task does too much and hides incomplete coverage
This review catches all of these before a single line of code is written.
User Context
$ARGUMENTS
Process — Execute in Order
Step 1 — Load Artifacts
Read the following files (all from the current feature directory):
spec.md— the authoritative source of requirementsplan.md— the technical approach and architecture decisionstasks.md— the generated implementation plandata-model.md(if exists) — entity and relationship constraintscontracts/(if exists) — interface contracts
If spec.md is missing, STOP and report:
ERROR: spec.md not found. Cannot perform coverage review without the spec.
Run speckit.specify first.
Step 2 — Extract Requirements from spec.md
Produce a numbered list of every distinct, testable requirement from spec.md:
Format:
R01: [requirement — one sentence, action-oriented]
R02: [requirement]
...
Include:
- Every user story acceptance criterion
- Every constraint mentioned ("must not", "shall not", "required")
- Every non-functional requirement (performance, security, compatibility)
- Every error/edge case described
Mark each requirement as:
[TESTABLE]— can be verified by a test[OBSERVABLE]— can be verified by running the feature[STRUCTURAL]— architectural constraint (no direct test, but verifiable via code review)
Step 3 — Map Requirements to Tasks
For each requirement R-XX, find which task(s) in tasks.md implement it.
Produce the coverage matrix:
| Req | Requirement | Tasks | Coverage |
|------|--------------------------------------|-----------|------------|
| R01 | User can log in with email+password | T3, T4 | ✓ Covered |
| R02 | Failed login shows error message | T4 | ✓ Covered |
| R03 | Passwords are stored hashed (bcrypt) | — | ✗ Gap |
| R04 | Session expires after 24 hours | — | ✗ Gap |
| R05 | Supports OAuth2 login | T7 | ~ Partial |
Coverage status:
✓ Covered— at least one task explicitly addresses this requirement~ Partial— a task addresses part of this requirement but leaves sub-requirements open✗ Gap— no task addresses this requirement
Step 4 — Produce Gap Report
For every ✗ Gap or ~ Partial:
## Coverage Gaps
### Gap: R03 — Passwords are stored hashed (bcrypt)
**Requirement:** spec.md, Section 2.3 — "Passwords must be stored using bcrypt
with a minimum work factor of 12"
**Missing task:** No task in tasks.md creates or verifies password hashing logic.
**Suggested task addition:**
> Task N+1: Write test asserting stored password hash matches bcrypt format with
> work factor ≥ 12. Implement bcrypt hashing in the auth service. Verify
> no plaintext passwords appear in logs or database.
---
### Gap: R04 — Session expires after 24 hours
**Requirement:** spec.md, Section 2.5 — "Sessions must be invalidated after 24 hours"
**Missing task:** Session expiry logic has no corresponding test task.
**Suggested task addition:**
> Task N+2: Write test asserting session token is rejected after 24 hours.
> Implement expiry check in session middleware.
Step 5 — Check Task Quality
Beyond coverage, flag any task that has these quality issues:
| Quality Issue | Example | Flag |
|---|---|---|
| No test step | Task says "implement X" but has no "write failing test" step | ⚠ Missing TDD step |
| Vague file path | "Update the auth module" with no specific file | ⚠ Missing file path |
| Placeholder content | Task says "fill in details later" or "add appropriate handling" — open-ended directives with no concrete action | ⚠ Placeholder detected |
| Multiple behaviors in one task | Task covers login AND logout AND session | ⚠ Overly broad |
| No commit step | Task has no git commit at end |
⚠ Missing commit step |
Step 6 — Summary and Decision
Produce a summary:
## Coverage Review Summary
**Requirements extracted:** [N]
**Fully covered:** [A] ([A/N]%)
**Partially covered:** [B]
**Gaps identified:** [C]
**Task quality issues:** [D]
**Decision:**
If C > 0 (gaps exist):
⚠ GAPS DETECTED — Implementation should not begin until gaps are addressed.
Recommended action:
1. Review each gap above
2. Add missing tasks to tasks.md
3. Re-run coverage review OR proceed with explicit acknowledgment of scope reduction
If C == 0 and D == 0:
✓ COVERAGE COMPLETE — All requirements have corresponding tasks.
tasks.md is ready for implementation.
If C == 0 but D > 0:
⚠ QUALITY ISSUES — Coverage is complete but task quality issues may cause
TDD violations during implementation.
Recommended action: Fix flagged tasks before running speckit.implement.
Non-blocking Mode
If the user explicitly ran this review after acknowledging gaps, note the acknowledged gaps and proceed:
NOTE: [N] gaps were identified and flagged. Proceeding to implementation
with explicit acknowledgment. Gaps should be tracked as follow-on work.