| name | triage-issues |
| description | Triage open GitHub issues by reviewing unlabeled ones and applying the most appropriate labels based on their content |
| targets | ["*"] |
Triage Open Issues
Review all open GitHub issues that currently have no labels and apply the most appropriate labels based on their content.
Step 1: List Available Labels
Fetch the full list of labels defined in this repository so the triage stays within the known label set:
gh label list --limit 100
Treat this list as the authoritative vocabulary. Do not invent new labels.
Step 2: Find Unlabeled Open Issues
Fetch all open issues that have no labels attached:
gh issue list --state open --search "no:label" --limit 100 --json number,title,author,url
If the result is empty, report that nothing needs triage and stop.
Step 3: Gather Context per Issue
For each unlabeled issue, read the description and the discussion so the label choice is grounded in the actual content:
gh issue view <issue_number>
gh issue view <issue_number> --comments
Run these in parallel across issues where practical.
Step 4: Decide the Labels
For each issue, pick the labels that best describe it. Typical signals:
bug — something is broken or behaves incorrectly.enhancement — a new feature, new tool/feature support, or a capability request.documentation — docs, README, or docs/**/*.md changes.refactoring — internal restructuring without behavior change.improvement — quality, DX, or polish work that isn't a bug or a new feature.question — the author is asking for clarification or usage help.duplicate — already tracked by another issue (link it in a comment if you apply this).invalid / wontfix — only if the issue itself states this or the content clearly indicates it; otherwise skip.good first issue — small, well-scoped, approachable for newcomers.help wanted — maintainer explicitly wants external contribution; do not apply speculatively.considering — proposals that are worth discussing but not yet accepted.high priority — explicit urgency signals (regression, blocking users, security). Be conservative.security — security-relevant reports or hardening work.codex — specific to the Codex CLI integration.maintainer-scrap — do NOT add this unless the issue body explicitly says so; it's reserved for maintainer-only scratch notes.
Guidelines:
- Prefer a small, precise set of labels (usually 1–3). Do not over-label.
- Combine a type label (
bug / enhancement / documentation / refactoring / improvement / question) with optional modifiers (good first issue, considering, security, codex) when they clearly apply.
- If the issue is ambiguous or you cannot confidently choose labels, skip it and note it in the final report rather than guessing.
Step 5: Apply the Labels
Apply the chosen labels using gh issue edit. Example:
gh issue edit <issue_number> --add-label "bug" --add-label "good first issue"
Only add labels; do not remove existing ones (these issues have none by definition, but be defensive).
Step 6: Report
Output a concise summary grouped by action:
Labeled: #<number> <title> → label1, label2 (one line per issue)Skipped (ambiguous): #<number> <title> → short reason
Keep the report compact; do not repeat the full issue bodies.
