AI 编程里最烧时间的往往不是写代码，而是方向错了之后的返工：需求没问清就开工、查资料不标来源、调试靠猜、审查不对照原始需求。mattpocock/skills 这个开源仓库把这几类高发失败点分别固化成了小而可组合的 Skill，是观察”如何把专家经验沉淀为可复用能力”的好样本。

思路：不为基本功重复造轮子，只给易翻车的环节补流程

这个仓库的设计哲学很克制：主流 Coding Agent 已经能稳定完成的基础动作，不必每次重教；真正值得写成 Skill 的，是那些反复返工、且有明确方法论的环节。需求含糊，就补一段需求澄清流程；Bug 难查，就补一套诊断纪律；准备交付，就补一次对照需求的审查。每个 Skill 都保持小、可读、可修改、可组合。

这正是”固化专家经验”的标准做法：把高手面对某类问题时的判断顺序、不能省的步骤、容易踩的坑写成显性规则，让 Agent 每次按同样的纪律执行，而不是靠模型当场发挥。

四个代表性 Skill

grilling：把需求问清楚再动手

grilling 不是简单的”多问几个问题”，它把访谈纪律规定得很细：沿决策树往下走，一次只处理一个决定，因为前面的答案会改变后面的分支，不能像发问卷一样一口气抛出十几个问题；事实和决定严格分开——项目用了什么框架、现有接口怎么设计，Agent 应自己读代码和文档查证，而首期做哪个方案、要不要兼容旧行为、愿意承担多少复杂度，必须逐个问人；双方确认达成共同理解之前，不允许擅自开工。v1.1.0 还把确认步骤改成了显式停止条件，防止组合调用它的上层 Agent 顺手替用户做产品决定。

它适合范围未定的新需求；改一处文案、补一个空值判断这类验收标准明确的任务，直接做反而更省时间。担心访谈拉得太长，可以设置每轮 3～5 个问题的预算，但预算用完后 Agent 仍不能自行补齐剩余决定或直接开工。

research：把查资料变成可复查的交付物

升级 SDK、跨版本迁移时，”当前版本支持哪些参数、旧接口何时弃用”不该凭记忆回答，也不适合让主 Agent 一边改代码一边翻长文档。research 把问题交给后台 Agent，只查官方文档、源码、规范和第一方 API，结论写进仓库里的一个 Markdown 文件并标明来源，主 Agent 同时可以继续处理其他工作。它钉死了两件事：不拿二手教程替代官方资料，也不把几十页检索过程塞回主会话，只留下可复查的结论。只查一个方法签名时不必动用它；涉及版本迁移、协议差异或陌生依赖，再把这条支线交出去。

diagnosing-bugs：先建反馈环，再谈修复

Agent 排障最常见的错误是过早下判断：看到可疑分支就改，没修好再换下一个猜测，改动越堆越多，故障现象却始终没有被稳定复现。diagnosing-bugs 把最多的精力放在第一阶段——先做出一个能准确捕获当前 Bug 的反馈环：一条失败测试、一段固定输入的 curl 或 CLI、Playwright 脚本、线上请求回放均可，要求能捕获原故障、运行稳定、足够快、Agent 可以独立执行。确实无法复现时，它会列出已尝试的手段，再向用户申请可复现环境、HAR、日志或 core dump。

反馈环就位后，再列出 3～5 个可证伪的假设，按”如果它是原因，改变什么之后现象会如何变化”的预测加断点或定向日志；修复时把最小复现转成回归测试，看着它先失败再通过；收尾清掉临时日志和调试代码，把根因写进提交或 PR。

code-review：规范与需求分两条线审

很多审查只看实现质量，代码本身挑不出毛病，却实现错了需求。code-review 把审查拆成 Standards 与 Spec 两路并行 Subagent：前者读仓库自己的 CONTRIBUTING.md 和编码约定，仓库明文规则优先，内置的一组 Fowler Code Smells 只作判断线索、不能直接算违规；后者回到最初的 Issue、PRD 或技术方案，核对交付是否真的覆盖了原需求。审查前还要固定比较基点，基于 merge base 查看 HEAD 以来的 diff，而不是泛读整个仓库。两路结果最后合并，避免管风格的上下文干扰需求核对。CI、静态检查和人工领域审查仍然要保留，它并不替代。

技能文件的组织：规则集中，组合复用

仓库里最能体现组织功力的是访谈系列的分层：

grill-me ──────────> grilling
grill-with-docs ───> grilling + domain-modeling

grilling 是可复用的底层访谈 Skill，模型可以主动调用，用户和其他 Skill 也能复用；/grill-me 只是更明确的人工入口，负责启动一次访谈会话；/grill-with-docs 在此之上叠加 domain-modeling，把讨论中确定的领域术语写入 CONTEXT.md，把少量难以撤销的决定记录为 ADR。访谈规则只维护在 grilling 一处，其他 Skill 直接复用——规则不复制，变化只改一个地方。主文件保持短，细节按需加载，这与 Skill 生态”渐进式披露”的设计思路一致。

如何沉淀自己的技能库

这套仓库的用法本身也是方法论。安装通过 skills.sh 的安装器完成：

npx skills@latest add mattpocock/skills

安装器会让你挑选具体 Skill 和目标 Agent，不必全量装上。想体验需求访谈，先选 grill-me 和 grilling 就够。第一次使用建议限定在单个仓库，拿两三个真实任务观察返工次数、执行时间和产物质量：模型没有 Skill 也能稳定做好的环节，删掉；同一个问题反复出现的环节，留下对应的那一小段流程。团队采用”讨论 → Spec → Tickets → 实现 → 审查”整条链路时，再组合 tdd、to-spec、to-tickets 这类配套 Skill。

第三方 Skill 本质上是交给 Agent 执行的指令，安装前先读一遍它的 SKILL.md，检查 scripts、references 和权限要求。列表短一点没关系——知道每个 Skill 为什么还在，用起来反而省心。

小结

沉淀技能库的要义不在收集数量，而在对症下药：先找到自己工作流里反复返工的点，再把对应的专家流程写成小而有纪律的 Skill，并定期修剪。专家经验一旦显性化，就能被 Agent 稳定复用，而不是每次靠运气。