Triage GitHub issues using the gh CLI. Analyzes new issues to apply labels, assess priority, detect duplicates, and optionally assign owners. Use when user asks to triage issues, label issues, check for duplicates, prioritize backlog, or process incoming issues. Triggers on phrases like 'triage issue #N', 'triage issues', 'label this issue', 'is this a duplicate', 'prioritize issue', 'process new issues in repo'.
Triage GitHub issues: label, prioritize, detect duplicates, and assign.
gh CLI installed (apt install gh if missing)gh auth status to verify)Determine mode:
owner/repo + issue numberowner/repo + filter (e.g., unlabeled issues)bash scripts/fetch_issue.sh <owner/repo> <issue_number>
bash scripts/list_labels.sh <owner/repo>
Cache this per-repo; labels rarely change mid-session.
Extract key terms from title/body, then search:
bash scripts/find_duplicates.sh <owner/repo> "<key terms>"
If likely duplicate found:
duplicate labelDetermine primary type from content:
| Type | Indicators |
|---|---|
bug | "error", "crash", "doesn't work", "broken", stack traces |
feature | "add", "would be nice", "request", "enhancement" |
docs | "documentation", "typo", "README", "unclear" |
question | "how do I", "is it possible", "?", support-style asks |
security | "vulnerability", "CVE", "exploit", "injection" |
chore | "upgrade", "dependency", "refactor", "tech debt" |
Evaluate based on:
| Signal | Priority Impact |
|---|---|
| Security issue | → Critical |
| Data loss potential | → Critical |
| Blocks many users | → High |
| Workaround exists | → Lower |
| Edge case | → Lower |
| Reactions (👍 count) | Higher count → Higher priority |
| Author is maintainer/contributor | May indicate importance |
Priority labels (adapt to repo conventions):
priority: critical — Security, data loss, wide breakagepriority: high — Significant impact, no workaroundpriority: medium — Normal bugs/featurespriority: low — Minor issues, nice-to-havesIf repo uses area labels (e.g., area/api, area/ui, component/auth), identify from:
gh issue edit <issue_number> --repo <owner/repo> \
--add-label "bug,priority: high,area/api"
If repo has CODEOWNERS or known maintainers per area:
gh issue edit <issue_number> --repo <owner/repo> \
--add-assignee "<username>"
Only assign if:
For complex issues or when clarification needed:
gh issue comment <issue_number> --repo <owner/repo> --body "<comment>"
Comment templates:
Needs more info:
Thanks for reporting! To help us investigate, could you provide:
- Steps to reproduce
- Expected vs actual behavior
- Environment details (OS, version, etc.)
Duplicate detected:
This appears to be a duplicate of #<original>. Closing in favor of that issue.
Please add any additional context there. Reopen if this is actually distinct.
Triaged successfully:
Triaged: labeled as `<labels>`, priority `<priority>`.
<optional: assigned to @user or "Added to backlog for future planning.">
Provide user with:
Include:
To triage multiple issues:
# List unlabeled open issues
gh issue list --repo <owner/repo> --label "" --state open --limit 20
Then loop through each, applying the single-issue workflow.
For large backlogs, summarize findings:
## Triage Summary
| Issue | Type | Priority | Labels Applied | Notes |
| ----- | ---- | -------- | -------------- | ------------ |
| #42 | bug | high | bug, area/api | — |
| #43 | dup | — | duplicate | Dup of #12 |
| #44 | feat | medium | enhancement | Needs design |
Issue lacks detail: Label needs-info, post comment requesting details, don't set priority yet.
Security issue: Label security, set critical priority, avoid discussing details publicly. Suggest private disclosure if repo supports it.
Issue is actually a PR or discussion: Redirect author to correct venue, close issue.
Author is first-time contributor: Be welcoming in tone; they may not know repo conventions.
Contentious/heated issue: Triage factually; don't engage in debates. Flag for maintainer attention if needed.
Before reporting completion:
If the harness supports command files, use commands/triage-issue.md as the canonical entrypoint for this skill.