Refactor to use agent teams in a worktree

Timeline · 2 events

1. epm:clarify2026-05-01T18:50:12.000Z· system
   <!-- epm:clarify v1 --> ## Clarifier — RESOLVED Three blocking ambiguities were resolved by the user inline: 1. **Mech…

   <!-- epm:clarify v1 -->
   ## Clarifier — RESOLVED
   
   Three blocking ambiguities were resolved by the user inline:
   
   1. **Mechanism** — Use Claude Code's native primitives: `team_name` + `isolation: "worktree"` on `Agent` calls, plus `TeamCreate`/`TeamDelete` for lifecycle. Not a conceptual reorg.
   2. **Scope** — All multi-agent skills. We are designing a new workflow.
   3. **Backward compatibility** — Hard cutover. The new workflow replaces the current one.
   
   Issue body has been populated with the resolved spec. Proceeding to gate-keeper.
   <!-- /epm:clarify -->

2. epm:gate2026-05-01T18:51:32.000Z· system
   <!-- epm:gate v1 --> ## Gate-Keeper Verdict — MODIFY ### Scores | Dimension | Score | Justification | |-----------|---…

   <!-- epm:gate v1 -->
   ## Gate-Keeper Verdict — MODIFY
   
   ### Scores
   
   | Dimension | Score | Justification |
   |-----------|-------|---------------|
   | Information value | 4/5 | Genuinely open question whether native team primitives subsume the marker-comment state machine. Result either retires substantial custom orchestration (big simplification) or surfaces concrete gaps in the native primitives that we document. Both outcomes update beliefs. |
   | De-risking | 2/5 | The two open design questions in the issue body — "does `team_name` survive across invocations?" and "how does the `status:*` machine map to team lifecycle?" — are exactly the questions that, if answered "no," kill or massively rescope the refactor. The plan commits to a hard cutover before answering them. No spike, no dry-run on a synthetic skill, no fallback. |
   | Strategic fit | 3/5 | Aligns with `agents-vs-skills.md` philosophy. But the project's research clock is ticking — `aim:cross-cutting` infra refactors compete with experiment work, and current orchestration is functional (3 issues running right now, 9 active worktrees, ~15 approved queued). "Functional but ad-hoc" is a weaker case than "broken." |
   | Feedback speed | 4/5 | Pure code refactor, no GPUs, end-to-end dry run on a synthetic issue gives same-day signal. Iteration cost is low. |
   | Opportunity cost | 4/5 | `compute:none` so no GPU contention. Cost is agent-hours and merge-coordination risk against in-flight issues, which is real but bounded. Nothing comparable in the `aim:infra` queue. |
   | **Average** | **3.4/5** | (just under RUN threshold) |
   
   ### Verdict — MODIFY
   
   The strategic case is strong (align with native primitives, retire ad-hoc machinery, simpler state model) and the cost is low (no GPUs, contained worktree). But the de-risking score is the binding constraint: the issue body itself flags two open questions whose answers determine whether this is a clean cutover or a months-long migration that ends in keeping the marker-comment system anyway. Land a 1-2 hour spike that answers them empirically before committing to a full hard cutover across every multi-agent skill. Also de-risk by either staging the cutover (start with `/adversarial-planner`, the simplest multi-agent skill, with no durable state) or timing it for a drain window when no issues are mid-pipeline.
   
   ### Required revisions to the issue body
   
   1. **Add a Phase 0 spike (mandatory before planning).** A 1-2 hour empirical investigation that answers the two open design questions:
      - Does `Agent({ team_name: "X", isolation: "worktree" })` re-attach to an existing team across separate `/issue` invocations, or does each invocation create a new team? Test: invoke twice in separate sessions with the same `team_name`, observe behaviour.
      - What state actually persists across invocations of agents in the same team? Conversation history? Worktree contents only? Nothing?
      - Conclusion: are marker comments still load-bearing for resumability, or can they be retired? Document the answer in the issue.
   2. **Stage the cutover.** Replace "all multi-agent skills in one hard cutover" with: (a) `/adversarial-planner` first — it has no durable state, no `status:*` machine, just three agents in one invocation, so it's the cleanest test of the team primitives, (b) then iterate on `/issue` only after the spike answers the resumability question, (c) leave `/auto-experiment-runner`, `/clean-results`, `/experiment-proposer` for last (or out of scope — they're orchestrators with their own concerns).
   3. **Add a drain criterion.** "Land when no issues are in `status:running`, `status:planning`, `status:plan-pending`, `status:approved`, `status:interpreting`, or `status:reviewing`" — currently 24 issues are in those states (3 running, 3 planning, 0 plan-pending, ~15 approved, 0 interpreting, 3 reviewing). The cutover window needs to be either picked or replaced with a coexistence story.
   4. **Add an acceptance test that exercises resume.** "End-to-end dry run on 

Comments · 0

No comments yet. (Auth + comment composer land in step 5.)