superpowers技能使用备忘

● Superpowers 技能套件介绍

  obra/superpowers 是一套由高安装量的开发工作流技能，共 6
  个，覆盖了从需求到交付的完整开发闭环：

  ---
  1. 🧠 brainstorming (282K 安装)

  创意 → 设计文档

  在任何编码之前，通过协作式对话将想法转化为完整的设计方案：

  - 探索项目上下文 → 逐一提问澄清意图/约束/成功标准 → 提出 2-3 种方案及权衡 →
  呈现设计方案 → 写入 docs/superpowers/specs/ → 用户审核
  - 硬性规则：未呈现设计并获得批准之前，禁止写任何代码

  ---
  2. 🐛 systematic-debugging (189.8K 安装)

  系统化调试

  遵循四阶段调试法，先找根因，再修 bug：

  - Phase 1: 根因调查（收集日志、复现、二分定位）
  - Phase 2: 理解为什么修复有效
  - Phase 3: 实现修复
  - Phase 4: 预防回归
  - 铁律：未完成 Phase 1 之前，禁止提出修复方案

  ---
  3. 📋 writing-plans (187.6K 安装)

  设计文档 → 实施计划

  将 spec 转化为 bite-size 的可执行任务列表：

  - 每个任务 2-5 分钟可完成
  - 明确文件结构、接口边界、测试策略
  - 遵循 DRY / YAGNI / TDD / 频繁提交
  - 计划写入 docs/superpowers/plans/
  - 假定执行者是有能力的开发者但对当前项目没有上下文

  ---
  4. 📖 using-superpowers (186.1K 安装)

  技能调度中枢

  确保在对话开始时先检查并调用合适的技能：

  - 在任何操作之前（包括提问、探索代码库）必须检查是否有技能适用
  - 流程类技能优先于实现类技能
  - 防止「这个太简单了不需要技能」的合理化借口

  ---
  5. 👀 requesting-code-review (170.1K 安装)

  请求代码审查

  在每个任务完成后、合并前派发 code review 子 agent：

  - 通过 git diff 范围派发 reviewer
  - 按 Critical / Important / Minor 分级处理反馈
  - 原则：早审查、常审查

  ---
  6. 🟢 test-driven-development (168.6K 安装)

  测试驱动开发

  严格的红-绿-重构循环：

  - 铁律：没有先看到失败的测试，不写任何生产代码
  - 先写测试 → 看它失败 → 写最小实现 → 重构
  - 修 bug 也必须先写复现测试

  ---
  🔗 工作流串联

  brainstorming → writing-plans → TDD (写测试→实现) → code-review
                       ↑                                  ↓
                       └── systematic-debugging ←── (发现 bug)

  所有技能通过 using-superpowers 统一调度，确保不会跳过关键步骤。

❯ 这些技能会自动被调用吗，还是我需要主动描述调用                                

● 这些技能的触发机制分为两层：

  自动提醒（描述匹配）

  每个技能的 description
  会出现在系统提示中，当我匹配到对应场景时就会被引导调用。比如你现在能看到：

  - brainstorming — 提示我：做任何创造性工作之前必须用
  - systematic-debugging — 遇到 bug/测试失败时，提修复方案之前用
  - using-superpowers — 每次对话开始时建立技能调度规则
  - test-driven-development — 写实现代码之前用

  也就是说，当你描述一个任务时，我会自动识别场景并调用相应技能，不需要你手动写
  /brainstorming 之类的。

  手动调用（更精确）

  你也可以直接用 slash command 显式指定，这样更精确：

  /brainstorming         # 开始头脑风暴
  /systematic-debugging  # 系统化调试
  /writing-plans         # 写实施计划
  /using-superpowers     # 技能调度
  /requesting-code-review # 代码审查
  /test-driven-development # TDD 流程

  实际情况

  坦白说，这套机制依赖于我在看到系统提醒时主动 Skill 调用。using-superpowers
  的设计初衷是「在任何操作之前先检查技能」，但实际上它本身也需要被调用才能生效。
  最佳实践是：

  1. 复杂的创造性任务 — 你可以说"帮我做一个 X 功能"，我会自动触发 brainstorming
  2. 调试 — 你说"有个 bug"，我会触发 systematic-debugging
  3. 简单的单行修改 — 不会触发，避免过度流程化