---
name: triage-spawn
description: Triage open beads issues by model capability, then spawn each into its own worktree + tmux session. Combines /beads:ready, /tmux-spawn, and /worktree skills.
arguments:
  - name: filter
    description: "Optional: only spawn issues matching this label or type (e.g., 'bug', 'feature', 'frontend')"
    required: false
  - name: dry-run
    description: "If 'true', show the triage plan without spawning anything"
    required: false
---

# Triage and Spawn Beads Issues

Read open beads issues, classify each by which model should handle it, then spawn isolated worktree+tmux sessions for each.

## Procedure

### Step 1: Get ready issues

Run `bd ready --json` via Bash to get all unblocked issues. If a `filter` argument was given, also use `bd list --label <filter> --json` or `bd list --type <filter> --json` to narrow down.

Parse the JSON output. For each issue, run `bd show <id> --json` to get the full description, notes, design, and acceptance criteria.

### Step 2: Triage each issue

For each issue, classify it as **opus**, **sonnet**, or **haiku** based on these heuristics:

**Haiku-tier** (trivial, zero-judgment, impossible to botch):
- Single-line typo fixes where the exact correction is in the issue title
- Deleting a file or removing a clearly dead import
- Changing a single hardcoded string/number that's spelled out in the issue
- **Must be**: 1 file, < 5 lines, zero ambiguity, no logic changes
- **When in doubt, use Sonnet.** Haiku should be rare (0-2 per triage).
- Labels: `trivial`

**Sonnet-tier** (moderate complexity, clear direction):
- Bug fixes with clear reproduction steps
- Features with detailed design + acceptance criteria already written
- Multi-file changes where the approach is straightforward
- Writing tests for existing code
- Config changes, dependency bumps, rename variables, delete dead code
- Simple chores/docs that touch multiple files or require any judgment
- Priority 2-3 (medium/low) with defined scope
- Labels: `chore`, `docs`, `small`, `bug`, `test`, `feature` (when well-scoped)

**Opus-tier** (complex, ambiguous, needs deep reasoning):
- Features requiring architectural decisions or design exploration
- Issues with vague or missing design/acceptance criteria
- Large refactors across many files with tricky interdependencies
- Priority 0-1 (critical/high) with broad or unclear scope
- Anything involving security, performance tuning, or cross-cutting concerns
- Labels: `complex`, `architecture`, `security`

**Skip** (don't spawn):
- Epics (they're containers, not work items)
- Issues of type `role` or `agent`
- Anything already `in_progress`

### Step 3: Present the plan

Show the user a table:

```
Issue    | Model  | Title                          | Reason
---------|--------|--------------------------------|------------------
bd-12    | haiku  | Fix typo in error message      | Obvious 1-line change
bd-15    | opus   | Refactor auth middleware        | Multi-file, architectural
bd-18    | sonnet | Add config validation           | Design written, multi-file but clear
bd-20    | sonnet | Fix session timeout bug         | Bug with repro steps, needs diagnosis
bd-23    | skip   | Q1 Feature Epic                | Epic, not actionable
bd-25    | haiku  | Bump Go to 1.23                | Mechanical config change
```

Ask the user to confirm, adjust model assignments, or remove issues before spawning.

### Step 4: Spawn sessions

If `dry-run` is true, stop here.

For each confirmed issue (in priority order, highest first):

1. **Mark in-progress:** `bd update <id> --status in_progress --json`

2. **Derive a slug** from the issue ID and first 1-2 words of the title. Example: `bd15-refactor-auth`

3. **CRITICAL: Always use the `-w` flag.** The `-w` flag makes Claude create and manage the worktree natively (auto-cleanup on exit, proper CWD tracking). **DO NOT** pre-create worktrees with `git worktree add` and `cd` into them. **DO NOT** run `claude` without `-w` in a worktree directory. That causes "escaped worktree" — Claude doesn't know it's in a worktree, CWD drifts, no auto-cleanup.

4. **Spawn a tmux window with `claude -w`:**

   ```bash
   REPO_ROOT=$(git rev-parse --show-toplevel)
   SLUG="<slug>"
   MODEL="<haiku|sonnet|opus>"
   SEED="<seed-prompt-text>"
   tmux new-window -n "cc-${SLUG}" -c "$REPO_ROOT" \
     "SSH_AUTH_SOCK=$SSH_AUTH_SOCK SSH_AGENT_PID=$SSH_AGENT_PID claude -w ${SLUG} --permission-mode acceptEdits --model ${MODEL} -- ${SEED@Q}"
   ```

   Use `${SEED@Q}` (bash quoting operator) to safely escape the seed prompt. This avoids nested-quote issues. The SSH env vars are forwarded inline for WSL2 compatibility.

5. **Seed prompt** content (the `SEED` variable):
   ```
   You are working on beads issue <id>: <title>
   Branch: worktree-<slug>

   ## Description
   <issue description>

   ## Design
   <design field, if any>

   ## Acceptance Criteria
   <acceptance field, if any>

   ## When done
   1. Run the code-simplifier agent on your changes before committing
   2. Commit your changes
   3. Run: bd close <id> --reason "<summary of what you did>"
   4. STOP. Your work is done.

   Do NOT merge to main — the parent session handles that.
   Do NOT manually delete your worktree — Claude handles cleanup on exit.
   ```

6. **Confirm** each spawn to the user with the tmux window name.

### Step 5: Summary

After all sessions are spawned, show:
- How many sessions spawned (opus count, sonnet count, haiku count)
- The tmux window names so the user can navigate (`Prefix + n` or `Prefix + <number>`)
- Remind: `/worktree list` to see all active worktrees, `/worktree clean-all` when done