pick-next-issue

$npx mdskill add tobihagemann/turbo/pick-next-issue

Ranks open GitHub issues by engagement and plans implementation for the selected one.

  • Helps developers decide which GitHub issue to work on next.
  • Uses the GitHub CLI to fetch issue data including reactions and comments.
  • Calculates an engagement score from weighted reactions and comment count.
  • Presents top 3 candidates and plans implementation for the user's pick.

SKILL.md

.github/skills/pick-next-issueView on GitHub ↗
---
name: pick-next-issue
description: "Fetch and rank open GitHub issues by community engagement, present the top 3 candidates, and plan implementation for the selected issue. Use when the user asks to \"pick next issue\", \"next issue\", \"which issue should I work on\", \"top issues\", \"most popular issues\", \"prioritize issues\", or \"what should I work on next\"."
---

# Pick Next Issue

Rank open GitHub issues by engagement and plan the selected issue.

## Step 1: Fetch and Rank Issues

Run `gh issue list` to fetch open issues with engagement data:

```bash
gh issue list --state open --json number,title,url,reactionGroups,comments,labels,createdAt --limit 50
```

Calculate an engagement score for each issue:

- **Reactions score**: Sum all reaction counts from `reactionGroups` (thumbs up, heart, hooray, etc.). Weight thumbs-up (`THUMBS_UP`) reactions 2x since they signal explicit demand.
- **Comments score**: Count of comments on the issue.
- **Engagement score**: `(weighted reactions) + comments`

Sort issues by engagement score descending.

## Step 2: Present Top 3

Present the top 3 issues in a numbered list. For each issue, show:

1. **Title** with issue number and link
2. **Labels** (if any)
3. **Engagement**: reaction breakdown and comment count
4. **Created**: date
5. **First paragraph** of the issue body (truncate if long)

If fewer than 3 open issues exist, present all of them.

If no open issues exist, inform the user and stop.

## Step 3: User Picks an Issue

Ask the user to pick one of the presented issues (or request to see more).

If the user asks to **see more**, present the next 3 issues from the ranked list.

## Step 4: Read the Full Issue

Fetch the complete issue details for the selected issue:

```bash
gh issue view <number> --json number,title,body,url,labels,comments,reactionGroups,assignees,milestone
```

Read the full issue body and comments to understand the requirements and any discussion context.

## Step 5: Run `/turboplan` Skill

Run the `/turboplan` skill with the issue body as the task description. Tell turboplan that the plan must include a final implementation step: "Close issue #N or reference it in the PR with `Closes #N`."

## Rules

- Requires `gh` CLI authenticated with access to the current repo
- If `gh` fails (not in a repo, not authenticated), inform the user and stop
- Never modify issues. This skill is read-only until the implementation is committed.

More from tobihagemann/turbo

SkillDescription
answer-reviewer-questionsFor each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".
apply-findingsApply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".
assess-technical-debtAssess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to \"assess technical debt\", \"find technical debt\", \"review technical debt\", \"what should we refactor\", \"find refactoring candidates\", \"where is the code rot\", or \"what's our worst code\". Analysis-only — does not modify code.
changelog-rulesShared changelog conventions and formatting rules referenced by /create-changelog and /update-changelog. Not typically invoked directly.
claude-printRun a non-interactive Claude Code print-mode call from Codex. Use when the user asks to \"claude print\", \"ask claude\", \"run claude\", \"consult claude\", or when a Codex Turbo skill needs Claude as an independent peer reviewer.
code-styleEnforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.
codex-execRun autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".
commit-rulesShared commit message rules and technical constraints referenced by /stage-commit and /commit-staged. Not typically invoked directly.
commit-staged-pushCommit already-staged changes and push in one step. Use when the user asks to \"commit and push staged changes\", \"commit and push what's staged\", or \"commit staged and push\".
consult-claudeConsult Claude Code for second opinions, brainstorming, or difficult debugging from Codex. Use when the user asks to \"consult claude\", \"ask claude\", \"get claude's opinion\", \"brainstorm with claude\", or \"discuss with claude\".