First-contact triage for a GitHub issue
64
75%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Fix and improve this skill with Tessl
tessl review fix ./.mastracode/skills/triage-issue/SKILL.mdUse 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.
Use only these auto-triage labels:
auto-triaged — add after a successful triage comment for every issue processed by this skill.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.
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.>Severity guide:
Gather enough context to classify well. Keep this fast and bounded; do not perform deep code investigation.
Fetch issue details, labels, comments, author context, and state:
gh issue view "$ISSUE" --comments --json number,title,state,author,authorAssociation,assignees,labels,createdAt,updatedAt,body,comments,urlThen check:
Useful commands:
ISSUE_NODE_ID=$(gh issue view "$ISSUE" --json id -q .id)
gh api graphql -f query='query($id:ID!){ node(id:$id){ ... on Issue { closedByPullRequestsReferences(first:20){ nodes{ number title state url isDraft } } } } }' -f id="$ISSUE_NODE_ID"
gh issue list --search "<keywords>" --state all --json number,title,state,labels,url --limit 20Choose one primary type and one primary route. If multiple types apply, pick the route that best determines what a maintainer should do next.
| Type | Use when | Route | Approval label |
|---|---|---|---|
feature request | The issue asks for new behavior, API, product direction, or policy change. | Prepare approval unless it is already clearly accepted policy. | Usually add needs-approval. |
bug | The issue reports broken or unexpected behavior. | Investigate issue #<n> when actionable; Ask author for info when repro/details are missing. | Usually no approval label. Add only if closing/rejecting is uncertain or product policy is involved. |
docs | The issue is about docs, examples, wording, missing explanation, or docs/product-positioning mismatch. | Investigate issue #<n> or docs fix when actionable; ask for specifics if unclear. | Add only for broad positioning/product decisions. |
question/support | The issue asks how something works or needs usage help. | Answer directly and route to close when confident; ask for info when not. | Usually no approval label. |
duplicate | A matching issue already exists. | Close as duplicate, linking the canonical issue. | No approval label unless the duplicate call is uncertain. |
resolved | A closing/fixing PR or released change appears to have resolved it. | Close as resolved or route to the fixing PR. | No approval label unless uncertain. |
invalid / spam / out-of-scope | The report is not actionable for this repo or is abusive/irrelevant. | Close as <reason> with brief neutral explanation. | Add needs-approval if the close/reject decision needs maintainer sign-off. |
maintenance / other | It does not fit the above categories. | Choose the closest actionable route and state uncertainty. | Add only if approval/prep is required. |
When there is an explicit active PR that closes/fixes the issue, mention it in the comment and route toward that PR instead of starting issue investigation.
After the comment is posted or updated:
auto-triaged.needs-approval only if the selected route needs maintainer approval/prep.status: needs triage if present.If the next route is investigation, approval prep, docs work, or a linked fixing PR, name that route in the comment and stop after the issue update.
3b78ed9
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.