| name | next-bug |
| description | Pick the next open GitHub issue to fix, ranked by severity (High > Medium > Low > decision-needed), then hand off to the `fix-bug` skill. Use when the user says "next bug", "what's next", "pick the next one", "do the next one by severity", or anything that asks for the next-priority bug-fix work. Lists all open issues in the current repo, parses the `## Severity / blast radius` section from each body, ranks them, presents the top pick with a one-line rationale, waits for user confirmation, then invokes `fix-bug` for that issue. |
/next-bug
Follow the shared conventions in ../conventions.md.
The picker that sits in front of fix-bug. Does NOT do any work itself; its only job is to surface the next issue and defer execution to fix-bug.
Pre-flight
Same canon as fix-bug. Verify the remote before listing anything (conventions.md § Remote policy). Resolve the repo from git remote -v in the current working directory; never guess.
Phase 1: list open issues
gh issue list -R <owner>/<repo> --state open --limit 50 --json number,title,labels,body
Filter the result to bug-fix candidates:
- Skip issues labeled
epic UNLESS the epic body itself contains an actionable ## Fix plan (i.e. it's the whole fix collected into one issue, not a tracking parent for sub-issues). The session that produced the canonical issue set bundles related fixes under one epic with concrete plans, so epics ARE actionable here.
- Skip issues labeled
question (design decision needed; not bug-fix work).
- Skip the meta issue
Design X to hold all analytics data style design docs (first-line Design/Plan issues).
Phase 2: parse severity from each body
The canonical issue body (see conventions.md § Issue-first and the fix-bug skill) puts severity in a ## Severity / blast radius section as a bold value:
## Severity / blast radius
**Medium.** Real crash potential under ...
Extract the first bold token after the heading. Map to a numeric score:
| Body text | Score |
|---|
**High.** | 3 |
**Medium-high.** or **High-medium.** | 2.5 |
**Medium.** | 2 |
**Low-medium.** or **Medium-low.** | 1.5 |
**Low.** | 1 |
**N/A, decision needed, or no severity section | 0 |
A priority: high label adds +1 to the score regardless of body text. This is the only label that affects ranking.
Phase 3: rank
Sort descending by (score, label tiebreakers, issue number ascending):
- Higher score first.
- Among equal scores:
bug label beats enhancement (bugs ship-broken; enhancements ship-improved).
- Among equal scores AND equal kind: non-epic before epic (smaller scope first).
- Among equal scores AND equal kind AND equal epic-status: lower issue number first (older issues are usually more important, and the catalog letters were assigned by audit order).
Phase 4: present the top pick
Output a single block to the user:
Next: #<N> (<title>)
Severity: <severity>. <one-line rationale from the body's Severity section>.
Labels: <comma-separated>.
Scope: <one-line summary from the body's Fix section>.
Tied with: #<N2>, #<N3> (same score, broken by <reason>).
Say "y" to start, or name a different issue.
Keep it tight. Three to five lines of body. The user makes the final call.
Phase 5: hand off (on confirmation)
When the user says "y", "yes", "do it", or names the same issue:
Invoke fix-bug for that issue. From a slash-command harness, this is /fix-bug <N>. From a free-text harness, it's "start fix-bug for issue #N" and follow that skill's phases.
If the user names a DIFFERENT issue, accept it without re-ranking. Their override beats the picker.
If the user says "skip" or names a different issue, mark the current top pick as --add-label "skip-this-cycle" (a transient label that the next next-bug call honours by excluding the skipped issue this session).
Constraints
- Never auto-invoke
fix-bug. Always wait for the user's explicit "y" or equivalent.
- Never modify the issue body. The ranking is read-only.
- Never re-order the list silently across runs. Each call is fresh; the user sees the current state.
When to use
- User says "next bug" / "what's next" / "pick by severity" / "next-bug" / "/next-bug".
- After merging a fix and the conversation continues. Don't auto-fire; wait for the user to ask.
When NOT to use
- When the user names a specific issue ("start on #X"). Hand off directly to
fix-bug; the picker has nothing to add.
- When there are zero open issues. Say so; do not invent work.
- When the only remaining issues are
question-labeled design decisions. Tell the user the bug queue is empty and the next steps are conversations, not code.
Failure modes to refuse
- Auto-invoking
fix-bug without the user's confirmation. Always confirm.
- Ranking by issue title or label color (vanity criteria). Severity is the only signal.
- Skipping a higher-severity issue because it's "complicated". The skill's job is to surface it; the user decides whether to defer.
- Picking from a different repo than the current working directory's GitHub remote.
