Superpowers 常用命令与使用场景
关注 Superpowers 有段日子了，今天终于抽空安装测试了一下，整理了一份常用命令笔记。
网上关于 Superpowers 的介绍和各类 Harness 框架的对比评测很多。但想知道它究竟好不好用、是否适配自己的项目，终究还是得亲手试过才知道。
如何安装？给你的Agent说：
1 | 去 https://raw.githubusercontent.com/obra/superpowers/master/README.md 看看怎么安装，然后帮我装上 |
1. Superpowers 是什么
Superpowers 是一套面向多个 AI 编程工具的 skills 和工作流约束。它可以用于 Claude Code、Cursor、Codex、OpenCode、GitHub Copilot CLI、Gemini CLI 等工具。
简单来说，它是一堆 skill 的集合，通过 skill 约束强制 AI 遵守工程纪律。
它的作用是让这些 AI 在处理开发任务时更像按规范工作的工程助手，例如：
- 做新功能前先梳理需求和方案
- 改复杂内容前先写计划
- 遇到 bug 时先系统排查
- 需要时用并行 agent、worktree、review 流程
2. 触发方式
自动触发
当请求明显符合某个 skill 的用途时，Claude 通常会自动调用对应 skill。
例子：
- “帮我设计这个功能” →
brainstorming - “这个测试失败帮我排查” →
systematic-debugging - “先给我一个实现计划” →
writing-plans - “改完后帮我确认是不是真的完成” →
verification-before-completion
手动触发
如果你想明确指定流程，可以直接点名或者使用/命令：
用 brainstorming 先想方案或/brainstorming按 test-driven-development 来实现先走 writing-plans，不要直接改代码
常用命令速查表
| 命令 | 作用 |
|---|---|
brainstorming |
需求澄清：在任何创造性工作之前必须使用，在实现前探索用户意图、需求和设计，适合新功能设计、需求不清、需要先澄清再做 |
writing-plans |
任务拆解：当你有多步骤任务的规格或需求时，在接触代码前使用，适合多文件修改、中大型重构、API/前端/测试联动 |
systematic-debugging |
根因定位：遇到任何 bug、测试失败或异常行为时，在提出修复方案前使用，适合测试失败、报错原因不明、行为不符合预期 |
test-driven-development |
测试先行：实现任何功能或修复 bug 时，在编写实现代码前使用，适合新功能开发、bug 修复、回归风险高的改动 |
verification-before-completion |
证据说话：在声称工作完成、已修复或通过测试之前使用，要求运行验证命令并确认输出，适合确认测试通过、构建成功、结果可验证 |
requesting-code-review |
代码审查：完成任务、实现重要功能或合并前，验证工作是否符合要求，适合重要功能、里程碑步骤、合并前质量检查 |
finishing-a-development-branch |
分支收尾：实现完成、所有测试通过、需要决定如何整合工作时使用，提供合并、PR 或清理的结构化选项 |
using-superpowers |
流程规范：在开始任何对话时使用，建立如何查找和使用 skills 的规范，要求在任何响应之前先调用 Skill 工具 |
3. 常用命令与使用场景
需求澄清类
brainstorming
作用： 在创造性任务开始前先梳理目标、边界和实现方案。
适用场景：
- 新功能设计
- 页面或交互方案比较
- 需求不清晰，需要先澄清再做
- 不想 Claude 直接开始改代码
示例：
- “先用
brainstorming设计一下导出功能”
计划执行类
writing-plans
作用： 在多步骤任务开始前先形成实现计划。
适用场景：
- 跨多个文件修改
- 新增一整套功能
- API、前端、测试联动
- 中大型重构
示例：
- “先用
writing-plans给我出实现计划”
executing-plans
作用： 按已经确定的计划执行实现。
适用场景：
- 计划已经写好
- 你希望按既定步骤推进
- 适合在新的会话里继续执行既有计划
示例：
- “按刚才的计划继续，用
executing-plans执行”
质量保障类
systematic-debugging
作用： 系统化排查 bug、失败测试和异常行为。
适用场景：
- 测试失败
- 程序行为和预期不一致
- 报错原因不明
- 不希望 Claude 直接猜测性修复
示例：
- “用
systematic-debugging看下这个报错”
test-driven-development
作用： 先定义测试或预期，再写实现。
适用场景：
- 新功能开发
- bugfix
- 回归风险高的逻辑改动
- 你希望实现结果可验证
示例：
- “按
test-driven-development来修这个 bug”
verification-before-completion
作用： 在宣称”完成”前，先做验证。
适用场景：
- 改完后需要确认测试通过
- 需要确认构建成功
- 不想只听到口头上的”修好了”
示例：
- “先用
verification-before-completion验证，再告诉我结果”
代码审查类
requesting-code-review
作用： 在完成阶段主动请求代码审查。
适用场景：
- 完成重要功能
- 完成一个里程碑步骤
- 合并前想做一次质量检查
示例：
- “这个功能做完后，用
requesting-code-review再审一遍”
receiving-code-review
作用： 收到 review 意见后，先评估建议是否成立，再修改。
适用场景：
- 你刚收到 code review comments
- feedback 不够清晰
- 不想机械照改
示例：
- “我收到 review 反馈了，先用
receiving-code-review看看是否合理”
分支管理类
finishing-a-development-branch
作用： 在工作完成后，决定如何收尾分支。
适用场景：
- 功能完成
- 测试通过
- 需要决定下一步是提 PR、合并还是清理
示例：
- “做完了，用
finishing-a-development-branch看怎么收尾”
using-git-worktrees
作用： 在隔离工作区中开展任务。
适用场景：
- 不想污染当前工作目录
- 需要并行处理多个任务
- 需要在独立环境中验证改动
示例：
- “这个功能我想在隔离 worktree 里做”
并行任务类
dispatching-parallel-agents
作用： 将多个相互独立的任务分发给并行 agent。
适用场景：
- 前后端可独立探索
- 一个任务可拆成多个互不依赖的子任务
- 想加快检索、分析或实现速度
示例：
- “这个需求拆成几块，用并行 agent 一起做”
subagent-driven-development
作用： 用多个子 agent 协作推进开发。
适用场景：
- 大任务拆分执行
- 测试、实现、探索可以并行
- 当前会话希望采用 agent 协作模式
其他工具类
update-config
作用： 修改 Claude Code 的配置，例如 .claude/settings.json。
适用场景：
- 配置 hooks
- 修改权限策略
- 设置环境变量
- 让某些行为以后自动执行
示例：
- “用
update-config把这个检查配置成自动运行”
using-superpowers
作用： 在开始任何对话时使用，建立如何查找和使用 skills 的规范，要求在任何响应（包括澄清问题）之前先调用 Skill 工具。
4. 推荐工作流
新功能开发
brainstormingwriting-planstest-driven-developmentverification-before-completionrequesting-code-reviewfinishing-a-development-branch
修 bug
systematic-debuggingtest-driven-developmentverification-before-completionrequesting-code-review（重要修复时）
先计划再实现
brainstormingwriting-plansexecuting-plans
做完后收尾
verification-before-completionrequesting-code-reviewfinishing-a-development-branch
5. 什么时候建议手动指定 skill
建议你明确写出 skill 名称的情况：
- 你想强制先想方案，不要直接动手
- 你想强制先写计划
- 你想严格按 TDD 做
- 你要我在完成前必须跑验证
- 你想指定 review / 收尾流程
- 你想配置以后自动化执行的行为
6. 常用命令速查表
常用命令
| 命令 | 作用 |
|---|---|
brainstorming |
需求澄清：在任何创造性工作之前必须使用，在实现前探索用户意图、需求和设计，适合新功能设计、需求不清、需要先澄清再做 |
writing-plans |
任务拆解：当你有多步骤任务的规格或需求时，在接触代码前使用，适合多文件修改、中大型重构、API/前端/测试联动 |
systematic-debugging |
根因定位：遇到任何 bug、测试失败或异常行为时，在提出修复方案前使用，适合测试失败、报错原因不明、行为不符合预期 |
test-driven-development |
测试先行：实现任何功能或修复 bug 时，在编写实现代码前使用，适合新功能开发、bug 修复、回归风险高的改动 |
verification-before-completion |
证据说话：在声称工作完成、已修复或通过测试之前使用，要求运行验证命令并确认输出，适合确认测试通过、构建成功、结果可验证 |
requesting-code-review |
代码审查：完成任务、实现重要功能或合并前，验证工作是否符合要求，适合重要功能、里程碑步骤、合并前质量检查 |
finishing-a-development-branch |
分支收尾：实现完成、所有测试通过、需要决定如何整合工作时使用，提供合并、PR 或清理的结构化选项 |
using-superpowers |
流程规范：在开始任何对话时使用，建立如何查找和使用 skills 的规范，要求在任何响应之前先调用 Skill 工具 |
其他命令
| 命令 | 作用与适用场景 |
|---|---|
executing-plans |
计划执行：当你有书面实现计划需要在单独会话中执行、带有审查检查点时使用 |
receiving-code-review |
审视反馈：收到 code review 反馈后，在实施建议前使用，尤其当反馈不清晰或技术上有疑问时——需要技术严谨性和验证 |
using-git-worktrees |
分支隔离：开始需要与当前工作区隔离的功能工作或执行实现计划前使用，创建独立的 git worktree，带有智能目录选择和安全验证 |
dispatching-parallel-agents |
并行分发：面对 2 个或以上可以无需共享状态或顺序依赖独立处理的任务时使用 |
subagent-driven-development |
协作推进：在当前会话中执行具有独立任务的实现计划时使用 |
7. 一句话总结
Superpowers 的核心价值不在于”新增神奇能力”，而在于把 Agent 的做事方式变得更规范：
- 先思考
- 先计划
- 先调试
- 先验证
- 再收尾
要学习或测试 Superpowers，最简单的是亲自上手试试，先从一个空项目尝试吧，怎么折腾都没事儿。
附录：全技能一览
Superpowers 由以下 14 个 skills 组成，以下是官方原始 skill 的原版描述：
| Skill 名称 | 原版描述 | 中文翻译 |
|---|---|---|
brainstorming |
You MUST use this before any creative work… | 在任何创造性工作之前必须使用——包括创建功能、构建组件、添加功能或修改行为。在实现前探索用户意图、需求和设计。 |
writing-plans |
Use when you have a spec or requirements for a multi-step task, before touching code | 当你有多步骤任务的规格或需求时，在接触代码前使用 |
systematic-debugging |
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes | 遇到任何 bug、测试失败或异常行为时，在提出修复方案前使用 |
test-driven-development |
Use when implementing any feature or bugfix, before writing implementation code | 实现任何功能或修复 bug 时，在编写实现代码前使用 |
verification-before-completion |
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs | 在声称工作完成、已修复或通过测试之前，在提交或创建 PR 之前使用——要求运行验证命令并确认输出，证据优先于断言 |
requesting-code-review |
Use when completing tasks, implementing major features, or before merging to verify work meets requirements | 完成任务、实现重要功能或合并前，验证工作是否符合要求 |
receiving-code-review |
Use when receiving code review feedback, before implementing suggestions… | 收到 code review 反馈后，在实施建议前使用，尤其当反馈不清晰或技术上有疑问时——需要技术严谨性和验证 |
finishing-a-development-branch |
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work | 实现完成、所有测试通过、需要决定如何整合工作时使用——提供合并、PR 或清理的结构化选项 |
executing-plans |
Use when you have a written implementation plan to execute in a separate session with review checkpoints | 当你有书面实现计划需要在单独会话中执行、带有审查检查点时使用 |
using-git-worktrees |
Use when starting feature work that needs isolation from current workspace… | 开始需要与当前工作区隔离的功能工作或执行实现计划前使用——创建独立的 git worktree，带有智能目录选择和安全验证 |
dispatching-parallel-agents |
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies | 面对 2 个或以上可以无需共享状态或顺序依赖独立处理的任务时使用 |
subagent-driven-development |
Use when executing implementation plans with independent tasks in the current session | 在当前会话中执行具有独立任务的实现计划时使用 |
writing-skills |
Use when creating new skills, editing existing skills, or verifying skills work before deployment | 创建新 skills、编辑现有 skills 或在部署前验证 skills 是否正常工作时使用 |
using-superpowers |
Use when starting any conversation - establishes how to find and use skills… | 在开始任何对话时使用——建立如何查找和使用 skills 的规范，要求在任何响应（包括澄清问题）之前先调用 Skill 工具 |
许可协议
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
分享文章
