Dispatching Guild Expedition

Dispatching Guild Expedition

Full pipeline: Scout → Approve → Analyze → Implement → Retrospect.

Step 0 — Focus Confirmation

Before spawning anything, ask the user one question:

"Which perspectives should Rangers focus on? (Leave blank for defaults)"

The perspectives from RECON.md, in priority order:

1. Robustness & Error Handling
2. Code Quality & Architecture
3. Performance
4. User Experience
5. Cross-Platform & Compatibility
6. Documentation Freshness
7. New Features (small scope only)

Default split across 4 Rangers:

If the user specifies different focuses, redistribute accordingly.

Step 1 — Scout (Ranger × 4, parallel)

Create a team. Spawn 4 issue-ranger agents in Pattern B (Team Member mode). Pass each agent's assigned perspective(s) in their task prompt:

"Scout from these perspectives only: [list]. Run as Pattern B — send your vetted candidate list to the Team Lead (me) before posting anything."

Wait until all 4 Rangers have reported their candidate lists.

Step 2 — Aggregate & Approve

Collect the 4 reports. Before showing the user:

• Deduplicate: same underlying problem from multiple Rangers → keep the best-scoped version; notify the relevant Ranger(s) to drop duplicates.
• Merge: near-identical candidates → combine into one issue.

Present the consolidated list to the user with AskUserQuestion (multiSelect: true). Each option: [Ranger] title — one-line summary.

Based on the user's selection:

1. Tell each Ranger which issues to post and which to skip.
2. Ask the user which posted issues should receive agent:ready immediately, or handle it as part of the ranger Ready Seal step.

Wait for all Rangers to confirm posting before proceeding.

Step 3 — Analyze (Raid Commander)

Spawn an issue-raid-commander agent as a subagent via the Task tool. Pass it the current agent:ready queue. Present its conflict analysis output to the user.

If the queue is empty (no agent:ready issues), skip to summary and stop.

Step 4 — Implement (Slayer × N)

Spawn issue-slayer agents based on the Raid Commander's sprint plan:

• Non-conflicting issues: spawn all in parallel, up to 8 agents.
• Conflicting groups: spawn in Raid Commander's recommended serial order — wait for each PR to open before spawning the next in the chain.

All Slayers run in Pattern B (Team Member mode). Coordinate merge order per the Raid Commander's analysis. When all Slayers have opened their PRs, shut down the team and report the sprint summary.

Step 5 — Hand-off

End the summary with a clear next-step prompt:

## Next Step

All PRs are open. Run `verify-sprint` to batch-verify and squash-merge them:

> /verify-sprint

This will merge each PR branch locally, run the quality gate, let you
visually inspect the result, then squash-merge to main.

Step 6 — End of Expedition

After the sprint summary, provide a brief retrospective:

• How many issues were scouted, approved, and implemented
• Notable conflicts or problems encountered during the expedition
• Any issues that were skipped, blocked, or deferred

Then ask the user:

"Want to record this expedition summary somewhere? (e.g., GitHub Discussion, Issue, project memory, or skip)"

If the user chooses a destination, write the summary there. If they skip, move on — do not persist anything.