Mastra 项目中的 understand-pr 技能基于 gh CLI 的引导式 PR 审查方法论【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra导读understand-pr是 Mastra 仓库.mastracode/skills/understand-pr/SKILL.md中定义的一项 AI 编码辅助技能它把一次 PR 审查组织为从目标认知到质量门禁再到历史考古最后到意见形成的七阶段引导式流程。本文以该技能文档为主体结合仓库中实际配套的 changeset 配置、废弃命令与姊妹技能完整还原这套基于ghCLI 的 PR 理解方法论并给出每条命令的用途、参数与执行顺序让读者能直接复刻到自己的开源项目协作流程中。understand-pr 是什么先理解再评论该技能在 frontmatter 中自我定位为Guided interactive PR review — understand the history and context before forming opinions引导式交互式 PR 审查——在形成观点之前先理解历史与上下文。它面向的是仓库维护者核心主张是审查者在形成观点、起草评论之前必须真正理解这个 PR 要做什么、为什么存在、以及它建立在怎样的历史之上。这一点在 critique-pr 命令 的弃用说明中得到了印证——该命令被标记为 Deprecated — activate the understand-pr skill instead理由是旧命令鼓励把批判性思维外包给代理而没有真正理解 PR、受影响的代码区域、架构或历史。understand-pr 取代它的方式是让 PR 审查变得协作式与考古式collaborative and archaeological先建立深层历史上下文追踪架构再与审查者一起基于证据形成观点而不是对着 diff 表面读一遍就生成评论。从文件组织看understand-pr 与 understand-issue 是一对姊妹技能前者处理理解一个 PR 的变更后者处理理解一个 Issue 的根因二者共享同一套gh交互式调查范式。Setup运行前的前置约定技能规定了启动前的五步准备每一步都对应明确的 CLI 命令解析入参从$ARGUMENTS中解析 PR 编号和可选的--working-file path。处理 working-file如果传入了--working-file先验证文件存在并读取它把它视为调用方提供的上下文按其交接指令执行并把调查发现回写到同一文件该文件不被视为最终面向用户的输出。如果文件不存在而参数被传入直接告知用户并结束。校验分支确认当前检出的分支与 PR 的 head 分支一致。拉取 PR 元数据gh pr view --json title,body,commits,files,labels,number,headRefName,author拉取完整 diffgh pr diff识别当前用户gh api user --jq .login红线规则未经明确批准绝不发布任何评论。技能文档特别提醒了一个容易踩坑的 Shell 细节gh输出经常包含会破坏jq解析的 ANSI 颜色码因此应优先使用gh内建的--jq标志而不是管道给jq或者给命令加上NO_COLOR1前缀。这也是整个技能中所有查询命令反复使用--jq的原因。People识别参与人及其上下文深度在开始分析前先弄清楚有哪些人牵涉其中PR 作者是维护者、常规贡献者还是首次提交的社区贡献者用gh api repos/{owner}/{repo}/collaborators/{author} --silent判断404 表示不是 collaborator。当前审查者即运行此命令的用户你是 PR 作者本人自审还是其他人。关联 Issue 的作者如果 PR 引用了 Issue这些 Issue 是谁开的是与 PR 作者同一人还是别人报告问题、PR 声称修复对每个被识别的人统计其在该仓库的合并 PR 数gh pr list --author login --state merged --limit 100 --json number --jq length。对关联 Issue 的作者额外统计其 Issue 数gh issue list --author login --state all --limit 100 --json number --jq length。这一步的价值在于评估每个人的上下文深度——首次贡献者需要的审查关注度与有 50 合并 PR 的常客完全不同高产 Issue 报告者的 bug 报告权重也不同于首次报障者。Linked Issues阅读关联 Issue如果 PR 描述或提交引用了 Issue例如 fixes #1234、closes #456 或仅仅 ##789立即读取它们gh issue view number --json title,body,labels,comments,author,state理解最初报告了什么、由谁报告、预期的修复形态是什么并检查 Issue 讨论中是否包含 PR 描述未提及的上下文。技能强调这是理解 PR Goal 的关键上下文——关联 Issue 往往比 PR 描述本身更能解释这个 PR 为什么存在。Phase 1: PR Goal——先对齐要做什么在讲历史和质量之前必须先让用户知道这个 PR 试图做什么。该阶段要求给出凝练的目标摘要解决什么问题、为什么存在、预期产出是什么并且必须落实在 PR 描述、提交消息和关联 Issue 上——fixes a bug 这种表述不够具体。技能特别要求如果 PR 改变了任何公共 API、导出的接口、CLI 命令、配置项或面向用户的行为要展示从用户视角看的前后对比。例如开发者代码会如何变化、有哪些新选项可用、导入方式有何不同——不要只描述内部实现要展示对使用者的影响。然后暂停给出字母选项让用户确认A) That matches my understanding — continue B) I think the goal is actually different — let me explain C) Im not sure what this PR is solving — dig deeper只有用户确认理解了 PR 目的后才进入质量门禁。Phase 2: Quality Gate——最低质量门槛在投入历史研究前先用gh pr checks检查 CI 状态然后评估是否达到最低门槛CI 是否通过构建、类型检查、测试若 CI 仍在运行注明并按带保留意见继续。是否新增或修改了测试从表面看是否有意义深度分析留到 Phase 3。diff 是否聚焦——是聚焦的变更还是混入无关改动的 WIP 垃圾堆。Changeset 检查如果仓库使用 changesets查看是否存在.changeset/目录任何改变运行时行为、修复 bug 或新增特性的 PR 都必须附带 changeset。缺失 changeset 属于质量门禁失败必须明确标出。是否满足其他仓库要求文档更新、AGENTS.md 更新等。作者验证PR 作者是否声明过亲自验证变更可用查找类似 tested locally、verified this fixes…、复现证据、截图或测试输出的表述。如果描述和评论中完全没有任何作者实际运行或测试过变更的迹象就要标记出来——若用户选择起草评论Phase 7这应作为提问提出。明显的红旗损坏的模式、被移除的安全检查、巨大的无关 diff。若未达标直接告知用户This PR isnt ready for detailed review yet: - [specific reasons] A) Review it anyway — I want to understand whats here B) Help me draft feedback to the author about what needs fixing C) Stop here仓库中的 changeset 实践Mastra 仓库确实在根目录维护了.changeset/目录.changeset/config.json 配置了baseBranch: main、access: public、通过fixed字段将mastra/core、mastra/server、mastra/deployer等包绑定在一起同步发版并用ignore白名单只对mastra、create-mastra、create-factory、mastracode、mastra/*等公开包生成变更记录。仓库中现存大量如all-bats-joke.md、cloudflare-sandbox-shell-command.md之类的 changeset 文件说明每个影响行为的 PR 都必须附带 changeset在该仓库是真实执行的硬约束。配套的 pr 命令 提供了创建 changeset 的标准做法pnpm changeset -s -m your changeset message (--major | --minor | --patch) pkg-name其中-s/--skipPrompt用于非交互式运行、-m指定消息--major/--minor/--patch分别对应破坏性变更、向后兼容的新特性、向后兼容的 bug 修复。该命令还强调了一个反模式警示一个 changeset 文件里塞进多个包会导致多个包的 changelog 出现巨大条目应当为逻辑分组分别创建 changeset。这与 understand-pr 质量门禁中检查 changeset 是否存在的规则构成了完整的闭环——先由 AI 在审查时发现缺失再由配套命令补齐。Phase 3: History Context——历史考古通过质量门禁后进入最核心的历史挖掘阶段目标是理解我们如何走到这一步、当前方案是否合理。Git 历史对 PR 中修改的每个文件git log --oneline -20 -- file——查看最近的提交历史git log --oneline --all -20 -- file——捕捉跨分支的活动在具体变更区域PR 之前的版本状态上使用git blame弄清当前代码是谁、何时写的追踪相关变更——若 PR 触及某个函数追踪其调用方并检查它们最近是否也有变更查看提交消息中关联的 Issue 或引用的 PR架构与周边代码阅读变更区域周边的代码而不只是变更行本身需要理解模块/包的架构以及变更代码在其中的位置与变更代码交互或依赖它的周边功能变更代码参与的接口、类型与契约数据在该代码区域中的流动方式变更包中相关的 AGENTS.md、README 或文档文件测试PR 是否新增或修改了测试仔细阅读。测试是否真正验证了声称的行为还是仅执行了代码路径而没有有意义的断言对照代码库中相似功能的测试模式——PR 是否遵循了这些模式还是更弱测试是否覆盖了边界情况和失败模式如果 PR 没有测试是否应该加Approach方案是否自洽综合历史与既定目标判断方案是否合理是在用正确的方式解决问题还是在与既有设计对抗如果结合代码库历史存在更简单、更一致的方案要指出来。产出理解产物如果提供了 working file把学到的东西和交接指令要求的输出写回同一文件否则在工作区根目录写.artifacts/understand-pr/HISTORY.md记录每个变更文件/模块为什么存在、最初解决什么问题它如何演化、塑造当前状态的关键提交近期活跃度——该区域是在被积极开发还是长期休眠变更代码如何融入更广阔的架构可能受影响的周边功能与依赖历史与代码库确立的模式或约定测试质量评估——测试是否有意义方案评估——PR 方案是否契合既有设计随后逐个文件/逻辑区域交互式呈现历史每次呈现后提供定制化的跟进选项A) Why was [specific thing] added originally? B) Who else has changed this recently? C) Show me the related code that depends on this D) I understand this part — move on选项必须针对实际内容定制禁止使用通用占位选项。直到用户看完全部主要变更区域的历史并表示就绪才进入 Phase 4。Phase 4: Walkthrough——逐块走读 diff带着 Phase 3 的历史上下文逐块走读 PR diff。对每一块展示改了什么保持简短——用户自己能读 diff结合刚讲过的历史解释为什么重要标记任何与既有模式矛盾、有风险或引发疑问的地方提供跟进选项A) What breaks if this change is wrong? B) Are there tests covering this path? C) Show me the surrounding code D) Next change同样要求选项量身定制。保持怀疑态度可疑之处直接说出来扎实之处不浪费笔墨夸奖。对于改动文件很多的大 PR按逻辑区域分组让用户选择先探索哪个区域而不是按字母序逐个文件过。Phase 5: Understanding Check——理解校验走读完成后提供三个选择Weve been through all the changes. Want to: A) Quick quiz to test your understanding B) Revisit a specific area C) I understand — lets move to opinions若用户选择测验出 3-5 道关于该 PR 的多选题——代码做什么、为何做这些决策、风险是什么。技能强调这些必须是真正检验理解的题不是送分题答错时要清楚解释并提议重访该区域。Phase 6: Opinion Exchange——先听后说在用户充分理解 PR 之后先征求用户的意见Ive formed my own opinion on this PR, but Id like to hear yours first. What do you think — is this ready to merge? Any concerns?等待用户回应然后坦诚分享自己的意见同意处同意、不同意处不同意不要为了迎合而软化立场。要点出合并前应修复的事项风险与未知缺失的测试、文档、changeset 或其他仓库要求值得肯定的地方简要Phase 7: Review Comment——按需起草与发布评论如果传入了--working-file默认不提供 PR 评论而是把 Review 结论写入 working file 后交还调用方处理生命周期输出。否则在意见交换后询问是否起草评论Want me to draft a review comment? Options: A) Draft a full review comment B) Draft a short approval/comment C) No comment needed起草后全文展示并提供迭代选项按原样发布 / 缩短 / 更详细 / 调整语气 / 编辑特定部分 / 不发布反复迭代直到用户满意或决定不发布。未经用户明确要求绝不发布。发布走 REST API 避开 GraphQL 限流技能明确建议用 REST API 发布评论以避开 GraphQL 的速率限制并给出了完整的 Bash 片段cat /tmp/pr-comment.md EOF Comment body here. EOF body$(jq -Rs . /tmp/pr-comment.md) gh api repos/:owner/:repo/issues/PR_NUMBER/comments \ -X POST \ -H Content-Type: application/json \ --input - EOF {body:$body} EOF发错内容时用 PATCH 修正关键细节把文件内容作为请求体传递而不是把file当作字面量 bodybody$(jq -Rs . /tmp/pr-comment.md) gh api repos/:owner/:repo/issues/comments/COMMENT_ID \ -X PATCH \ -H Content-Type: application/json \ --input - EOF {body:$body} EOF遇到速率限制错误时用gh api rate_limit --jq .rate检查 REST 配额。贯穿全程的交互设计原则understand-pr 技能文档通篇贯彻一套强约束的交互协议这也是它与传统一次性输出长评论式审查工具的本质区别不产生文字墙walls of text每条回复都要短、密、信息密度高。一律以字母选项收尾A/B/C/D用户只需敲一个字母即可继续把多轮会话的摩擦降到最低。最小化废话直接且信息密集每个阶段都以停下来确认收束确保人与代理在认知上同步而不是让代理自顾自输出结论。用户驱动用户选择探索哪些区域、何时认为自己理解够了代理不强行推进固定序列。与仓库中相关命令和技能的关系understand-pr 不是孤立存在的Mastra 仓库的 .mastracode 目录是一个完整的 AI 辅助开发工作流体系critique-pr 命令被 understand-pr 取代的旧命令弃用说明精确记录了这次演进的设计动机。understand-issue 技能面向 Issue 调查的姊妹技能同样包含 People 识别、Phase 化流程、working-file 机制以及绝不未授权发帖的硬规则。selfreview 命令面向作者自己的批判性自审Must fix / Risks / Suggested improvements 三段式输出与 understand-pr 形成自审 他审的互补。gh-pr-comments 命令处理 PR 评论回复的配套命令规定了与 coderabbitai 机器人评论交互的方式。pr 命令补全 changeset 创建与 PR 提交流程。这些文件共同说明understand-pr 是 Mastra 项目自带的、被设计为取代粗暴评论生成器的协作式审查标准流程它的价值不止于单次审查而在于让审查者无论人还是代理在形成意见前真正走完目标对齐 → 质量门禁 → 历史考古 → 逐块走读 → 理解校验 → 意见交换的完整认知链路。对于任何在开源项目中使用ghCLI 进行代码评审的团队这套方法论都可以直接迁移复用。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mastra 项目中的 understand-pr 技能：基于 gh CLI 的引导式 PR 审查方法论
Mastra 项目中的 understand-pr 技能基于 gh CLI 的引导式 PR 审查方法论【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra导读understand-pr是 Mastra 仓库.mastracode/skills/understand-pr/SKILL.md中定义的一项 AI 编码辅助技能它把一次 PR 审查组织为从目标认知到质量门禁再到历史考古最后到意见形成的七阶段引导式流程。本文以该技能文档为主体结合仓库中实际配套的 changeset 配置、废弃命令与姊妹技能完整还原这套基于ghCLI 的 PR 理解方法论并给出每条命令的用途、参数与执行顺序让读者能直接复刻到自己的开源项目协作流程中。understand-pr 是什么先理解再评论该技能在 frontmatter 中自我定位为Guided interactive PR review — understand the history and context before forming opinions引导式交互式 PR 审查——在形成观点之前先理解历史与上下文。它面向的是仓库维护者核心主张是审查者在形成观点、起草评论之前必须真正理解这个 PR 要做什么、为什么存在、以及它建立在怎样的历史之上。这一点在 critique-pr 命令 的弃用说明中得到了印证——该命令被标记为 Deprecated — activate the understand-pr skill instead理由是旧命令鼓励把批判性思维外包给代理而没有真正理解 PR、受影响的代码区域、架构或历史。understand-pr 取代它的方式是让 PR 审查变得协作式与考古式collaborative and archaeological先建立深层历史上下文追踪架构再与审查者一起基于证据形成观点而不是对着 diff 表面读一遍就生成评论。从文件组织看understand-pr 与 understand-issue 是一对姊妹技能前者处理理解一个 PR 的变更后者处理理解一个 Issue 的根因二者共享同一套gh交互式调查范式。Setup运行前的前置约定技能规定了启动前的五步准备每一步都对应明确的 CLI 命令解析入参从$ARGUMENTS中解析 PR 编号和可选的--working-file path。处理 working-file如果传入了--working-file先验证文件存在并读取它把它视为调用方提供的上下文按其交接指令执行并把调查发现回写到同一文件该文件不被视为最终面向用户的输出。如果文件不存在而参数被传入直接告知用户并结束。校验分支确认当前检出的分支与 PR 的 head 分支一致。拉取 PR 元数据gh pr view --json title,body,commits,files,labels,number,headRefName,author拉取完整 diffgh pr diff识别当前用户gh api user --jq .login红线规则未经明确批准绝不发布任何评论。技能文档特别提醒了一个容易踩坑的 Shell 细节gh输出经常包含会破坏jq解析的 ANSI 颜色码因此应优先使用gh内建的--jq标志而不是管道给jq或者给命令加上NO_COLOR1前缀。这也是整个技能中所有查询命令反复使用--jq的原因。People识别参与人及其上下文深度在开始分析前先弄清楚有哪些人牵涉其中PR 作者是维护者、常规贡献者还是首次提交的社区贡献者用gh api repos/{owner}/{repo}/collaborators/{author} --silent判断404 表示不是 collaborator。当前审查者即运行此命令的用户你是 PR 作者本人自审还是其他人。关联 Issue 的作者如果 PR 引用了 Issue这些 Issue 是谁开的是与 PR 作者同一人还是别人报告问题、PR 声称修复对每个被识别的人统计其在该仓库的合并 PR 数gh pr list --author login --state merged --limit 100 --json number --jq length。对关联 Issue 的作者额外统计其 Issue 数gh issue list --author login --state all --limit 100 --json number --jq length。这一步的价值在于评估每个人的上下文深度——首次贡献者需要的审查关注度与有 50 合并 PR 的常客完全不同高产 Issue 报告者的 bug 报告权重也不同于首次报障者。Linked Issues阅读关联 Issue如果 PR 描述或提交引用了 Issue例如 fixes #1234、closes #456 或仅仅 ##789立即读取它们gh issue view number --json title,body,labels,comments,author,state理解最初报告了什么、由谁报告、预期的修复形态是什么并检查 Issue 讨论中是否包含 PR 描述未提及的上下文。技能强调这是理解 PR Goal 的关键上下文——关联 Issue 往往比 PR 描述本身更能解释这个 PR 为什么存在。Phase 1: PR Goal——先对齐要做什么在讲历史和质量之前必须先让用户知道这个 PR 试图做什么。该阶段要求给出凝练的目标摘要解决什么问题、为什么存在、预期产出是什么并且必须落实在 PR 描述、提交消息和关联 Issue 上——fixes a bug 这种表述不够具体。技能特别要求如果 PR 改变了任何公共 API、导出的接口、CLI 命令、配置项或面向用户的行为要展示从用户视角看的前后对比。例如开发者代码会如何变化、有哪些新选项可用、导入方式有何不同——不要只描述内部实现要展示对使用者的影响。然后暂停给出字母选项让用户确认A) That matches my understanding — continue B) I think the goal is actually different — let me explain C) Im not sure what this PR is solving — dig deeper只有用户确认理解了 PR 目的后才进入质量门禁。Phase 2: Quality Gate——最低质量门槛在投入历史研究前先用gh pr checks检查 CI 状态然后评估是否达到最低门槛CI 是否通过构建、类型检查、测试若 CI 仍在运行注明并按带保留意见继续。是否新增或修改了测试从表面看是否有意义深度分析留到 Phase 3。diff 是否聚焦——是聚焦的变更还是混入无关改动的 WIP 垃圾堆。Changeset 检查如果仓库使用 changesets查看是否存在.changeset/目录任何改变运行时行为、修复 bug 或新增特性的 PR 都必须附带 changeset。缺失 changeset 属于质量门禁失败必须明确标出。是否满足其他仓库要求文档更新、AGENTS.md 更新等。作者验证PR 作者是否声明过亲自验证变更可用查找类似 tested locally、verified this fixes…、复现证据、截图或测试输出的表述。如果描述和评论中完全没有任何作者实际运行或测试过变更的迹象就要标记出来——若用户选择起草评论Phase 7这应作为提问提出。明显的红旗损坏的模式、被移除的安全检查、巨大的无关 diff。若未达标直接告知用户This PR isnt ready for detailed review yet: - [specific reasons] A) Review it anyway — I want to understand whats here B) Help me draft feedback to the author about what needs fixing C) Stop here仓库中的 changeset 实践Mastra 仓库确实在根目录维护了.changeset/目录.changeset/config.json 配置了baseBranch: main、access: public、通过fixed字段将mastra/core、mastra/server、mastra/deployer等包绑定在一起同步发版并用ignore白名单只对mastra、create-mastra、create-factory、mastracode、mastra/*等公开包生成变更记录。仓库中现存大量如all-bats-joke.md、cloudflare-sandbox-shell-command.md之类的 changeset 文件说明每个影响行为的 PR 都必须附带 changeset在该仓库是真实执行的硬约束。配套的 pr 命令 提供了创建 changeset 的标准做法pnpm changeset -s -m your changeset message (--major | --minor | --patch) pkg-name其中-s/--skipPrompt用于非交互式运行、-m指定消息--major/--minor/--patch分别对应破坏性变更、向后兼容的新特性、向后兼容的 bug 修复。该命令还强调了一个反模式警示一个 changeset 文件里塞进多个包会导致多个包的 changelog 出现巨大条目应当为逻辑分组分别创建 changeset。这与 understand-pr 质量门禁中检查 changeset 是否存在的规则构成了完整的闭环——先由 AI 在审查时发现缺失再由配套命令补齐。Phase 3: History Context——历史考古通过质量门禁后进入最核心的历史挖掘阶段目标是理解我们如何走到这一步、当前方案是否合理。Git 历史对 PR 中修改的每个文件git log --oneline -20 -- file——查看最近的提交历史git log --oneline --all -20 -- file——捕捉跨分支的活动在具体变更区域PR 之前的版本状态上使用git blame弄清当前代码是谁、何时写的追踪相关变更——若 PR 触及某个函数追踪其调用方并检查它们最近是否也有变更查看提交消息中关联的 Issue 或引用的 PR架构与周边代码阅读变更区域周边的代码而不只是变更行本身需要理解模块/包的架构以及变更代码在其中的位置与变更代码交互或依赖它的周边功能变更代码参与的接口、类型与契约数据在该代码区域中的流动方式变更包中相关的 AGENTS.md、README 或文档文件测试PR 是否新增或修改了测试仔细阅读。测试是否真正验证了声称的行为还是仅执行了代码路径而没有有意义的断言对照代码库中相似功能的测试模式——PR 是否遵循了这些模式还是更弱测试是否覆盖了边界情况和失败模式如果 PR 没有测试是否应该加Approach方案是否自洽综合历史与既定目标判断方案是否合理是在用正确的方式解决问题还是在与既有设计对抗如果结合代码库历史存在更简单、更一致的方案要指出来。产出理解产物如果提供了 working file把学到的东西和交接指令要求的输出写回同一文件否则在工作区根目录写.artifacts/understand-pr/HISTORY.md记录每个变更文件/模块为什么存在、最初解决什么问题它如何演化、塑造当前状态的关键提交近期活跃度——该区域是在被积极开发还是长期休眠变更代码如何融入更广阔的架构可能受影响的周边功能与依赖历史与代码库确立的模式或约定测试质量评估——测试是否有意义方案评估——PR 方案是否契合既有设计随后逐个文件/逻辑区域交互式呈现历史每次呈现后提供定制化的跟进选项A) Why was [specific thing] added originally? B) Who else has changed this recently? C) Show me the related code that depends on this D) I understand this part — move on选项必须针对实际内容定制禁止使用通用占位选项。直到用户看完全部主要变更区域的历史并表示就绪才进入 Phase 4。Phase 4: Walkthrough——逐块走读 diff带着 Phase 3 的历史上下文逐块走读 PR diff。对每一块展示改了什么保持简短——用户自己能读 diff结合刚讲过的历史解释为什么重要标记任何与既有模式矛盾、有风险或引发疑问的地方提供跟进选项A) What breaks if this change is wrong? B) Are there tests covering this path? C) Show me the surrounding code D) Next change同样要求选项量身定制。保持怀疑态度可疑之处直接说出来扎实之处不浪费笔墨夸奖。对于改动文件很多的大 PR按逻辑区域分组让用户选择先探索哪个区域而不是按字母序逐个文件过。Phase 5: Understanding Check——理解校验走读完成后提供三个选择Weve been through all the changes. Want to: A) Quick quiz to test your understanding B) Revisit a specific area C) I understand — lets move to opinions若用户选择测验出 3-5 道关于该 PR 的多选题——代码做什么、为何做这些决策、风险是什么。技能强调这些必须是真正检验理解的题不是送分题答错时要清楚解释并提议重访该区域。Phase 6: Opinion Exchange——先听后说在用户充分理解 PR 之后先征求用户的意见Ive formed my own opinion on this PR, but Id like to hear yours first. What do you think — is this ready to merge? Any concerns?等待用户回应然后坦诚分享自己的意见同意处同意、不同意处不同意不要为了迎合而软化立场。要点出合并前应修复的事项风险与未知缺失的测试、文档、changeset 或其他仓库要求值得肯定的地方简要Phase 7: Review Comment——按需起草与发布评论如果传入了--working-file默认不提供 PR 评论而是把 Review 结论写入 working file 后交还调用方处理生命周期输出。否则在意见交换后询问是否起草评论Want me to draft a review comment? Options: A) Draft a full review comment B) Draft a short approval/comment C) No comment needed起草后全文展示并提供迭代选项按原样发布 / 缩短 / 更详细 / 调整语气 / 编辑特定部分 / 不发布反复迭代直到用户满意或决定不发布。未经用户明确要求绝不发布。发布走 REST API 避开 GraphQL 限流技能明确建议用 REST API 发布评论以避开 GraphQL 的速率限制并给出了完整的 Bash 片段cat /tmp/pr-comment.md EOF Comment body here. EOF body$(jq -Rs . /tmp/pr-comment.md) gh api repos/:owner/:repo/issues/PR_NUMBER/comments \ -X POST \ -H Content-Type: application/json \ --input - EOF {body:$body} EOF发错内容时用 PATCH 修正关键细节把文件内容作为请求体传递而不是把file当作字面量 bodybody$(jq -Rs . /tmp/pr-comment.md) gh api repos/:owner/:repo/issues/comments/COMMENT_ID \ -X PATCH \ -H Content-Type: application/json \ --input - EOF {body:$body} EOF遇到速率限制错误时用gh api rate_limit --jq .rate检查 REST 配额。贯穿全程的交互设计原则understand-pr 技能文档通篇贯彻一套强约束的交互协议这也是它与传统一次性输出长评论式审查工具的本质区别不产生文字墙walls of text每条回复都要短、密、信息密度高。一律以字母选项收尾A/B/C/D用户只需敲一个字母即可继续把多轮会话的摩擦降到最低。最小化废话直接且信息密集每个阶段都以停下来确认收束确保人与代理在认知上同步而不是让代理自顾自输出结论。用户驱动用户选择探索哪些区域、何时认为自己理解够了代理不强行推进固定序列。与仓库中相关命令和技能的关系understand-pr 不是孤立存在的Mastra 仓库的 .mastracode 目录是一个完整的 AI 辅助开发工作流体系critique-pr 命令被 understand-pr 取代的旧命令弃用说明精确记录了这次演进的设计动机。understand-issue 技能面向 Issue 调查的姊妹技能同样包含 People 识别、Phase 化流程、working-file 机制以及绝不未授权发帖的硬规则。selfreview 命令面向作者自己的批判性自审Must fix / Risks / Suggested improvements 三段式输出与 understand-pr 形成自审 他审的互补。gh-pr-comments 命令处理 PR 评论回复的配套命令规定了与 coderabbitai 机器人评论交互的方式。pr 命令补全 changeset 创建与 PR 提交流程。这些文件共同说明understand-pr 是 Mastra 项目自带的、被设计为取代粗暴评论生成器的协作式审查标准流程它的价值不止于单次审查而在于让审查者无论人还是代理在形成意见前真正走完目标对齐 → 质量门禁 → 历史考古 → 逐块走读 → 理解校验 → 意见交换的完整认知链路。对于任何在开源项目中使用ghCLI 进行代码评审的团队这套方法论都可以直接迁移复用。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考