| name | issue-triage |
| description | Prioritize open issues by impact and difficulty. Use for backlog review, quick wins, or deciding what to work on next. |
| user_invocable | true |
| context | fork |
Triage all open issues and rank by difficulty/impact.
Worktree isolation
Before follow-on edits, follow the worktree isolation contract. It provides the atomic live-agent claim used below.
An existing worktree alone does not prove another agent is active.
wt is the only worktree tool. Never run git worktree add, and never use a harness worktree option such as EnterWorktree or isolation: "worktree". Those write to .claude/worktrees/, which is banned. wt places every worktree at <parent>/<repo>.<branch-slug>.
Triage stays read only and may use the primary checkout. Every follow-on implementation uses a task-owned worktree. Run wt list --format=json. Reuse the task's worktree with wt switch <branch>, or create one with wt switch --create <branch> --base <base>. Read its absolute path from the JSON, then pass that path as workdir to every later command.
Gotchas
- GitHub API rate limits --
gh issue list with --limit 100+ can hit rate limits on busy repos. If you get a 403, reduce the batch size or add --label filters.
- Stale issues -- issues older than 6 months with no recent activity are likely stale. Flag them separately rather than ranking alongside active issues.
- Misleading labels -- "good first issue" doesn't always mean low difficulty. Cross-check against the actual description before trusting the label.
- Body truncation --
gh issue list --json body truncates long bodies. For issues that need deeper analysis, fetch individually: gh issue view NUMBER --json body.
- Duplicate issues -- watch for multiple issues describing the same root cause. Group them and note the canonical issue number.
- Assigned != in progress -- stale assignments are common. Check if the assignee has recent activity on the issue before skipping it.
Data Storage
Track triage history to show deltas between runs:
echo "$(date -I) REPO TOTAL_ISSUES QUICK_WINS HIGH_PRIORITY" >> "${CLAUDE_PLUGIN_DATA}/triage-history.log"
On subsequent runs, read the log and highlight what changed since last triage.
Workflow
-
Determine repo and filters
- If
$ARGUMENTS provided, parse it:
- Bare value = repo name (e.g.,
nuxt/nuxt)
--label <name> = filter by label--limit <n> = override default 100
- Otherwise auto-detect:
gh repo view --json nameWithOwner -q .nameWithOwner
-
Fetch all open issues
gh issue list --repo <repo> --state open --limit <limit> --json number,title,labels,body,createdAt,author,comments,assignees
-
Parallel batch analysis
Split issues into batches of 10 and spawn parallel haiku classification agents (one per batch). Classification is cheap, mechanical extraction — haiku is the right tier. If <=10 issues, use a single agent.
For a large backlog (50+ issues), drive this with the Workflow tool: pipeline the batches through a classify stage (schema below) then a verify stage, so the schema is enforced and the verify pass runs per batch as it completes. This skill's instructions are the opt-in.
See references/heuristics.md for the full difficulty/impact scales and signal weighting.
Each agent returns a JSON array. Every entry has this shape. Reject and rerun malformed batches.
{ "number": 123, "difficulty": 2, "impact": 4, "hasRepro": true, "needsCodebaseReview":
