这恰恰说明大部分人没搞清楚一件事——这三个仓库根本不是同类竞品，它们代表着三种完全不同的工程哲学：一个是 library（工具集合），一个是 framework（方法论框架），一个是 reference implementation（官方参考实现）。你把它们当同类装在一起，大概率会冲突 + 互相覆盖 + 让 Claude Code 行为变得不可预测。

我做了 10 年后端架构，见过太多团队把「Spring」「Spring Boot」「Spring Cloud」当同一个东西装，结果踩到各种依赖冲突的坑。今天 Skill 生态正在重演这个故事，而且节奏快 10 倍。这篇文章把三大体系的设计哲学差异拆清楚，给你一个真正能用的选型矩阵。

先看实时数据：这周到底发生了什么

我用三个仓库的 GitHub 主页实测了一遍数据（2026-05-21）：

仓库	当前 stars	本周新增	作者	License
mattpocock/skills	97.5k	+18,368	Matt Pocock	MIT
obra/superpowers	201k	+10,851	Jesse Vincent	MIT
anthropics/skills	138k	+4,749	Anthropic 官方	Apache 2.0 + source-available

图：mattpocock/skills、obra/superpowers、anthropics/skills 三个 Skill 仓库本周 stars 增长 + 累计 stars + 定位对比（2026-05-21 实测）

三个数字背后有不同的故事：

mattpocock/skills 的增长曲线最陡——这个仓库初始 commit 是 2026-02-03，三个半月就到了 97.5k stars。Matt Pocock 是 TypeScript 教程界的网红，自己有 6 万订阅的 newsletter，他把自己 .claude 目录里的 skill 整理开源，社区接住得很快。

obra/superpowers 是其中最老牌的一个，已经迭代到 v5.1.0（2026-05-04 发布），201k 这个体量在 AI 工具类项目里是顶级。它的关键里程碑是 2026-01-15 被 Anthropic 官方 Plugin Marketplace 接收——一个第三方框架被官方接管推广，这在 Claude Code 生态里是头一次。

anthropics/skills 是 Anthropic 自己的官方公共库，定位最特殊——它既是教育示范（README 明确写「demonstration and educational purposes only」），又包含驱动 Claude.ai 文档生成功能的生产级实现（pdf、docx、xlsx、pptx 四个 skill）。

但 stars 数字解决不了一个核心问题：这三个仓库的工程哲学完全不同，混着装等于在你的 .claude 目录里塞三种不兼容的框架。

三种体系，三种工程哲学

这是本文的核心判断，先把它放出来：

图：从本质定位、使用范式、控制权、扩展性、跨平台、Java 类比六个维度对比三大体系

维度	mattpocock/skills	obra/superpowers	anthropics/skills
本质定位	Library（工具集合）	Framework（方法论框架）	Reference（官方参考实现）
使用范式	手动触发（slash command）	自动激活（mandatory workflow）	按需调用（demo/生产混合）
控制权归属	工程师手里	框架手里	Claude 自己
扩展性	鼓励 fork 改造	明确拒绝外部新增 skill	接受 PR，官方审核
跨平台	任意 .claude 目录	8 个 AI 编程平台原生支持	Claude Code / API / claude.ai

这种差异不是「风格不同」，是底层架构哲学的不同。我用 10 年做后端的经验给你一个最直观的类比——

如果把 AI Agent 编程比作 Java Web 开发，mattpocock/skills 就是 Apache Commons（工具类库，你想用哪个调哪个），obra/superpowers 是 Spring Framework（强约束的方法论，按它的规则走），anthropics/skills 是 JDK 自带的 java.sql 包（官方实现 + 参考标准 + 部分功能直接构成生产能力）。

这三者你混着用，技术上是可以的——但前提是你清楚每一个的边界在哪里。

mattpocock/skills：一个 TypeScript 教程作者怎么设计 Skill 库

Matt Pocock 在 README 里写「Skills for Real Engineers」，这个口号背后其实是一份反 vibe-coding 宣言——他不相信「让 AI 自己搞定一切」，他认为 AI Agent 在编程里有 4 个固定失败模式，每个模式都需要一个对应的 skill 来对抗。

这 4 个失败模式我看完之后愣了很久——它们本质上是分布式系统的 CAP 推论，只是把 AI 当成一个不稳定的分布式节点：

图：mattpocock/skills 的 4 大失败模式对应分布式系统的一致性/可观测性/可靠性/可维护性

1. Misalignment（意图错位）——agent 在没搞清楚意图前就开始动手。Matt 的方案是 /grill-me 和 /grill-with-docs，强制 Claude 在写代码前用苏格拉底式提问把需求问透。这就是分布式系统里的「一致性」问题——你和 agent 对同一个目标的理解必须先收敛。

2. Verbosity（语言冗余）——agent 不知道你团队的领域术语，每次都用一长串自然语言绕弯子描述。Matt 的方案是用 CONTEXT.md 文件建立共享词汇表。这就是「可观测性」——agent 输出可被人类快速理解的简洁信号。

3. Unreliable Code（不可靠代码）——没有反馈循环就让 agent 写代码 = 必然出问题。Matt 的方案是 /tdd 强制 red-green-refactor，/diagnose 提供结构化调试流程。这就是分布式系统的「可靠性」——每一次变更必须有可验证的反馈。

4. Architecture Degradation（架构退化）——快速开发加速技术债。Matt 的方案是 /improve-codebase-architecture、/zoom-out、/to-prd——定期把 agent 拉回到架构层面审视。这就是「可维护性」——长期演化的代码库必须有架构纪律。

这套思维不是「prompt 工程师」能想到的，是做过生产系统的人才会这样建模——把 AI agent 当成一个不靠谱的微服务节点来管理。

关于实战效果，第三方评测（explainx.ai 实测）给出的数字是「时间到正确 PR 的速度降低 20-40%」。其中最受欢迎的是 /grill-me（避免需求歧义），最反直觉的是 /caveman——它强制 agent 用「穴居人短句」回答（去掉所有客套和解释），实测输出 token 削减 62%。

适合谁用？看一下决策标准：

• 你对 Claude Code 的工作流有自己的偏好，不想被一个框架完全接管 → 选 mattpocock
• 你的团队主要写 TypeScript / Node.js → mattpocock 的多个 skill 是为 JS 生态优化的
• 你愿意手动 /grill-me、/tdd 来触发 skill → mattpocock 的「手动触发」模型适合你

不适合谁？团队工程纪律差、希望框架强制规范的——mattpocock 给你工具，但不强制你用。

obra/superpowers：一套强制纪律的方法论框架

如果说 mattpocock 是「给你工具」，那 obra/superpowers 就是「强制你按它的规则走」。

Jesse Vincent（obra）在 README 里有一句让我反复琢磨的话：「what AI coding agents are missing is not capability but discipline」——AI 编程 agent 缺的不是能力，是纪律。

这句话决定了 superpowers 跟其他 Skill 仓库的本质差异——它不是一组可选的工具，是一套不可绕过的强制工作流。

具体表现是「七阶段流水线」：

图：superpowers v5.1.0 的七阶段强制流水线 + 三条 Iron Law（测试优先 / 证据非声称 / 拒绝外部贡献）

Brainstorm（头脑风暴）
   ↓
Spec（编写规格说明）
   ↓
Plan（拆解可执行任务）
   ↓
TDD（红绿重构强制循环）
   ↓
Subagent Dev（子 agent 实现）
   ↓
Review（两阶段审查：规格合规 + 代码质量）
   ↓
Finalize（交付前最终验证）

每个阶段都对应一个 skill，关键是这些 skill 不是「你想用才用」——它们在 session 启动时通过 hook 注入，agent 在做任何事之前必须先检查相关 skill 是否应该触发。

最极端的体现是 test-driven-development 这个 skill 的 Iron Law：如果 agent 在写测试之前就开始写实现代码，superpowers 会强制删除这段代码，要求从测试重新开始。这种「执行层面的强制力」是普通 Skill 库做不到的。

obra/superpowers 还有几个让我觉得它「不是普通 skill 库」的工程细节：

第一，明确拒绝外部贡献新 skill。 仓库贡献指南里直接写：「we don't generally accept contributions of new skills」。这跟 mattpocock 鼓励 fork 改造完全相反——superpowers 把自己定位成方法论而不是工具集，方法论一旦稀释就变味了。

第二，跨 8 个 AI 编程平台。Claude Code、Cursor、Codex、OpenCode、GitHub Copilot CLI、Gemini CLI、Factory Droid 等。这意味着 superpowers 的 skill 文件不能用任何平台的特有特性，全部是纯 markdown + 约 2000 tokens 的 bootstrap 引导词。

第三，2026-01-15 被 Anthropic 官方 Plugin Marketplace 接收。一个第三方框架被原厂收编，这在生态里是稀有事件——意味着 Anthropic 内部也认可 superpowers 的方法论价值。

适合谁用？

• 团队工程纪律差，需要框架强制规范 → superpowers 的强制工作流就是为这个设计的
• 项目复杂、bug 多、重构频繁 → 七阶段流程能把回归 bug 降到很低
• 你跨多个 AI 编程平台工作 → superpowers 是唯一在 8 个平台一致工作的框架

不适合谁？

• 做快速原型、写一次性脚本 → 七阶段流程的开销太大
• 经验丰富、自己已经形成稳定工作流的工程师 → 强制框架会让你觉得被掣肘

anthropics/skills：官方公共库的双重身份

这个仓库最有意思的地方，是它同时扮演两个角色——既是教育示范，又是生产实现。

打开 README 你会看到这样一句声明：「These skills are provided for demonstration and educational purposes only」——这些 skill 仅供演示和教育目的使用，使用前必须自己充分测试。

听起来像是免责声明，但仔细看仓库结构你会发现一件事：