- Add 6 agent definitions (devils-advocate, implementer, proponent, research-lens, spike-runner, verifier) for specialized AI team workflows - Add 4 team slash commands (battle-test, debate, dev-loop, spikes) - Add openspec-journal.py processor + pre-compaction hook script - Update settings.json and .mcp.json for agent team support
5.3 KiB
| name | description | category | tags | ||||
|---|---|---|---|---|---|---|---|
| Team: Battle Test | Spawn a proposal battle-test team for an OpenSpec change's proposal.md and design.md before specs/tasks harden | Agent Teams |
|
Battle-test an OpenSpec change before specs/tasks harden.
Input ($ARGUMENTS): one of
- A change name (e.g.
spatial-niche-attachments) - Empty — ask which OpenSpec change
This command reviews both:
openspec/changes/<change>/proposal.mdopenspec/changes/<change>/design.md
The output is a change-local review artifact:
openspec/changes/<change>/battle-test.md
Pre-flight
-
Verify agent teams are enabled.
.claude/settings.jsonmust contain"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"underenv. If not, refuse and tell the user to add it and restart Claude Code. -
Resolve the change.
- If
$ARGUMENTSincludes a change name, use it. - If empty, run
openspec list --jsonand ask the user which change. - Refuse if
openspec/changes/<change>/does not exist.
- If
-
Verify target artifacts exist.
- Require
proposal.md. - Require
design.md. - If either is missing, refuse and tell the user to run
/opsx:continueuntil both artifacts exist.
- Require
-
Verify the change is pre-apply. Run
openspec status --change <change> --json. If tasks are complete and implementation has started, warn that this command is proposal/design review, not implementation verification. Continue only if the user explicitly wants late review. -
Read the targets end-to-end before spawning teammates. The lead must read:
proposal.mddesign.md- any existing
specs/**/*.mdif present openspec/specs/CLAUDE.md- every canonical touchpoint listed in
proposal.md
-
Write OpenSpec journal entries when a journal exists.
- Before the team run:
python3 scripts/openspec-journal.py <change> turn.start input="Battle-test proposal and design" - Record team spawn:
python3 scripts/openspec-journal.py <change> agent.spawned count=<n> kind="battle-test" - After writing
battle-test.md:python3 scripts/openspec-journal.py <change> artifact.added ref="battle-test.md" - End:
python3 scripts/openspec-journal.py <change> turn.end output="Battle-test complete; see battle-test.md"
- Before the team run:
Team Spawn
Create an agent team with these teammates:
| Name | Subagent type | Model | Role |
|---|---|---|---|
adversary |
devils-advocate |
opus | Break the proposal/design with load-bearing critiques only. |
defender |
proponent |
opus | Defend, concede-patch, concede-future, or stalemate each critique. |
Spawn prompts:
-
adversary: "Adversarially review OpenSpec change
<change>, focusing onproposal.mdanddesign.md. Read the canonical touchpoints listed inproposal.md, plus any existing change specs if present. Produce up to 10 load-bearing critiques only. Each critique must name failure mode, affected artifact section, canonical conflict if any, and the cheapest falsifier. Post critiques to the team mailbox addressed todefender. Do NOT edit files." -
defender: "Defend OpenSpec change
<change>against critiques posted byadversary. Readproposal.md,design.md, canonical touchpoints, and any existing change specs. For each critique use exactly one verdict: defend, concede-patch, concede-future, stalemate. For concede-patch, name the smallest artifact edit. Post responses to the team mailbox addressed tolead. Do NOT edit files."
Mediation Loop
Lead's job:
- Wait for
adversarycritiques. - Ensure
defenderresponds to every critique. - Allow one rebuttal round only for defended critiques.
- Synthesize
openspec/changes/<change>/battle-test.md. - Apply only trivial typo/clarity patches immediately. For structural edits, list exact recommended patches in
battle-test.mdand ask the user before mutating proposal/design/spec artifacts.
Battle-Test Artifact Shape
Write:
# Battle Test — <change>
**Date:** <YYYY-MM-DD>
**Targets:** proposal.md, design.md
**Team:** adversary, defender
## Verdict
Proceed | Patch first | Rework
<one paragraph>
## Surviving Critiques
### <title>
**Severity:** blocker | major | watch
**Failure mode:** ...
**Hits:** proposal.md#... / design.md#... / canonical doc...
**Falsifier:** ...
**Disposition:** defended | patch | future | stalemate
## Conceded Patches
- <artifact>: <exact edit needed>
## Future Work
- <item>
## Lead Recommendation
<what to do before /opsx:continue or /opsx:apply>
Hard Rules
- No teammate edits files. Lead writes only
battle-test.mdunless the user approves structural artifact patches. - No Bash for thought teammates. Use Bash only in the lead pre-flight and journal/status steps.
- Maximum one rebuttal round. This is a hardening pass, not an endless debate.
- Concede early. If critique identifies a missing falsifier, missing observability surface, hidden migration cost, or canonical contradiction, record it.
- English only. Repo rule.
- Do not run implementation checks. This command reviews proposal/design. Use verifier/apply workflows for implementation evidence.
Cleanup
After writing battle-test.md, ask the user whether to clean up the team.
Do not archive temp findings until the user has read the synthesis.