安装此技能
npx skills@latest add mattpocock/skills --skill=pr 然后在你的编码 agent 里输入 /pr 。
本页目录
它做什么
pr 定义一个 PR（pull request）正文（PR body）的形状：**摘要（Summary）**展示改动，**证据（Evidence）**证明它有效，**合并风险（Merge Danger）**判断落地有多危险。它是一份格式参考，不是一条流程。它不推送分支、不打开 PR，也不决定里面放什么。它告诉 agent 在写 PR 正文时该长什么样。
摘要是一幅图示（visual），不是一段文字。默认的 PR 正文用散文描述 diff。这一份挑选最小视图（smallest view），把要点讲清楚（伪代码、调用树、组件树、文件树、Mermaid 图，或者一份形状化的 diff），并让周围的文字保持简短。审查者已经打开了 diff，所以正文在他们读它之前先展示它的形状。
什么时候用它
输入 /pr，或者每当 agent 在写 PR 正文时，它会自动来拿它。
| 你的情形 | 该用哪个 |
|---|---|
| 一个分支准备好了，需要一段审查者能扫读的正文 | pr |
| 代码写完了，但还没有人审查过 | 先用 code-review，然后用 pr |
| PR 已经打开，审查评论正在回来 | 这套技能里暂时没有；pr 只写正文 |
模板
三个小节，按这个顺序：
- 摘要：一个或多个小图示，每一个都放在它所支撑的短文字旁边。用一个，有时用几个，很少全用。只保留审查者需要的调用、文件、props 和边界。
- 证据：一个改动前和改动后。当改动是视觉性的、而且环境（environment）能截图时，截图是最强的证据。否则，用那个先失败、现在通过的确切测试，写成伪代码，或者用发生变化的那段控制台输出。
- 合并风险：这个改动是一扇单向门（one-way door）还是一扇双向门（two-way door），以及它的爆炸半径（blast radius）。双向门撤销起来很便宜；单向门（一次破坏性迁移、一次公开 API 移除、一个难以逆转的决定）不是。爆炸半径点名如果改动错了、什么可能坏掉：布局偏移、某个 API 的消费方、移动端响应式。
门的判断（door call）是那个引导性的想法。它把「这个能安全合并吗？」从一种直觉变成一条明确的主张，审查者可以不同意。它还告诉审查者该把人工审查（human review）花在哪里。快速扫读一扇爆炸半径很小的双向门，慢慢读一扇单向门。
常见问题
我能相信 agent 自己的门的判断吗？
不能盲目相信，而这正是把它说出来的意义。写下这个改动的 agent 就是给它打分的那一个，所以当它说「双向门，爆炸半径很小」时，你最该怀疑。diff 也经常掩盖一个改动能否逆转。正如一位用户所说，「回滚一次提交并不能撤回一批已经发出的邮件」，而一次带开关的灰度发布，只有在第一次以新格式写入落地之前才是双向的。这个技能给 agent 的是一个定义（破坏性动作和难以逆转的决定是单向的），不是一张检查清单，所以要最仔细地检查合并风险那一行。两件事有帮助：确保 agent 面前有工单（ticket）或规范文档（spec），而不只是 diff；并把你的仓库一贯视为单向的改动（schema 迁移、任何向外发布或删除的东西）写在 agent 做判断之前会读到的地方。
它会替我把 PR 打开吗？
不会。pr 只覆盖正文。implement 以提交到当前分支结束。要求一个能打开 PR 的技能或选项（一个 /to-pr，或者让 implement 打开 PR 而不是提交）的请求，仍然是开放的提案。一位用户的变通办法是一句针对 implement 的本地覆盖，告诉它去打开一个 PR。implement-spec 是例外：当你的 issue 追踪器通过 PR 关闭工作，或者你主动要求时，它会打开一个草稿 PR。因为 pr 是模型（model）调用的，所以每当你让 agent 打开 PR 时，它都会用这个形状来写正文。
它不会只是产出另一大堆文字和图表吗？
这个技能在设计上就是防止那个的，但它仍然可能发生。用户对 agent 写的 PR 正文的抱怨很一致：「摘要很长，但我只需要知道改了什么、怎么验证的、什么可能坏、以及合并是否安全。」这个技能告诉 agent 跳过前言、让散文保持简短、挑选最小视图，通常用一幅图示，很少全用。如果你仍然拿到一摞图表，那是 agent 忽略了这个要求。如果正文巨大是因为 diff 巨大，那问题在于 PR 的大小，而 pr 不会替你拆分它。
我的仓库已经有一个 PR 模板了。哪一个赢？
默认情况下，谁都不赢。pr 有自己的模板，不会去找 .github/pull_request_template.md 或类似的东西。好几位用户要求这个技能使用仓库的模板。如果你什么都不做，agent 对同一份文档就有两条相互竞争的指令。在你的仓库 agent 文档里把它定下来，例如填写仓库模板，并在它下面放摘要、证据和合并风险。
输出是 HTML 吗？为什么 Mermaid 图不渲染？
输出是一个 markdown 的 PR 正文，不是一个 HTML 页面。GitHub 和 GitLab 会在 PR 描述里渲染 Mermaid 块，但终端不会，所以当 agent 还在本地给你看的时候，图看起来像原始文本。使用 CLI 运行环境的用户用 ASCII Mermaid 渲染器，或者让 agent 把一个 HTML 版本附到 PR 上，以此绕过这个问题。Mermaid 是六种视图之一。调用树、文件树或形状化的 diff 在哪里读起来都一样。
它能梳理回来的审查评论吗？
不能。它写完正文就停下。用户不止一次要求一种方式来分拣其他开发者或审查机器人留下的评论（哪些值得处理，哪些不算问题）。这个技能不做那件事。
它会随着 PR 变化而让正文保持最新吗？
不会。它在某一个时间点写下正文，而一个在审查中继续变化的 PR 会让那份正文过时。在大幅改动之后，让 agent 重写正文。agent 又是在写 PR 正文，所以它会用同样的形状。
我的改动没有 UI。证据里放什么？
除了截图之外的一切。只有当改动是视觉性的时候，截图才是最强的证据。对于一次迁移、一个后台任务或一次重构，证据是那个改动前失败、现在通过的确切测试，或者发生变化的那段控制台输出。仅凭「测试是绿的」是一条主张，不是一组前后对比。
它能把正文标记为由 LLM 写的吗？
它自己不能。一位用户的做法是在仓库的 agent 文档里放一条常驻指令：agent 写的每个 issue、评论和 PR 都以一行声明结尾。这条规则属于仓库，因为它覆盖 agent 发布的一切，而不是属于某一个文档类型的模板。
它生效的标志
- 只看摘要里的图示，在打开 diff 之前，你就能说出这个 PR 改了什么。
- 正文没有前言：它从摘要标题开始。
- 证据小节展示了一个改动前和一个改动后，而不是一句测试通过的断言。
- 每个 PR 都说明一扇门和一个爆炸半径，而你会放慢速度的是那些单向门。
它在体系中的位置
pr 在构建以 pull request 形式发布时，位于审查与复盘之间：to-spec → to-tickets → implement → code-review → pr → retro。它是模型调用的，所以当 agent 在那条链之外写 PR 正文时，它也会自己触发。
- code-review 在它之前运行，因为 PR 正文应当描述一个已经被审查过的 diff。
- implement 产出正文所描述的提交。
当你不确定情境想要哪个技能时，ask-matt 会在整套技能上为你路由。