Matt Pocock 开源的mattpocock/skills是一套面向真实工程工作的 AI Agent 技能库。它把需求澄清、领域建模、TDD、Bug 诊断、代码评审、任务拆分、PRD 编写等工程动作拆成一组可以被 Claude Code / Codex 等 Agent 调用的 skills。使用它的重点是让 Agent 按一套清晰流程协助工程工作。一、mattpocock-skills 提供了什么mattpocock/skills是 Matt Pocock 维护的一组 AI Agent Skills面向 Claude Code、Codex 等编码代理。它围绕工程工作流提供了一组互相配合的技能能力方向代表技能用途选择流程ask-matt根据当前任务判断该走哪条 skill flow需求澄清grill-me、grill-with-docs、grilling通过连续提问把想法问清楚项目初始化setup-matt-pocock-skills配置 issue tracker、triage labels、domain docs领域建模domain-modeling维护项目术语、CONTEXT.md和 ADR任务拆分to-prd、to-issues把对话变成 PRD再拆成可执行 issue实现implement、tdd按 issue/PRD 实现并用 TDD 推进Bug 诊断diagnosing-bugs建立反馈循环、复现、最小化、修复架构改进codebase-design、improve-codebase-architecture发现深模块机会改善代码结构评审code-review从 Standards 和 Spec 两条轴检查改动上下文交接handoff把当前会话整理成可延续的交接文档学习与写作teach、writing-great-skills用 Agent 辅助学习或编写更好的 skills从使用者视角看它提供的是一个工程协作工具箱当你要澄清需求、拆任务、实现功能、排查问题、评审代码时都能找到对应的 skill。二、skills结构它是怎么组织起来的mattpocock-skills 提供了一套清晰的插件结构不只是把SKILL.md放在目录里。核心目录大致是这样mattpocock-skills/ ├── .claude-plugin/ │ └── plugin.json ├── skills/ │ ├── engineering/ │ ├── productivity/ │ ├── deprecated/ │ ├── in-progress/ │ ├── misc/ │ └── personal/ ├── docs/ │ ├── engineering/ │ └── productivity/ ├── .agents/ ├── scripts/ ├── CONTEXT.md ├── README.md └── package.json真正作为插件暴露给 Claude Code 的是.claude-plugin/plugin.json里列出的技能。本地这份配置注册了 20 个正式技能分类技能Engineeringask-matt、diagnosing-bugs、grill-with-docs、triage、improve-codebase-architecture、setup-matt-pocock-skills、tdd、to-issues、to-prd、implement、prototype、research、domain-modeling、codebase-design、code-reviewProductivitygrill-me、grilling、handoff、teach、writing-great-skills这点很重要skills/目录里还有deprecated、in-progress、misc、personal等目录但它们不一定属于默认暴露面。真正应该被用户稳定依赖的是插件清单里注册的正式技能。另外还有几类支撑文件文件/目录作用CONTEXT.md记录这个技能仓库自己的领域语言比如 Issue tracker、Issue、Triage roledocs/engineering/、docs/productivity/为每个正式 skill 生成或维护说明文档.agents/Agent 写文档、调用规则、ADR 等协作约定scripts/list-skills.sh列出仓库里的所有SKILL.mdscripts/link-skills.sh维护者本地开发用把技能软链到~/.claude/skills和~/.agents/skills.changeset/记录技能变更用于版本发布从实现上看它把 Skill 当作一个可发布、可演进、可维护的软件包来组织。三、如何安装和初始化安装方式很直接npx skillslatest add mattpocock/skills安装时需要选择要安装到哪些 coding agents并确保选中/setup-matt-pocock-skills安装后在 Agent 里运行/setup-matt-pocock-skills这个初始化技能会配置其它 engineering skills 依赖的项目级信息配置项用途Issue tracker告诉to-issues、to-prd、triage等技能应该把 issue 写到 GitHub、GitLab、本地 markdown还是其它系统Triage labels告诉triage技能每个状态角色对应哪个真实 labelDomain docs告诉domain-modeling、tdd、diagnosing-bugs等技能项目的CONTEXT.md和 ADR 在哪里初始化技能会生成或更新几类文档文件作用docs/agents/issue-tracker.md记录 issue tracker 工作方式docs/agents/triage-labels.md记录 triage role 到真实 label 的映射docs/agents/domain.md记录领域文档布局是单上下文还是多上下文AGENTS.md或CLAUDE.md的 Agent skills 区块告诉 Agent 这些配置在哪里完成这一步后其它技能才知道该从哪里读 issue、写文档、查领域语言、应用 triage 标签。四、两类技能用户主动调用与模型自动触发mattpocock-skills把技能分成两类类型谁来触发作用User-invoked用户手动输入例如/grill-me编排流程启动一段明确的工作Model-invoked用户或模型都可以触发承载可复用纪律例如 TDD、调试、代码评审这个分类很关键。如果所有 skill 都让模型自动触发系统提示会变重Agent 每一轮都要带着一大堆触发描述增加上下文负担。如果所有 skill 都只能用户手动触发又会增加用户记忆成本你得记得什么时候该输入哪个命令。所以 Matt Pocock 的做法是编排型 skill 多数由用户主动触发纪律型 skill 可以被模型自动调用用户主动触发的 skill 可以组合模型触发型 skill用户主动触发的 skill 不再互相调用避免编排层层嵌套比如/grill-with-docs是用户主动调用的技能它会启动一次需求拷问并结合 domain modeling 去沉淀术语和架构决策。而tdd、diagnosing-bugs、codebase-design这类技能则更像工程纪律可以被其它流程引用。五、核心使用流程从想法到交付本地实现里ask-matt把主要工作流描述成一条idea → ship的路线。可以把它理解成这套 skills 的推荐用法1. /ask-matt 不知道该用哪个 skill 时先让它路由。 2. /grill-with-docs 对一个功能想法进行需求澄清同时沉淀领域语言和 ADR。 3. 必要时 /prototype 如果某个设计问题靠讨论说不清用一个可丢弃原型回答。 4. /to-prd 把已经讨论清楚的需求整理成 PRD。 5. /to-issues 把 PRD 拆成可独立执行的垂直切片 issue。 6. /implement 每个 issue 单独实现内部尽量走 /tdd。 7. /code-review 完成后从 Standards 和 Spec 两条轴检查改动。如果当前任务只覆盖其中一部分也可以直接从中间进入当前任务推荐入口不知道该用哪个技能/ask-matt有一个模糊想法/grill-with-docs没有代码仓库只想澄清一个计划/grill-me已经有 PRD要拆 issue/to-issues已经有一个明确 issue要实现/implement只想 test-first 做一个小功能/tdd遇到难排 bug/diagnosing-bugs代码库结构越来越难改/improve-codebase-architecture要评审一个分支或 PR/code-review会话太长需要交接/handoff六、几个代表性 Skill 解析1.ask-matt技能路由器本地实现里ask-matt是一个很关键但容易被忽略的 skill。它不直接写代码而是回答一个问题我现在应该用哪条 skill flow它把主要工作流描述成一条idea → ship的路线grill-with-docs - 必要时 handoff 到 prototype - 多 session 时 to-prd - to-issues 拆成垂直切片 - 每个 issue 用 implement - implement 内部尽量走 tdd - 最后 code-review这相当于给整套技能库加了一个“路由层”。当用户不记得具体命令时可以先问/ask-matt让它根据当前任务判断应该进入哪条流程。这也解释了为什么仓库要区分 user-invoked 和 model-invokedask-matt、grill-with-docs、to-prd、to-issues、implement更像编排型入口而tdd、domain-modeling、codebase-design更像被流程复用的底层纪律。2./grill-me与/grill-with-docs先拷问再开工AI 编码最常见的问题是用户以为自己说清楚了Agent 也以为自己听懂了。结果开工后才发现边界没定、异常没问、业务语言没统一、非目标场景没排除。/grill-me和/grill-with-docs的作用就是在动手前先进行一轮高密度提问。它们会把 Agent 带入一轮更细的需求追问这个功能到底服务谁哪些场景必须支持哪些场景明确不做失败时应该怎样表现和现有系统的边界在哪里有没有必须遵守的业务术语/grill-with-docs更进一步它不只问问题还会把形成共识的术语和决策写进文档例如CONTEXT.md和 ADR。这让一次对话里的理解不会只停留在当前上下文窗口里而是沉淀为项目资产。3.domain-modeling给 Agent 建立共同语言很多 Agent 回复啰嗦不只是因为模型爱啰嗦而是因为它没有项目里的“短词”。团队里一个成熟项目会有自己的领域语言。例如“物化”“履约单”“冻结库存”“素材发布”“结算周期”这些词背后压缩了大量业务含义。Agent 如果不懂就只能用一整段自然语言绕过去。domain-modeling的目标是在项目里维护这种共同语言。它会做几件事当用户使用模糊词时逼近精确定义当用户说法和已有 glossary 冲突时指出冲突用具体场景测试术语边界在术语确定时更新CONTEXT.md对真正重要、难回滚、有取舍的决定建议写 ADR这和领域驱动设计里的 ubiquitous language 很像。这里的共同语言同时服务人和 Agent。4.tdd把“代码能跑”变成反馈循环Agent 最大的弱点之一是它能写出看起来合理、实际上没跑通的代码。tddskill 用红绿循环来解决这个问题先写一个失败测试 - 写最少代码让它通过 - 一个垂直切片一个垂直切片推进它强调几个点原则含义red before green先看到测试失败再写实现one slice at a time一次只推进一个垂直切片test at seams测公共边界不测内部细节avoid tautological tests预期值必须来自独立来源不要重复实现逻辑这里最重要的是“seam”。测试会先确认公共边界再围绕这个边界验证行为。这能有效降低 Agent 常见的两种坏习惯写一堆贴着实现细节的脆弱测试一口气写完所有代码最后再试图补测试5.diagnosing-bugs先建立红灯再猜原因很多调试失败是因为一开始就猜原因。diagnosing-bugs的第一步是建立反馈循环必须有一个能稳定复现问题、能变红也能变绿的信号。它建议的反馈循环包括failing testcurl / HTTP scriptCLI fixturePlaywright / Puppeteer 脚本重放真实请求或 trace最小化 harnessfuzz loopgit bisect harness只有当这个 loop 存在以后后面的假设、插桩、修复才有意义。这对 Agent 特别重要。因为 Agent 很容易在没有证据时写出“看似合理”的解释然后顺手改代码。这个 skill 把它拉回工程纪律没有红灯就别急着修。6.implement把实现流程收束成一条工程闭环本地实现里还有一个正式暴露的/implementskill。它的正文很短但位置很关键。它负责把一个 PRD 或 issue 真正落到代码上并约束实现过程尽可能使用/tdd在预先确认的 seam 上写测试经常跑 typecheck经常跑单个测试文件最后跑完整测试套件完成后用/code-review检查改动最后提交当前分支这个 skill 的特点是“短”。它不重复解释 TDD 和 code review 的所有规则而是把这些规则交给专门的 skill。这正是可组合设计的体现编排型 skill 只负责调用顺序工程纪律放在独立 skill 里维护。7.code-review把评审拆成 Standards 和 Spec 两条轴代码评审很容易混在一起这段代码是否有风格问题它是否满足需求它是否引入了未要求的范围它是否有架构味道code-reviewskill 的做法是把评审拆成两条方向方向关注点Standards是否符合项目编码标准和代码味道基线Spec是否忠实实现了 issue、PRD 或 spec这很有价值。因为一段代码可能写得很漂亮但做错了需求功能实现对了但严重违反项目约定把两个方向分开可以避免一个问题遮住另一个问题。8.writing-great-skillsSkill 本身也需要工程设计还有一个很有意思的 productivity skillwriting-great-skills。它教你怎么写好 skill。里面有几个概念很值得借鉴概念含义context loadskill 描述长期占用上下文的成本cognitive load用户必须记住某个 skill 存在的成本progressive disclosure把低频使用的细节下沉到外部文件completion criterion每一步必须有可检查的完成条件no-op不改变模型行为的废话规则leading word用一个强概念锚定一整套行为这说明 Matt Pocock 把 skill 当成一种可以设计、拆分、维护和重构的工程对象。七、按场景怎么使用可以按任务场景来选择 skill场景使用方式开始一个新功能先用/grill-with-docs澄清需求如果是大功能再用/to-prd和/to-issues拆解实现一个明确 issue用/implement让它按 issue 执行、跑测试、最后 code review想 test-first 开发直接用/tdd先确认 seam再红绿循环处理线上 bug 或复杂回归用/diagnosing-bugs先建立可复现、可变红的反馈循环整理一堆未处理 issue用/triage按状态机把 issue 归类、补充信息、写 agent brief代码库不好改用/improve-codebase-architecture找 deepening opportunities分支完成后想检查用/code-review分别检查 standards 和 spec需要跨会话继续用/handoff输出交接文档再开新会话继续想学习某个概念用/teach把当前目录当作状态化学习空间八、一个简单示例假设你想给一个博客项目增加“本地搜索页”但还没有想清楚搜索范围、交互和验收方式可以这样使用用户 /ask-matt 我想给博客增加一个本地搜索页应该走哪个流程 Agent 建议先用 /grill-with-docs 澄清需求因为这是一个新功能 需要确认搜索数据来源、页面入口、移动端体验和验收标准。接着进入需求澄清用户 /grill-with-docs 我要给博客增加一个本地搜索页。 Agent 可能会追问 - 搜索范围是标题、摘要、正文还是 tags/categories - 搜索结果要展示哪些字段 - 是否需要高亮命中词 - 搜索页入口放在哪里 - 没有结果时怎么展示 - 是否要兼容移动端需求问清楚后可以把讨论整理成 PRD用户 /to-prd 把刚才讨论的本地搜索页整理成 PRD。如果功能不小再拆成 issue用户 /to-issues 把这个 PRD 拆成可以独立实现的垂直切片。可能会得到这样的 issueIssue内容1生成搜索索引数据并在构建时输出2新增搜索页面和入口3实现搜索结果展示、空状态和移动端样式最后每个 issue 可以单独开一个新会话执行用户 /implement 请根据 PRD 和 issue #1 实现搜索索引数据生成。implement会尽量调用/tdd在确认测试 seam 后小步实现完成后再用/code-review检查这次改动是否满足 spec 和项目标准。九、使用建议1. 先跑 setup首次使用时先运行/setup-matt-pocock-skills它会把 issue tracker、triage labels、domain docs 这些基础信息写清楚。没有这些配置to-issues、triage、domain-modeling等技能就很难稳定工作。2. 不确定时先问 ask-matt如果你只记一个入口可以记/ask-matt它会告诉你当前场景应该走哪条 flow。对新用户来说这是降低记忆成本的最好入口。3. 大任务不要直接 implement如果任务还很模糊先/grill-with-docs。如果任务很大先/to-prd和/to-issues。等 issue 足够独立、足够清楚再交给/implement。这样做的好处是每个 Agent 会话只处理一个清晰的垂直切片不需要在一个上下文里吞下整个大项目。4. 把上下文写进项目这套 skills 很重视把理解沉淀到项目文件里CONTEXT.md项目领域语言docs/adr/重要架构决策docs/agents/Agent 协作配置issue trackerPRD、任务切片、triage brief这些文件会让下一次 Agent 进来时更快进入状态。5. 用 code-review 做收口implement会在完成后使用/code-review。如果你手动完成了一段工作也可以单独调用/code-review。它会把检查拆成两条轴Standards是否符合项目标准和代码味道Spec是否实现了原始 issue / PRD这个收口动作很适合放在提交前。十、总结mattpocock/skills提供的是一组面向工程工作的 Agent skills用ask-matt选择流程用grill-with-docs澄清需求并沉淀文档用to-prd/to-issues拆解工作用implement/tdd推进实现用diagnosing-bugs处理复杂问题用code-review收口质量用domain-modeling和 ADR 保持长期上下文它的使用方式也很清楚先安装运行/setup-matt-pocock-skills初始化项目配置日常不确定怎么走时先/ask-matt遇到具体任务时选择对应 skill。对真实项目来说这种“按任务类型调用明确 skill”的方式比把所有要求塞进一次对话更容易维护。参考资料mattpocock/skillsskills.sh 上的 mattpocock/skillsgrill-with-docstdddiagnosing-bugsdomain-modelingcode-reviewwriting-great-skills