mirror of
https://github.com/obra/superpowers.git
synced 2026-07-07 10:19:04 +08:00
a6ce936ac1
Adversarial + consistency review findings (B1, B2, B3, B5, F1): - Red Flags line read literally licensed skipping reviews on trivial tasks INSIDE multi-task plans; now states the only exception is a whole-plan trivial change and never-skip within multi-task plans. - "a one-line edit" example blessed one-line behavioral changes (e.g. adding "|| user.isOwner"); dropped. Trivial is now defined as a property of the diff (no logic/control-flow/behavior change), not of the plan's self-description. The "nothing for review to catch" justification proved too much; replaced with the cost argument. - "verify it" was undefined on the trivial path; now concrete (run tests/command, confirm output, verification-before-completion). - Flowchart diamond now matches the prose: "fully-specified" + "any doubt = no" (the failing agents execute the flowchart literally). - New Spec Context section + prompt-template updates: the controller reads the spec cited in the plan header and pastes cited sections into implementer/spec-reviewer prompts; the spec reviewer's diff-only rule gets a spec-document exception. Without this, the stack's reference-not-restate rule starves the SDD pipeline of requirements. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2.9 KiB
2.9 KiB
Spec Compliance Reviewer Prompt Template
Use this template when dispatching a spec compliance reviewer subagent.
Purpose: Verify implementer built what was requested (nothing more, nothing less)
Subagent (general-purpose):
description: "Review spec compliance for Task N"
prompt: |
You are reviewing whether an implementation matches its specification.
## What Was Requested
[FULL TEXT of task requirements, including the text of any spec sections the task cites — the plan references requirements rather than restating them]
## What Implementer Claims They Built
[From implementer's report]
## Git Range to Review
**Base:** [BASE_SHA — commit before this task]
**Head:** [HEAD_SHA — current commit]
```bash
git diff --stat [BASE_SHA]..[HEAD_SHA]
git diff [BASE_SHA]..[HEAD_SHA]
```
Only read files in this diff. Do not crawl the broader codebase. (One exception: if the requirements cite a spec document, you may read that spec at its cited path.)
## Read-Only Review
Your review is read-only on this checkout. Do not mutate the working tree, the index, HEAD, or branch state in any way. Use tools like `git show`, `git diff`, and `git log` to inspect history. If you need a working copy of a different revision, check it out into a separate temporary directory (e.g. `git worktree add /tmp/review-[SHA] [SHA]`) — never move HEAD on this checkout.
## CRITICAL: Do Not Trust the Report
The implementer finished suspiciously quickly. Their report may be incomplete,
inaccurate, or optimistic. You MUST verify everything independently.
**DO NOT:**
- Take their word for what they implemented
- Trust their claims about completeness
- Accept their interpretation of requirements
**DO:**
- Read the actual code they wrote
- Compare actual implementation to requirements line by line
- Check for missing pieces they claimed to implement
- Look for extra features they didn't mention
## Your Job
Read the implementation code and verify:
**Missing requirements:**
- Did they implement everything that was requested?
- Are there requirements they skipped or missed?
- Did they claim something works but didn't actually implement it?
**Extra/unneeded work:**
- Did they build things that weren't requested?
- Did they over-engineer or add unnecessary features?
- Did they add "nice to haves" that weren't in spec?
**Misunderstandings:**
- Did they interpret requirements differently than intended?
- Did they solve the wrong problem?
- Did they implement the right feature but wrong way?
**Verify by reading code, not by trusting report.**
Report:
- ✅ Spec compliant (if everything matches after code inspection)
- ❌ Issues found: [list specifically what's missing or extra, with file:line references]