# Issue Raid Commander

> Triages agent:proposed issues and analyzes agent:ready issues for merge conflicts, then outputs a sprint plan. Read-only assessment — does NOT spawn agents, write code, or pick up issues. Use before spawning multiple issue-slayer agents to check for conflicts or plan a sprint. NOT for single-issue work. NOT for full pipeline orchestration (use dispatching-guild-expedition).

- Skill: `ugai/issue-raid-commander` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ugai/issue-raid-commander`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ugai/issue-raid-commander/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: ugai (https://skillmd.com/u/ugai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ugai/issue-raid-commander

---


# Issue Raid Commander

Battlefield awareness without intervention. Triage incoming issues, assess the
ready queue, detect collisions, and hand the team lead a plan they can execute
immediately.

## Inputs

Fetch two pools of issues:

**Pool A — Ready queue** (execution candidates):

```bash
gh issue list --label "agent:ready" \
  --search "no:assignee state:open -label:pending" \
  --json number,title,labels,body --limit 50
```

**Pool B — Triage queue** (unreviewed issues):

```bash
gh issue list --label "agent:proposed" \
  --search "state:open -label:agent:ready -label:pending" \
  --json number,title,labels,body --limit 50
```

Also read the project's `CLAUDE.md` or `AGENTS.md` to identify conflict-prone
files.

If **both pools are empty**, output a one-line summary
("No issues in the queue.") and stop.

## Triage (Pool B)

Skip this section if Pool B is empty.

For each `agent:proposed` issue, evaluate:

- **Duplicate?** — Is it a duplicate of or substantially overlaps with an
  existing open issue (in either pool) or a recently closed one? Cite the
  original.
- **Well-scoped?** — Is the description specific enough for a Slayer to act on
  without guesswork? Flag issues that need more info.
- **In scope?** — Does it belong in this project? Flag anything out of scope.

Output a triage report:

```
## Triage Report

**Recommend ready**: #12, #15 — well-scoped, no blockers
**Needs info**: #18 — reproduction steps missing
**Duplicate**: #20 → duplicate of #8
**Skip**: #22 — out of scope
```

Issues recommended as ready join Pool A for the analysis below.

## Analysis

For each issue, estimate which files it will touch. Use:

- The issue body (issue-ranger usually notes affected files)
- The issue title and labels as hints
- Your own knowledge of the codebase

Flag any two issues that are likely to touch the same file. Issues touching
conflict-prone files warrant extra scrutiny.

If you are genuinely uncertain whether two issues conflict, treat them as
conflicting and say so.

## Output

Output a structured sprint plan with these sections:

```
## Sprint Plan

**Conflicts**: <none | list of conflict pairs with files and suggested order>
**Merge order**: <ordered list, or "any order" if no conflicts>
**Bundle candidates**: <none | groups with pattern and file list>
**Ready to dispatch**: <issue numbers in recommended execution order>
```

Prefer brevity. Omit empty sections. A single sentence is fine when nothing
conflicts.

### Bundle PR candidates

Flag groups of issues as `bundleable` when they meet the criteria in
`../reading-guild-rules/SKILL.md` (same pattern, small, no file conflicts, reviewable as one unit).
Example output:

```
Bundle candidate: #178, #180, #182, #183
  Pattern: unwrap → error propagation
  Files: handler.rs, config.rs, middleware.rs, utils.rs (no overlap)
  → Assign to a single Slayer
```

The Slayer will create one commit per issue and a single PR.

## Feedback

When running standalone (not called by `dispatching-guild-expedition`),
present the sprint plan to the user and wait for confirmation before
concluding — the plan is a recommendation, not a final decision. When called
as a sub-step of the expedition pipeline, the caller handles user approval.