Fire Next Up — Pull, Dispatch, and Chain Agents

Pulls the next "Up Next" item from the GitHub Project board and runs the full agent chain for that issue type. By default, agents run in Depot remote sandboxes (fire-and-forget). Use --local to fall back to local worktrees.

Agent Chains

Research: Technical → FiremanDecko, Product → Freya. Sole agent, posts findings and creates PR. No Loki step. After PR merges, orchestrator presents findings to Odin for Review (plan into issues, shelve, or drop).

Chain rules: Same branch throughout. First agent creates PR with PR for issue: #<NUMBER> in the body (clean title, no issue ref). Loki adds tests on the same PR. If any agent fails, chain stops and orchestrator reports.

Flags

Session ID Parsing

When --resume receives a Depot session ID instead of an issue number, extract the issue number from it. Session IDs follow the convention: issue-<N>-step<S>-<agent>-<uuid8>. Parse <N> as the issue number and resume that chain.

Examples:

• issue-621-step1-firemandecko-8d0410cd → --resume #621
• issue-300-step2-loki-a1b2c3d4 → --resume #300

Also accept Depot URLs: https://depot.dev/orgs/.../claude/<session-id> — extract the session ID from the URL path, then parse as above.

Multi-Issue Review Loop

When multiple issue numbers are passed (#N1 #N2 #N3 ...), the orchestrator runs an interactive review loop instead of batch-dispatching blindly:

Phase 1 — Pre-fetch everything in parallel (LOOP OPTIMIZATION):

Do ALL of the following in a single parallel batch BEFORE starting the interactive loop. This eliminates all per-issue latency during the loop — every AskUserQuestion response can be acted on immediately without any additional I/O.

1. Fetch all issues in parallel: fire one gh issue view <N> --json number,title,body,labels per issue simultaneously. Do NOT fetch them one at a time.

2. Pre-read all needed agent templates: from the --peek output, each issue has a chain field (e.g. "FiremanDecko → Loki", "Luna → FiremanDecko → Loki"). Collect the unique Step-1 agents across the entire queue (e.g. firemandecko, luna, heimdall) and read ALL their template files in parallel. This means every dispatch in the loop is a single tool call (just the spawn) rather than read-then-spawn.

3. Pre-resolve all blockers: scan each issue body for Blocked by #N patterns. For every blocker found, fetch gh issue view <N> --json number,state in parallel. Cache the results so blocked issues can be flagged immediately when presented in the loop (no per-issue fetch).

4. Sort: critical → high → normal → low. Within the same priority, preserve the order Odin listed them (or peek order for the default Up Next queue).

5. Pre-compose all prompts: with all issue data and templates already in context, compose every agent prompt before entering the loop. Store them keyed by issue number. Dispatch becomes a single bash dispatch-job.sh call — no compose step inside the loop.

Phase 2 — Interactive loop (one issue at a time): For each issue in priority order, present via AskUserQuestion:

Question: "#<N> — <TITLE> (<priority>/<type>) — <1-line summary from body>"
Header: "#<N>"
Options:
  - "Dispatch" — dispatch via `/dispatch #<N>` immediately
  - "Skip" — leave on Up Next, move to next issue
  - "Hold" — move issue to the "On Hold" column on the project board, continue to next issue
  - "Double check" — verify issue status matches reality before deciding
  - "Stop" — stop processing remaining issues

Phase 3 — Execute decisions:

Double Check — Reality Verification

When Odin selects "Double check", run these checks before re-presenting the issue:

1. Branch check: git ls-remote --heads origin | grep <issue-number> — does a branch already exist?
2. PR check: gh pr list --search "<issue-number>" --state all --json number,title,state,headRefName — any open/merged PRs?
3. Agent dispatch check: kubectl get jobs -n fenrir-agents -l issue=<issue-number> --no-headers 2>/dev/null and check --chain-status <N> — was an agent already dispatched?
4. Issue comments: gh issue view <N> --json comments — any handoff/verdict comments already posted?
5. Board position: Confirm the issue is actually in the column pack-status says it is.

Present findings as a brief status block before re-asking the same question:

**Double check #<N>:**
- Branch: `fix/issue-<N>-...` exists / none found
- PR: #<PR> (open/merged/none)
- Agent: dispatched step 1 FiremanDecko (running/succeeded/none)
- Handoff: FiremanDecko → Loki posted / none
- Verdict: PASS / FAIL / none
- Board: Up Next (confirmed)

→ Re-presenting for decision...

Then re-present the same AskUserQuestion with the same options. This lets Odin make an informed dispatch/skip/hold decision after seeing the real state.

Phase 4 — Summary report: After the loop completes (or is stopped), output a single summary:

## Dispatch Summary

| # | Title | Decision |
|---|-------|----------|
| 1397 | fix: exclude tests from coverage | Dispatched → session-id |
| 1406 | Karl tab styling | Skipped |
| 1416 | Thrall E2E timeout | Dispatched → session-id |
| 1415 | WSS status badge | Stopped (not processed) |

All dispatched issues are dispatched in sequence (not parallel) so Odin can adjust decisions based on what was already dispatched. Each dispatch fires immediately after Odin says "Dispatch" — do not batch them.

Pack Status Script

All data queries go through the pack-status script. Do not use gh project item-list or manual GraphQL.

SCRIPT_DIR="$(git rev-parse --show-toplevel)/.claude/skills/fire-next-up/scripts"
node "$SCRIPT_DIR/pack-status.mjs" <subcommand>

pack-status.mjs is the sole source file — edit it directly. No build step needed.

Dashboard Output Format

Render --status JSON as this markdown:

## Pack Status Dashboard

### In Flight (N issues)

| # | Title | Chain Position | PR | Job | Runtime | Next Action |
|---|-------|----------------|-----|-----|---------|-------------|
| 269 | Back button | Loki PASS | #286 | complete | 8m 12s | `gh pr merge 286 --squash --delete-branch` |
| 279 | Dashboard tabs | Awaiting FiremanDecko | #288 | running | 3m 45s | `/fire-next-up --resume #279` |

Use `job_runtime` and `job_status` from `--status` JSON to populate Job and Runtime columns.
Show "—" when no job data available (e.g. parent issues, old completed chains).

### Verdict Summary
- PASS, ready to merge: #X, #Y
- FAIL, needs attention: #Z
- Awaiting Loki: #A, #B
- No response (may need re-dispatch): #C

### Up Next Queue (N items)
- #X — Title (critical/bug) → `/fire-next-up #X`
- #Y — Title (high/ux) → `/fire-next-up #Y`
- #Z — Title (normal/enhancement) → `/fire-next-up #Z`
- *(show ALL items, not just top 3)*

### Research Awaiting Review
- #168 Marketing campaign plan — `/fire-next-up --resume #168`

### Suggested Next Actions (copy-paste ready)
gh pr merge 286 --squash --delete-branch   # #269 Loki PASS — merge it
/fire-next-up --resume #277                # Loki QA needed
/fire-next-up --resume #279                # FiremanDecko needed
/fire-next-up --resume #168                # Research review needed

Auto-Advance Rules (--resume without #N — SCOPED COMMANDS EXCLUDED)

SCOPE: These rules apply only when --resume is called without an issue number. When --resume #N is given, skip this section entirely — only advance issue N via --resume-detect N. No other in-progress chains are scanned, dispatched, or merged.

When --resume (no #N) finds actions that are clearly ready, execute them immediately:

Only pause for Odin's approval on: ambiguous situations or FAIL verdicts.

Do NOT pause for: merges, Loki dispatches, or any other obvious action. Execute all clear-cut actions immediately and report what was done in the dashboard output.

Board automation (GitHub Projects V2 built-in workflows): GitHub automatically handles these board transitions — do NOT move items manually for these:

• PR opened/linked → In Progress (auto)
• PR merged → Done (auto)
• Issue closed (via Fixes #N) → Done (auto)
• Stale Done items → Archived (auto)

The orchestrator only moves items manually for:

• --move N up-next — when filing new issues
• --move N in-progress — belt & suspenders when dispatching agents (redundant with PR auto-move, but ensures the issue moves even before the PR exists)

Research Review Flow

When --resume detects a completed research chain (handoff comment exists, PR merged, issue still open), the orchestrator runs the review flow instead of spawning another agent.

Detection

The dashboard and resumeDetect() identify research issues where:

• Has a ## Freya Handoff or ## FiremanDecko Handoff comment (without → Loki)
• PR is merged (check via gh pr list --state merged --head <branch>)
• Issue is still open
• These show as next_action: "review" in the dashboard

Review Presentation

Read the deliverable file(s) from the merged PR, then present to Odin:

**Research Complete: #<N> — <TITLE>**
**Agent:** <Freya/FiremanDecko>
**Deliverable:** `<file path>`

**Key findings:**
- <3-5 bullet summary from the deliverable>

**Odin — what's the call?**
1. **Plan it** → Break findings into actionable issues via /plan-w-team
2. **Shelve it** → Close issue, findings stay in repo for future reference
3. **Drop it** → Close issue, delete the deliverable file

Odin's Decision

Dispatch Flow

Step 1 — Select the Issue(s)

Default (no flag): Run --peek to get ALL Up Next items sorted by priority. Then run Phase 1 of the Multi-Issue Review Loop (parallel pre-fetch) before entering the loop.

Single issue (#N): Use that issue directly — skip to Step 2 refinement.

Multi-issue (#N1 #N2 ...): Run Phase 1 of the Multi-Issue Review Loop (parallel pre-fetch of all issues, templates, and blockers), then enter the loop.

Loop mode: When the queue has 2+ issues, ALL issue fetches, agent template reads, blocker checks, and prompt composition happen in Phase 1 before any AskUserQuestion is shown. See Multi-Issue Review Loop → Phase 1 for the full pre-fetch spec. For single-issue dispatch, fetch the issue and read the template before Step 2.

Before dispatching, check body for Blocked by #N — if blocking issue is open, warn and ask (single) or skip (batch).

Step 2 — Refine with Odin

Present the selected issue:

**Issue #<NUMBER>**: <TITLE>
**Type:** <type label> | **Priority:** <priority label>
**Chain:** <Agent1> → <Agent2> [→ <Agent3>]

**Summary:** <3-4 sentences>
**Proposed approach:** <1-2 sentences>
**Acceptance criteria:** <bullet list>

Odin — does this look right? Any adjustments before I fire it off?

Skip refinement when: --batch, skip-refinement in body, or --resume. Always refine when: First dispatch (Up Next → In Progress).

Step 2b — Local Design Interview

When Odin requests: adopt agent persona locally, ask 4-6 questions, post summary comment on issue. Return to remote execution.

Step 3 — Dispatch via /dispatch

After refinement, delegate all spawning to /dispatch:

Fresh dispatch:

/dispatch #<NUMBER> --agent <agent> --step 1

Chain continuation (resume):

/dispatch #<NUMBER> --agent <next-agent> --step <N> --branch <existing-branch>

Batch dispatch:

/dispatch #N1 #N2 #N3 --parallel

Refinement re-dispatch:

/dispatch #<NUMBER> --agent <same-agent> --step <N> --branch <branch> --prompt-extra "<Odin's notes>"

CI bounce-back:

/dispatch #<NUMBER> --agent loki --step <N> --branch <branch> --template loki-bounce-back --prompt-extra "<CI failure details>"

Local execution: Add --local to any of the above.

Dry run (preview prompt without spawning):

/dispatch #<NUMBER> --agent <agent> --dry-run

Chain Continuation

Depot: fire-and-forget. User continues with /fire-next-up --resume #N. Read templates/resume-flow.md.

Local: when background agent completes, check result → spawn next agent on same branch → Loki = final step, report PR URL.

Reports

Read templates/reports.md for dispatch summary, step transition, and chain completion report formats.

Pre-Flight (Local Mode)

REPO_ROOT=$(git worktree list --porcelain | head -1 | sed 's/^worktree //')
git worktree list --porcelain | grep '^worktree ' | sed 's/^worktree //' | while read -r wt; do
  [ "$wt" = "$REPO_ROOT" ] && continue
  echo "$wt" | grep -q '\.claude/worktrees/.*\.claude/worktrees/' && \
    git worktree remove "$wt" --force 2>/dev/null || rm -rf "$wt"
done
git worktree prune

After chain completes, clean up worktrees for the issue:

for wt in "$REPO_ROOT/.claude/worktrees/issue-<NUMBER>-"*; do
  [ -d "$wt" ] && git worktree remove "$wt" --force 2>/dev/null || rm -rf "$wt"
done
git worktree prune

Rules

• One chain per invocation unless --batch.
• The orchestrator coordinates — never do an agent's work yourself.
• Each agent handles its own commits and pushes.
• For test issues, Loki is both first and final agent.
• Board transitions are handled by GitHub Projects V2 built-in workflows (PR opened → In Progress, PR merged → Done, issue closed → Done). /dispatch also moves issues to In Progress as belt & suspenders.
• All agent spawning goes through /dispatch. Never call depot claude directly.
• Always use AskUserQuestion when asking Odin anything. Never output a question as plain text and wait — use the AskUserQuestion tool so Odin gets a proper prompt. This applies to ALL interaction points: refinement questions, blocked-issue warnings, research review decisions, FAIL verdict approvals, design interview questions, and any other situation where you need Odin's input before proceeding.