Superpowers 使用指南

Superpowers 是 Claude Code 的官方工作流增强插件，包含一系列专业化的Skills（技能），帮助你更系统、更高效地完成开发任务。✅- 探索需求和设计✅- 拆解任务✅- TDD 实施✅- 修复测试失败✅- 完成前验证✅- 请求审查✅ 功能完整的用户管理 API✅ 95.6% 测试覆盖率✅ 所有测试通过✅ 代码质量检查通过✅ 安全性考虑周全✅ 文档完整无 Superpowers有

深林小怪nan

2481人浏览 · 2026-03-19 10:51:04

深林小怪nan · 2026-03-19 10:51:04 发布

Superpowers 使用指南

Claude Code 工作流增强插件完整使用手册

概述

什么是 Superpowers

Superpowers 是 Claude Code 的官方工作流增强插件，包含一系列专业化的 Skills（技能），帮助你更系统、更高效地完成开发任务。

为什么需要 Superpowers

没有 Superpowers 的问题：

❌ 直接开始编码，需求理解不充分
❌ 测试失败后盲目修改，缺乏系统性排查
❌ 代码写完自认为"完成"，实际未验证
❌ 重构时没有计划，容易遗漏场景

使用 Superpowers 的优势：

✅ 强制性的需求探索（brainstorming）
✅ 测试驱动开发（TDD）
✅ 系统化的调试流程（systematic-debugging）
✅ 完成前强制验证（verification-before-completion）
✅ 规范的代码审查流程

安装方法

# 在 Claude Code 中执行
/plugin install superpowers@claude-plugins-official

# 重新加载插件
/reload-plugins

核心理念

Skill-First 工作流

黄金法则： 在执行任何操作前，先检查是否有相关的 skill 可用。即使只有 1% 的可能性相关，也应该调用检查。

用户请求 → 检查 Skills → 调用 Skill → 按流程执行 → 完成任务
             ↑
         这一步不能跳过！

何时必须使用 Skill

场景	对应 Skill	触发条件
开发新功能/组件	`brainstorming`	任何创建性工作前
实现功能/修复 bug	`test-driven-development`	写代码前
遇到 bug/测试失败	`systematic-debugging`	出现意外行为时
声称"完成"	`verification-before-completion`	提交/创建 PR 前
多步骤任务	`writing-plans`	需要修改 3+ 文件时

常见的"合理化"陷阱

当你产生以下想法时，立即停止，你正在合理化跳过 skill：

❌ 错误想法	✅ 正确做法
“这只是个简单问题”	简单任务更需要规范流程
“我需要先看看代码”	Skill 会告诉你怎么看
“先收集信息再说”	Skill 会指导你收集什么
“我记得这个 skill”	Skills 会更新，必须读最新版
“让我先试试这个方法”	无纪律的行动浪费时间

可用 Skills 分类

必用类（刚性流程）

这些 skills 提供严格的流程，必须完整遵循，不能裁剪或跳过步骤。

1. `brainstorming`

用途： 任何创建性工作前探索需求和设计
触发： 开发新功能、修改行为、添加组件
示例： “帮我开发一个用户登录功能”

2. `test-driven-development`

用途： 测试驱动开发流程
触发： 实现任何功能或修复 bug 前
流程： 写测试 → 测试失败 → 写代码 → 测试通过 → 重构

3. `systematic-debugging`

用途： 系统化诊断 bug
触发： 测试失败、意外行为、错误报告
流程： 重现 bug → 收集证据 → 提出假设 → 验证 → 修复

4. `verification-before-completion`

用途： 完成前强制验证
触发： 声称"完成"、提交代码、创建 PR 前
要求： 运行验证命令，确认输出，禁止"我觉得应该没问题"

规划类

用于拆解和执行复杂任务。

5. `writing-plans`

用途： 为多步骤任务编写实施计划
触发： 有明确需求规格，需要修改 3+ 文件
输出： 结构化的实施计划文档

6. `executing-plans`

用途： 在独立会话中执行计划
特点： 带检查点，可暂停审查

7. `subagent-driven-development`

用途： 在当前会话中并行执行计划中的独立任务
触发： 计划中有可并行的独立模块

协作类

代码审查相关流程。

8. `requesting-code-review`

用途： 完成任务后请求代码审查
触发： 完成功能实现、准备合并前

9. `receiving-code-review`

用途： 接收并处理代码审查反馈
触发： 收到审查意见，实施建议前
要求： 技术严谨性，验证反馈，不能盲目接受

10. `finishing-a-development-branch`

用途： 决定如何整合完成的工作
触发： 实现完成，测试通过，需要决定合并/PR/清理

工具类

提供特定场景的工具支持。

11. `dispatching-parallel-agents`

用途： 2+ 个无依赖的独立任务可并行时
示例： 同时查询多个服务状态、并行构建多个模块

12. `using-git-worktrees`

用途： 创建隔离的 git worktree
触发： 用户明确说"worktree"或需要执行计划时

13. `writing-skills`

用途： 创建、编辑、验证自定义 skills
触发： 开发新 skill 或修改现有 skill

典型工作流

工作流 1：开发新功能

用户请求：开发用户登录功能

Step 1: brainstorming
├── 探索需求：密码加密方式？JWT？session？
├── 设计方案：技术选型、架构设计
└── 输出：明确的实施方案

Step 2: writing-plans（如果复杂）
├── 拆解任务：路由 → 控制器 → 数据库 → 测试
├── 识别依赖：哪些可以并行？
└── 输出：step-by-step 计划

Step 3: test-driven-development
├── 为每个模块写测试
├── 运行测试（失败）
├── 编写实现代码
├── 运行测试（通过）
└── 重构

Step 4: verification-before-completion
├── 运行所有测试
├── 运行 linter
├── 验证功能完整性
└── 确认无遗留问题

Step 5: requesting-code-review
├── 总结变更
├── 列出测试覆盖
└── 请求审查

工作流 2：修复 Bug

用户报告：登录接口返回 500 错误

Step 1: systematic-debugging
├── 重现 bug：具体的重现步骤
├── 收集证据：日志、错误堆栈、请求数据
├── 提出假设：可能的原因列表
├── 验证假设：逐个排除
└── 定位根因

Step 2: test-driven-development
├── 编写能重现 bug 的测试
├── 运行测试（失败，证明 bug 存在）
├── 修复代码
├── 运行测试（通过）
└── 确认其他测试未破坏

Step 3: verification-before-completion
├── 运行完整测试套件
├── 验证修复有效
└── 确认无副作用

Step 4: requesting-code-review
└── 提交修复

工作流 3：重构代码

用户请求：重构用户模块，提取公共逻辑

Step 1: brainstorming
├── 分析当前问题：重复代码在哪？
├── 设计重构方案：提取哪些函数？
└── 评估风险：影响范围？

Step 2: writing-plans
├── 列出需要修改的文件
├── 确定重构步骤
└── 识别需要更新的测试

Step 3: test-driven-development
├── 先运行现有测试（基线）
├── 执行重构
├── 持续运行测试确保行为不变
└── 如有测试失败 → systematic-debugging

Step 4: verification-before-completion
├── 所有测试通过
├── 代码质量检查
└── 性能无劣化

Step 5: requesting-code-review
└── 审查重构质量

最佳实践

1. Skill 调用时机

❌ 错误：

用户："帮我开发一个登录功能"
Claude："好的，我先看看现有代码..." [直接开始读文件]

✅ 正确：

用户："帮我开发一个登录功能"
Claude：[调用 brainstorming skill]
Claude："使用 brainstorming skill 来探索需求..."

2. 多个 Skills 的优先级

当多个 skills 都适用时：

优先级顺序：

流程类优先（brainstorming, debugging） - 决定 HOW（如何做）
实施类其次（TDD, 具体实现） - 执行 WHAT（做什么）

示例：

用户："修复登录 bug"
正确顺序：systematic-debugging → test-driven-development → 实现修复

3. 与 CLAUDE.md 规则的关系

优先级：

用户明确指令（CLAUDE.md、直接要求）— 最高优先级
Superpowers Skills — 覆盖默认系统行为
默认系统提示 — 最低优先级

示例冲突处理：

如果 CLAUDE.md 说：

## 基本规则
编写代码前，请先描述你的方案并等待批准。

而 test-driven-development skill 说先写测试：

✅ 遵守 CLAUDE.md：先描述方案，获批准后再按 TDD 流程执行
❌ 不要盲目执行 skill 违反用户规则

4. 判断是否应该使用 Skill

决策树：

是否涉及任何行动？
├─ 否 → 可能不需要 skill（纯咨询性问题）
└─ 是 → 检查是否有匹配的 skill
         ├─ 有 → 必须使用
         └─ 不确定 → 调用检查（1% 原则）

实际示例：

用户请求	是否需要 Skill	使用哪个
“这个函数是做什么的？”	❌ 可能不需要	直接回答（如果简单）
“帮我优化这个函数”	✅ 需要	brainstorming → TDD
“测试失败了”	✅ 需要	systematic-debugging
“代码写完了，可以提交吗？”	✅ 需要	verification-before-completion

常见问题 FAQ

Q1: 每个任务都要用 Skills 吗？

A: 不是所有任务，但涉及行动的任务必须检查。

✅ 需要：开发、修复、重构、验证
❌ 不需要：简单咨询、解释概念、查看代码

Q2: Skill 太繁琐，能跳过某些步骤吗？

A: 刚性 skills（TDD、debugging）不能裁剪。

这些流程经过验证，跳过步骤会导致：

测试覆盖不足
Bug 未彻底修复
代码质量下降

Q3: 如果 Skill 不适合我的场景怎么办？

A: 调用后如果确实不适合，可以不使用。

Skill 加载后，你会看到完整内容，如果确实不匹配，说明判断即可。
但必须先调用检查，不能主观臆断。

Q4: 我的 CLAUDE.md 和 Skill 冲突怎么办？

A: CLAUDE.md 优先级最高。

示例：

CLAUDE.md：“超过3个文件先拆分”
Skill 建议直接实施
遵守 CLAUDE.md，先拆分任务

Q5: 为什么调用 Skill 后还要宣布？

A: 让用户知道你在使用哪个流程。

✅ 好的做法：
"使用 brainstorming skill 来探索登录功能的需求和设计..."

❌ 不好的做法：
[静默调用 skill，用户不知道发生了什么]

Q6: 如何知道有哪些 Skills 可用？

A: 系统会在会话中提示可用的 skills。

也可以查看本文档的"可用 Skills 分类"章节。

实战案例

案例：开发用户管理 REST API

背景

为一个 Node.js + Express 项目开发用户管理功能，包含：

用户注册（POST /api/users/register）
用户登录（POST /api/users/login）
获取用户信息（GET /api/users/:id）
更新用户信息（PUT /api/users/:id）

技术栈：

Node.js + Express
MongoDB + Mongoose
JWT 认证
Jest 测试框架

完整工作流演示

用户： “帮我开发用户管理的 REST API”

Step 1: 使用 brainstorming skill

Claude: 使用 brainstorming skill 来探索需求...

[调用 Skill tool: brainstorming]

探索问题：
1. 密码存储方式？
   - 使用 bcrypt 加密
   - Salt rounds: 10

2. 认证方式？
   - JWT token
   - 过期时间：24小时

3. 数据验证？
   - 邮箱格式验证
   - 密码强度：至少8位，包含数字和字母

4. 错误处理？
   - 统一错误响应格式
   - HTTP 状态码规范

设计方案：
- 路由层：routes/users.js
- 控制器层：controllers/userController.js
- 模型层：models/User.js
- 中间件：middleware/auth.js（JWT 验证）
- 工具函数：utils/validation.js

是否确认这个设计？

用户： “确认，开始实施”

Step 2: 使用 writing-plans skill

Claude: 使用 writing-plans skill 来制定实施计划...

[调用 Skill tool: writing-plans]

实施计划：

Task 1: 创建用户模型
- 文件：models/User.js
- 内容：Schema 定义、密码加密方法、token 生成方法

Task 2: 创建认证中间件
- 文件：middleware/auth.js
- 内容：JWT 验证逻辑

Task 3: 创建验证工具
- 文件：utils/validation.js
- 内容：邮箱、密码验证函数

Task 4: 实现用户控制器
- 文件：controllers/userController.js
- 内容：register, login, getUser, updateUser 方法

Task 5: 配置路由
- 文件：routes/users.js
- 内容：绑定路由到控制器

Task 6: 编写测试
- 文件：tests/users.test.js
- 内容：每个 API 的测试用例

依赖关系：
- Task 1, 2, 3 可以并行
- Task 4 依赖 Task 1, 2, 3
- Task 5 依赖 Task 4
- Task 6 贯穿始终（TDD）

开始执行？

用户： “开始”

Step 3: 使用 test-driven-development skill

Claude: 使用 test-driven-development skill 实施 Task 1...

[调用 Skill tool: test-driven-development]

3.1 编写测试（tests/models/User.test.js）：

const User = require('../../models/User');

describe('User Model', () => {
  test('should hash password before saving', async () => {
    const user = new User({
      email: 'test@example.com',
      password: 'password123'
    });
    await user.save();
    expect(user.password).not.toBe('password123');
  });

  test('should generate valid JWT token', () => {
    const user = new User({
      _id: '123',
      email: 'test@example.com'
    });
    const token = user.generateAuthToken();
    expect(token).toBeDefined();
  });
});

3.2 运行测试（预期失败）：

npm test tests/models/User.test.js

FAIL  tests/models/User.test.js
  ✕ should hash password before saving (5ms)
  ✕ should generate valid JWT token (2ms)

Tests: 2 failed, 2 total

3.3 实现代码（models/User.js）：

const mongoose = require('mongoose');
const bcrypt = require('bcrypt');
const jwt = require('jsonwebtoken');

const userSchema = new mongoose.Schema({
  email: {
    type: String,
    required: true,
    unique: true,
    lowercase: true
  },
  password: {
    type: String,
    required: true
  }
}, { timestamps: true });

// 保存前加密密码
userSchema.pre('save', async function(next) {
  if (!this.isModified('password')) return next();
  this.password = await bcrypt.hash(this.password, 10);
  next();
});

// 生成 JWT token
userSchema.methods.generateAuthToken = function() {
  return jwt.sign(
    { _id: this._id, email: this.email },
    process.env.JWT_SECRET,
    { expiresIn: '24h' }
  );
};

module.exports = mongoose.model('User', userSchema);

3.4 运行测试（通过）：

npm test tests/models/User.test.js

PASS  tests/models/User.test.js
  ✓ should hash password before saving (245ms)
  ✓ should generate valid JWT token (12ms)

Tests: 2 passed, 2 total

Step 4: 继续实施其他 Tasks

Claude: Task 2 - 创建认证中间件

[继续使用 TDD 流程]

先写测试 → 运行（失败）→ 写代码 → 运行（通过）

Task 3 - 创建验证工具
[同上]

Task 4 - 实现用户控制器
[同上，这里会写 API 集成测试]

Step 5: 遇到测试失败，使用 systematic-debugging skill

Claude: 运行测试时发现 login API 返回 500 错误

[调用 Skill tool: systematic-debugging]

5.1 重现 bug：

npm test -- tests/users.test.js -t "should login with valid credentials"

FAIL  tests/users.test.js
  ✕ should login with valid credentials (156ms)

  Expected: 200
  Received: 500

5.2 收集证据：
- 错误日志：TypeError: Cannot read property 'compare' of undefined
- 请求数据：{ email: 'test@example.com', password: 'password123' }
- 数据库状态：用户已存在

5.3 提出假设：
Hypothesis 1: 密码比较方法未定义
Hypothesis 2: 用户查询返回 null
Hypothesis 3: bcrypt 未正确引入

5.4 验证假设：
[检查 userController.js]

// 发现问题：忘记在 User schema 中定义 comparePassword 方法
const user = await User.findOne({ email });
const isMatch = await user.comparePassword(password); // ← comparePassword 未定义

5.5 修复：
在 models/User.js 中添加：

userSchema.methods.comparePassword = async function(candidatePassword) {
  return await bcrypt.compare(candidatePassword, this.password);
};

5.6 验证修复：

npm test -- tests/users.test.js -t "should login with valid credentials"

PASS  tests/users.test.js
  ✓ should login with valid credentials (187ms)

Step 6: 所有功能完成，使用 verification-before-completion skill

Claude: 使用 verification-before-completion skill 进行最终验证...

[调用 Skill tool: verification-before-completion]

验证清单：

✅ 运行完整测试套件：

npm test

PASS  tests/models/User.test.js
PASS  tests/middleware/auth.test.js
PASS  tests/controllers/userController.test.js
PASS  tests/routes/users.test.js

Tests: 24 passed, 24 total
Coverage: 95.6%

✅ 运行 Linter：

npm run lint

✔ No linting errors found

✅ 手动验证关键路径：

# 启动服务器
npm start

# 测试注册
curl -X POST http://localhost:3000/api/users/register \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"password123"}'
# Response: 201 Created, { token: "eyJhbGc..." }

# 测试登录
curl -X POST http://localhost:3000/api/users/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"password123"}'
# Response: 200 OK, { token: "eyJhbGc..." }

# 测试获取用户信息
curl http://localhost:3000/api/users/123 \
  -H "Authorization: Bearer eyJhbGc..."
# Response: 200 OK, { _id: "123", email: "test@example.com" }

✅ 检查错误处理：
- ✓ 邮箱格式错误：返回 400
- ✓ 密码过短：返回 400
- ✓ 用户已存在：返回 409
- ✓ 凭据错误：返回 401
- ✓ Token 过期：返回 401

✅ 确认文档更新：
- ✓ API 文档已添加到 docs/api.md
- ✓ README.md 中添加使用说明

所有验证通过，可以提交！

Step 7: 使用 requesting-code-review skill

Claude: 使用 requesting-code-review skill 请求审查...

[调用 Skill tool: requesting-code-review]

代码审查请求：

变更摘要：
- 新增用户管理 REST API（注册、登录、获取、更新）
- 实现 JWT 认证中间件
- 完整的单元和集成测试

文件变更：
- 新增：models/User.js（用户模型）
- 新增：controllers/userController.js（控制器）
- 新增：routes/users.js（路由）
- 新增：middleware/auth.js（认证中间件）
- 新增：utils/validation.js（验证工具）
- 新增：tests/（所有测试文件）
- 修改：app.js（注册路由）

测试覆盖：
- 单元测试：24 个
- 覆盖率：95.6%
- 所有测试通过

安全考虑：
- 密码使用 bcrypt 加密
- JWT secret 存储在环境变量
- 输入验证防止注入攻击

请审查以下方面：
1. API 设计是否合理
2. 错误处理是否充分
3. 安全性是否有遗漏
4. 测试覆盖是否足够

案例总结

使用的 Skills：

✅ brainstorming - 探索需求和设计
✅ writing-plans - 拆解任务
✅ test-driven-development - TDD 实施
✅ systematic-debugging - 修复测试失败
✅ verification-before-completion - 完成前验证
✅ requesting-code-review - 请求审查

工作成果：

✅ 功能完整的用户管理 API
✅ 95.6% 测试覆盖率
✅ 所有测试通过
✅ 代码质量检查通过
✅ 安全性考虑周全
✅ 文档完整

时间对比：

无 Superpowers	有 Superpowers
直接开始编码 → 需求理解不足 → 返工	brainstorming → 需求明确 → 一次性完成
写完代码再补测试 → 覆盖率低	TDD → 测试先行 → 高覆盖率
盲目调试 → 浪费时间	systematic-debugging → 快速定位
自认为完成 → 遗留 bug	verification → 完整验证 → 质量保证

预计节省时间：40-50%

结语

Superpowers 不是增加工作量，而是让工作更系统化、更高效。

初期可能觉得流程繁琐，但长期收益巨大：

✅ 更少的返工
✅ 更高的代码质量
✅ 更快的问题定位
✅ 更强的团队协作

建议：

从小任务开始练习使用 skills
逐步养成 skill-first 的工作习惯
遇到问题先问"有没有对应的 skill？"
不要合理化跳过流程

记住黄金法则：即使只有 1% 的可能性相关，也要调用检查。

附录：快速参考表

任务类型	使用 Skill	关键点
开发新功能	brainstorming → writing-plans → TDD	需求先行
修复 bug	systematic-debugging → TDD	重现 bug，写测试
重构代码	brainstorming → writing-plans → TDD	保持测试通过
准备提交	verification-before-completion	验证所有测试
请求审查	requesting-code-review	总结变更
并行任务	dispatching-parallel-agents	确保独立性

龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

学生党福音：OpenClaw+nanobot搭建学习监督助手

本文介绍了如何在星图GPU平台上自动化部署🐈 nanobot：超轻量级OpenClaw镜像，构建智能学习监督助手。该方案利用轻量级模型实现网课进度跟踪、自动生成练习题和错题整理功能，特别适合学生群体通过QQ机器人实现移动端学习管理，显著提升学习效率。

龙虾开发者社区

OpenClaw+GLM-4.7-Flash语音交互：对接Whisper实现语音控制

本文介绍了如何在星图GPU平台上自动化部署【ollama】GLM-4.7-Flash镜像，构建语音交互系统。该系统结合Whisper语音识别与GLM-4.7-Flash的指令理解能力，实现智能家居控制等场景的语音操作，提升日常任务执行效率。

龙虾开发者社区

OpenClaw创意工坊：用nanobot镜像生成技术海报文案

本文介绍了如何在星图GPU平台上自动化部署🐈 nanobot：超轻量级OpenClaw镜像，快速生成技术海报文案。该镜像基于Qwen3-4B模型，能将复杂技术术语转化为通俗表达，适用于技术活动宣传、社交媒体推广等场景，显著提升内容创作效率。

龙虾开发者社区

所有评论(0)

查看更多评论

深林小怪nan

@a2335vg

已为社区贡献2条内容

Superpowers 使用指南

深林小怪nan

Superpowers 使用指南

目录

概述

什么是 Superpowers

为什么需要 Superpowers

安装方法

核心理念

Skill-First 工作流

何时必须使用 Skill

常见的"合理化"陷阱

可用 Skills 分类

必用类（刚性流程）

1. brainstorming

2. test-driven-development

3. systematic-debugging

4. verification-before-completion

规划类

5. writing-plans

6. executing-plans

7. subagent-driven-development

协作类

8. requesting-code-review

9. receiving-code-review

10. finishing-a-development-branch

工具类

11. dispatching-parallel-agents

12. using-git-worktrees

13. writing-skills

典型工作流

工作流 1：开发新功能

工作流 2：修复 Bug

工作流 3：重构代码

最佳实践

1. Skill 调用时机

2. 多个 Skills 的优先级

3. 与 CLAUDE.md 规则的关系

4. 判断是否应该使用 Skill

常见问题 FAQ

Q1: 每个任务都要用 Skills 吗？

Q2: Skill 太繁琐，能跳过某些步骤吗？

Q3: 如果 Skill 不适合我的场景怎么办？

Q4: 我的 CLAUDE.md 和 Skill 冲突怎么办？

Q5: 为什么调用 Skill 后还要宣布？

Q6: 如何知道有哪些 Skills 可用？

实战案例

案例：开发用户管理 REST API

背景

完整工作流演示

案例总结

结语

附录：快速参考表

所有评论(0)

深林小怪nan

1. `brainstorming`

2. `test-driven-development`

3. `systematic-debugging`

4. `verification-before-completion`

5. `writing-plans`

6. `executing-plans`

7. `subagent-driven-development`

8. `requesting-code-review`

9. `receiving-code-review`

10. `finishing-a-development-branch`

11. `dispatching-parallel-agents`

12. `using-git-worktrees`

13. `writing-skills`