// Triage open issues by difficulty and impact. Use when user says "review issues", "triage issues", "what should I work on", "prioritize backlog", "rank issues", "find quick wins", or "what's high priority".
Triage inbox emails with himalaya. Use when user says "check email", "triage email", "email triage", "check inbox", "process email", "email me", "what emails do I have", "clear inbox", "inbox zero", "follow ups", "awaiting reply", "who hasn't replied", or "chase up".
Find deepening opportunities in a TypeScript package, leaning on TS-package-native seams (package.json `exports`, subpath/conditional exports, workspace `packages/*`, factories + hooks, plugin shapes, citty/hookable/unbuild conventions). Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a TS library/CLI/monorepo more testable and AI-navigable. Works on single-repo packages and pnpm monorepos.
Find deepening opportunities in a Nuxt codebase, leaning on Nuxt-native seams (hooks, modules, layers, plugins, composables, server routes, nitro, runtime config). Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a Nuxt app/module more testable and AI-navigable.
Use when user asks to "conform package", "check standards", "sync package", "audit project config", "update catalogs", "add github actions", "setup eslint", "configure vitest", "init package", "create npm package", "scaffold project", "init nuxt module", "create nuxt module", "scaffold module", "sync nuxt module", "add playground", "setup test fixtures", "configure @nuxt/test-utils", or needs help with pnpm workspace catalogs, obuild config, standard npm package architecture, Nuxt module architecture, runtime vs build-time code, addImports, addServerHandler, or nuxt-module-builder.
Strategic Product & Scope Review. Use this skill when planning a new feature, architecting a change, or reviewing a project's strategy. It challenges premises, maps ambition modes, and ensures zero silent failures.
Generate release notes for major/minor releases. Use when user says "release notes", "write release notes", "draft changelog", "prepare release announcement", "what changed since last release", or "generate upgrade guide".
| name | issue-triage |
| description | Triage open issues by difficulty and impact. Use when user says "review issues", "triage issues", "what should I work on", "prioritize backlog", "rank issues", "find quick wins", or "what's high priority". |
| user_invocable | true |
| context | fork |
Triage all open issues and rank by difficulty/impact.
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.gh issue list --json body truncates long bodies. For issues that need deeper analysis, fetch individually: gh issue view NUMBER --json body.Track triage history to show deltas between runs:
# After triage, save results
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.
Determine repo and filters
$ARGUMENTS provided, parse it:
nuxt/nuxt)--label <name> = filter by label--limit <n> = override default 100gh repo view --json nameWithOwner -q .nameWithOwnerFetch all open issues
gh issue list --repo <repo> --state open --limit <limit> --json number,title,labels,body,createdAt,author,comments,assignees
Parallel batch analysis (8-10x faster than sequential)
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 conforming exactly to this schema (reject and re-run any batch that returns malformed entries):
{ "number": int, "difficulty": 1-5, "impact": 1-5, "hasRepro": bool, "needsCodebaseReview": bool, "notes": string }
Merge results from all agents into unified list.
Adversarially verify the candidate quick wins. A wrong "difficulty 1, impact 4" recommendation costs the user a wasted worktree, so before presenting, spawn a haiku verifier per issue scored difficulty 1-2 AND impact 3+. Prompt it to refute the score: "Read issue #N. Is this genuinely a <=2-difficulty change with 3+ impact, or is there hidden scope (migration, API surface, cross-cutting state)? Default to downgrading if uncertain." Demote any issue the verifier refutes. Skip this pass for backlogs where no issue clears the quick-win bar.
Display table sorted by: has repro (yes first), then impact/difficulty ratio (descending)
| # | Title | Labels | Repro | Diff | Impact | Assigned | Notes |
|---|---|---|---|---|---|---|---|
| 42 | Fix CSS regression | bug | yes | 1 | 3 | 1-line fix | |
| 17 | Add dark mode | enhancement | n/a | 2 | 4 | @dev | PR in progress |
Highlight quick wins -- low difficulty (1-2), decent impact (2+), survived verification
Highlight high priorities -- impact 4-5 regardless of difficulty
Offer worktree setup -- prompt user with options:
For each selected issue, create an isolated worktree using wt (git worktree manager):
wt switch --create fix/<number>-<slug>
Where <slug> is a kebab-case short title (first 4-5 words). wt switch --create creates a new branch + worktree from current HEAD.
After creation, list worktrees with wt list so user can open them in separate sessions.