claude-superpowers

Claude Superpowers 技能

阻止 Claude 提交它写出的第一个版本。Superpowers 模式会将 Claude 锁定在四个阶段中——计划、隔离、测试优先、双重审查——确保它最终交付的内容确实正确。

默认情况下，Claude 会一上来就冲刺，一次写完所有内容，看起来很棒——直到有人运行它。它不会规划，不会测试，也不会验证。结果就是：代码在边缘情况下出错，调试轮次消耗大量 token，返工成本甚至高于一开始就把事情做好。

致谢： 灵感来自 Nate Herk 的 YouTube 频道上的一项技能——并针对此库进行了改编和扩展。

---

必需输入

无需输入。Superpowers 会在收到命令后激活，并应用于之后的任何编码任务。

---

四个阶段

阶段 1 — 计划

在编写任何代码之前，Claude 必须先提供书面计划，并等待用户确认。

计划格式：

PLAN
════

TASK
[One-sentence restatement of what was asked. If anything is ambiguous, flag it here before proceeding.]

APPROACH
[2–4 sentences describing the implementation approach and key decisions. If there are multiple valid approaches, briefly explain why this one was chosen.]

FILES TO CREATE OR MODIFY
- [path/to/file.ts] — [what changes: create / modify / delete — one line reason]
- [path/to/file.ts] — [what changes]

EDGE CASES I WILL HANDLE
- [Edge case 1]
- [Edge case 2]
- [Edge case 3]

EDGE CASES I AM NOT HANDLING (out of scope)
- [Out of scope case — reason]

ASSUMPTIONS
- [Any assumption made where the requirements were unclear]

Confirm this plan before I start coding.

在用户表示同意（或提出修改）之前，Claude 不得继续。如果用户修改计划，Claude 必须先修订并重新确认，然后才能开始。

---

阶段 2 — 隔离

Claude 会在隔离环境中工作，直到输出完成并经过审查。在获得明确批准之前，不得触及主项目。

隔离规则：

• 如果可以使用 git：在进行任何更改之前创建一个功能分支。分支名称格式：superpowers/[task-slug]
• 如果没有 git：说明更改是在工作副本中进行的，并在最后列出所有已修改的文件，供用户审查；审查通过后才能视为“已交付”
• 除非用户在会话期间明确扩大范围，否则不得修改计划中定义范围以外的文件
• 如果任务进行期间发现需要扩大范围（例如需要更改依赖项），应明确说明：“这还需要修改 [X]——要将其纳入范围吗？”

开始阶段 2 时，宣布：

ISOLATE
Working in isolation on branch: superpowers/[task-slug]
No changes will be considered final until Stage 4 review is complete.

---

阶段 3 — 测试优先

在编写实现之前，先编写测试（或至少将预期行为定义为可执行断言）。

测试优先方法：

1. 编写测试，定义任务的预期行为
2. 编写测试，覆盖计划中确定的每种边缘情况
3. 运行测试——测试应当失败（因为实现尚不存在）
4. 在编写实现之前，确认测试失败的原因正确
5. 编写实现
6. 运行测试——此时测试应当通过
7. 如果测试失败：修复实现，而不是测试

如果项目没有测试配置： 应说明这一点，并提供两个选项：

• 选项 A：继续之前先搭建最小化测试环境（推荐）
• 选项 B：将预期行为定义为手动验证步骤清单（更快，但效果较弱）

编写实现之前展示的测试摘要：

TESTS WRITTEN
─────────────
File: [test file path]
Tests:
  ✗ [test description — covers: happy path]
  ✗ [test description — covers: edge case 1]
  ✗ [test description — covers: edge case 2]
  ✗ [test description — covers: error state]

All tests failing as expected. Starting implementation.

---

阶段 4 — 双重审查

完成代码并运行测试后，Claude 必须先对自己的工作进行两轮审查，然后再提交结果。这两轮审查都不能流于形式。

审查 1 —“这符合要求吗？”

根据原始请求和已确认的计划检查完成的代码：

• 是否完成了所有要求？
• 是否处理了计划中的所有边缘情况？
• 计划内容与实际实现之间是否存在不一致？
• 是否加入了未经确认的假设？

审查 2 —“代码质量好吗？”

独立于需求检查技术质量：

• 明显的错误或逻辑问题
• 缺少错误处理（尤其是边界处：API 调用、文件 I/O、用户输入）
• 安全问题（注入漏洞、机密泄露、缺少身份验证检查）
• 可读性：其他开发者 6 个月后能否看懂这段代码？
• 性能：关键路径上是否存在明显的低效之处？
• 新引入的死代码或未使用的导入

双重审查输出格式：

REVIEW 1 — CORRECTNESS
───────────────────────
✅ Handles [requirement 1]
✅ Handles [requirement 2]
✅ Edge case [X] covered
⚠️  [Issue found — what it is and what was changed to fix it]

REVIEW 2 — CODE QUALITY
────────────────────────
✅ Error handling present at all API boundaries
✅ No obvious security issues
⚠️  [Issue found — what it was and how it was fixed]
✅ Readable — no unexplained complexity

VERDICT: [Ready to present / Fixed N issues before presenting]

如果任一轮审查发现问题，应修复问题并说明修复内容。提交修正后的版本，而不是原始草稿。

---

激活响应

当用户触发 Superpowers 模式时，回复：

Superpowers mode active.

I'll work in 4 stages for every coding task this session:
  1. PLAN    — Write a plan and wait for your confirmation before coding
  2. ISOLATE — Work on a branch; nothing ships until you approve
  3. TEST    — Write tests before the implementation
  4. REVIEW  — Review my own work twice before presenting it

What are we building?

---

输出结构

完整任务流程（全部四个阶段）

PLAN
════
[Plan format as above]
Confirm this plan before I start coding.

---
[User confirms]
---

ISOLATE
Working in isolation on branch: superpowers/[task-slug]

TESTS WRITTEN
─────────────
[Test summary — all failing]
Starting implementation.

---
[Implementation runs]
---

REVIEW 1 — CORRECTNESS
───────────────────────
[Checklist]

REVIEW 2 — CODE QUALITY
────────────────────────
[Checklist]

VERDICT: Ready to present.

---

COMPLETE
════════
[Summary of what was built, files created/modified, how to run/test it]
Branch: superpowers/[task-slug] — merge when ready.

---

CLAUDE.md 安装文本

为本次会话激活 Superpowers 后，向用户提供要添加到其 CLAUDE.md 中的确切文本，以使其永久生效：

```
## Superpowers Framework

This framework is always active for coding tasks in this project.

### Stage 1 — Plan
Before writing any code: produce a written plan including task restatement, approach, files to create/modify, edge cases to handle, and assumptions. Wait for explicit user confirmation before proceeding.

### Stage 2 — Isolate
Work on a feature branch (superpowers/[task-slug]) or clearly flagged working copy. Nothing is considered shipped until the user approves after Stage 4.

### Stage 3 — Test First
Write tests before writing the implementation. Tests should fail before implementation, pass after. If no test setup exists, offer to create one or produce a manual verification checklist.

### Stage 4 — Double Review
After completing code, run two reviews before presenting:
- Review 1: Does this match what was asked for? Check against original request and plan.
- Review 2: Is this good code? Check for bugs, missing error handling, security issues, readability.
Fix any issues found. Present the corrected version. Show the review checklist.
```

告诉用户：“将此内容添加到你的 CLAUDE.md，Superpowers 就会在此项目中永久生效。”

---

质量检查

• 阶段 1 的计划已展示，并且在编写任何代码之前已获得用户明确确认
• 计划包含：任务重述、方法、要修改的文件、范围内的边缘情况、范围外的边缘情况、假设
• 原始请求中的歧义已在计划中标明，而非默默假设
• 阶段 2 隔离：已创建功能分支（如果没有 git，则已标明使用的是工作副本）
• 阶段 3 的测试是在实现之前编写的，而非之后
• 已运行测试，并确认其在实现开始前未通过
• 阶段 4 的评审 1 对照原始请求进行检查，而不仅仅是对照计划
• 阶段 4 的评审 2 检查了错误、错误处理、安全性、可读性这四项
• 两次评审中发现的问题都已在提交前修复，而非标记为“以后再修复”
• 最终输出说明了实现内容、修改的文件，以及如何运行／测试
• 激活后已提供 CLAUDE.md 安装文本

---

反模式

• 未获得用户对计划的明确确认，不要进入阶段 2——未经确认就开始编写代码，会让规划阶段失去意义
• 不要在实现后再编写测试并称之为“测试优先”——必须先编写测试并确认其未通过，然后才能开始实现
• 时间紧张时不要跳过双重评审——恰恰是在速度优先时，评审最有价值，因为此时最容易出错
• 阶段 2 中不要擅自扩大范围——悄然扩大范围会产生用户未批准、也可能不想要的代码
• 不要在没有实际执行评审的情况下将两次评审都标记为无问题——敷衍了事的评审会造成虚假的信心，也会让整个框架失去意义

示例触发短语

• “启用 superpowers 模式”
• “激活 superpowers”
• “为本次会话开启 superpowers”
• “使用 superpowers 框架”
• “确保先规划再编码”
• “我希望你在展示成果前先评审自己的工作”
• “这次先编写测试”
• “先慢下来，把计划做好再开始构建”
• “在分支上工作，并在动手前给我看计划”