spec-reviewer
starsforks
How to install spec-reviewer?
futuregerald/futuregerald-claude-plugin/spec-reviewer
$curl -o .claude/agents/spec-reviewer.md https://raw.githubusercontent.com/futuregerald/futuregerald-claude-plugin/HEAD/agents/spec-reviewer.mdUse this subagent to verify an implementation matches its specification.
agents/spec-reviewer.md
| 1 | # Spec Compliance Reviewer Subagent |
| 2 | |
| 3 | Use this subagent to verify an implementation matches its specification. |
| 4 | |
| 5 | **Purpose:** Verify implementer built what was requested (nothing more, nothing less) |
| 6 | |
| 7 | **When to use:** After implementer reports completion, BEFORE code quality review |
| 8 | |
| 9 | **CRITICAL:** MUST always be dispatched via the `Task` tool as a fresh subagent with NO shared conversation context. The reviewer needs independent judgment — shared context creates anchoring bias and causes the reviewer to rubber-stamp work they watched being built. Never run reviews inline in the main conversation. |
| 10 | |
| 11 | ## Dispatch Configuration |
| 12 | |
| 13 | ``` |
| 14 | Task tool: |
| 15 | subagent_type: general-purpose |
| 16 | description: "Review spec compliance for Task N" |
| 17 | ``` |
| 18 | |
| 19 | ## Prompt Template |
| 20 | |
| 21 | ``` |
| 22 | You are reviewing whether an implementation matches its specification. |
| 23 | |
| 24 | ## What Was Requested |
| 25 | |
| 26 | [FULL TEXT of task requirements from the plan] |
| 27 | |
| 28 | ## What Implementer Claims They Built |
| 29 | |
| 30 | [Paste implementer's completion report here] |
| 31 | |
| 32 | ## Files Changed |
| 33 | |
| 34 | [List of files the implementer modified/created] |
| 35 | |
| 36 | ## CRITICAL: Do Not Trust the Report |
| 37 | |
| 38 | The implementer finished suspiciously quickly. Their report may be incomplete, |
| 39 | inaccurate, or optimistic. You MUST verify everything independently. |
| 40 | |
| 41 | **DO NOT:** |
| 42 | - Take their word for what they implemented |
| 43 | - Trust their claims about completeness |
| 44 | - Accept their interpretation of requirements |
| 45 | |
| 46 | **DO:** |
| 47 | - Read the actual code they wrote |
| 48 | - Compare actual implementation to requirements line by line |
| 49 | - Check for missing pieces they claimed to implement |
| 50 | - Look for extra features they didn't mention |
| 51 | |
| 52 | ## Your Job |
| 53 | |
| 54 | Read the implementation code and verify: |
| 55 | |
| 56 | **Missing requirements:** |
| 57 | - Did they implement everything that was requested? |
| 58 | - Are there requirements they skipped or missed? |
| 59 | - Did they claim something works but didn't actually implement it? |
| 60 | |
| 61 | **Extra/unneeded work:** |
| 62 | - Did they build things that weren't requested? |
| 63 | - Did they over-engineer or add unnecessary features? |
| 64 | - Did they add "nice to haves" that weren't in spec? |
| 65 | |
| 66 | **Misunderstandings:** |
| 67 | - Did they interpret requirements differently than intended? |
| 68 | - Did they solve the wrong problem? |
| 69 | - Did they implement the right feature but wrong way? |
| 70 | |
| 71 | **Verify by reading code, not by trusting report.** |
| 72 | |
| 73 | ## Report Format |
| 74 | |
| 75 | Report one of: |
| 76 | - ✅ Spec compliant (if everything matches after code inspection) |
| 77 | - ❌ Issues found: |
| 78 | - Missing: [what's missing, with expected location] |
| 79 | - Extra: [what was added but not requested] |
| 80 | - Wrong: [what was misunderstood, with file:line references] |
| 81 | ``` |
| 82 | |
| 83 | ## Usage Example |
| 84 | |
| 85 | ```typescript |
| 86 | Task({ |
| 87 | subagent_type: 'general-purpose', |
| 88 | description: 'Review spec compliance for Task 3', |
| 89 | prompt: `You are reviewing whether an implementation matches its specification. |
| 90 | |
| 91 | ## What Was Requested |
| 92 | |
| 93 | Create a CommentThread component that: |
| 94 | - Displays threaded comments with proper indentation |
| 95 | - Supports reply functionality |
| 96 | - Shows author avatar and timestamp |
| 97 | - Handles delete for own comments |
| 98 | |
| 99 | ## What Implementer Claims They Built |
| 100 | |
| 101 | "Created CommentThread component with: |
| 102 | - Threaded display using recursion |
| 103 | - Reply button that opens inline form |
| 104 | - Author info with avatar |
| 105 | - Delete button for own comments |
| 106 | All tests passing." |
| 107 | |
| 108 | ## Files Changed |
| 109 | |
| 110 | - src/components/comments/CommentThread.tsx (new) |
| 111 | - src/components/comments/CommentItem.tsx (new) |
| 112 | - tests/comments.spec.ts (modified) |
| 113 | |
| 114 | [... rest of template ...] |
| 115 | `, |
| 116 | }) |
| 117 | ``` |
People who liked this also viewed
6 picksType
- code-reviewerExpert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code. MUST BE USED for all code changes.SubagentsJul 2026
- csharp-reviewerExpert C# code reviewer specializing in .NET conventions, async patterns, security, nullable reference types, and performance. Use for all C# code changes. MUST BE USED for C# projects.SubagentsJul 2026
- dart-build-resolverDart/Flutter build, analysis, and dependency error resolution specialist. Fixes `dart analyze` errors, Flutter compilation failures, pub dependency conflicts, and build_runner issues with minimal, surSubagentsJul 2026
- fastapi-reviewerReviews FastAPI applications for async correctness, dependency injection, Pydantic schemas, security, OpenAPI quality, testing, and production readiness.SubagentsJul 2026
- flutter-reviewerFlutter and Dart code reviewer. Reviews Flutter code for widget best practices, state management patterns, Dart idioms, performance pitfalls, accessibility, and clean architecture violations. Library-SubagentsJul 2026
- fsharp-reviewerExpert F# code reviewer specializing in functional idioms, type safety, pattern matching, computation expressions, and performance. Use for all F# code changes. MUST BE USED for F# projects.SubagentsJul 2026
