首页 › skills-review › 拆superpowers:先背目录再干活

本期拆解对象:obra/superpowers

这是本栏目 Skills 生态观察的第 2 轮,按轮次安排做单个热门 Skill 的深度拆解。这次选的是 obra/superpowers——社区里名气最大、也最常被模仿的技能包之一。选它不是因为热榜排名(时效数据请以仓库页为准),而是因为它回答了所有 Skill 作者都绕不开的三个问题:Claude 怎么记得自己会什么?一堆技能怎么互相咬合成流程?技能库怎么自己长大?

先说结论:superpowers 卖的其实不是某个技能,而是一套「先背目录、再干活」的运行系统。它的 SKILL.md 单独拿出来,每一篇都不算惊艳;组合起来,却成了把 Claude 从「即兴写码」掰成「先问、再计划、再红绿测试」的完整约束链。本文按仓库的文件层次逐层拆开,最后提炼六条可以直接抄走的设计模式。

说明:成稿时未能实时核对仓库的星标数与最新技能清单,文中不引用具体数字,时效信息以 github.com/obra/superpowers 页面为准;结构与分析基于该仓库公开内容整理。

仓库全景:它不是一件 Skill,是一条流水线

先纠正一个常见误解。很多人把 superpowers 当成「一个很厉害的技能」来装,装上才发现它是一个插件形态的技能集合,主干大致是这样的:

obra/superpowers/
├── .claude-plugin/          # 插件清单,marketplace 分发的元数据
├── commands/                # 斜杠命令入口
├── hooks/                   # SessionStart 钩子:会话开始时注入技能索引
└── skills/
    ├── using-superpowers/              # 索引技能:动手前先翻目录
    ├── brainstorming/                  # 先问后写
    ├── writing-plans/                  # 把设计落成计划文件
    ├── executing-plans/                # 照单执行
    ├── subagent-driven-development/    # 子代理分派
    ├── test-driven-development/        # 红绿循环铁律
    ├── systematic-debugging/           # 四阶段排障
    ├── verification-before-completion/ # 交差前先验证
    ├── requesting-code-review/         # 发起评审
    ├── receiving-code-review/          # 接收评审
    ├── using-git-worktrees/            # 工作树隔离
    └── writing-skills/                 # 元技能:教 Claude 写新技能

(个别技能随版本增删,以仓库实际目录为准。)

看懂这张图的关键是分清四层:入口层(plugin 清单 + 钩子)、索引层(using-superpowers)、流程层(brainstorming → plans → 执行)、质量层(TDD、排障、验证、评审),外加一个元层(writing-skills)。市面上绝大多数技能包只有「质量层」散件,superpowers 的护城河在入口层和索引层。

逐文件拆解

1. hooks/:整个系统的命门

技能包最常见的死法不是写得差,而是 Claude 根本不知道它存在。你装了十个技能,模型上下文里没有它们的影子,触发就全靠 description 里那句「Use when...」碰运气。

superpowers 的解法是工程手段而不是提示词技巧:用 SessionStart 钩子,在每次会话开始时把技能索引拍进上下文。Claude 一睁眼就拿到一份「我会什么」的清单,后续每个技能再靠检索按需加载细节。这是典型的渐进披露(progressive disclosure):索引常驻、正文懒加载,token 开销被压在可控范围。

这一手值得所有 Skill 作者抄:你的技能再好,解决不了「被记住」的问题就等于不存在。

2. using-superpowers:一份会自我指涉的目录

索引技能的 frontmatter 里,description 不写广告词,写的是触发条件;正文只有一件事——要求 Claude 在动手前先检索技能库,找到匹配的技能再开始。它相当于给整包技能加了一个「开机自检」。

设计上最妙的是自我指涉:索引本身也是一个技能,遵守和其他技能完全相同的格式规范。系统里没有特权文件,规则统一,维护成本就低。

3. brainstorming:把「直接开写」定为违规

这个技能针对的是 Claude 写码最被诟病的习惯:用户说「做个 X」,模型立刻产出三百行代码。

brainstorming 的正文是一组行为约束:一次只问一个问题;每个问题给出两三个带取舍的选项让用户选;聊到需求边界清楚为止;最后把结论沉淀成设计文档,而不是口头共识。它甚至在反面清单里点名了自己要治的病——「不要在用户还没说完时就给方案」。

4. writing-plans / executing-plans:成对出现的流程件

这两个技能展示了 Skill 设计里容易忽略的一条原则:流程件要成对设计。

writing-plans 规定产物必须是一个 markdown 文件(落在 docs/plans/ 一类的目录),任务要切到「一口能吃完」的粒度,每步写明涉及的具体文件路径和验证方式。executing-plans 则规定照单执行、每个任务一次提交;如果发现规格里没写的东西,上报,而不是即兴发挥——这句约束直接封死了 Claude 最擅长的「好心加戏」。

5. test-driven-development:用大写字母立的铁律

这是全仓库最有辨识度的一篇。正文用大写祈使句立了一条铁律:没有失败中的测试,就不许写实现代码。流程是标准红绿循环:先写测试看它失败(RED),再写最小实现让它通过(GREEN),然后重构(REFACTOR);而且一次只写一两个用例,不批量。

大写不是排版事故,是提示词工程:在长上下文里,格式强度就是约束强度。后面 xlsx、docx 这些官方件里铺满的 CRITICAL 标注,逻辑同源。

6. systematic-debugging:先诊断,后开药

排障技能把修 bug 拆成四阶段:读清报错、调查根因、形成假设并验证、最小化修复。它的反面清单同样直白——禁止「试试看」式地改代码。和 TDD 一样,它治的不是能力问题,是流程跳步问题:模型有本事修对,但默认路径是先乱改一气。

7. verification-before-completion:封死「应该能跑」

交差前必须完整跑一遍测试,不许用「应该没问题」收尾。单看是常识,但把它做成独立技能、并且挂在执行链末端强制经过,性质就变了:验证从建议变成了关卡。

8. requesting / receiving-code-review:连「被评审的姿态」都管

发起评审的技能规定请求里要带什么材料、请对方按什么维度看(正确性、规格符合度、注释质量);接收评审的技能规定被评审方逐条回应、不谄媚、不为了讨好评审而推翻自己的合理决定。连「对反馈 say thank you 但不盲目改」这种细节都写进去了——这是把职场协作礼仪编译成了提示词。

9. writing-skills:让技能库自己长大

元层是 superpowers 最有野心的部分。writing-skills 教 Claude 什么时候值得把一段经验沉淀成新技能、新技能怎么命名、模板长什么样。用户说「这个坑记下来」,它不是记进某次对话,而是产出一个符合规范的新技能目录,下次会话经索引自动生效。

装得越久越强,说的就是这层。它把技能包从「静态资产」变成了「可自我繁殖的系统」。

工作流全景

把上面的件串起来,就是 superpowers 期望的一次标准开发循环:

flowchart TD
    A["会话启动"] --> B["SessionStart钩子"]
    B --> C["注入技能索引"]
    C --> D["using-superpowers"]
    D --> E{"任务类型"}
    E -->|模糊需求| F["brainstorming"]
    E -->|修bug| G["systematic-debugging"]
    E -->|已有计划| H["executing-plans"]
    F --> I["writing-plans"]
    I --> H
    H --> J["test-driven-development"]
    G --> J
    J --> K["verification-before-completion"]
    K --> L["requesting-code-review"]
    L --> M["逐任务提交"]

再看仓库的四层结构:

mindmap
  root((superpowers))
    入口层
      插件清单
      SessionStart钩子
      斜杠命令
    索引层
      using-superpowers
      会话开头注入目录
    流程层
      brainstorming
      writing-plans
      executing-plans
    质量层
      test-driven-development
      systematic-debugging
      verification-before-completion
      code-review两件
    元层
      writing-skills
      自我繁殖新技能

可直接抄走的六条设计模式

  1. description 写触发条件,不写广告词。每篇 SKILL.md 的 description 都在回答「什么情况下该用我」,全篇找不到「强大」「高效」这类自我表扬。
  2. 铁律用大写祈使句。真正的硬约束(不写失败测试不写码)用格式强度顶上去,软建议正常行文——约束分层,读者(模型)才分得清轻重。
  3. 索引常驻、正文懒加载。SKILL.md 本体保持短小,细节外链成文件,靠钩子注入的目录解决「被记住」问题。
  4. 流程件成对出现。写计划的技能必配执行的技能,立规矩的技能必配守规矩的技能,单件流程约束在长任务里必然走样。
  5. 每个技能带反面清单。点名「不要做什么」比罗列「要做什么」更能矫正模型的默认习惯。
  6. 留一个元技能。教系统写新技能,让使用过程变成资产积累过程——这是技能包和技能库的分界线。

评测对比表

对照组选官方 anthropics/skills 的 example-skills 系列,以及最常见的「单件裸装」模式。实战效果一项基于社区反馈整理,非本人横向实测。

维度(权重) superpowers 官方 example-skills 单件裸装
功能完整度 25% ★★★★★ 整链覆盖开发全流程 ★★★★ 单件扎实、流程靠用户自己拼 ★★ 只管一件事
设计质量 25% ★★★★★ 索引+钩子+成对流程件 ★★★★★ 官方规范的定义者 ★★★ 良莠取决于作者
实战效果 20% ★★★★ 长任务收益最大 ★★★★ 单任务即装即用 ★★★ 看场景
上手难度 15% ★★★★ 需理解插件机制 ★★★★★ 克隆即用 ★★★★★ 装完就生效
社区活跃度 15% ★★★★★ 分叉模仿众多 ★★★★★ 官方维护 ★★ 多数无维护
加权总分 4.65 4.55 2.90

两者只差 0.1 分,但差距的性质值得说清:官方件赢在规范与即用性,superpowers 赢在系统性。要一个「做 PPT 的件」,用官方;要把 Claude 的开发行为整体掰弯,用 superpowers。

安装与使用

# 方式一:Claude Code 内以插件市场安装(推荐)
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

# 方式二:手动克隆后按 README 指引启用
git clone https://github.com/obra/superpowers.git

安装后在 Claude Code 里说「我想做个 X 功能」,观察它是否先进入提问环节而不是直接写码——这是验证装好的最快方式。具体命令以仓库 README 当前版本为准。

适用与不适用场景

适用:从零开发新功能、要求测试覆盖的项目、多轮长任务、希望把踩坑经验沉淀成团队资产的场景。

不适用:一行式小修复(走完整流程纯属浪费)、纯问答与写作类任务(流程层用不上)、上下文预算极度敏感的场合(会话开头注入索引有固定开销)。另外要提醒:它对模型行为的约束相当强硬,如果你就喜欢 Claude 即兴出活的手感,这套铁律会显得碍事。

推荐排行榜

结语

superpowers 的真正贡献,是把「提示词工程」往上拔了一层,变成了「技能系统工程」:单篇 SKILL.md 是术,索引机制、成对流程、元技能才是道。看完这轮拆解,如果你只记住一句话,记住这句——先解决「Claude 记得自己会什么」,再谈「Claude 会得多好」。

参考来源

  1. obra/superpowers — 本文拆解对象,技能包主仓库,结构与技能清单以此为准
  2. obra/superpowers-marketplace — 插件市场清单仓库,安装入口
  3. anthropics/skills — 官方技能仓库,评测对照组来源
  4. skills.sh — 技能生态榜单站,热度与生态面参考
  5. blog.fsck.com — 作者 Jesse Vincent 的博客,连载过 superpowers 的设计过程,具体篇目以站内检索为准

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入