forgejo-mcp/.claude/commands/team/spikes.md

name	description	category	tags
Team: Spikes	Spawn N parallel `spike-runner` teammates to execute autonomous feasibility spikes against a single research spec	Agent Teams	agent-teams sandbox spikes

Spawn parallel autonomous spike-runner teammates against a research spike spec.

Input ($ARGUMENTS): one of

• A spec file path (e.g. docs/research/predicate-language-spike.md) — spawn one teammate per spike defined in the spec
• A spec path plus a comma-separated list of spike-name=type pairs (e.g. docs/research/predicate-language-spike.md | cel-wasm=crate, views-lockpick=module)
• Empty — ask which spec

Pre-flight

1. Verify agent teams are enabled (env flag). If not, refuse + instructions.

2. Verify the spec file exists under docs/research/ and contains pass criteria + a reporting template. Refuse otherwise.

3. Verify each spike's sandbox/sk-sndbx-<name>/ does NOT already exist. Conflict = refuse for that one. Other spikes can still proceed.

4. Confirm the user wants autonomous execution. Spike-runner has Bash. It will start a local spacetime start node, publish modules, run reducers. If you (the lead) suspect the user wanted to drive these manually, ask first using AskUserQuestion. Skip this confirmation if the spec explicitly authorizes autonomous runs.

5. Local-node prerequisite check. Run spacetime --version via Bash to confirm the CLI is on PATH. If not, refuse — sandbox doctrine says spike-runner brings up its own local node, which requires the binary.

Team spawn

Create a team with one spike-runner teammate per spike. Each gets model: sonnet (from the agent file). For 2+ spikes, this is the full team; for a single spike, prefer single-shot delegation (Use the spike-runner agent to ...) instead — teams are overkill for N=1.

For each spike, spawn with this prompt:

Execute spike `<spike-name>` (type=<crate|module>) per spec
`<spec-path>`. Run autonomously to verdict per the spike-runner
agent's loop. Produce all required teaching artifacts.

Hard reminders:
- DB name = sk-sndbx-<spike-name>
- Local node only (sandbox default) — start your own background `spacetime start`
- Append your `## Results — <YYYY-MM-DD>` section to the spec file
- Write `sandbox/sk-sndbx-<spike-name>/README.md` with one-line verdict + anchor link
- Stop at 2× the spec's time-box

When done, post a one-line verdict + path to your README to the team
mailbox addressed to `lead`.

Mediation loop (lead's job — i.e. you)

1. Let the teammates run. Do not implement anything yourself — wait.

2. As verdicts arrive, collect them. Don't synthesize until all teammates have reported (or hit timeout).

3. Once all teammates have reported, append a joint synthesis section to the spec file:

   ## Joint Verdict — <YYYY-MM-DD>
   - Spikes run: <list>
   - Per-spike verdicts: <table>
   - Joint recommendation: <PROCEED | FALLBACK | NO-GO> with reasoning
   - Open questions for the user: <bullets>
   

4. Do not delete spike directories. That's the user's call after they've read the reports.

5. List any cleanup state (running spacetime start PIDs, undeleted local DBs, dirty working trees) for the user.

Hard rules

• Spike-runners are autonomous. Do not micromanage them. If one is stuck for >10 min, message it once asking for status; don't replace it unless dead.
• Lead does not edit spike directories. Each spike dir is owned by its teammate.
• Lead does not run cargo or spacetime for the spikes. That's the teammates' job. The lead may run git status, git diff for the synthesis section.
• No git commit, no git push from the lead during the run. The user reviews and commits.
• Cleanup of the team itself: after synthesis is written, ask the user to confirm before running clean up the team.

Argument: $ARGUMENTS