Triage Issue

Use this skill for first-contact intake on one GitHub issue. Gather enough context to classify the issue, choose the next route, post or update one concise issue comment, apply the minimal triage labels, and stop.

Keep the work focused on first-contact intake: classify the issue, explain the route, update the issue, and stop. If the issue needs technical investigation after triage, route it to Investigate issue #<number> so a follow-on understand-issue run can do that work.

Label policy

Use only these auto-triage labels:

• status: auto-triaged, add after a successful triage comment for every issue processed by this skill.
• status: needs approval, add only when the recommended next action needs maintainer approval or prep before someone should investigate, implement, close, or reject.

Also remove status: needs triage after the triage comment is posted or updated, if that label is present.

Apply only the labels listed above.

Output contract

Triage ends with one GitHub-visible issue comment. Update an existing auto-triage comment when possible instead of adding duplicates.

Use this shape:

Thanks for opening this.

**Triage:** <bug|feature request|docs|question/support|maintenance|duplicate|resolved|invalid|spam|out-of-scope|other>, <one-sentence classification>
**Route:** <Investigate issue #n|Prepare approval|Ask author for info|Close as duplicate/resolved/invalid/spam/out-of-scope|Answer provided / close|Other>
**Severity:** <🔴 critical|🟠 high|🟡 medium|🟢 low>, <short reason>
**Confidence:** <high|medium|low>, <short reason>
**Next step:** <concise maintainer-facing next action>

<Short explanation with the concrete evidence used, what was not checked if relevant, and why this route was chosen.>

<If asking for info, list the exact missing details. If duplicate/resolved, link the issue or PR. If answering a question, give the answer briefly and say it can be closed if no follow-up is needed.>