## 安装（Cursor）

在 Agent 聊天里执行：

```text
/add-plugin superpowers
```

或在插件市场搜索 `superpowers` 安装。装好后技能会进入 Agent 的 skills 列表，一般无需再配置。

---

## 怎么用：核心原则

**多数时候不用记命令。** 你正常说话即可，例如：

- 「帮我做一个登录页」
- 「这个接口 500 了，帮我查」
- 「按这个 plan 开始实现」

Agent 会先匹配相关 skill，读 `SKILL.md`，再按流程执行。你也可以显式点名：

```text
用 brainstorming 帮我设计一下配额限流
请用 systematic-debugging 排查这个报错
用 writing-plans 把刚才的设计写成实现计划
按 plan 用 subagent-driven-development 开始做
```

优先级：**你的明确指示 > Skills > Agent 默认行为**。想跳过某流程，直接说即可，例如：「跳过设计，直接改这段代码」。

---

## 标准功能开发（完整闭环）

这是 Superpowers 最完整的用法：

```text
你：我想加一个「用户 Token 配额」功能
        ↓
① brainstorming（澄清 + 设计）
        ↓
你：设计 OK，继续
        ↓
② using-git-worktrees（隔离分支/工作区，可选）
③ writing-plans（写成可执行小任务）
        ↓
你：开始实现 / go
        ↓
④ subagent-driven-development（推荐）
   或 executing-plans（无子代理时）
        ↓
⑤ 过程中自动穿插 TDD、code review
        ↓
⑥ finishing-a-development-branch（合并 / PR / 保留 / 丢弃）
```

### ① Brainstorming（设计阶段）

Agent 会：

1. 先看项目上下文  
2. **一次只问一个问题**（目的、约束、成功标准）  
3. 给出 2–3 种方案和取舍  
4. 分段展示设计，每段等你确认  
5. 写入 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`  
6. 让你审规格，再转入写计划  

**你怎么配合：**

- 回答问题，尽量具体（验收标准、边界、不要什么）  
- 设计不满意就说「方案 B」或「某某点改一下」  
- 确认后再让它写计划，不要急着说「直接写代码」  

示例：

```text
我想给 agent 加 token 配额门控，和现有 agent_token_quota_gate 对齐。
先用 brainstorming，不要直接改代码。
```

### ② Writing Plans（计划阶段）

设计通过后，Agent 会写到类似：

`docs/superpowers/plans/YYYY-MM-DD-<feature>.md`

特点：任务拆得很细（约 2–5 分钟一步），含文件路径、测试步骤、提交点；按「先写失败测试 → 实现 → 通过 → commit」组织。

**你怎么配合：** 扫一眼任务边界和文件是否合理；有问题先改 plan，再开干。

### ③ 执行计划（实现阶段）

| 方式 | 适用 | 特点 |
|------|------|------|
| `subagent-driven-development` | 同会话、有子代理 | 每任务新子代理 + 两阶段审查，中间较少打断你 |
| `executing-plans` | 新开会话、或无子代理 | 本会话按任务推进，卡点会停下来问你 |

示例：

```text
计划在 docs/superpowers/plans/2026-07-22-token-quota.md
请用 subagent-driven-development 开始执行，不要每步都问我要不要继续。
```

### ④ 收尾

任务做完会走 `finishing-a-development-branch`：跑测试 → 给你选 merge / PR / 保留分支 / 丢弃。

---

## 修 Bug 怎么用

不要一上来就「帮我改一下」。更符合流程的说法：

```text
登录后偶尔 401，复现步骤是……
请用 systematic-debugging，先找根因再改。
```

四阶段（改代码前必须先做调查）：

1. **根因调查**：读报错、稳定复现、看近期改动  
2. **提出假设**：基于证据，不是猜  
3. **最小修复**：只修根因  
4. **验证**：确认修好，并防回归  

宣称「修好了」前还会用 `verification-before-completion`：要有命令/测试证据，不能口头说完事。

---

## 各 Skill 速查（什么时候用）

| Skill | 你什么时候会碰到 | 你可以怎么说 |
|-------|------------------|--------------|
| `brainstorming` | 新功能、改行为 | 「先设计，不要写代码」 |
| `writing-plans` | 设计已确认 | 「写成实现计划」 |
| `executing-plans` | 有 plan、按步骤做 | 「按这个 plan 执行」 |
| `subagent-driven-development` | 有 plan + 要高质量自动推进 | 「用子代理按任务做」 |
| `test-driven-development` | 实现过程中 | 「严格 TDD」 |
| `systematic-debugging` | bug / 失败 / 异常 | 「先系统排查」 |
| `verification-before-completion` | 声称完成前 | 「先验证再宣布完成」 |
| `using-git-worktrees` | 要隔离分支 | 「在 worktree 里做」 |
| `requesting-code-review` | 阶段性审查 | 「按 plan 做 code review」 |
| `receiving-code-review` | 处理评审意见 | 「按评审意见改，先评估再动手」 |
| `finishing-a-development-branch` | 功能做完 | 「收尾，给我合并选项」 |
| `dispatching-parallel-agents` | 多块独立工作可并行 | 「并行查 A 和 B」 |
| `writing-skills` | 自己写新 skill | 「帮我写一个 skill」 |

---

## 日常对话里你会看到什么

正常时 Agent 会类似这样说：

> Using brainstorming to refine the design before implementation.

这表示它已进入对应流程。设计阶段它会**多问、少写代码**；实现阶段会**少问「要不要继续」**（尤其是 subagent 模式），卡死或缺信息才会停。

文档默认落在：

- 规格：`docs/superpowers/specs/`  
- 计划：`docs/superpowers/plans/`  

仓库里已有约定目录的话，以你的偏好为准。

---

## 实战提示（让效果更好）

1. **大需求先设计**：一句话功能也建议走 brainstorming，避免做错方向。  
2. **小改动可显式跳过**：`「只改 agent_token_quota_gate.rs 里这一个判断，跳过 brainstorming」`。  
3. **修 bug 给复现**：步骤、期望、实际、日志/截图越全，调试 skill 越准。  
4. **有 plan 再长时间挂机**：计划越细，子代理越不容易跑偏。  
5. **Cursor 里子代理可用时优先 SDD**：质量通常高于单会话硬扛整份 plan。  
6. **中途纠偏直接说**：`「停，任务 3 方向了，先改 plan」`。

---

## 三种最短使用模板

**新功能**

```text
做 X。先 brainstorming 出设计给我确认，再写 plan，我同意后再实现。
```

**修问题**

```text
现象：… 复现：… 请 systematic-debugging，找到根因后再修，修完要跑验证。
```

**已有计划**

```text
执行 docs/superpowers/plans/xxx.md，用 subagent-driven-development，连续做完。
```

---

一句话：**安装后正常下任务即可；想控节奏就用「先设计 / 先排查 / 按 plan 执行 / 跳过某某」这类指令。** 如果你愿意，我可以按你当前仓库（比如 token 配额门控）演示一轮「该怎么对 Agent 说话」的完整对话示例。