介绍：

简单来说，Superpowers是一个为 AI 编程智能体（Agent）设计的高标准工程流水线。它不是一个简单的工具，而是一套约束（Guardrails）和技能库（Skills），强制 AI 像顶级资深软件架构师一样思考和工作，而不是拿到需求就直接“无脑”写代码。

进入管理员cmd claudecode

/plugin marketplace add obra/superpowers-marketplace

/plugin install superpowers@superpowers-marketplace

使用见图片 superpowers使用.png

work flow：

brainstorming(头脑风暴) → writing-plans → executing-plans / subagent-driven-development
                                    ↓
                              using-git-worktrees
                                    ↓
                              test-driven-development
                                    ↓
                              requesting-code-review
                                    ↓
                              receiving-code-review
                                    ↓
                              verification-before-completion
                                    ↓
                              finishing-a-development-branch

1、brainstorming(头脑风暴)

用途: 在任何创造性工作之前必须使用 - 创建功能、构建组件、添加功能或修改行为时，通过协作对话探索用户意图、需求和设计。

核心流程:

  • 探索项目上下文（检查文件、文档、最近提交）
  • 一次问一个澄清问题
  • 提出2-3种方案及其权衡
  • 分段呈现设计并获得用户批准
  • 将设计文档保存到docs/plans/YYYY-MM-DD--design.md
  • 调用writing-plans技能创建实现计划

关键原则: 在获得设计批准前，不得进行任何实现操作。

2、writing-plans (编写计划)

用途: 当你有规格或需求需要多步骤任务时，在接触代码之前使用。

核心原则: 编写详细的实现计划，假设工程师对代码库零上下文。记录他们需要知道的一切：每个任务要触及哪些文件、代码、测试、文档，如何测试。将整个计划分解为小任务。

任务粒度: 每个步骤是一个动作（2-5分钟）：

  • "编写失败的测试" - 一个步骤
  • "运行确认失败" - 一个步骤
  • "实现最小代码使测试通过" - 一个步骤
  • "运行测试确认通过" - 一个步骤
  • "提交" - 一个步骤

输出: 计划保存到docs/plans/YYYY-MM-DD-.md

3、executing-plans (执行计划)

用途: 当你有书面实现计划需要在单独会话中执行时使用，带有审查检查点。

核心流程:

  • 加载并审查计划
  • 批量执行任务（默认前3个）
  • 报告进度等待反馈
  • 继续下一批
  • 完成后调用finishing-a-development-branch

关键原则: 批量执行 + 架构师审查检查点。遇到阻塞立即停止并寻求帮助。

4、 systematic-debugging (系统化调试)

用途: 遇到任何 bug、测试失败或意外行为时，在提出修复之前使用。

铁律: 没有根本原因调查就不能提出修复。症状修复是失败。

5、 test-driven-development (测试驱动开发)

用途: 实现任何功能或修复 bug 时，在编写实现代码之前使用。

铁律: 没有失败的测试就不能写生产代码。先写代码？删除它，重新开始。

红-绿-重构循环:

  • RED: 编写失败的测试
  • 验证 RED: 确认测试正确失败
  • GREEN: 编写最小代码使测试通过
  • 验证 GREEN: 确认测试通过
  • REFACTOR: 清理代码

关键原则: 如果没有看到测试失败，你不知道它是否测试了正确的东西。

6、 subagent-driven-development (子代理驱动开发)

用途: 在当前会话中执行具有独立任务的实现计划时使用。

核心流程:

  • 读取计划，提取所有任务，创建 TodoWrite
  • 为每个任务派发实现子代理
  • 两阶段审查：规格合规性审查 → 代码质量审查
  • 修复问题后重新审查
  • 标记任务完成
  • 完成后调用finishing-a-development-branch

优势: 每个任务使用新子代理（无上下文污染）、两阶段审查确保质量、快速迭代。

7、using-git-worktrees (使用 Git Worktrees)用途:

开始需要与当前工作区隔离的功能开发时，或在执行实现计划之前使用。核心功能: Git worktrees 创建共享同一仓库的隔离工作区，允许同时在多个分支上工作而无需切换。

目录选择优先级:

  • 检查现有目录（.worktrees或worktrees）
  • 检查 CLAUDE.md 中的偏好
  • 询问用户

安全验证: 对于项目本地目录，必须验证目录已被 gitignore 忽略。

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

用途: 实现完成、所有测试通过后，需要决定如何集成工作时使用。

核心流程:

  • 验证测试通过
  • 确定基础分支
  • 提供4个选项：
  • 执行选择
  • 清理 worktree

关键原则: 测试失败时不能继续提供选项。

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

用途: 完成任务、实现主要功能或合并前验证工作满足需求时使用。

核心原则: 尽早审查，经常审查。

何时请求:

  • 强制：子代理驱动开发中每个任务后、完成主要功能后、合并到 main 前
  • 可选但有价值：卡住时、重构前、修复复杂 bug 后

处理反馈:

  • 立即修复 Critical 问题
  • 继续前修复 Important 问题
  • 稍后记录 Minor 问题

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

用途: 接收代码审查反馈时，在实施建议之前使用，特别是当反馈不清楚或技术上有疑问时。

核心原则: 实施前验证。假设前询问。技术正确性优于社交舒适度。

响应模式:

  • 阅读：完整阅读反馈不反应
  • 理解：用自己的话重述需求（或询问）
  • 验证：对照代码库现实检查
  • 评估：对这个代码库技术合理吗？
  • 响应：技术确认或有理由的回击
  • 实现：一次一项，逐个测试

禁止的响应: "你完全正确！"、"好观点！"、"让我现在实现"（验证前）

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

用途: 即将声称工作完成、修复或通过时，在提交或创建 PR 之前使用。

铁律: 没有新鲜验证证据就不能声称完成。如果在这个消息中没有运行验证命令，就不能声称它通过。

门控功能:

  • 识别：什么命令证明这个声明？
  • 运行：执行完整命令
  • 阅读：完整输出，检查退出码，计算失败
  • 验证：输出确认声明吗？
  • 只有这样：做出声明

常见失败: 使用"应该"、"可能"、"似乎"；在验证前表达满意。

12. dispatching-parallel-agents (派发并行代理)

用途: 面对2个以上可以独立工作的独立任务时使用。

使用场景:

  • 3个以上测试文件因不同根本原因失败
  • 多个子系统独立损坏
  • 每个问题可以在没有其他上下文的情况下理解
  • 调查之间没有共享状态

模式:

  • 识别独立域
  • 创建聚焦的代理任务
  • 并行派发
  • 审查并集成

不使用场景: 失败相关、需要完整上下文、探索性调试、共享状态。

13. using-superpowers (使用 Superpowers)

用途: 开始任何对话时使用 - 确立如何查找和使用技能。

核心规则: 在任何响应或操作之前调用相关或请求的技能。即使只有1%的可能性技能适用，也必须调用技能检查。

技能优先级:

  • 流程技能优先（brainstorming、debugging）- 决定如何处理任务
  • 实现技能其次（frontend-design、mcp-builder）- 指导执行

危险信号: "这只是个简单问题"、"我需要更多上下文"、"让我先探索代码库" - 这些想法意味着你在合理化，应该先检查技能。

14. writing-skills (编写技能)

用途: 创建新技能、编辑现有技能或在部署前验证技能工作时使用。

核心原则: 编写技能就是应用于流程文档的测试驱动开发。

TDD 映射:

  • 测试用例 = 使用子代理的压力场景
  • 生产代码 = 技能文档（SKILL.md）
  • 测试失败（RED）= 代理在没有技能时违反规则
  • 测试通过（GREEN）= 代理在有技能时合规
  • 重构 = 在保持合规的同时关闭漏洞

技能类型:

  • 技术型: 有步骤可遵循的具体方法
  • 模式型: 思考问题的方式
  • 参考型: API 文档、语法指南、工具文档

exp：

claude cli 或vscode clade code插件chat窗口

第一步：开启“架构师脑暴” (Brainstorming)

/brainstorm 我想做一个 GitHub Star 追踪工具，用 Node.js 写，需要支持本地 JSON 缓存，缓存有效期 5 分钟。请帮我细化技术方案。

第二步：制定“精密”计划 (Writing Plans)

/write-plan 根据brainstorm的结果，拆解执行计划。

第三步：任务执行与 TDD 强约束 (Execute Plan)

/execute-plan

第四步：系统化 Debug (Systematic Debugging)

/systematic-debugging  "GitHub API 403 错误，可能是频率限制"