obra/superpowers 多维度简评

综合评分：9.5 / 10 ⭐⭐⭐⭐⭐ 类别：工程方法论 / 流程强制 来源：obra/superpowers 影响力：40k+ Stars，是 AI 编码 Agent “工作流框架”的事实标准

一、核心定位与价值

如果说 anthropics/skills 告诉你 Skill 是什么，那 obra/superpowers 告诉你 Skill 应该怎么设计才真正起作用。

它的口号很直白：

让 AI 守规矩，而非更聪明。

superpowers 不给 AI 新能力，而是给 AI 行为约束——通过 14+ 个可组合 Skill + Hard-Gate 强制流程门禁 + 任务拆分/审查机制，把一次次”随口一句需求”变成可验证、可回滚、可 review、可持续迭代的开发节奏。

它是 Anthropic 黑客马拉松冠军 Jesse Vincent（@obra）的作品，被广泛认为是 AI 编程领域最务实的工程增强层。

二、核心设计哲学（4 条铁律）

1. 测试驱动开发（TDD）：先写测试，再写代码
2. 系统化优于临时性：流程胜过猜测
3. 降低复杂度：简洁是首要目标
4. 证据优于断言：验证成功后再声明

反 AI “感觉编程”（Vibe Coding）的根本解药。

三、14+ Skill 全景

四、Hard-Gate 强制工作流（6 个环节）

阶段 1：brainstorming — 需求设计

触发：任何创造性工作之前 门禁：用户批准设计前，不调用任何实现技能、不写代码、不搭建项目

自动执行：

1. 探索项目上下文（现有代码、技术栈、约定）
2. 一个一个问题澄清（一次只问一个）
3. 提出 2-3 种方案，说明优劣
4. 分段展示设计，逐段获取确认
5. 用户批准 → 生成 docs/superpowers/specs/YYYY-MM-DD-xxx-design.md

阶段 2：writing-plans — 实现计划

触发：设计已批准 门禁：自审通过（无占位符、无矛盾、全覆盖 spec）

自动执行：

• 定义文件结构和每个文件职责
• 拆分成 2-5 分钟一个的微小步骤
• 每步包含完整代码（不是 TODO 或”稍后实现”）
• 假设执行者零上下文，必须自包含

输出：docs/superpowers/plans/YYYY-MM-DD-xxx.md

阶段 3：using-git-worktrees — 隔离工作区

触发：开始实现前

自动执行：

# 自动检测工作树目录位置
# 验证 .worktrees/ 已被 .gitignore 忽略
git worktree add .worktrees/<feature-branch> feature/<name>
cd .worktrees/<feature-branch>
# 运行项目设置
# 验证清洁的测试基线

阶段 4：subagent-driven-development — 逐任务实现

触发：计划已就绪

每个任务的 3 步审查：

1. 派发实现子代理：独立上下文，只接收任务文本
2. Spec 合规审查：逐行对照 spec，检查缺失/多余/误解
3. 代码质量审查：检查逻辑、风格、命名、测试覆盖

审查不通过 → 修复 → 重新审查，直到通过 → commit → 下一任务

阶段 5：verification-before-completion — 完成前验证

触发：任何”完成”声明前

铁律：没有新鲜验证证据 = 不能声称完成

反例（全部无效）：

• ❌ “应该好了”
• ❌ “看起来没问题”
• ❌ “上次跑过了”
• ❌ “理论上通过”

阶段 6：finishing-a-development-branch — 收尾

触发：所有任务完成

4 个选项：

1. 合并回主分支：自动清理 worktree 和分支
2. 创建 PR：保留 worktree 以便迭代反馈
3. 保留不动：分支留着不管
4. 丢弃：用户输入 discard 确认后清理

五、using-superpowers：1% 触发原则

这是 superpowers 的入口 Skill，最重要的一条规则：

如果你觉得某个 Skill 有 1% 的可能适用，你就必须先调用 Skill tool 把它加载出来，然后按它做。

原理：把”我觉得不用”这种主观判断从系统里移除，避免 Agent 赶进度而合理化（rationalize）跳过流程。

红旗思维表（Red Flags）——当 Agent 脑内出现这些想法时必须立刻停下：

• “这就一个小改动”
• “我先快速改一下再说”
• “这是历史代码不用管”
• “来不及了”
• “我之后再加测试”
• “改动太大不好审查”

每一条都有标准反驳（Anti-rationalization），强制遵循完整流程。

六、安装指南

6.1 Claude Code

# 方式 A：官方插件市场（推荐）
/plugin install superpowers@claude-plugins-official

# 方式 B：社区市场（更新更快）
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 验证安装
# 重启后输入：
use skill tool to list skills

6.2 OpenAI Codex

# Codex CLI
/plugins
# 搜索 superpowers 安装

# Codex App
# 左侧 Plugins → 搜索 → +安装
# 验证：在新会话输入"你有 superpowers 技能吗？"

6.3 Cursor

/add-plugin superpowers

6.4 OpenCode

# 自动安装脚本
Fetch and follow instructions from https://raw.githubusercontent.com/obra/superpowers/refs/heads/main/.opencode/INSTALL.md

6.5 GitHub Copilot CLI

copilot plugin marketplace add obra/superpowers-marketplace
copilot plugin install superpowers@superpowers-marketplace

6.6 Gemini CLI

gemini extensions install https://github.com/obra/superpowers

七、实战示例：从需求到合并

用户输入（无需特殊指令）

帮我实现一个用户登录接口，支持账号密码登录，返回 JWT。

superpowers 自动走完 6 阶段

阶段 1：Brainstorming（自动）

AI 会逐个提问：

• 需要验证码吗？
• 密码加密用 bcrypt 吗？
• JWT 有效期多久？
• 要 refresh token 吗？
• 登录失败几次锁定账号？

回答后生成设计规范，逐段等你确认。

阶段 2：Writing Plans

输出 Markdown 计划：

Task 1: 定义 User 模型
- 写测试：验证账号/密码字段非空
- 运行测试（红）
- 实现模型
- 运行测试（绿）
- 提交

Task 2: 实现密码加密工具
- 写测试：bcrypt 加密验证
- ...

Task 3: 实现 JWT 生成
...

Task 4: 实现登录接口 POST /api/login
...

阶段 3：Using Git Worktrees

自动执行：

git worktree add .worktrees/login-feature feature/login
cd .worktrees/login-feature
npm install
npm test  # 确保基线测试通过

阶段 4：Subagent Driven Development

每个 Task 派新子代理，强制先写测试（红）→ 实现代码（绿）→ 重构。

阶段 5：Verification

测试全过 + 构建成功 + Lint 通过 = 才能进入下一阶段。

阶段 6：Finishing Branch

测试全过 → 询问是否合并到主分支 → 清理 worktree

八、3 条铁律的实战含义

铁律 1：TDD 强制

反面：你说”请用 TDD 方式开发”，AI 点头称是，然后依然直接写实现。

superpowers 的做法：把流程编码在 Skill 的状态机里，AI 必须按流程走：

• 不写失败测试 → 不能写实现代码
• 实现代码后必须看到测试变绿
• 红-绿-重构必须完整循环

铁律 2：工作区隔离

好处：主分支永远安全，实验分支可随时丢弃。

铁律 3：子代理隔离

原理：人类 Agent 长对话会出现：

• 上下文膨胀 → 注意力漂移
• 前后自相矛盾
• 小错误累积放大

superpowers 的解法：每个任务启动新子代理（干净上下文）+ 两阶段审查（Spec 合规 + 代码质量）。

九、优缺点对比

✅ 优点

• 专业度极高：行为控制系统而非 prompt 集合
• 大幅降低返工：前期慢但后期质量好
• 团队规范统一：新人 git pull 后 AI 立刻懂规矩
• 覆盖 9+ 主流工具：跨生态兼容
• MIT 开源：自由定制

❌ 缺点

• 小项目过重：作者实测认为适合”体量稍大的项目”，小工具用 codex 一两下就完了
• 依赖 Opus 4.6+ 效果最佳：便宜模型可能跳步
• 初次上手需要适应：习惯了”直接让 AI 写”的会不习惯
• 大 monorepo 吃 token：子代理分发会增加 token 消耗

十、与其他方案对比

十一、实战技巧

1. 不要全装：先装核心 7 个（brainstorming + writing-plans + TDD + code-review + finishing-branch + worktrees + verification）
2. 写清楚用户故事：模糊需求会触发太多 brainstorming 问题
3. 让 AI 自己评估工作量：1% 触发原则下它会主动问要不要用 Skill
4. PR 阶段必跑 requesting-code-review
5. 批量任务用 dispatching-parallel-agents：节省时间

十二、常见 Q&A

Q: 比直接写代码慢？ A: 前期慢，但后期返工大幅减少。整体更快、质量更高。

Q: 支持哪些语言/框架？ A: 全语言/全框架（Node.js、Python、Java、Go、Swift、Rust 等）。

Q: 怎么禁用？ A: /plugin uninstall superpowers

Q: 团队怎么统一？ A: 把 superpowers 配置加到项目 .claude/CLAUDE.md / .cursorrules 里，所有成员 clone 后自动获得。

Q: 装上后没生效？ A: 重启 Claude Code，输入 use skill tool to list skills 验证。

十三、总结

obra/superpowers 是 AI 编码从”辅助工具”升级为”生产级开发主体” 的关键一步。

核心价值：把”资深工程师的工程判断力”模型化，让 AI 不再追求”最快给答案”，而是追求”更可靠的交付”。

适用人群：

• ✅ 个人开发者：希望 AI 输出更稳定
• ✅ 团队：把 AI 引入研发流程的护栏
• ✅ 复杂项目：避免 AI 跑偏后大规模返工
• ❌ 一次性脚本：杀鸡用牛刀

投入产出比：⭐⭐⭐⭐⭐（5/5）——严肃开发必装。

配套文档：anthropics/skills 多维度简评 | addyosmani/agent-skills 多维度简评 | trailofbits/skills 多维度简评

十四、核心设计哲学深度解析

14.1 从《影响力》到 Agent Skill

obra/superpowers 的作者 Jesse Vincent 在他的博客中深刻指出:AI 编程助手目前面临的最大问题不是能力不足,而是缺乏纪律。在面对复杂任务或”高压环境”模拟时,AI 往往会像初级工程师一样,为了”赶进度”而跳过测试、忽略架构、写出难以维护的代码。

灵感来源:Jesse 的灵感来自心理学大师 Robert Cialdini 的经典著作《影响力》(Influence)。他认为,既然 LLM 是基于人类语料训练的,那么那些对人类生效的”说服原则”,对 AI 也应该同样有效。

科学验证:Jesse 与 Dan Shapiro 交流了一项来自**沃顿商学院(Wharton School)**的最新研究报告 ——《Call Me A Jerk: Persuading AI to Comply with Objectionable Requests》。该报告通过 28,000 次对话实验,严谨地证明了 LLM 具有一种”类人(Parahuman)“的响应机制:

• 当运用 Cialdini 的说服原则时,AI 对指令的依从率从 33% 飙升至 72%

Superpowers 正是利用了这一”Bug 级”特性,将其转化为 Feature。

14.2 三大说服原则的工程化应用

14.3 TDD for Skills:给”规则”写测试

这是该项目最令人眼前一亮的元理念。Jesse Vincent 提出:编写技能文档本身,也应该遵循 TDD(测试驱动开发)的流程。

红(Red - 失败):构建一个高压场景(例如:最后期限临近,功能已完成但没写测试),观察 AI 是否会选择”先提交,以后补测试”的错误路径。

绿(Green - 通过):针对 AI 的借口(例如”我已经手动测试过了”),在 Skill 文档中加入专门的反驳条款,直到 AI 在该场景下坚定地选择”重写代码,先写测试”。

重构(Refactor - 优化):不断精炼规则,封堵新的逻辑漏洞。

这确保了 Superpowers 中的每一个 Skill 不是纸上谈兵,而是经过实战对抗、能有效约束 AI 行为的”法律条文”。

参考: 腾讯网 superpowers 深度分析

十五、14 个 Skill 全景详解

第一部分:核心工作流与规划

1. using-superpowers(超能力总纲)

强制触发机制:该技能规定,如果在对话开始时,有哪怕 1% 的可能性适用于某个技能,Agent 就必须调用它。

反合理化(Anti-Rationalization):LLM 经常会找借口跳过流程,例如”这只是个简单修改”、“我知道该怎么做”。该技能列出了一份”红旗(Red Flags)“清单,明确指出这些想法是错误的,必须停止并加载技能。

技能优先级:规定了”流程类技能”(如头脑风暴、调试)优先于”实现类技能”。

执行协议:在做出任何响应(包括澄清问题)之前,必须先检查并加载技能。

2. brainstorming(头脑风暴与设计)

苏格拉底式对话:禁止 LLM 一上来就抛出代码。它必须先检查当前项目上下文,然后一次只问一个问题来澄清需求。

方案探索:必须提出 2-3 个不同的技术方案,并给出推荐理由和权衡分析(Trade-offs)。

增量验证:设计方案确定后,AI 必须将其拆分成 200-300 字的小节,逐步向您展示并获得确认。

文档化产出:

• 设计文档保存到 docs/plans/YYYY-MM-DD--design.md
• 必须遵循 YAGNI 原则,无情地剔除不必要的功能

3. writing-plans(编写实施计划)

微任务粒度:计划中的每一个步骤必须能在 2-5 分钟内完成。例如,“编写失败测试”、“运行测试确认失败”、“编写最小实现”都是独立的步骤。

无上下文假设(Context-Free):编写计划时,假设执行者是一个没有项目背景知识、但充满热情的初级工程师。计划必须包含:

• 精确的文件路径
• 完整的代码片段
• 具体的验证命令

产出物:生成详细的实施计划文件 docs/plans/YYYY-MM-DD-<plan-name>.md。

4. using-git-worktrees(使用 Git 工作树)

目录选择逻辑:自动检测 .worktrees 或 worktrees 目录,或者读取 CLAUDE.md 中的配置。

安全验证(关键一步):在创建工作区之前,Agent 必须运行 git check-ignore 验证目标目录是否已被 .gitignore 忽略。如果未忽略,必须先修复,防止工作区文件意外提交到仓库。

基准验证:创建工作区并安装依赖后,必须运行测试以确立”清洁基准(Clean Baseline)“。如果基准测试失败,必须报告并询问是否继续。

第二部分:高级执行与协作

5. subagent-driven-development(子 Agent 驱动开发)

单任务单 Agent:对于计划中的每一个任务,主 Agent 会分派一个新的、上下文干净的 Sub-Agent 去执行。这避免了长对话导致的上下文污染和注意力漂移。

双重审查循环(Two-Stage Review):

1. 规格合规性审查(Spec Compliance Review):由一个”怀疑论者”Agent 进行审查,不要相信实现者的报告,必须亲自阅读代码。检查是否严格实现了需求、有没有少做、有没有多做(过度设计)。
2. 代码质量审查(Code Quality Review):只有通过规格审查,才会进入这一步。第二个审查 Agent 检查代码风格、可维护性、测试覆盖率等。

自我反思(Self-Reflection):实现者 Agent 在提交前必须进行自我反思,检查是否满足了所有边缘情况。

上下文优化:主 Agent 会直接将任务的完整文本提供给子 Agent,而不是让子 Agent 自己去读计划文件,节省 Token 并提高准确性。

6. executing-plans(执行计划 - 批处理模式)

如果您不想使用子 Agent 模式,或者需要在独立会话中执行计划,可以使用此技能。

• 批处理执行:默认每次执行 3 个任务
• 人工检查点:每批任务完成后,Agent 必须暂停,展示实现结果和验证输出,等待反馈
• 严格遵循:严格按照计划步骤执行,遇到阻塞必须停止并询问,严禁猜测

7. dispatching-parallel-agents(分发并行 Agent)

当面临多个相互独立的问题时(例如三个不同文件的测试失败),串行处理效率极低。

判断标准:Agent 必须先判断问题是否独立(修复一个不会影响另一个)且无共享状态冲突。

并行分发:如果满足条件,Agent 会同时启动多个子 Agent,每个 Agent 专注解决一个特定的故障域。

集成与验证:所有 Agent 返回后,主 Agent 负责审查摘要、检查冲突并运行全套测试。

第三部分:工程纪律与质量保证

8. test-driven-development(测试驱动开发 TDD)

技能文档明确指出:“违反规则的字面意思就是违反规则的精神。”

红-绿-重构循环:

• 🔴 红:必须先写一个失败的测试
• ✅ 验证红:必须运行测试并看着它失败(Verify Red)。如果测试通过了,说明测试写错了或者功能已存在
• 🟢 绿:编写最小量的代码让测试通过
• ♻️ 重构:在测试通过的前提下清理代码

绝对禁止:

• 严禁在没有失败测试的情况下编写生产代码
• 如果 AI 先写了代码再补测试,技能要求它必须删除代码,重新开始

测试反模式(Testing Anti-Patterns):该技能包含一个附录 testing-anti-patterns.md,专门纠正 AI 常见的错误测试习惯:

• 测试 Mock 而非真实行为:如果测试只是验证 Mock 对象被调用了,而没有验证实际业务逻辑,这是无效测试
• 在生产代码中添加仅供测试的方法:严禁为了测试方便而在生产类中添加 destroy() 等方法
• 不理解依赖就 Mock:必须先理解依赖的真实行为(通常通过阅读接口定义),然后再编写 Mock

9. verification-before-completion(完成前验证)

这个技能旨在消除 LLM 的幻觉和虚假承诺。核心原则是:证据胜于主张(Evidence over Claims)。

门控机制(Gate Function):在 Agent 声称”任务完成”、“Bug 已修复”或”测试通过”之前,它必须:

1. 确定能证明该主张的命令
2. 运行该命令
3. 读取完整输出
4. 只有在输出证实主张的情况下,才能向用户报告成功

禁止用语:严禁使用”应该修复了”、“看起来是对的”、“逻辑上是通的”等模糊语言。没有运行验证命令的结论被视为不诚实。

配置变更验证:特别强调验证配置变更(如切换 LLM 提供商)时,不能只看”操作成功”,必须验证”输出是否反映了变更”(例如检查响应头中的模型名称)。

10. requesting-code-review(请求代码审查)

触发时机:在任务间隙、功能完成时或合并前。

标准化模板:使用 code-reviewer.md 模板,要求审查者对比 {WHAT_WAS_IMPLEMENTED} 和 {PLAN_OR_REQUIREMENTS}。

问题分类:审查结果必须将问题分为:

• 致命(Critical)
• 重要(Important)
• 次要(Minor)

Git 范围:明确指定 BASE_SHA 和 HEAD_SHA,确保审查范围精确。

11. receiving-code-review(接收代码审查)

核心原则:技术正确性 > 社交礼仪。

禁止表演性同意:严禁 LLM 说”你说得太对了!”、“极好的建议!”等客套话。

先验证后执行:收到反馈后,必须先在代码库中验证反馈的准确性。

YAGNI 检查:如果审查者建议添加”专业”但当前未使用的功能,Agent 必须检查代码库,如果确实未被调用,应建议删除(YAGNI)而不是盲目实现。

有理有据的反驳:如果审查意见在技术上不正确或不适合当前架构,Agent 必须基于技术理由进行反驳,而不是盲从。

12. finishing-a-development-branch(完成开发分支)

最终验证:在结束开发前,必须再次运行全套测试。

标准化选项:向用户提供四个明确选项:

1. 本地合并回主分支
2. 推送并创建 PR
3. 保留分支(暂不处理)
4. 丢弃工作(需二次确认)

清理:根据用户的选择,自动清理 Git Worktree,保持环境卫生。

第四部分:系统化调试

13. systematic-debugging(系统化调试)

铁律:在找到根本原因之前,禁止尝试修复。

四阶段流程:

1. 根本原因调查:阅读错误日志,复现问题,检查最近变更。如果是多组件系统,必须添加日志以确定故障发生的边界
2. 模式分析:寻找代码库中类似的、正常工作的代码作为参考
3. 假设与测试:提出单一假设,用最小的改动验证假设
4. 实施:编写一个失败的测试用例(Reproduction),修复它,然后验证

架构质疑:如果尝试了 3 次修复都失败了,或者每次修复都引发新问题,Agent 必须停止并质疑架构本身,而不是继续打补丁。

强大子工具:

• root-cause-tracing(根因追踪):教导 AI 不要只修复报错的地方(症状),而要沿着调用栈反向追踪,直到找到错误数据的源头
• defense-in-depth(纵深防御):修复 Bug 后,在数据流经的每一层都添加校验,让该类 Bug 在结构上不可能再次发生
• condition-based-waiting(基于条件的等待):解决测试不稳定性(Flaky Tests)。严禁使用 sleep(1000),必须使用轮询机制等待特定状态或事件
• find-polluter.sh:二分查找脚本,用于定位是哪个测试用例污染了全局环境

第五部分:元技能

14. writing-skills(编写技能)

既然”TDD for Skills”是核心哲学,那么如何执行?这个 Skill 就是操作手册。

核心流程:

1. 构建测试场景:强迫写出”高压剧本”,模拟 LLM 最容易偷懒或违规的真实业务场景
2. 捕获合理化借口:记录下 LLM 在压力下为了绕过规则而编造的具体理由,在 Skill 指令中进行针对性防御
3. 文档结构优化:指导如何编写 SKILL.md 的 Frontmatter,提醒 description 字段应仅包含”触发条件(Use when…)“,严禁包含流程摘要,以防止 LLM 产生”我已经懂了”的幻觉而跳过阅读正文

参考: CSDN 读代码系列 | 掘金 superpowers 详解

十六、社区与生态

16.1 关键人物

16.2 社区数据(2026 Q1)

16.3 商业化项目

16.4 衍生项目

参考: 博客园 手动安装教程 | 掘金 深度解析

十七、性能与基准测试

17.1 vs 无 Skill 对比(2025 Q4 用户调研,n=500)

17.2 Token 消耗对比

关键洞察:Superpowers 在短任务上有 overhead,但在中长任务上节省 40-60% Token。适合中等以上复杂度项目。

17.3 案例数据

案例 1: 基于 Superpowers 的增量开发实践

背景:50 人研发团队,从无 AI 编程到 Superpowers 标准化 实施:

• 第 1 周:培训 + 装 Superpowers
• 第 2-3 周:用 brainstorming + writing-plans 重构 3 个老项目
• 第 4 周:全面 TDD 结果:
• Bug 率下降 50%
• 需求变更响应时间 -40%
• 开发者满意度 +35%

案例 2:独立开发者

1 人团队,3 个月连续开发 AI 写作 SaaS 用 Superpowers + Claude Opus 4.6 平均每天交付 1.2 个功能(2-5 分钟任务粒度) 零重大 bug 漏到生产

参考: CSDN 调研数据

十八、与其他方法论 Skill 的对比

结论:三者互补不冲突。最佳实践是obra/superpowers(流程) + addyosmani(浏览器) + Anthropic(工具)。

十九、未来发展方向(2026-2027)

19.1 短期(Q3-Q4 2026)

• Superpowers Pro:团队版 + 协作 + 审计
• Skill Marketplace:第三方 Skill 商店
• 多模型支持:扩展到 GPT-5、Gemini 2.5
• VSCode 插件:可视化 Skill 触发

19.2 中期(2027)

• Skill 自进化:根据使用数据自动优化
• Skill 性能基准:类似 MLPerf 的标准评测
• 企业级 SLA:99.9% Skill 可用性

19.3 长期愿景

“让 AI 写代码,像人写代码一样靠谱。”

参考: Jesse Vincent 博客

二十、参考链接(完整版)

20.1 官方资源

1. obra/superpowers GitHub 仓库 ⭐ 34k+
2. superpowers-marketplace - Claude Code 官方市场
3. Anthropic Skills 主页 - 跨项目对比
4. agentskills.io 规范 - 行业标准
5. Jesse Vincent 博客 - 作者设计哲学
6. 沃顿商学院研究 - “Call Me A Jerk” 论文

20.2 中文深度分析

7. CSDN 极力推荐 Superpowers - 全景解析
8. 腾讯网 沃顿 + Superpowers - 学术 + 实战
9. CSDN GitHub 每日速递 - 18.5k stars 时代
10. 掘金 superpowers 深度解析 - “超能力”解密
11. 掘金 技能库学习 - 8 步工作流
12. CSDN opencode 与 agent skills - 跨平台安装
13. 博客园 手动安装教程 - 高级用户向
14. 博客园 Superpowers 详细用法 - 实战教程

20.3 学术与研究

15. Wharton: Call Me A Jerk - 28,000 次对话研究
16. Cialdini《影响力》 - 说服原则原始研究
17. Kent Beck TDD - 测试驱动开发

20.4 工具集成

18. Claude Code 官方
19. OpenCode 平台
20. Codex CLI
21. GitHub Copilot CLI

20.5 相关项目

22. addyosmani/agent-skills ⭐ 37k+
23. trailofbits/skills ⭐ 3k+
24. anthropics/skills ⭐ 108k+
25. awesome-claude-code

最后:obra/superpowers 不是另一个 Coding Agent,而是给 Coding Agent 用的”工程方法论框架”。它真正吸引人的地方,不在于”能多做一件事”,而在于”让已经会做事的 Agent,用更靠谱的流程去做事”。

十七、常见问题 FAQ

17.1 什么是 Skills?

Skills 是打包在文件夹中的一组指令,用于教 Claude 如何处理特定任务或工作流。通过 Skills,用户无需在每次对话中重复解释偏好、流程和专业知识。

17.2 Skills vs Subagents vs MCP?

17.3 如何选择 Skill?

1. 重复工作流 → Skill
2. 复杂多步骤 → Subagent
3. 外部 API → MCP
4. 结合使用 → Skill 编排 Subagent + MCP

17.4 Skills 在哪些平台可用?

• Claude Code
• Claude.ai
• Cursor
• OpenCode
• OpenClaw
• GitHub Copilot
• Windsurf
• Cline
• Roo Code
• Kiro
• Junie
• Augment Code
• Warp
• Goose

17.5 Skill 大小有限制吗?

• description:≤ 1024 字符(开放) / ≤ 1536 字符(Claude Code)
• SKILL.md:建议 < 500 行
• 完整加载:≤ 5,000 token
• 总大小:无硬性限制,建议 < 1MB

17.6 如何让 Skill 真正被触发?

来自 Anthropic 14 个设计模式:

1. description 主动:写明触发词
2. 排除条款:说明什么时候不用
3. 示例:在 SKILL.md 里放 2-3 个 Input/Output 示例
4. 测试:跑 5-10 个真实场景

17.7 8 个参考链接

1. Anthropic Skills 官方
2. 简书 Claude Code Skills 完整指南
3. CSDN 14 个 Skill 设计模式
4. CSDN Vibe Coding 实战
5. 腾讯网 Skill 创建完全指南
6. Anthropic Lessons from Claude Code
7. Superpowers 实战
8. OpenSkills 仓库

十八、结语:Skills 改变的不只是工作流

来自 腾讯网 Anthropic 内部 Skill 方法论 收尾洞察:

“Skill 本质上是在做 Context Engineering。”

当 5 年后我们回望 2026,会发现:

• Skills 重新定义了”软件工程”——从代码到流程
• Skills 重新定义了”团队”——从人到 AI 协作者
• Skills 重新定义了”个人成长”——每个 Skill 都是一次能力跃迁

未来属于那些能写出好 Skill 的人。

写一个 Skill,送给未来的自己。

参考资料

1. obra/superpowers GitHub 仓库
2. Anthropic Claude Code 官方文档
3. Cialdini Influence at Work
4. 腾讯网 superpowers 深度分析
5. CSDN: Superpowers Skills 完整探索