next-bug

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):

1. Higher score first.
2. Among equal scores: bug label beats enhancement (bugs ship-broken; enhancements ship-improved).
3. Among equal scores AND equal kind: non-epic before epic (smaller scope first).
4. 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.