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
2.0 KiB
2.0 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)
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]