用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/mastra-ai/mastra --skill triage-issue命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Triage a Factory work item's issue — trace history, understand architecture, diagnose root cause, then advance the stage
Review open mastra-ai/mastra GitHub issues, identify direct @mastra/core bugs, and apply the @mastra/core label. Use when auditing issues for core ownership, labeling direct core bugs, or periodically reconciling the @mastra/core issue label.
Re-review a pull request after a push — reconcile the previous review against the new commits, look for new defects the push introduced, then a fresh pass over the whole PR, and finish with a verdict on the PR
正在显示 SKILL.md
| name | triage-issue |
| description | First-contact triage for a GitHub 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.
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.
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 #| | | ////| / |>
<🔴 critical|🟠 high|🟡 medium|🟢 low> —
—
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,url
Then 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 20
Choose 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 status: 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 status: 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:
status: auto-triaged.status: 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.