本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。
Agent 创建的 PR 描述普遍是垃圾：冗长、罗列文件、复述 diff、没有证据、不看合并风险。
这是 AI Coding 的大背景下，越来越严重的问题。各路大神也开始输出自己的思考和方案，其中 Matt Pocock (264K🌟 Skills For Real Engineers 作者) 和 dex (HumanLayer 创始人) 的方案和思考过程，值得学习！Matt 提议并最终落地了一个 /pr skill，dex 把 HumanLayer 内部捆绑的 visual-pr skill 开源出来，最后 dex 又抛出了一个更架构层的追问：skills 之间怎么互相复用？
Matt 的 /pr skill：核心设计
Matt 的 PR #1092 经历了三次重写，最终的形态很克制，值得注意的取舍：
定位是“格式参考”，不是“工作流”。 它不碰 git、不校验 diff、不执行 gh pr create——只规定 PR body 应该长什么样。Matt 认为一旦加入“最后创建 PR”这类动作步骤，skill 的性质就从参考文档变成了操作流程，模型注意力会被机制分散。这个“reference vs. workflow”的划分他自己也承认是实验性的。
PR body 模板五个部分，每一部分都针对一种具体的审查摩擦：
| 部分 | 解决的问题 |
| --- | --- |
| Summary | 必须来自一手来源（issue/规格）而非 diff——diff 只回答“怎么做”，不回答“为什么” |
| Size and door | 开头声明变更规模 + 是单向门还是双向门（借亚马逊的决策框架：单向门 = 不可逆，需慢审；双向门 = 可回滚，可快合） |
| The shape of the change | 几乎逐字复用 dex 的 show-me 方法，用最小的图/diff 草图展示结构 |
| Evidence | 前后对比对，视觉优先——单个 after 截图只能证明“现在能用”，不能证明“是这个 diff 改变了它” |
| Left out on purpose | 主动写出审查者本来要自己去找的缺口 |这套设计的本质是：PR body 的读者是 reviewer，不是写者的自我陈述。每一节都在压缩 reviewer 的认知成本，而不是展示 agent 干了多少活。
dex 的 visual-pr 与 show-me
从 SKILL.md 原文看，两者是“积木 + 组装”的关系：
show-me 是纯表达层：约定了一组最小可视化语法——伪代码（逻辑）、调用树（控制流）、组件树（UI 结构）、浅层文件树（职责/重构）、Mermaid 时序图（交互）、以及 diff 块（“变化本身”才是重点时）。核心原则是“选最小能说清问题的视图，不要全用”。这部分 Matt 直接署名引用进了自己的 skill。
visual-pr 是工作流层：它是一个会真正动手的 skill——检查当前分支 PR、必要时提交推送并创建 PR、读 ticket 和完整 diff、套用模板写描述、gh pr edit 发布。模板比 Matt 的更紧：Why 一句话、Special notes 最多 3 条、Change outline 用 show-me 语法而非文件级 changelog。两者恰好构成了 Matt 那个“reference vs. workflow”划分的两个侧面——dex 走 workflow 路线，Matt 最终走了 reference 路线。
dex 的第三个问题：skills 之间怎么互相复用？
这是三篇里与 Skills 架构最相关的部分。dex 观察到大家开始把 show-me 当积木（他自己内部到处是 grill-me + show-me 的混搭，Matt 也在 vendor 它），于是提出一个轻量的 vendoring 方案：把依赖 skill 的 SKILL.md 内容作为 reference 内联进主 skill，不去 fork 整个仓库导致与上游脱钩。他称之为“kustomize for markdown”；不做完整的包管理器，只做声明式的混搭/补丁。
这个判断是准的：当前 skills 生态（Claude Code plugins、npx skills 等）没有依赖机制，复用的唯一手段就是复制粘贴，而复制必然 fork。Matt 的 CREDITS.md 逐字引用就是这种手工 vendoring 的活例；上游一改，他就烂了。dex 的方案本质上是把版本管理问题从“社会契约”（署名 + 手动同步）变成“技术机制”（声明 + 自动拉取）。
