Maintainers Triage Note【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastraCurrent Phase:TriagedNext Step:Review PR #n|Investigate issue #n|Ask author for info|Close as duplicate/invalid/spam|Approve CI checks before Review|Select fixing PR|Critical-path owner review|Continue to Approve|Await final approval|OtherTriage:Type: bug|feature request|docs|question/support|maintenance|duplicate|invalid|spam|other —Maintainer read: brief user-visible problem/goal and why this route was chosenRoute: Review PR #n|Investigate issue #n|Ask author for info|Close as duplicate/invalid/spam|Approve CI checks before Review|Select fixing PR|Critical-path owner review|OtherSeverity: critical| high| medium| low —Review:Status: not started|in progress|completeFindings: brief implementation/root-cause/check-risk summary, orNot reviewed yet.Confidence: Pending Review|1/5|2/5|3/5|4/5|5/5 — use only these exact values; no text labelsFollow-up: author/maintainer follow-up needed, orNone yet.Approve:Status: not started|waiting for final approval|approved|not approvedFinal approver: person or org/team, orNot identified yet.Notes: approval/merge/close/reopen guidance, orPending Review.使用该模板有两条严格约定 - **标题只放严重程度符号**、、 或 不附加文字而 Severity 字段则需要符号 标签 理由。 - **严重程度定义** critical 安全问题/数据丢失/服务中断/核心路径损坏 high 严重回归/工作流被阻塞 medium 真实但范围有限的 issue或文档/行为困惑 low 次要问题/支持类/重复/无效/垃圾/不清晰。 - **Confidence 只属于 Review 阶段**且取值必须严格是 Pending Review、1/5、2/5、3/5、4/5、5/5 之一**禁止使用 medium-high 这类自由文本**——这是为了让下游决策是否进入 Approve完全可程序化。 ## 核心产出物二Issue/PR Comment面向作者的沟通 当需要向作者索取信息、或解释为何重复/不可执行时使用独立的评论格式如下 markdown Thanks for opening this. Concise maintainer-facing response: what was found, what is needed, or why this is not actionable. If asking for info, list exactly what is needed. If duplicate, link the duplicate/closed issue or PR. If spam/invalid, keep it brief and neutral.使用边界很清晰常规 Review 产出不新建评论Review 结论一律写入已有的 Maintainers Triage Note只有当用户明确要求面向作者的消息时才单独发评论。交互模式下评论必须获得明确批准后才能发布headless 模式下则由分类结果直接决定输出并发布。此外当一条PR 的 triage note 路由了关联/关闭的 issue时还必须在每个关联 issue 上发一条简短评论并移除这些 issue 上已有的status: needs triage标签Thanks for opening this issue. This has been triaged and routed to PR #n for maintainer follow-up. Maintainers will continue the lifecycle tracking on that PR.Phase 1Triage 的四步走步骤 1解析输入必须提供一个 issue/PR 编号或 URL。缺失输入时交互模式直接询问并停止headless 模式则明确失败。类型解析规则/issues/n或issue n→ issue/pull/n或pr n→ PR裸数字 /#n调用 issue API若返回对象含pull_request字段则按 PR 处理。解析仓库与状态的参考命令OWNER_REPO$(gh repo view --json nameWithOwner -q .nameWithOwner) OWNER${OWNER_REPO%/*} REPO${OWNER_REPO#*/} gh api repos/$OWNER/$REPO/issues/number --jq {number, state, isPr: has(pull_request)}步骤 2委派 issue triage 给triage-issueskill如果解析结果是issuegh-triage 不直接处理而是激活 triage-issue skill原样透传 issue 编号/URL 和--headless标志Activate skill: triage-issue Arguments: issue number or URL [--headless]从 triage-issue SKILL.md 的源码可以看到该 skill 专门负责 issue 的一手接待first-contact intake收集上下文、分类、发布一条简洁的 issue 评论、打上最小化标签后停止。它的标签策略与 gh-triage 完全对齐status: auto-triaged— 每次成功发布 triage 评论后添加status: needs approval— 仅当推荐的下一个动作需要维护者审批/准备时才添加同时移除已存在的status: needs triage。triage-issue还内置了一张类型→路由→标签决策表bug、feature request、docs、question/support、duplicate、resolved、invalid/spam/out-of-scope、maintenance/other 各自对应什么路由、何时打status: needs approval并强调不承诺修复、不分配所有权、不关闭 issue、不暗示已获批准。只有当triage-issue完成 Triage 且所选下一步明确进入 Phase 2 Review 时控制权才交回 gh-triage。步骤 3收集 PR triage 上下文对于 PR先获取足够信息以完成分类和写 Note不做实现级审查gh pr view $PR --comments --json number,title,state,isDraft,author,authorAssociation,assignees,labels,createdAt,updatedAt,body,comments,url,mergeStateStatus,statusCheckRollup,closingIssuesReferences,files关键检查清单停止条件PR 非 open 或为 draft 时停止作者是核心贡献者authorAssociation为OWNER、MEMBER或COLLABORATOR时停止除非用户明确要求 triage关联 issue 状态PR 仅关联已关闭/已解决的 issue 时往往是重复或过期 PR记录变更文件、merge/冲突状态、CI 批准状态、已有的 Maintainers Triage NoteCI 处理Triage 期间忽略 Vercel checks不得将其当作阻塞或失败项引用若 CI workflow 正在等待批准或尚未获批不报告具体失败/挂起 check而是推荐Approve CI checks before Review只有 CI 已批准且 check 结果为真实失败时才报告非 Vercel 的失败项近期历史查看相关区域的 git 历史以辅助判断下一步、严重程度和可能审查者默认回溯 90 天仅在高频区域不活跃时才放宽关键路径比对对 PR 读取 CRITICAL_PATHS.md 并将变更文件与之比对。配套的参考命令ISSUE_NODE_ID$(gh issue view $ISSUE --json id -q .id) gh api graphql -f queryquery($id:ID!){ node(id:$id){ ... on Issue { closedByPullRequestsReferences(first:20){ nodes{ number title state url isDraft } } } } } -f id$ISSUE_NODE_ID gh api repos/$OWNER/$REPO/issues/$ISSUE/timeline --paginate --jq .[] | select(.eventcross-referenced) | {source:.source.issue | {number,title,state,pull_request,url}} # PR linked issue states gh pr view $PR --json closingIssuesReferences --jq .closingIssuesReferences[]? | {number,title,state,url} # Relevant-area history. For PRs, use changed files; for issues, infer the narrowest likely paths from labels/title/body/comments. RELEVANT_PATHpath/from/repo/root git log --since90 days ago --oneline --decorate -- $RELEVANT_PATH | head -20 git log --since90 days ago --format%h %ad %an %s --dateshort -- $RELEVANT_PATH | head -20步骤 4分类并路由五个案例Triage 必须以恰好一条主输出路由收尾。五个案例的分工如下Case A无关 / 重复 / 已解决 / 不清晰 / 可疑 / 不可执行适用于暂不应启动 Review 的一切场景spam、无关、无效、不支持、明显超范围缺少复现/细节重复 issue/PR输入 PR 仅关联已关闭/已解决 issue暗示 PR 重复、过期或不再需要issue 已被关闭/合并的 PR 或之前的维护者答复解决PR 代码或附件可疑恶意、窃取凭据、数据外泄风险。Next StepsClose as reasonspam/invalid/duplicate/resolved/suspiciousAsk author for info补充具体细节即可行动Escalate suspicious security risk代码恶意/不安全不得进入常规 ReviewApprove CI checks before ReviewCI 未批准Wait for author/checks阻塞来自外部Review 尚早。Output只发 issue/PR comment不创建/更新 Maintainers Triage Note除非用户显式覆盖路由。交互式确认Does this look non-actionable, or is there context that makes it worth Review?Case B关键路径Critical Path当 active PR 的变更文件命中 CRITICAL_PATHS.md 时触发。该资源文件是 Mastra 维护者的脆性代码路径清单每条记录一个文件或 glob、必须审查的 GitHub 所有者以及原因。例如packages/core/src/loop/loop.ts→ 所有者TylerBarnes、CalebBarnes、abhiaiyer91理由核心 agent 执行循环排序、流式、工具调用与恢复行为都汇聚于此packages/core/src/workflows/workflow.ts→ 所有者rase-、taofeeq-deru、abhiaiyer91理由主 workflow 引擎实现状态转换与恢复行为高度耦合packages/core/src/mastra/index.ts→ 所有者wardpeet、abhiaiyer91理由连接 agents、tools、workflows、storage、telemetry 的根框架枢纽。CRITICAL_PATHS 资源还规定了两条特殊规则外部贡献者非mastra-ai组织成员改动packages/core/src/loop/loop.ts或packages/deployer/**时自动关闭 PR附礼貌评论建议改为提 issue其余命中路径则把清单中列出的所有 owner 添加为 reviewer并在 triage 评论中列出每个命中路径及原因。Output遵循资源输出自动关闭/评论或请求/添加 owner 并发布一条精炼 Note点名命中路径、owner 和原因默认跳过 Review不激活understand-pr、不创建工作文件除非用户明确要求。交互式确认This touches a critical path. Post the critical-path triage output and stop here?Case C单个 PR 待审查适用于输入本身就是 active PR或恰好有一个 active PR 明确关闭/修复该 issue且关联 issue 状态不足以判定 PR 明显重复/过期。前置检查关联/关闭的 issue 是 open 的或 PR 独立修复了一个仍然有效的问题没有更强的 active PR 处理同一问题draft/非 open 状态已排除。Next StepsCI 已批准或 Review 前无需 check 时选Review PR #nCI workflow 等待批准时选Approve CI checks before Review。Output发布 Maintainers Triage Note包含关联 issue 状态、变更区域、非 Vercel 阻塞项、CI 批准建议如相关、以及为何该 PR 是 Review 目标若 PR 有关联/关闭 issue还需准备每条关联 issue 的 triage 评论。交互式确认Should this PR be the Review target?Case D多个候选 PR适用于多个 active PR 明确关闭/修复同一 issue 或解决同一现存问题。Next Steps 为Select one fixing PR for Review除非其中某个 PR 明显是正确目标或为选中 PR 追加 CI 批准建议。OutputNote 中列出候选 PR 及每行的下一步事实关联 issue 状态、CI 批准状态、明显的非 Vercel 阻塞项不做深层实现对比选中 PR 有关联 issue 时同样准备各关联 issue 的评论。交互式确认Which PR should move to Review?Case EIssue 调查适用于open issue 且没有明确关闭/修复它的 active PR且信息足以开展调查。Next Step 为Investigate issue #n。OutputNote 中包含可能区域、已知证据、缺失但非阻塞的上下文、以及为何先做 issue 调查而非 PR Review除非信息不足而回退到 Case A否则 Triage 阶段不发布面向作者的评论。交互式确认Should this issue move to Review as an investigation?步骤 5发布/更新 Note 或评论然后暂停Case A发评论、移除status: needs triage如存在、停止不得进入 ReviewCase B按 CRITICAL_PATHS 输出、移除标签、停止除非用户显式要求进入 ReviewCase C-E更新已有 Note否则新建发布后移除status: needs triage带关联 issue 的 PR note 路由发布 PR note 后在每条关联 issue 上发 triage 评论再移除这些 issue 上的status: needs triage--headless完成分类、发布所选输出、按需移除标签、退出不做确认暂停不进入 Review交互模式展示所选草稿、推荐路由、发布前询问除非已被要求。交互模式下的选项模板Triage output is ready: Case A issue/PR comment|critical-path output|Maintainers Triage Note|Maintainers Triage Note linked issue comment(s). Recommended next step: Review PR #n|Investigate issue #n|Ask author for info|Close as reason|Approve CI checks before Review|Select fixing PR|Critical-path owner review. A) Post the selected Triage output and stop here B) Show/edit the draft before posting C) The triage read is wrong — let me explain D) Post the selected Triage output, then continue to Review E) Do not post — stop here注意选项 D 只在 Case C-E 提供Case A-B 永远不提供若输出已自动发布则将发布选项替换为已发布内容的简短摘要并停止。Phase 2Review —— 一个工作文件 一个配套 skill只有用户显式选择后才进入。写完工作文件不能停必须继续激活配套 skill、走完其交互式 Review 流程再回头更新已有的 Maintainers Triage Note。步骤 1准备唯一的 Review 工作文件PR Review.pr-review/GH_TRIAGE_PR_pr-number.md由 PR diff 和路由上下文构建gh pr diff $PR --patch gh pr view $PR --comments --json number,title,url,author,body,comments,reviews,mergeStateStatus,statusCheckRollup,closingIssuesReferences,filesIssue Review.issue-review/GH_TRIAGE_ISSUE_issue-number.md由 issue body、comments、timeline、labels、候选 PR 和路由问题构建。文件只应包含 Review 上下文输入 URL/编号、所选路由、Maintainers Triage Note 的评论 URL/id如有、相关事实、以及留给 skill 的问题。不要把 Note 模板或评论模板嵌入工作文件——它只是内部 Review 上下文绝不是 Phase 2 的最终输出。步骤 2激活配套 skill 并走完 ReviewActivate skill: understand-pr Arguments: PR number or URL --working-file .pr-review/GH_TRIAGE_PR_pr-number.mdActivate skill: understand-issue Arguments: issue number or URL --working-file .issue-review/GH_TRIAGE_ISSUE_issue-number.md以 understand-pr SKILL.md 为例其核心哲学是先真正理解 PR再形成观点包含七阶段PR Goal目标确认→ Quality GateCI/测试/changeset/作者验证等质量门槛→ History Context每个变更文件的 git log/blame、周边架构、测试质量→ Walkthrough逐块过 diff→ Understanding Check可选小测验→ Opinion Exchange先听用户观点再坦诚分享→ Review Comment按需起草。它强调所有回复都要短小、信息密集、以字母选项收尾且未经明确批准绝不发布评论。当携带--working-file时skill 默认不提供 PR 评论而是把 Review 发现写回工作文件交还调用方处理生命周期输出。understand-issue SKILL.md 则面向 issue/缺陷的协同调查识别 issue支持从分支名如fix/1234提取 issue 号→ 检索相关问题/先前工作 → 初步调查从症状追到代码→ 诊断先判断 issue 本身是否成立XY problem、配置/用户错误、文档缺口、按设计工作、还是真 bug→ 交互式深挖 → 理解质量门 → 理解文件 → 可选分享到 GitHub。多个候选 PR 时先询问先审哪个no-action 路由不进入 Review除非用户纠正路由。步骤 3更新已有 NotePhase 2 结束前必须把 Review 发现更新进已有的 Maintainers Triage Note不要新增独立评论或 PR review 作为生命周期输出除非用户要求面向作者的消息。选项模板Review output is ready: update the existing Maintainers Triage Note. A) Update the existing Maintainers Triage Note with Review findings B) Show me the proposed note update first C) Update the note, then draft a separate author-facing comment D) Continue Review before updating anything更新时编辑同一条评论Current Phase: Reviewed、顶层Next Step: Continue to Approve、精炼的 Review 发现、精确的 Confidence 值1/5–5/5、Approve 仍为 pending。更新后不要用完成摘要收尾直接询问是否继续 Approve。Phase 3Approve —— 找到唯一的最终审批人仅当 Review 完成度足以进行最终维护者路由时才进入。不得 merge、close、打标签、assign 或改变 PR/issue 状态。步骤 1确定唯一的最终审批人基于工作文件中的已审查文件/区域先查 CODEOWNERS依次查找.github/CODEOWNERS、CODEOWNERS、docs/CODEOWNERS。Mastra 仓库实际就配有完整的 .github/CODEOWNERS例如packages/core/src/workflows/对应rase- taofeeq-deru abhiaiyer91/stores/对应NikAiyer abhiaiyer91/docs/对应LekoArts PaulieScanlon bookercodes除非 PR 明确改动 docs 或引入了需要文档跟进的功能否则不列出文档维护者CODEOWNERS 清晰时使用一个匹配的user或org/team提及不清晰时用受影响路径的近期历史选一位有近期上下文的人只有确认的 GitHub 用户名才用仍不清晰则写明No clear final approver identified并给出简短理由。参考命令find .github . docs -name CODEOWNERS -maxdepth 2 2/dev/null git log --since6 months ago --format%an %ae -- path | sort | uniq -c | sort -rn | head -10步骤 2展示 Approve 选项并收尾Review is ready for final approval routing. Final approver: person/org/team or no clear approver — short reason. A) Update the Maintainers Triage Note as waiting for final approval with this approver B) Show me the proposed note update first C) Pick a different final approver D) Do not update anything — stop here【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考