Superpowers Skill 套件整理

Superpowers 由 obra 开源，是一套覆盖完整开发流程的 Skill 套件。核心哲学：不靠直觉和运气写代码，每一步都该有明确的方法论撑着。

和 Trellis 相比，Superpowers 更轻量，不依赖项目初始化、不侵入目录结构，把 Skill 装上去就能用。14 个 Skill 覆盖了从”想清楚要做什么”到”确认做完了没问题”的完整链路，还包括元技能引导、子代理开发、分支收尾、编写自定义 Skill 等进阶能力。

安装与基本使用

安装

Superpowers 是公开 Skill，在支持 Skill 的 AI 编程工具（OpenCode / Claude Code / Codex / Cursor 等）中直接搜索安装即可：

1
2
3
4
5

# 在工具内搜索安装，例如 OpenCode：
/skills install obra/superpowers

# 或者装单个 Skill
/skills install obra/superpowers/writing-plans

GitHub 仓库地址：github.com/obra/superpowers

使用方式

安装后，Skill 会根据你说话的内容自动触发。比如你描述了一个 bug，systematic-debugging 会自动介入；你要开始写新功能，test-driven-development 会自动接管流程。

也可以显式调用，在对话中直接说你要用哪个 Skill：

1

帮我用 test-driven-development 的方式写一个用户登录接口

推荐安装策略

快速上手：一个完整示例

假设你要做一个”用户邀请功能”。全装 Superpowers 后的对话流程大概是这样的：

第一步 — brainstorming 自动触发：

1
2
3
4

> 我想做一个团队邀请功能，管理员通过邮箱邀请新成员加入工作区。

AI 引导你讨论：邀请生命周期、角色分配时机、过期策略、重复邀请处理……
最终收敛成一个清晰的需求范围。

第二步 — writing-plans 自动接手：

1
2
3
4
5
6

AI 把上一步的结论整理成 plan.md：
- 目标：实现团队成员邮箱邀请功能
- 约束：不破坏现有权限模型、支持事务回滚
- 方案：分 5 步实现（数据库 → API → 邮件 → 前端 → 集成测试）
- 风险：邮件发送失败如何处理
- 验收标准：每步有具体可验证的 checklist

第三步 — executing-plans 驱动执行：

1
2
3
4

> 按 plan.md 开始执行。

AI 从第一步"数据库表设计"开始，完成后对照验收标准自查，
通过后自动进入第二步"API 实现"……直到全部完成。

第四步 — test-driven-development 保障质量（你不提用tdd执行他就不会测试先行而是直接去写）：

1
2

每一步的实现都以测试先行：先写失败测试 → 看到它变红 → 最小实现让它变绿 → 重构。
铁律是没亲眼看到测试失败就不算数。

第五步 — requesting-code-review 准备提 PR：

1
2
3
4

> 准备提 PR 了，帮我做一下 CR 前检查。

AI 列出变更清单、标注 JWT 刷新逻辑为高风险改动、
生成 CR 描述（写的是"为什么用事务包裹邀请+邮件"，而不是"改了哪些文件"）。

第六步 — 收到反馈后，receiving-code-review 处理：

1
2
3
4

> reviewer 提了 3 条意见，帮我处理。

AI 分类：1 个逻辑问题（高优）、1 个设计建议（中优）、1 个命名偏好（低优）→ 
逐条生成回应 → 引导修改 → 改完后回查。

第七步 — verification-before-completion 完工检查：

1
2
3
4

> 应该差不多了，帮我做最后的完工验证。

AI 跑全量测试、逐条对验收标准、检查边界（空邮箱、超长邮箱、并发邀请）、
确认没有遗留 TODO → 全部通过 → 标记完成。

中途出了 bug？ — systematic-debugging 介入：

1
2
3

> 邀请邮件有时候发不出去，但没报错。

AI 引导你列出三个假设 → 二分法验证 → 定位到 SMTP 连接池超时 → 最小复现确认 → 修复。

整个流程走完，每一步都有方法论撑着，不需要靠直觉猜”下一步该干啥”。

整体概览

一、brainstorming — 结构化头脑风暴

很多讨论最后变成闲聊，不是因为大家不认真，而是缺少一个把想法往下推的框架。brainstorming 把头脑风暴拆成三个阶段：

内置 5 种引导模板：产品策略、技术架构、UI 方案、性能优化、重构路径。不管讨论什么话题，它都能帮你把发散的想法一步步收敛成可执行的结论。

基本使用：

安装后，当你描述一个模糊的需求或想法时自动触发。也可以显式调用：

1
2
3
4

帮我用 brainstorming 讨论一下这个后台管理系统应该怎么设计权限模型。

目前的需求是：管理员、编辑者、只读用户三种角色，不同角色能看到不同的菜单和操作按钮。
参考 RBAC 来设计。

它会先让你自由发散方案（不评判），再用矩阵筛选可行性高的，最后用 Pugh 矩阵给出量化对比结论。

二、writing-plans — 编写实施计划

需求到手之后很容易直接动手写代码，但跳过计划环节往往是返工的根源。writing-plans 强制把需求拆成五步：

1

目标 → 约束 → 方案 → 风险 → 验收标准

每一步都要求具体可验证的输出。不允许模糊的”优化一下”这种话出现。支持草稿→评审→定稿三轮迭代，最终产出可直接交付执行的 plan.md。

基本使用：

描述你要做的事情时自动触发，或者显式调用：

1
2
3
4

帮我用 writing-plans 给用户登录功能写一个实施计划。

需求：支持手机号+验证码登录、邮箱+密码登录、JWT 鉴权、刷新 token。
技术栈：Node.js + Express + PostgreSQL。

产出会包含：明确的目标、技术栈约束、分步实施方案、潜在风险和缓解措施、每步的验收标准。

三、executing-plans — 严格按计划执行

有计划之后，executing-plans 负责确保执行不跑偏。核心规则很简单：

1. 每完成一步，先对照验收标准 self-check
2. 通过后才进入下一步
3. 遇到偏差时暂停，先更新计划，不闷头硬干

它和 writing-plans 天然配对使用——writing-plans 产出的 plan.md 直接拿来驱动执行。

基本使用：

有了 writing-plans 产出的 plan.md 之后，继续对话时自动触发：

1

按照刚才写的 plan.md 开始执行，先从第一步数据库表设计开始。

每完成一步它会自动对照验收标准自查，通过后才放行下一步。遇到偏差会暂停提醒你更新计划。

四、systematic-debugging — 系统化调试

最容易被低估的一个 Skill。日常调试很容易变成”试一下改这里看看行不行”，随机尝试改完能跑就算了。systematic-debugging 要求每次修改前先回答**”为什么这个改法能解决问题”**：

不是不让试，而是要求每次尝试都有理由。避免试了十次改好了但不知道为什么好的情况。

基本使用：

描述一个 bug 时自动触发，或者显式调用：

1
2
3
4

帮我用 systematic-debugging 排查这个 bug：

用户点击"提交订单"按钮后页面卡住，控制台报 500 错误，但订单有时候又确实创建成功了。
后端是 NestJS + PostgreSQL，没有加日志。

它会先让你列三个最可能的假设，然后引导你一步步二分法验证直到定位根因。

五、test-driven-development — 严格 TDD

TDD 是老概念了，但真正严格执行的人不多。test-driven-development 把标准钉死在三个动作上：

1

写失败测试 → 亲眼看见它变红 → 最小实现让它变绿 → 重构

铁律：没亲眼看到测试失败就不算 TDD。 禁止先写实现再补测试。新功能、修 bug、重构一律适用，覆盖单测 + 集成测试 + E2E 分层策略。

基本使用：

描述一个需要实现的功能时自动触发：

1
2
3

帮我用 TDD 的方式实现一个邮箱格式校验函数。

规则：必须包含 @，@ 前面至少一个字符，@ 后面是域名+顶级域名，不允许连续两个点。

它会先写测试用例，跑一遍确认全部变红，再逐步实现让测试变绿，最后重构。

六、requesting-code-review — 提交 CR 前自检

很多时候 CR 沟通成本高的原因不是 reviewer 不好好看，而是提交者没把上下文交代清楚。requesting-code-review 在提交 CR 前强制做三件事：

1. 自我 review 变更清单：标注高风险改动
2. 补全上下文说明：写清楚”为什么这样改”而不是”改了什么”
3. double-check 测试覆盖：确认变更都有对应的验证

让 reviewer 花最少的时间看懂你的意图，而不是靠猜。

基本使用：

代码改完之后，准备提 PR 之前调用：

1
2
3

帮我用 requesting-code-review 检查一下这次变更，准备提 PR 了。

改动范围：新增了 user.service.ts 的邮箱校验逻辑，改了 auth.middleware.ts 的 token 刷新策略。

它会帮你列出变更清单、标注高风险点、生成 CR 描述（写原因不写过程）、检查测试覆盖。

七、receiving-code-review — 处理 CR 反馈

收到 CR 意见之后的常见问题：要么改了没说，要么说了没改，要么每条都回很长但没分清主次。receiving-code-review 给出一套标准流程：

避免陷入”改了但没解释”和”解释但没改”两种极端。

基本使用：

收到 CR 意见后调用：

1
2
3
4
5

帮我用 receiving-code-review 处理这些 CR 意见：

1. "这里用 any 类型不安全，改成泛型" 
2. "这个 SQL 查询有 N+1 问题，用 join 优化一下"
3. "变量命名建议用 camelCase"

它会帮你分类、排优先级、逐条生成回应，然后引导修改并回查。

八、verification-before-completion — 完工前验证

最后一个 Skill，也是最容易被跳过的。verification-before-completion 要求在标记 done 之前必须过一遍：

• 跑全量测试
• 逐条检查验收标准
• 验证边界 / 异常路径
• 检查是否有遗漏文件或 TODO

没通过自检不能标记完成。类比工厂出厂质检——不是信任问题，是流程保障。

基本使用：

功能写完之后，准备说”做完了”之前调用：

1
2
3

帮我用 verification-before-completion 做最后的完工检查。

这次做的功能是用户登录，验收标准在 plan.md 里。

它会跑全量测试、逐条对验收标准、扫边界和异常路径、检查有没有遗留的 TODO 或临时文件。

九、using-superpowers — 元技能：如何发现和使用 Skill

这是整个 Superpowers 套件的”大脑”。using-superpowers 不解决具体技术问题，它教 agent 如何找到并使用其他 Skill。

核心规则只有一条：

在任何回复或行动之前，先检查有没有相关的 Skill。哪怕只有 1% 的可能性适用，也必须调用。

它建立了三级优先级：

1. 用户指令（AGENTS.md、直接请求）—— 最高
2. Superpowers 技能 —— 与默认行为冲突时覆盖
3. 系统默认提示 —— 最低

另外内置了一套”危险信号”自检表，防止 agent 给自己找借口跳过 Skill：

基本使用：安装后自动生效，不需要显式调用。它是所有其他 Skill 的调度中心。

十、subagent-driven-development — 子代理驱动开发

如果你已经用 writing-plans 产出了一份 plan.md，subagent-driven-development 提供了一种更高效的执行方式：每个任务派发一个全新子代理去实现 + 审查。

vs. executing-plans：executing-plans 是串行自己在当前会话做；subagent-driven-development 是每个任务用全新上下文的子代理来做，更干净、更快，但需要计划已写好且任务相对独立。

基本使用：有了 plan.md 后自动触发，或者显式调用：

1

按照 subagent-driven-development 的方式执行 plan.md，从 Task 1 开始。

十一、dispatching-parallel-agents — 并行派发子代理

当多个任务彼此独立、无共享状态、无顺序依赖时，排队做就是浪费时间。dispatching-parallel-agents 教你怎么把独立任务并行派发给多个子代理。

适用条件：

• 3 个以上测试文件报不同的错
• 多个子系统独立出问题
• 每个问题不需要其他问题的上下文就能理解
• 没有共享状态（不会改同一个文件）

基本使用：

1

这三个测试文件报错的原因互不相关，帮我用 dispatching-parallel-agents 并行排查。

一次派发三个子代理，它们同时工作，最后由你整合结果。

十二、finishing-a-development-branch — 分支收尾

代码写完了、测试全绿了，然后呢？finishing-a-development-branch 提供标准化的收尾流程：

1. 验证测试 —— 先跑全量测试，不过不能进入下一步
2. 检测环境 —— 自动判断普通仓库 / worktree / detached HEAD
3. 提供选项 —— 精确给出 4 个选项（detached HEAD 则 3 个）

基本使用：功能开发完毕后自动触发，或者显式调用：

1

代码差不多了，帮我用 finishing-a-development-branch 收尾。

十三、using-git-worktrees — Git Worktree 环境隔离

每次开发新功能时，using-git-worktrees 确保你在隔离的工作空间中工作。

三步流程：

1. 检测现有隔离 —— 如果已经在 worktree 里，跳过创建
2. 创建隔离空间 —— 优先用平台原生工具，fallback 到 git worktree add
3. 验证基线 —— 装依赖、跑测试，确认环境干净

核心原则：不跟自己打架——先检测再创建，有原生工具就不用 git 手动命令。

基本使用：开始新功能开发时自动触发，或者显式调用：

1

帮我用 using-git-worktrees 创建一个隔离的工作空间来开发新功能。

十四、writing-skills — 编写自己的 Skill

writing-skills 把 TDD 方法论应用到编写 Skill 本身：先写测试场景（用子代理模拟压力场景），看 agent 在不加载 Skill 的情况下怎么犯错（RED），再写 Skill 修正这些行为（GREEN），最后不断补漏洞（REFACTOR）。

核心理念：

没亲眼看到 agent 在没有 Skill 的情况下失败，你就不知道这个 Skill 教得对不对。

它涵盖：

• Skill 的 YAML frontmatter 规范（name/description 怎么写才能被正确发现）
• 关键词覆盖策略（错误信息、症状、工具名）
• 反”找借口”设计（理性化表格、危险信号列表）
• 四种 Skill 类型各自的测试方法（规则类、技巧类、模式类、参考类）

基本使用：当你需要创建自定义 Skill 时调用：

1

帮我用 writing-skills 写一个 React 表单校验的 Skill，我发现自己总是遗漏边界情况。

场景搭配建议

日常开发全流程

组合：using-superpowers + brainstorming + writing-plans + executing-plans（或 subagent-driven-development）+ verification-before-completion + finishing-a-development-branch

从头到尾一条线：想清楚 → 写出计划 → 按计划执行（串行或子代理） → 完工前验证 → 分支收尾。适合大部分功能开发和重构任务。

复杂功能开发（推荐子代理模式）

组合：brainstorming + writing-plans + subagent-driven-development + verification-before-completion + finishing-a-development-branch

每个任务独立子代理实现 + 审查，质量更高，迭代更快。适合多步骤、任务相对独立的场景。

Bug 修复

组合：systematic-debugging + test-driven-development

先系统化定位根因，再用 TDD 方式写回归测试 + 修复。确保修完不会再犯。

团队协作

组合：requesting-code-review + receiving-code-review

一个负责提交前的自检和信息补全，一个负责收到反馈后的标准处理流程。双向降低 CR 摩擦。

工程管理

组合：using-git-worktrees + dispatching-parallel-agents + finishing-a-development-branch

环境隔离 → 并行开发 → 规范化收尾，保证工作空间干净、效率高。

重难点功能

组合：全上。

从 using-superpowers 调度，到 brainstorming 想清楚，writing-plans 写计划，subagent-driven-development 子代理执行，test-driven-development 保障质量，requesting-code-review 自检，verification-before-completion 验证，finishing-a-development-branch 收尾——14 个 Skill 全链路覆盖。适合关键模块、复杂重构、或者你对这块不太熟需要方法论撑着的场景。

Superpowers vs Trellis

两者不互斥。Superpowers 管方法论层——帮你把每一步做扎实；Trellis 管工程层——帮你把上下文和任务状态持久化。可以一起用，也可以挑一个。

官方仓库：github.com/obra/superpowers