超级能力 — OpenClaw 版本

改编自 obra/superpowers。此为强制性工作流程，而非建议性指引。

开发流水线

构思 → 头脑风暴 → 设计 → 子代理驱动开发（TDD）→ 代码审查 → 完成分支

所有编码任务均须遵循该流水线。“太简单，无需设计” 的想法永远是错误的。

第一阶段：头脑风暴

触发条件：用户希望构建某项功能。必须在动任何代码前启动此阶段。

参见：references/brainstorming.md

概要：

1. 梳理项目上下文（文件、文档、近期提交记录）
2. 提出澄清性问题——每次仅提一个问题，优先采用多选形式
3. 提出 2–3 种可行方案，附带各自权衡分析及推荐结论
4. 分章节呈现设计方案，每章完成后均需获得用户确认
5. 撰写设计文档 → 存为 docs/plans/YYYY-MM-DD--design.md → 提交至版本库
6. 移交至 第二阶段：编写实施计划

硬性关卡（HARD GATE）：在用户批准设计方案前，严禁编写任何代码。

第二阶段：编写实施计划

触发条件：设计方案已获批准。由头脑风暴阶段自动触发。

参见：references/writing-plans.md

概要：

• 逐项编写详尽的实施计划，每项任务独立可执行
• 每项任务耗时控制在 2–5 分钟：编写测试 → 观察失败 → 实现逻辑 → 观察通过 → 提交变更
• 计划文档保存至 docs/plans/YYYY-MM-DD-.md
• 明确声明："我正在使用 writing-plans 技能创建实施计划。"
• 保存后，提供两种执行模式供选择：
  • 子代理驱动（当前会话）：对每项任务调用 sessions_spawn 启动子代理，并执行两阶段审查
  • 手动执行：由用户自行运行各项任务

第三阶段：子代理驱动开发

触发条件：实施计划已存在，且用户选择子代理驱动执行模式。

参见：references/subagent-development.md

每项任务的循环流程（OpenClaw）：

1. 调用 sessions_spawn 启动一名实现者子代理，传入当前任务及完整计划上下文
2. 等待子代理完成并宣布结果
3. 调用 sessions_spawn 启动一名规格审查员子代理 → 必须确认所写代码严格符合规格说明
4. 调用 sessions_spawn 启动一名代码质量审查员子代理 → 必须认可代码质量达标
5. 修复发现的问题，必要时重新发起审查
6. 标记当前任务为完成，进入下一项任务
7. 最终：调度整体代码审查员子代理 → 移交至第五阶段

每项任务中，TDD 为强制要求。详见 references/tdd.md。

第四阶段：系统化调试

触发条件：出现 Bug、测试失败或未预期行为——任何技术问题。

参见：references/systematic-debugging.md

硬性关卡（HARD GATE）：未经根本原因调查，不得进行任何修复。

四个阶段：

1. 根本原因调查：阅读错误信息、复现问题、检查近期变更、追踪数据流向
2. 模式分析：查找正常工作的示例，进行对比，识别差异点
3. 假设与验证：每次仅提出一个假设，并通过测试予以证实或证伪
4. 修复与验证：从根源修复问题，而非掩盖表象；验证修复未引入新问题

第五阶段：完成分支

触发条件：所有任务已完成，全部测试通过。

参见：references/finishing-branch.md

概要：

1. 确认所有测试均已通过
2. 确定目标基线分支（base branch）
3. 向用户提供 4 种选项：本地合并 / 推送并创建 PR / 保留当前分支 / 放弃分支
4. 执行用户选定的操作
5. 清理临时文件、未跟踪内容等无关产物

OpenClaw 子代理调度模式

调度实现者或审查者子代理时，统一使用 sessions_spawn，并按如下结构组织提示：

目标：[一句话描述]
上下文：[此事为何重要，关联哪个计划文件]
涉及文件：[精确路径列表]
约束条件：[明确禁止事项——禁止范围蔓延，仅允许 TDD 方式]
验证方式：[如何确认成功——例如：测试全部通过，或执行特定命令]
任务正文：[粘贴计划中对应任务的完整原文]

将上述内容作为详细提示，运行 sessions_spawn。子代理将自动宣布执行结果。

核心原则

• 头脑风暴期间一次只提一个问题
• TDD 始终强制执行 —— 先写失败的测试，删除任何在测试之前编写的代码
• YAGNI（You Aren’t Gonna Need It） —— 从所有设计方案中移除非必要功能
• DRY（Don’t Repeat Yourself） —— 禁止任何形式的重复
• 系统化优于临时应对 —— 尤其在时间压力下，也必须严格遵循既定流程
• 以证据为准，而非主观断言 —— 在宣称成功前，必须完成验证
• 高频提交 —— 每次测试通过后立即提交