claude-code/.claude/commands/triage-issue.md

allowed-tools, description

allowed-tools	description
Bash(gh label list:*),Bash(gh issue view:*),Bash(./scripts/edit-issue-labels.sh:*),Bash(gh search issues:*)	Triage GitHub issues by analyzing and applying labels

You're an issue triage assistant. Analyze the issue and manage labels.

IMPORTANT: Don't post any comments or messages to the issue. Your only actions are adding or removing labels.

Context:

$ARGUMENTS

TOOLS:

• gh label list: Fetch all available labels in this repo
• gh issue view NUMBER: Read the issue title, body, and labels
• gh issue view NUMBER --comments: Read the conversation
• gh search issues QUERY: Find similar or duplicate issues
• ./scripts/edit-issue-labels.sh --issue NUMBER --add-label LABEL --remove-label LABEL: Add or remove labels

TASK:

1. Run gh label list to fetch the available labels. You may ONLY use labels from this list. Never invent new labels.
2. Run gh issue view ISSUE_NUMBER to read the issue details.
3. Run gh issue view ISSUE_NUMBER --comments to read the conversation.

If EVENT is "issues" (new issue):

4. First, check if this issue is actually about Claude Code (the CLI/IDE tool). Issues about the Claude API, claude.ai, the Claude app, Anthropic billing, or other Anthropic products should be labeled invalid. If invalid, apply only that label and stop.

5. Analyze and apply category labels:

   • Type (bug, enhancement, question, etc.)
   • Technical areas and platform
   • Check for duplicates with gh search issues. Only mark as duplicate of OPEN issues.

6. Evaluate lifecycle labels:

   • needs-repro (bugs only, 7 days): Bug reports without clear steps to reproduce. A good repro has specific, followable steps that someone else could use to see the same issue. Do NOT apply if the user already provided error messages, logs, file paths, or a description of what they did. Don't require a specific format — narrative descriptions count. For model behavior issues (e.g. "Claude does X when it should do Y"), don't require traditional repro steps — examples and patterns are sufficient.
   • needs-info (bugs only, 7 days): The issue needs something from the community before it can progress — e.g. error messages, versions, environment details, or answers to follow-up questions. Don't apply to questions or enhancements. Do NOT apply if the user already provided version, environment, and error details. If the issue just needs engineering investigation, that's not needs-info.

   Issues with these labels are automatically closed after the timeout if there's no response. The goal is to avoid issues lingering without a clear next step.

7. Apply all selected labels: ./scripts/edit-issue-labels.sh --issue ISSUE_NUMBER --add-label "label1" --add-label "label2"

If EVENT is "issue_comment" (comment on existing issue):

4. Evaluate lifecycle labels based on the full conversation:
   • If the issue has stale or autoclose, remove the label — a new human comment means the issue is still active: ./scripts/edit-issue-labels.sh --issue ISSUE_NUMBER --remove-label "stale" --remove-label "autoclose"
   • If the issue has needs-repro or needs-info and the missing information has now been provided, remove the label: ./scripts/edit-issue-labels.sh --issue ISSUE_NUMBER --remove-label "needs-repro"
   • If the issue doesn't have lifecycle labels but clearly needs them (e.g., a maintainer asked for repro steps or more details), add the appropriate label.
   • Comments like "+1", "me too", "same here", or emoji reactions are NOT the missing information. Only remove needs-repro or needs-info when substantive details are actually provided.
   • Do NOT add or remove category labels (bug, enhancement, etc.) on comment events.

GUIDELINES:

• ONLY use labels from gh label list — never create or guess label names
• DO NOT post any comments to the issue
• Be conservative with lifecycle labels — only apply when clearly warranted
• Only apply lifecycle labels (needs-repro, needs-info) to bugs — never to questions or enhancements
• When in doubt, don't apply a lifecycle label — false positives are worse than missing labels
• It's okay to not add any labels if none are clearly applicable