mathias
62cfe46927
The vendored skills were written against a generic `Task()` and an operator called "your human partner". Neither exists here. An agent following dispatching-parallel-agents literally would call a tool that is not in its list. `Task tool` becomes the `Agent` tool with `subagent_type` across all six prompt templates and the Gemini mapping table, and the dispatch example gains the three options that actually matter for parallel work: issuing every dispatch in ONE message (several Agent uses in a single turn run concurrently; one per turn serialises them), `isolation: "worktree"` so two agents cannot fight over the same tree, and per-agent `model` override for cheap mechanical fan-out. `Workflow` is named as the structured alternative — phases, per-finding verify, fan-in — with its opt-in condition stated, because a skill that told an agent to reach for it unprompted would be teaching a policy violation. "your human partner" becomes "the operator" in five skills. Beyond phrasing, it was factually wrong in executing-plans, which told the reader to *ask* whether subagents are available; on this fleet Claude Code has them and Crush/Pi/OpenCode do not, so it now says which skill to use where. Closes #17 Bump-Type: patch
62 lines
2.0 KiB
Markdown
62 lines
2.0 KiB
Markdown
# 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)
|
|
|
|
```
|
|
Agent tool (`subagent_type: "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]
|
|
|
|
## What Implementer Claims They Built
|
|
|
|
[From implementer's report]
|
|
|
|
## 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]
|
|
```
|