Triage

Process

1. Fetch available labels — run gh label list --json name,description to understand the label taxonomy. Labels are organized into type, effort, priority, and area categories.

2. Fetch target issues — based on the scope above. For each issue, fetch the full body:

   gh issue view {number} --json number,title,body,labels
   

3. For each issue:

   • Read the title and full body carefully
   • If needed, explore the codebase (Glob, Grep, Read) to understand the affected code
   • Classify: one type, one effort, one priority, one or more areas
   • Track relationships with other issues (duplicates, related, blocking)
   • Apply labels:

     gh issue edit {number} --add-label "type,effort/level,P#,area.domain"
     

   • Skip issues that already have complete labeling (type + effort + priority + area)
   • For partially labeled issues, only add missing label categories

4. Output a triage summary:

   ## Triage Summary
   
   | Issue | Title | Labels Applied | Reasoning |
   |-------|-------|----------------|-----------|
   | #67 | ... | bug, effort/low, P1, core.config | ... |
   
   **Totals:**
   - Issues triaged: X
   - Already labeled (skipped): Y
   - By priority: P0(n), P1(n), P2(n), P3(n)
   
   ## Relationships Discovered
   
   | Issues | Relationship | Notes |
   |--------|--------------|-------|
   | #61, #62 | Related | Both involve config/logging UX |
   

Rules

• Don't hardcode labels — always fetch current labels first, they may change
• Respect existing labels — don't remove labels, only add missing ones
• Check issue body — titles alone aren't enough context
• Use the codebase — if understanding a relationship requires seeing how modules connect, look
• When uncertain, note it — flag ambiguous issues in the summary rather than guessing