每天一个开源项目#76 Skills：23万星的 Agent 工程技能库
Trending 排名：#1 ｜ 快照日期：2026-08-22 ｜ Stars：230,235 ｜ Forks：19,673 ｜ 主要语言：Shell ｜ License：MIT
写代码 Agent 最容易翻车的地方，往往不是模型不会写某个函数，而是它太早开始写了。需求还没问清楚，测试边界没定，项目里的词也没对齐，Agent 就已经开始改文件。最后代码看起来很勤奋，真正要用时却到处漏水。
Skills 把这个问题拆成一组很小的工作流文件。它不是一个新的 Agent 运行时，也没有声称靠沙箱或调度器接管开发流程。它更像一套给 Claude Code、Codex 这类工具使用的工程规程：什么时候先拷问需求，什么时候写规格，什么时候拆 Issue，什么时候用 TDD，什么时候请另一个 Agent 做代码审查。看完源码后，我觉得它有意思的地方不在“提示词集合”这四个字，而在它把软件工程里的反馈循环压进了可安装、可组合、可版本化的技能目录。
📋 项目概览
| 项目 | 内容 |
|---|---|
| 项目名 | mattpocock/skills |
| 一句话 | 面向真实工程项目的 Agent Skills 工作流库，把澄清、规格、TDD、代码审查和交接拆成可安装的技能。 |
| Stars | 230,235（Trending 快照）；API 同日补充核验为 230,237 |
| Forks | 19,673 |
| 语言 | GitHub 显示 Shell；仓库语言占比为 Shell 70.6%、JavaScript 29.4% |
| License | MIT |
| 版本 | package.json 与 Claude 插件清单均为 v1.2.3；最新 GitHub Release 为 v1.2.3 |
| 默认分支 | main |
| 最近核验提交 | 5b15a47，2026-08-21，clarify wording in code review process |
🔥 为什么值得关注
很多 Agent 工作流喜欢做“大一统”：一个 CLI 接管需求、计划、实现、测试、提交。听起来省心，但坏处也明显。流程越厚，调错越难；一旦 Agent 在某个早期判断上跑偏，后面所有步骤都会把这个偏差放大。Skills 走的是相反方向，它把流程切成 25 个被插件正式发布的技能，其中 14 个只能由人显式调用，11 个允许模型在匹配场景时自动触发。
这个边界很实用。比如 /grill-me 和 /to-spec 属于人触发的入口，避免模型自己假装已经问清楚需求；tdd、diagnosing-bugs、code-review 则可以作为模型可见的纪律约束，在实现或排错时把 Agent 拉回可验证路径。源码里的 disable-model-invocation: true 和 Codex 侧 policy.allow_implicit_invocation: false 不是摆设，它们把“谁能启动这段流程”写进了文件。
另一个细节是分发方式。Claude Code 用户可以直接安装只读插件；Codex 和其他工具则通过 skills.sh 把文件复制到项目里编辑。两种入口分别对应“订阅维护者的流程”和“把流程改成自己的”。这比只给一个 README 更稳，因为技能目录、插件清单、版本同步脚本和发布工作流都在仓库里。
🏗️ 核心特性
- 可安装的工程技能集，不是单次提示词
仓库的产品主体是 SKILL.md 和配套文档。浅克隆核验显示，仓库共有 162 个 Git 跟踪文件，其中 111 个 Markdown 文件、36 个 SKILL.md、9,229 行文本与脚本。Claude 插件只发布 engineering/ 和 productivity/ 下的 25 个 promoted skills，misc/、in-progress/、deprecated/ 不进入正式插件。
---
name: tdd
description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
---
这段 frontmatter 说明了一个关键取舍：技能的“入口”很短，真正的约束在正文里。tdd 不是让 Agent 机械生成一堆测试，而是规定只在确认过的 seam 上写测试，先红后绿，避免测试内部实现和“用被测代码重新算期望值”的假测试。
- 用户触发和模型触发分开
| 类别 | 数量 | 例子 | 作用 |
|---|---|---|---|
| 用户显式触发 | 14 | ask-matt、grill-me、to-spec、wayfinder | 需要人参与、做决策、确认范围的流程 |
| 模型可自动触发 | 11 | tdd、diagnosing-bugs、code-review、wizard | Agent 工作中应主动采用的工程纪律 |
| 全部 SKILL.md | 36 | 含 in-progress 与 misc | 仓库总知识库，不等于正式插件暴露面 |
| 正式插件技能 | 25 | .claude-plugin/plugin.json 明确列出 | Claude Code 安装后的实际产品面 |
这个设计解决了一个常见问题：不是所有技能都应该被模型自己拿来用。需求访谈、Issue 路由和长任务分解需要人参与；测试原则、bug 诊断和代码审查更适合在模型执行中持续约束它。
- 工程流程从“聊天”变成状态机
triage、wayfinder、to-tickets 这类技能把开发活动拆成状态变化。wayfinder 使用 decision ticket 表示“还没做之前必须先决定的问题”，并通过 issue tracker 记录依赖关系；triage 把 Issue 和外部 PR 都当成同一种请求面处理；to-spec 生成规格后直接发布到项目的 issue tracker，而不是把长文本丢在聊天记录里。
想法或需求
-> grill / grill-with-docs 澄清边界
-> to-spec 固化用户故事、实现决策、测试决策
-> to-tickets 拆成带阻塞关系的 Issue
-> implement 执行
-> code-review 从标准和规格两条线复核
- 插件发布有确定性校验
仓库不是只维护一堆 Markdown。package.json、.claude-plugin/plugin.json、Changesets 和 GitHub Actions 组成了版本面。scripts/sync-plugin-version.mjs --check 会检查 package 版本和插件版本是否一致；本次核验执行 npm run check-plugin-version 返回：plugin.json version is 1.2.3 (already in sync)。claude plugin validate . --strict 也通过了本地校验。
- 性能表要按“控制成本”看
技能库没有运行时 benchmark，因为它并不在热路径里跑推理或编译。这里的性能主要是上下文成本、触发成本和纠错成本。
| 机制 | 成本表现 | 源码证据 | 边界 |
|---|---|---|---|
| 短 frontmatter 入口 | 模型先看到触发描述，不必一次吞完整知识库 | 每个技能的 description 很短，正式插件显式列目录 | 触发质量仍取决于宿主 Agent 的技能检索 |
| 用户触发隔离 | 人参与流程不会被模型误自动调用 | disable-model-invocation: true 与 policy.allow_implicit_invocation: false | 不是权限沙箱，只是技能调用边界 |
| 规格与 Issue 写入 | 决策离开聊天上下文，进入项目记录 | to-spec、to-tickets、wayfinder 工作流 | 需要项目配置 issue tracker |
| 版本同步脚本 | 插件版本漂移可被脚本发现 | sync-plugin-version.mjs --check | 只检查版本字段，不证明技能质量 |
🔬 技术架构深度解析
Skills 的架构不在某个核心类里，而在“指令如何流动”里。按源码看，可以拆成五层。
+---------------------------------------------------------+
| 分发层 |
| Claude Code plugin: .claude-plugin/plugin.json |
| skills.sh: npx skills@latest add mattpocock/skills |
+----------------------------+----------------------------+
|
v
+---------------------------------------------------------+
| 技能索引层 |
| engineering/ + productivity/ promoted skills |
| misc/ + in-progress/ + deprecated/ 留在仓库但不进插件 |
+----------------------------+----------------------------+
|
v
+---------------------------------------------------------+
| 触发控制层 |
| user-invoked: 人显式输入 slash command |
| model-invoked: 模型按 description 自动采用 |
+----------------------------+----------------------------+
|
v
+---------------------------------------------------------+
| 工程动作层 |
| grill -> spec -> tickets -> implement -> review |
| bug diagnosis / TDD / architecture scan / wizard |
+----------------------------+----------------------------+
|
v
+---------------------------------------------------------+
| 持久记录层 |
| CONTEXT.md、ADR、Issue tracker、handoff、throwaway branch |
+---------------------------------------------------------+
1. 真实产品层：Markdown 决策协议
GitHub 语言显示 Shell，是因为语言统计只计算代码文件。仓库本身的工程密度主要在 Markdown。浅克隆核验结果如下：
| 指标 | 数值 |
|---|---|
| Git 跟踪文件 | 162 |
| Markdown 文件 | 111 |
| JSON 文件 | 5 |
| Shell 脚本 | 5 |
| YAML 文件 | 36 |
SKILL.md 数量 | 36 |
| 总行数 | 9,229 |
| Markdown 行数 | 7,004 |
| 正式插件技能 | 25 |
这说明它不是传统意义的 SDK。它的“代码”是让 Agent 遵守的流程文本，外加少量发布和链接脚本。分析这类项目时，不能把 Markdown 当成说明书附属品；Markdown 就是产品。
2. Router 不是关键词表，而是相位边界
ask-matt 的角色很像路由器，但它处理的不是简单关键词匹配，而是“工作处在哪个阶段”。例如：
| 阶段 | 对应技能 | 目的 |
|---|---|---|
| 还没想清楚 | grill-me、grill-with-docs | 先问问题，避免 Agent 自己补需求 |
| 已有上下文 | to-spec | 把讨论转成规格，不再继续访谈 |
| 任务太大 | wayfinder | 用 decision ticket 找出还没决定的部分 |
| 要实现 | implement、tdd | 按规格执行，测试只落在确认过的 seam 上 |
| 要复核 | code-review | 分别检查标准符合度和规格符合度 |
这比“把所有最佳实践塞进一个长 prompt”更容易维护。一个技能只关心自己的相位，其他相位通过 router 和文档指针接上。
3. 文档不是缓存，除非它记录了代码看不出的事
仓库的 CLAUDE.md 写得很直接：安装命令从 .agents/install-block.md 复制，不允许各处各写一份；技能目录必须和插件清单同步；添加或改动正式技能时，README、docs 页面和 ask-matt 都要跟着更新。这是一种很务实的文档治理：能从配置文件查到的东西，不要在十个地方复述；必须给 Agent 看的约定，才写进文档。
4. 可执行校验和模型约束分清楚
Skills 里有些规则能被程序检查，有些只能靠 Agent 遵守。这个边界必须说清楚。
| 控制项 | 类型 | 说明 |
|---|---|---|
| 插件 manifest 校验 | 可执行 | claude plugin validate . --strict 已通过 |
| 插件版本同步 | 可执行 | npm run check-plugin-version 已通过 |
| promoted skills 是否进入插件清单 | 可执行加人工维护 | .claude-plugin/plugin.json 明确列出 25 个路径 |
| TDD 只测 seam | Agent 介导 | 技能会要求确认 seam，但不会强制拦截测试文件 |
| code-review 双线复核 | Agent 介导 | 依赖 Agent 按标准和规格两条线审查 |
/grill-me 真正问到位 | 人加 Agent 协作 | 质量取决于交互，不是单次命令能证明 |
这是我最喜欢的一点：仓库没有把 Markdown 规则包装成“自动保证”。它更诚实地把可执行校验放在发布和版本层，把工程判断留给 Agent 与人。
5. 版本面：源码、插件、Release 一致
package.json 和 .claude-plugin/plugin.json 都是 1.2.3；GitHub Releases 最新 tag 也是 v1.2.3，发布时间为 2026-08-06。最近几次 release 主要围绕安全输出、跨 harness 文案、wizard、prototype、wayfinder 等技能修订。最新提交是 2026-08-21 的 code review wording 修正，说明 main 分支在 release 后仍有文档和技能细节更新。
📖 README 核心内容摘要
README 的主张很清楚：真实应用开发难，GSD、BMAD、Spec-Kit 这类流程会试图接管整个过程，但接管越多，开发者越难在流程出错时介入。Skills 把流程做小，允许你改、组合、替换。
安装有两条路，二选一。
Claude Code 走官方插件市场。这个命令已通过 claude plugins --help 核验，install 是插件命令的正式子命令。
claude plugins install mattpocock-skills
Codex 和其他 Agent 走 skills.sh。这个命令已通过 npx skills@latest --help 核验，add <package> 是正式命令，--skill、--agent 等选项也在帮助输出里。
npx skills@latest add mattpocock/skills
README 里反复出现的工程观念有四个：
| 问题 | README 给出的处理方式 | 对应技能 |
|---|---|---|
| Agent 没理解需求 | 先做 grilling session，逼近真实需求 | grill-me、grill-with-docs |
| Agent 说得太散 | 建立项目里的共同语言 | domain-modeling、CONTEXT.md |
| 代码不能跑 | 使用类型、浏览器、自动化测试等反馈回路 | tdd、diagnosing-bugs |
| 代码变成泥球 | 持续寻找 deep module 和更好的 seam | improve-codebase-architecture、codebase-design |
它也支持多 harness。v1.2.0 加入了 Codex metadata，每个技能旁边有 agents/openai.yaml，用于描述 Codex UI 和隐式调用策略。Claude 插件清单则通过显式路径列出 promoted skills，避免把 in-progress/ 或 misc/ 下的实验内容一起发布出去。
🚀 快速上手
如果你用 Claude Code，直接安装插件：
claude plugins install mattpocock-skills
安装后，在项目里先运行 /setup-matt-pocock-skills。它会问三类问题：Issue tracker 用 GitHub、Linear 还是本地文件；triage 标签怎么映射；Agent 生成的文档应该放在哪里。
如果你用 Codex 或其他支持 skills.sh 的 Agent：
npx skills@latest add mattpocock/skills
安装器会让你选择要安装哪些技能和目标 Agent。README 特别提醒要选 setup-matt-pocock-skills，否则后续工程技能拿不到 issue tracker、标签和文档目录这些基础配置。
一个比较顺手的最小工作流如下：
1. /setup-matt-pocock-skills
2. /grill-with-docs 先问清需求，同时补 CONTEXT.md 与 ADR
3. /to-spec 把当前讨论固化成规格
4. /to-tickets 把规格拆成带阻塞关系的 Issue
5. 让 Agent 按 Issue 实现，期间模型可自动参考 tdd、diagnosing-bugs
6. /code-review 按项目标准和原规格做复核
维护者开发插件时还有一个本地检查命令，本次核验已执行通过：
npm run check-plugin-version
如果你只是想试一两个技能，skills.sh 也支持指定技能安装，帮助输出里的选项名是 --skill：
npx skills@latest add mattpocock/skills --skill=tdd
📊 增长速度与社区热度
Skills 创建于 2026-02-03，Trending 快照日为 2026-08-22。按快照 Stars 计算，约 200 天积累 230,235 Stars，生命周期粗略基线约为 1,151 Stars/天。这个数只能说明从创建到快照的平均速度，不能当作当天新增 Stars；预跑数据没有保留每个仓库的 daily stars。
| 指标 | 数值 | 说明 |
|---|---|---|
| Trending 排名 | #1 | 2026-08-22 快照 |
| Stars | 230,235 | 快照值；同日 API 补充核验为 230,237 |
| Forks | 19,673 | 快照值 |
| Open Issues | 377 | API 补充核验 |
| Contributors | 4 | API contributors 前 10 中返回 4 个账号 |
| 最大贡献者 | mattpocock，418 commits | API contributors 返回值 |
| 最新 Release | v1.2.3 | 2026-08-06 发布 |
| 最近提交 | 2026-08-21 | main 分支提交 5b15a47 |
社区热度不只来自 Star。它还有 19,673 forks，这对一个以文本规程为主体的仓库来说很关键，因为 fork 意味着大量团队可能会改写这些技能，而不是只收藏。Open Issues 有 377 个，PR 和 release 记录显示维护者在持续修订细节，比如诊断时的密钥脱敏、跨 Claude/Codex 的术语、wizard 的人工步骤脚本模板等。
今日 GitHub Trending 榜单
| Rank | Repository | Language | Stars | Daily Stars |
|---|---|---|---|---|
| 1 | mattpocock/skills | Shell | 230,235 | 未保留 |
| 2 | harry0703/MoneyPrinterTurbo | Python | 114,191 | 未保留 |
| 3 | AprilNEA/OpenLogi | Rust | 13,211 | 未保留 |
| 4 | PostHog/posthog | Python | 38,375 | 未保留 |
| 5 | microsoft/TypeScript | Go | 110,426 | 未保留 |
| 6 | obra/superpowers | Shell | 275,791 | 未保留 |
| 7 | santifer/career-ops | JavaScript | 67,610 | 未保留 |
| 8 | cursor/plugins | TypeScript | 4,488 | 未保留 |
| 9 | modular/modular | Mojo | 28,750 | 未保留 |
| 10 | affaan-m/ECC | JavaScript | 241,900 | 未保留 |
| 11 | TryGhost/Ghost | JavaScript | 54,981 | 未保留 |
| 12 | ruvnet/ruflo | TypeScript | 68,740 | 未保留 |
| 13 | apache/maka | TypeScript | 2,098 | 未保留 |
| 14 | protocolbuffers/protobuf | C++ | 71,794 | 未保留 |
| 15 | elder-plinius/OBLITERATUS | Python | 7,875 | 未保留 |
| 16 | microsoft/onnxruntime | C++ | 21,532 | 未保留 |
🎯 适用场景
| 场景 | 为什么适合 | 使用方式 |
|---|---|---|
| 个人项目中频繁用 Claude Code 写功能 | 容易跳过需求澄清和测试边界 | 用 /grill-with-docs、/to-spec、tdd 建立固定节奏 |
| 团队想把 Agent 产出接到 Issue 流程 | 聊天记录无法承担项目管理 | 用 setup-matt-pocock-skills 配置 issue tracker，再用 to-tickets 和 triage |
| 旧代码库需要架构改良 | Agent 容易只做局部重构 | 用 improve-codebase-architecture 找 deepening opportunities |
| 需要跨会话交接 | 长对话上下文会膨胀，也容易丢判断 | 用 handoff 把当前状态写成可接手文档 |
| 新人或非核心开发者参与需求澄清 | 领域词不统一，描述会变长 | 用 domain-modeling 和 CONTEXT.md 固化共同语言 |
| 要在 Codex、Claude Code 等不同工具间复用流程 | 单平台插件会锁住流程 | Claude 用插件，其他 Agent 用 skills.sh 拷贝技能文件 |
💡 总结
Skills 的价值不在“收集了很多提示词”。如果只是提示词合集，它不会有 25 个正式插件技能、用户触发和模型触发的双入口、版本同步脚本、Claude 插件清单、Codex metadata 和发行记录。
我更愿意把它看成一个轻量的 Agent 工程操作手册。它没有替你实现隔离沙箱，也不会保证 Agent 每次都按规范执行；它做的是把容易被忽略的工程动作变成可安装的工作流。先问清楚，再写规格；先定 seam，再写测试；先把决策放进 Issue，再让 Agent 执行。对真正把 Agent 放进日常开发的人来说，这种“少接管，多约束”的路线比全自动口号更可靠。
