Superpower 使用大纲

Superpower 使用大纲

• • 一、Superpower概览
  • • [1.1 概念](#1.1 概念)
    • [1.2 7步工作流](#1.2 7步工作流)
    • [1.3 14项技能](#1.3 14项技能)
    • [1.5 设计理念](#1.5 设计理念)
  • 二、安装方式
  • • [2.1 claude code安装](#2.1 claude code安装)
    • [2.2 Codex CLI 安装](#2.2 Codex CLI 安装)
    • [2.3 Cursor 编辑器安装](#2.3 Cursor 编辑器安装)
    • [2.4 Gemini CLI 安装](#2.4 Gemini CLI 安装)
  • [三 头脑风暴(brainstorming)](#三 头脑风暴(brainstorming))
  • • [3.1 原理](#3.1 原理)
    • [3.2 需求探索阶段](#3.2 需求探索阶段)
    • [3.3 问题澄清/提出方案](#3.3 问题澄清/提出方案)
    • [3.4 视觉伴侣(非必须)](#3.4 视觉伴侣(非必须))
    • [3.5 分布呈现设计](#3.5 分布呈现设计)
    • [3.6 编写设计文档](#3.6 编写设计文档)
    • [3.7 规范自查/用户审查](#3.7 规范自查/用户审查)
    • [3.8 交接](#3.8 交接)
  • [四、实施计划(writing plan)](#四、实施计划(writing plan))
  • • [4.1 原理](#4.1 原理)
    • [4.2 流程/输出物](#4.2 流程/输出物)
    • [4.3 禁止模式](#4.3 禁止模式)
    • [4.4 执行过程](#4.4 执行过程)
  • 五、子代理开发(SDD/TDD)
  • • [5.1 原理](#5.1 原理)
    • [5.2 工作流程](#5.2 工作流程)
    • [5.3 TDD执行](#5.3 TDD执行)
  • 六、代码审查(code-review)
  • • [6.1 原理](#6.1 原理)
    • [6.2 流程](#6.2 流程)
    • [6.3 审查报告](#6.3 审查报告)
    • [6.4 代码审查](#6.4 代码审查)
  • 七、分支收尾
  • • [7.1 工作流程](#7.1 工作流程)
    • [7.2 收尾的4种方式](#7.2 收尾的4种方式)
  • 八、多工作树(using-git-worktrees)
  • • [8.1 git 的worktree](#8.1 git 的worktree)
    • [8.2 工作流程](#8.2 工作流程)
    • [8.3 核心使用场景与操作说明](#8.3 核心使用场景与操作说明)
    • [8.4 关键特性与约束规则](#8.4 关键特性与约束规则)
    • [8.5 使用效果](#8.5 使用效果)
  • 九、系统化调试
  • • [9.1 工作流程](#9.1 工作流程)
    • [9.2 关键规则与约束](#9.2 关键规则与约束)
    • [9.3 与常规调试的核心区别](#9.3 与常规调试的核心区别)
  • 十、相关问题
  • • [10.1 **中断继续**](#10.1 中断继续)

一、Superpower概览

1.1 概念

Superpowers 是一套AI 编程方法论框架，用来解决 AI 写代码随机性强、不稳定的问题。

核心思想 ：流程优先 ，靠标准化流程约束 AI（7步标准流程，14个工作技能），释放 AI 开发能力，不盲目追求编写速度，从而保证编程更准确高效。

优点：大幅提升代码规范性、稳定性，适配国产大模型效果更好

缺点 ：极度消耗 Token，会扫描全项目历史内容，使用成本高；流程繁琐。

1.2 7步工作流

Superpowers的7步工作流是一套强制性的工程化流程，旨在约束AI编程工具（如Claude Code）遵循从需求澄清到分支收尾的完整闭环，避免"跳过设计直接编码"导致的常见问题。
#mermaid-svg-j24AYkRqdrmp5xxf{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-j24AYkRqdrmp5xxf .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-j24AYkRqdrmp5xxf .error-icon{fill:#552222;}#mermaid-svg-j24AYkRqdrmp5xxf .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-j24AYkRqdrmp5xxf .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-j24AYkRqdrmp5xxf .marker{fill:#333333;stroke:#333333;}#mermaid-svg-j24AYkRqdrmp5xxf .marker.cross{stroke:#333333;}#mermaid-svg-j24AYkRqdrmp5xxf svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-j24AYkRqdrmp5xxf p{margin:0;}#mermaid-svg-j24AYkRqdrmp5xxf .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-j24AYkRqdrmp5xxf .cluster-label text{fill:#333;}#mermaid-svg-j24AYkRqdrmp5xxf .cluster-label span{color:#333;}#mermaid-svg-j24AYkRqdrmp5xxf .cluster-label span p{background-color:transparent;}#mermaid-svg-j24AYkRqdrmp5xxf .label text,#mermaid-svg-j24AYkRqdrmp5xxf span{fill:#333;color:#333;}#mermaid-svg-j24AYkRqdrmp5xxf .node rect,#mermaid-svg-j24AYkRqdrmp5xxf .node circle,#mermaid-svg-j24AYkRqdrmp5xxf .node ellipse,#mermaid-svg-j24AYkRqdrmp5xxf .node polygon,#mermaid-svg-j24AYkRqdrmp5xxf .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-j24AYkRqdrmp5xxf .rough-node .label text,#mermaid-svg-j24AYkRqdrmp5xxf .node .label text,#mermaid-svg-j24AYkRqdrmp5xxf .image-shape .label,#mermaid-svg-j24AYkRqdrmp5xxf .icon-shape .label{text-anchor:middle;}#mermaid-svg-j24AYkRqdrmp5xxf .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-j24AYkRqdrmp5xxf .rough-node .label,#mermaid-svg-j24AYkRqdrmp5xxf .node .label,#mermaid-svg-j24AYkRqdrmp5xxf .image-shape .label,#mermaid-svg-j24AYkRqdrmp5xxf .icon-shape .label{text-align:center;}#mermaid-svg-j24AYkRqdrmp5xxf .node.clickable{cursor:pointer;}#mermaid-svg-j24AYkRqdrmp5xxf .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-j24AYkRqdrmp5xxf .arrowheadPath{fill:#333333;}#mermaid-svg-j24AYkRqdrmp5xxf .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-j24AYkRqdrmp5xxf .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-j24AYkRqdrmp5xxf .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-j24AYkRqdrmp5xxf .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-j24AYkRqdrmp5xxf .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-j24AYkRqdrmp5xxf .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-j24AYkRqdrmp5xxf .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-j24AYkRqdrmp5xxf .cluster text{fill:#333;}#mermaid-svg-j24AYkRqdrmp5xxf .cluster span{color:#333;}#mermaid-svg-j24AYkRqdrmp5xxf div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-j24AYkRqdrmp5xxf .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-j24AYkRqdrmp5xxf rect.text{fill:none;stroke-width:0;}#mermaid-svg-j24AYkRqdrmp5xxf .icon-shape,#mermaid-svg-j24AYkRqdrmp5xxf .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-j24AYkRqdrmp5xxf .icon-shape p,#mermaid-svg-j24AYkRqdrmp5xxf .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-j24AYkRqdrmp5xxf .icon-shape .label rect,#mermaid-svg-j24AYkRqdrmp5xxf .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-j24AYkRqdrmp5xxf .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-j24AYkRqdrmp5xxf .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-j24AYkRqdrmp5xxf :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 收尾验收
开发执行
前期准备
头脑风暴

Brainstorming
创建分支树

Using-git-worktrees
编写计划

Writing-plans
多代理开发

Subagent-driven-development
测试驱动开发

TDD

Test-Driven-Development
代码审查

Requesting-code-review
完成分支

finishing-a-development-branch

阶段	技能模块	核心目标	关键产出/行为
头脑风暴	brainstorming	需求澄清与设计 禁止直接编码，先通过提问理解需求并探讨多种方案。	结构化设计文档
环境隔离	using-git-worktrees	创建独立工作区 利用git worktree创建隔离的开发环境 避免影响主分支	独立的Git工作树
编写计划	writing-plans	任务拆解 将设计拆分为多个2-5分钟 可完成的小任务。 每个任务必须包含精确的文件路径和验证步骤，严禁使用"TODO"占位符	可执行的实施计划
子代理开发	subagent-driven-development	并行执行与审查 为每个任务分派独立的子代理（避免上下文污染）， 任务完成后执行两阶段审查： 1. 规范符合性审查 2. 代码质量审查	子代理实现的代码
测试驱动开发	test-driven-development	强制TDD循环 遵循红-绿-重构 循环。 铁律：先写测试在写代码，如果先写了生产代码则删除。	通过测试的需求代码
代码审查	requesting-code-review	自动化审查 在任务间隙或完成后自动触发检查是否符合计划， 并按严重程度（Critical/Important/Minor）报告问题。	审查报告与修复
分支收尾	finishing-a-development-branch	验证与清理 最终验证测试结果 提供合并/PR/保留/丢弃分支的选项，并清理工作区.	可合并/交付的分支

1.3 14项技能

Superpowers框架中包含的14项核心技能。

这些技能并非简单罗列，而是根据其核心用途分为了测试、调试、协作和元技能 四大类

构成了一个完整的开发方法论。

分类	技能名称	核心作用与阶段
测试	test-driven-development	核心开发 ：强制执行红-绿-重构的TDD循环，确保代码质量与可测试性。
调试	systematic-debugging	问题定位：遵循4阶段根因分析流程，系统化排查问题。
	verification-before-completion	修复验证：在声明问题解决前，强制要求验证修复的有效性。
协作	brainstorming	需求澄清：在编码前通过苏格拉底式提问，细化需求并产出设计文档。
	writing-plans	任务拆解：将设计转化为包含精确文件路径与验证步骤的、可执行的微小任务。
	executing-plans	计划执行：按批次执行计划，并在关键节点设置人工检查点。
	dispatching-parallel-agents	并发加速：为可以并行的任务分派多个子代理，提高效率。
	subagent-driven-development	代理开发：为每个任务启动独立子代理，并强制执行两阶段审查（规范符合性、代码质量）。
	requesting-code-review	发起审查：在任务间隙自动发起代码审查，并按严重程度报告问题。
	receiving-code-review	响应反馈：指导代理如何正确理解和处理收到的代码审查意见。
	using-git-worktrees	环境隔离 ：利用git worktree创建独立的工作分支，避免干扰主分支。
	finishing-a-development-branch	分支收尾：在任务完成后，提供合并、提交PR、保留或丢弃分支等选项，并完成清理。
元技能	writing-skills	技能扩展：遵循最佳实践（含测试方法）来为框架创建新的技能。
	using-superpowers	入门引导：作为系统的介绍，解释技能系统的核心概念与使用方法。

1.5 设计理念

哲学原则	核心理念	实践体现（简化）	反对什么
测试优先 (Test-First)	先写测试，后写实现	强制TDD：红-绿-重构，先写代码则删除重来	事后补测、无测试提交
系统化优于临时判断 (Systematic over ad-hoc)	遵循固定流程，不靠直觉	7步工作流强制执行，编码前必须先设计和计划	跳过设计直接编码
降低复杂性 (Complexity reduction)	简单性是首要目标	遵循YAGNI，任务拆解为2-5分钟的小步骤	过度设计、过早优化
证据高于声称 (Evidence over claims)	用可验证的结果说话	强制验证修复有效性，按严重等级报告问题	"应该修好了"
过程纪律 (Process discipline)	流程是铁律，不是建议	每个技能有强制触发条件和产出，无TODO占位符	选择性遵守流程
子代理即隔离 (Subagent isolation)	每个任务用独立代理执行	每任务新子代理，两阶段审查（规范→质量）	长会话上下文偏差
可组合与可扩展 (Composable & Extensible)	技能是独立、可组合的单元	技能分四大类，可通过writing-skills自定义扩展	单体式方法论

二、安装方式

2.1 claude code安装

需要claude code 版本在

方式一：通过官方插件市场

/plugin install superpowers@claude-plugins-official

方式二：项目专属市场

1. 先注册市场源

/plugin marketplace add obra/superpowers-marketplace

2. 再通过superpowers-marketplace安装插件

/plugin install superpowers@superpowers-marketplace

---

配置作用域并重新加载插件

# superpowers 安装可选作用域 项目级(project) > 用户级(user) > 系统级(system)
# 刷新插件
/reload-plugins

# 如果无法使用 /brainstorming 重启claude code

2.2 Codex CLI 安装

#1.打开插件搜索面板
/plugins

#2.搜索插件名
superpowers

#3.点击 `Install Plugin` 完成安装

2.3 Cursor 编辑器安装

在 AI 对话窗口直接执行

/add-plugin superpowers

也可在插件市场搜索 superpowers 可视化安装

2.4 Gemini CLI 安装

安装

gemini extensions install https://github.com/obra/superpowers

后续更新

gemini extensions update superpowers

---

这里我们使用7步工作流来实操完成一个需求开发，有关我的个人记账软件-新增二级分类功能

---

三 头脑风暴(brainstorming)

3.1 原理

核心思想 ：设计先于代码

为什么必须先"头脑风暴"

• 杜绝"即兴编码"：强制禁止AI在获得设计批准前编写任何代码，无论任务看起来多么简单。
• 明确真实需求：通过一系列提问，挖掘出你未言明的约束、偏好和成功标准。
• 探索多种可能：强制要求AI提出2-3种不同的解决方案并分析其权衡，避免一开始就走偏。
• 产出唯一"真理"：最终交付一份双方认可的设计文档（Spec），作为后续所有工作的唯一依据。

执行命令

# 开启头脑风暴
/brainstorming
/superpowers:brainstorming                          

标准流程

通常包含以下9个步骤，AI会像项目经理一样引导你完成整个流程

阶段	流程说明	用户任务
上下文探索	主动检查项目的现有文件、文档和最近的提交记录。	无需操作，AI会自行分析。
提议视觉伴侣	如果你的需求涉及UI/UX，AI会询问是否开启一个浏览器窗口 来辅助展示原型或图表。	按需选择是否开启。
澄清性问题	一次只问一个问题，来理解你的核心目的、约束条件和成功标准。	逐一、清晰地回答AI的问题。
提出方案	基于你的回答，提出2-3种 可行的设计方案， 并说明每种方案的优缺点和它的推荐意见。	审阅方案，选择你倾向的方向或提出修改意见。
分步呈现设计	将选定的方案拆解成多个部分，逐段 向你展示详细设计， 并在每段后寻求你的批准。	仔细审阅每一部分，批准或要求修改， 确保细节无误。
编写设计文档	将所有确认过的内容，整理成一份Markdown文件，保存在 docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md。	无需操作，文档会自动生成。
规范自查	对刚写好的文档进行自我审查，检查是否有"TODO"占位符、 内部矛盾或范围过大的问题。	无需操作，这是AI的内部质检环节。
用户最终审查	将完整的文档呈现给你，请求你进行最终的、整体性 的审阅和批准。	这是你最重要的"把关"时刻 。仔细通读全文， 确认设计完全符合你的预期。
交接	获得你的最终批准后，自动调用 writing-plans 技能 ，进入计划制定阶段。	确认无误后，给出批准指令，流程将继续。

3.2 需求探索阶段

检查现有项目，并提问做什么的问题

引导提出问题 我的需求描述如下：

我想新增一个新功能，目前在添加记账详情页面的支出列中只有一个一级分类，我想为每一个一级分类添加一个二级分类，用户记账的时候必选一级分类，可选二级分类

3.3 问题澄清/提出方案

一次问一个问题，来理解你的核心目的、约束条件和成功标准。

问题澄清的过程中会进行

提出方案 基于你的回答，提出2-3种可行的设计方案并说明每种方案的优缺点和它的推荐意见。

3.4 视觉伴侣(非必须)

需求涉及UI/UX，AI会询问是否开启一个浏览器窗口来辅助展示原型或图表。

superpowers生成三种原型图供我们选择

3.5 分布呈现设计

将选定的方案拆解成多个部分，逐段 向你展示详细设计

3.6 编写设计文档

将所有确认过的内容，整理成一份Markdown文件

3.7 规范自查/用户审查

对刚写好的文档进行自我审查

1. 占位符/模糊描述：TBD、TODO、待定、需要进一步讨论
2. 功能逻辑是否正确
3. 范围检查：明确单一功能，而非一次写多个不相干功能
4. 是否有其一

用户审查 ：规范自查完毕后，将完整的文档呈现给你，请求你进行最终的、整体性的审阅和批准。

3.8 交接

转向下一步 获得你的最终批准后，自动调用 writing-plans 技能，进入计划制定阶段。

brainstorming` 完成 → 设计文档保存在 `docs/superpowers/specs/YYYY-MM-DD-<主题>-design.md

四、实施计划(writing plan)

4.1 原理

核心定位：实施计划(writing plan) 是Superpowers 体系核心技能，用来撰写可落地的项目执行方案。

在头脑风暴中已经生成了xxx-design.md 里面已经写明了要做什么了，为啥还需要计划文档

核心区别在于：设计文档（design.md）回答"做什么"，计划文档（plan.md）回答"怎么做"。

方式一：头脑风暴后自动触发
方式二：手动执行命令

# 手动触发实施计划
/writing-plans 
/superpowers:writing-plans    

4.2 流程/输出物

五大流程

作用	说明
1. 设计 → 任务翻译	将设计文档xxx-feature-design.md中的需求描述，转化为可直接执行的、粒度极细的任务清单
2. 强制原子化拆解	每个任务被拆解为 2-5 分钟可完成的步骤（写测试→运行→写代码→运行→提交）
3. 消除模糊性	禁止任何 TODO、TBD 或模糊指令（如"添加适当的错误处理"），所有步骤必须包含精确的代码和命令
4. 子代理执行蓝图	计划文档是 subagent-driven-development 执行的唯一依据，子代理按任务清单逐项完成
5. 验收基准	计划文档成为后续代码审查的判断标准，审查时会逐条检查是否按计划实现

输出产物

计划文档保存在：

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

每个任务包含：

• 精确的文件路径（创建/修改/测试）
• 可执行的测试代码
• 可执行的验证命令（如 pytest xxx）
• 可执行的 Git 提交命令
• 每一步的预期结果

4.3 禁止模式

禁止出现的模式

禁止内容	示例
TODO/TBD	TODO: 后续补充
模糊指令	添加适当的错误处理
引用之前任务	类似 Task 2 的做法
空测试	为上述功能编写测试（没有具体代码）
描述性步骤无代码	只写"做什么"不写"怎么做"

4.4 执行过程

如上图：实施计划(writing plans)完成，输出对应的plan文档，并提示自动流转到subagent-driven-development

五、子代理开发(SDD/TDD)

5.1 原理

核心定位：计划文档是唯一真理

subagent-driven-development 是 Superpowers 中执行计划的核心技能 ，位于 writing-plans 之后、代码审查之前。

它的职责是：按照计划文档中的任务清单，逐个派发独立的子代理去实现，并在每个任务完成后执行两阶段审查。

同时对于每一个子代理走test-driven-development(TDD)：先写测试-再写业务代码。

多子代理

传统做法	SDD 做法
一个 AI 会话完成所有任务	每个任务启动一个全新的子代理
上下文累积 → 偏差累积 → 出错	每个子代理只有计划文档 + 当前任务，无历史污染
任务间依赖隐式传递	任务间依赖通过计划文档显式声明

二阶段提交

阶段	审查内容	谁执行
第一阶段：规范符合性	代码是否严格按照计划实现？是否有计划外的额外代码？	专门的审查子代理
第二阶段：代码质量	是否有明显 bug？是否遵循项目规范？测试是否通过？	专门的审查子代理

5.2 工作流程

#mermaid-svg-lM3a8wA7r7a60mx8{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-lM3a8wA7r7a60mx8 .error-icon{fill:#552222;}#mermaid-svg-lM3a8wA7r7a60mx8 .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-lM3a8wA7r7a60mx8 .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-lM3a8wA7r7a60mx8 .marker{fill:#333333;stroke:#333333;}#mermaid-svg-lM3a8wA7r7a60mx8 .marker.cross{stroke:#333333;}#mermaid-svg-lM3a8wA7r7a60mx8 svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-lM3a8wA7r7a60mx8 p{margin:0;}#mermaid-svg-lM3a8wA7r7a60mx8 .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 .cluster-label text{fill:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 .cluster-label span{color:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 .cluster-label span p{background-color:transparent;}#mermaid-svg-lM3a8wA7r7a60mx8 .label text,#mermaid-svg-lM3a8wA7r7a60mx8 span{fill:#333;color:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 .node rect,#mermaid-svg-lM3a8wA7r7a60mx8 .node circle,#mermaid-svg-lM3a8wA7r7a60mx8 .node ellipse,#mermaid-svg-lM3a8wA7r7a60mx8 .node polygon,#mermaid-svg-lM3a8wA7r7a60mx8 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-lM3a8wA7r7a60mx8 .rough-node .label text,#mermaid-svg-lM3a8wA7r7a60mx8 .node .label text,#mermaid-svg-lM3a8wA7r7a60mx8 .image-shape .label,#mermaid-svg-lM3a8wA7r7a60mx8 .icon-shape .label{text-anchor:middle;}#mermaid-svg-lM3a8wA7r7a60mx8 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-lM3a8wA7r7a60mx8 .rough-node .label,#mermaid-svg-lM3a8wA7r7a60mx8 .node .label,#mermaid-svg-lM3a8wA7r7a60mx8 .image-shape .label,#mermaid-svg-lM3a8wA7r7a60mx8 .icon-shape .label{text-align:center;}#mermaid-svg-lM3a8wA7r7a60mx8 .node.clickable{cursor:pointer;}#mermaid-svg-lM3a8wA7r7a60mx8 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-lM3a8wA7r7a60mx8 .arrowheadPath{fill:#333333;}#mermaid-svg-lM3a8wA7r7a60mx8 .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-lM3a8wA7r7a60mx8 .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-lM3a8wA7r7a60mx8 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-lM3a8wA7r7a60mx8 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-lM3a8wA7r7a60mx8 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-lM3a8wA7r7a60mx8 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-lM3a8wA7r7a60mx8 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-lM3a8wA7r7a60mx8 .cluster text{fill:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 .cluster span{color:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-lM3a8wA7r7a60mx8 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-lM3a8wA7r7a60mx8 rect.text{fill:none;stroke-width:0;}#mermaid-svg-lM3a8wA7r7a60mx8 .icon-shape,#mermaid-svg-lM3a8wA7r7a60mx8 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-lM3a8wA7r7a60mx8 .icon-shape p,#mermaid-svg-lM3a8wA7r7a60mx8 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-lM3a8wA7r7a60mx8 .icon-shape .label rect,#mermaid-svg-lM3a8wA7r7a60mx8 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-lM3a8wA7r7a60mx8 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-lM3a8wA7r7a60mx8 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-lM3a8wA7r7a60mx8 :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 不通过
通过
不通过
通过
是
否
读取计划文档
确定下一个未完成任务
为任务派发新子代理
子代理执行任务

写测试→运行→写代码→运行→提交
第一阶段审查

规范符合性
子代理修复问题
第二阶段审查

代码质量
标记任务完成

更新计划文档checkbox
还有未完成任务?
完成，交还控制权

阶段	执行流程	输入/输出
** 读取计划**	主代理 解析 plan.md，定位下一个未完成任务 ---	计划文档 → 当前任务详情
派发子代理	主代理 为当前任务创建全新子代理	计划片段 + 任务指令 → 就绪的子代理
子代理执行	子代理 TDD循环：写测试→运行(FAIL)→写代码→运行(PASS)→提交 不通过 → 重复本阶段	任务步骤 → 代码 + 测试 + 提交
规范审查	审查代理 检查是否严格按计划实现（路径、代码、无额外改动） 不通过 → 子代理修复	子代理输出 + 计划 → 通过/不通过
质量审查	审查代理 检查bug、测试有效性、项目规范 不通过 → 子代理修复	子代理输出 → 通过/不通过
标记完成	主代理 更新计划文档checkbox	审查通过信号 → 更新的 plan.md
循环/结束	主代理 继续下一任务或交还控制权	任务完成状态 → 最终结果

5.3 TDD执行

我的需求他会分成多个task列表，每一个task交由一个子代理去执行，每一个代理执行流程为TDD

所谓TDD=Test-Driven Development。先写测试代码 → 再写业务功能代码 → 最后重构优化

标准三步流程

1. 红 ：编写单元测试，此时还没写功能代码 → 测试直接失败（红色）
2. 绿 ：写最简单的业务代码，只满足测试通过即可 → 测试成功（绿色）
3. 重构 ：优化代码结构、精简逻辑，不改业务逻辑，保证测试依旧通过

每一个任务执行完成运行通过都会进行git提交，同时标记任务状态为完成。

六、代码审查(code-review)

6.1 原理

superpowers:requesting-code-review 是 Superpowers 工作流中的"质检员"。它通过在关键节点自动或手动触发，对你的代码进行系统化审查，其核心原则是"尽早审查，频繁审查"（Review early, review often）。

代码审查任务由一个独立的 superpowers:code-reviewer 子代理执行。这么做的好处是：

• 专注变更本身：只专注于你的代码变更和计划，不会被历史对话所干扰。
• 上下文纯净：子代理只看代码变更，避免了对话历史对审查结果的潜在"污染"。

6.2 流程

#mermaid-svg-KNqpWfZj6dFSFFJQ{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-KNqpWfZj6dFSFFJQ .error-icon{fill:#552222;}#mermaid-svg-KNqpWfZj6dFSFFJQ .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-KNqpWfZj6dFSFFJQ .marker{fill:#333333;stroke:#333333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .marker.cross{stroke:#333333;}#mermaid-svg-KNqpWfZj6dFSFFJQ svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-KNqpWfZj6dFSFFJQ p{margin:0;}#mermaid-svg-KNqpWfZj6dFSFFJQ .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .cluster-label text{fill:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .cluster-label span{color:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .cluster-label span p{background-color:transparent;}#mermaid-svg-KNqpWfZj6dFSFFJQ .label text,#mermaid-svg-KNqpWfZj6dFSFFJQ span{fill:#333;color:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .node rect,#mermaid-svg-KNqpWfZj6dFSFFJQ .node circle,#mermaid-svg-KNqpWfZj6dFSFFJQ .node ellipse,#mermaid-svg-KNqpWfZj6dFSFFJQ .node polygon,#mermaid-svg-KNqpWfZj6dFSFFJQ .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .rough-node .label text,#mermaid-svg-KNqpWfZj6dFSFFJQ .node .label text,#mermaid-svg-KNqpWfZj6dFSFFJQ .image-shape .label,#mermaid-svg-KNqpWfZj6dFSFFJQ .icon-shape .label{text-anchor:middle;}#mermaid-svg-KNqpWfZj6dFSFFJQ .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .rough-node .label,#mermaid-svg-KNqpWfZj6dFSFFJQ .node .label,#mermaid-svg-KNqpWfZj6dFSFFJQ .image-shape .label,#mermaid-svg-KNqpWfZj6dFSFFJQ .icon-shape .label{text-align:center;}#mermaid-svg-KNqpWfZj6dFSFFJQ .node.clickable{cursor:pointer;}#mermaid-svg-KNqpWfZj6dFSFFJQ .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .arrowheadPath{fill:#333333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-KNqpWfZj6dFSFFJQ .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-KNqpWfZj6dFSFFJQ .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-KNqpWfZj6dFSFFJQ .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-KNqpWfZj6dFSFFJQ .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .cluster text{fill:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ .cluster span{color:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-KNqpWfZj6dFSFFJQ .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-KNqpWfZj6dFSFFJQ rect.text{fill:none;stroke-width:0;}#mermaid-svg-KNqpWfZj6dFSFFJQ .icon-shape,#mermaid-svg-KNqpWfZj6dFSFFJQ .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-KNqpWfZj6dFSFFJQ .icon-shape p,#mermaid-svg-KNqpWfZj6dFSFFJQ .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-KNqpWfZj6dFSFFJQ .icon-shape .label rect,#mermaid-svg-KNqpWfZj6dFSFFJQ .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-KNqpWfZj6dFSFFJQ .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-KNqpWfZj6dFSFFJQ .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-KNqpWfZj6dFSFFJQ :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 否
是
Critical
Important
Minor
任务完成/需要审查
获取Git Commit SHAs
派发code-reviewer子代理

并提供审查上下文
子代理执行审查
发现问题?
查通过

继续工作流
生成分级反馈报告

Critical / Important / Minor
根据报告采取行动
问题严重性?
立即修复

阻塞所有进度
必须修复

才能继续
记录在案

后续处理

6.3 审查报告

审查报告的"三层分级

严重等级	含义	行动指引
Critical （严重/阻塞）	严重问题，如安全漏洞、核心功能缺失、与计划严重不符。	立即修复，必须解决才能继续，否则会阻塞合并-。
Important （重要/建议修复）	重要但非阻塞问题，如代码规范、错误处理不完整、逻辑可优化。	必须修复后，才建议继续下一步开发。
Minor （轻微/建议改进）	轻微或改进建议，如魔法数字、命名建议、潜在小优化。	记录并留待后续处理，不阻塞当前流程。

6.4 代码审查

七、分支收尾

finishing-a-development-branch ：superpowers的核心计划，是把"代码写完了"这个模糊阶段，变成一个自动化、可复制的标准化流程。

触发时机：自动触发

这个技能是由subagent-driven-development（子代理驱动开发）或executing-plans（执行计划）这两个工作流在执行完所有任务后，自动触发作为终点。

7.1 工作流程

finishing-a-development-branch 遵循一个严格的线性流程，每个步骤都是下一阶段的门禁，以确保最终结果可控。

步骤	核心原则	具体行动
验证测试	硬性门禁	- 运行当前项目的完整测试套件 ↓ 不通过则流程立即中止，且禁止强制继续
识别环境	环境适配	- 检测当前开发环境，以适配不同的清理或合并方式
确认基分支	避免错配	- 自动识别特性分支是从哪个基础分支创建的 ↓ 不明确时则主动询问你进行二次确认
呈现选项	结构化决策	- 根据检测到的环境，展示一个固定且清晰的选项菜单供你选择，避免开放性问题
执行与清理	按需有度	- 根据你选择的选项，执行对应的合并、推送或丢弃操作 仅当选项合理时才清理工作树（如"推送并创建PR"就不会清理）

7.2 收尾的4种方式

选项	核心操作	合并柱分枝	删除本地分支	清理工作树
提交未完成的修改 并保留在本地	提交当前所有变更，保留本地分支和工作树	❌ 否	❌ 否	❌ 否
Push 并创建 Pull Request	推送特性分支到远程，使用模板创建 PR， 保留本地环境以便后续修改	❌ 否（仅推送）	❌ 否	❌ 否
保持现状后续自行处理	不做任何操作，仅通知你分支和工作树的位置	❌ 否	❌ 否	❌ 否
丢弃本次工作	强制二次确认 （如输入 discard）后， 强制删除本地分支并清理工作树	❌ 否	✅ 是	✅ 是

八、多工作树(using-git-worktrees)

using-git-worktrees ：superpowers 提供的 Git 多工作树能力，借助 Git worktree 机制，实现同一仓库多目录并行开发，解决单工作区切换分支冲突、环境互相干扰的问题，是并行开发、多分支同时作业的标准化能力。

触发时机：手动调用 / 开发场景按需触发

该能力基于原生 git worktree 实现，常配合多分支并行开发、临时分支调试、版本并行维护等场景使用，可独立调用，也可在开发流程中按需拉起多工作树环境。

8.1 git 的worktree

概念

不同目录下同时chekout出同一个仓库的多个分支

相关命令

# 分支没有 -b 新建分支 同时创建工作树
git worktree add -b 新分支名 目录名(工作树)
# 查看所有工作树
git worktree list
#删除工作树
rm -rf 目录名
git worktree prune

操作示范

#所有工作树命令，都必须在主仓库根目录执行
cd 你的项目/
# 以 master分支(已存在分支) 创建工作树 main(master分支)
git worktree add master main
# 创建功能分支工作树（新分支） -b基于你「当前所在的分支」创建feature-user 并新建工作树
git worktree add -b feature-user feature-user
#创建紧急修复工作树（新分支）
git worktree add -b hotfix-login hotfix-login

目录结构

你的项目/         👈 主仓库（只有这里有 .git）
├── .git/
├── main/               工作树 1 → main 分支
├── feature-user/       工作树 2 → 功能分支
└── hotfix-login/       工作树 3 → 紧急修复分支

8.2 工作流程

using-git-worktrees 遵循规范的创建、使用、销毁流程，各环节有明确校验与约束，保障仓库与工作树状态稳定。

步骤	核心原则	具体行动
环境校验	前置检查	- 检测当前 Git 仓库状态、已存在工作树列表，校验仓库合法性，异常则终止操作
创建工作树	隔离独立	- 指定目标分支、本地目录，创建独立 Git 工作树，每个工作树绑定唯一分支
并行开发	互不干扰	- 不同工作树可独立编写代码、执行测试、提交代码，分支切换互不影响
状态查看	统一管控	- 支持查看全仓库所有工作树、对应分支、目录路径及运行状态
移除清理	闭环管理	- 分支任务完成后，按需删除指定工作树，同步清理对应目录与关联配置

8.3 核心使用场景与操作说明

应用场景	核心操作	分支隔离	目录独立	保留原工作区
并行开发多个功能分支	为不同特性分支分别创建独立工作树，多目录同时编码、调试	✅ 是	✅ 是	✅ 是
临时拉取分支排查问题	新建临时工作树绑定问题分支，排查、修复完成后直接移除工作树	✅ 是	✅ 是	✅ 是
多版本并行维护（新旧版本）	主线版本、历史版本分属不同工作树，独立迭代、发版、修复bug	✅ 是	✅ 是	✅ 是
临时切换分支不影响当前开发	不切换原有工作区分支，新建工作树处理紧急任务，做完即清理	✅ 是	✅ 是	✅ 是

8.4 关键特性与约束规则

1. 分支绑定约束 ：一个工作树同一时间仅绑定一个分支，禁止单个工作树跨分支混用。
2. 文件隔离：各工作树目录相互独立，代码、依赖、运行环境完全隔离，不会产生文件覆盖冲突。
3. 仓库同源：所有工作树共享同一个远端 Git 仓库，提交、拉取、推送逻辑和常规 Git 一致。
4. 清理规范：闲置、废弃的工作树建议及时移除，避免产生冗余目录与无效分支关联。
5. 权限与路径：创建时校验本地目录读写权限，目录已存在或被占用时会提示并终止创建。

8.5 使用效果

如下图所示 目录/.claude/worktrees/feature/test-workstree chekout了master分支

九、系统化调试

systematic-debugging ：superpowers 的标准化、自动化、可复现调试流程 ，把 "凭经验找 bug" 变成结构化、步骤化、门禁式的问题定位与修复体系，杜绝盲目调试，确保问题 100% 可追溯、可解决。

触发时机：自动触发 / 手动触发

/systematic-debugging url接口报错了，帮忙修复一下

• 代码运行报错、测试失败、流程中断时自动触发
• 开发 / 排查过程中可手动调用启动系统化调试

9.1 工作流程

systematic-debugging 遵循严格线性门禁流程，每一步必须通过才能进入下一阶段，确保调试不漏项、不跳步、不遗漏根因。

步骤	核心原则	具体行动
错误捕获	全量采集	- 自动捕获报错信息、日志、堆栈、退出码- 记录触发场景、命令、环境变量- 不丢弃任何异常上下文
问题定位	根因优先	- 解析错误堆栈，定位到具体文件 / 函数 / 行号- 区分：语法错误 → 逻辑错误 → 依赖错误 → 环境错误
验证复现	可复现门禁	- 自动尝试复现问题，不可复现则流程暂停- 记录最小复现步骤与复现条件
方案生成	结构化修复	- 给出 1~3 个最可能的修复方案- 标注风险点、影响范围、验证方式
修复执行	安全修改	- 按方案自动 / 辅助修改代码- 不破坏原有逻辑，最小范围改动
验证闭环	必须通过	- 重新运行测试 / 原命令- 问题消失才算修复完成- 未修复则自动回滚并重新进入调试

9.2 关键规则与约束

1. 不可复现，不修复：必须先稳定复现问题，禁止盲目猜测修改。
2. 最小改动原则：只修改与 bug 直接相关的代码，不做大范围重构。
3. 自动回滚保护 ：修复后验证不通过，自动撤销修改，避免代码污染。
4. 门禁不可跳过：定位→复现→修复→验证，所有步骤必须执行。
5. 问题可追溯：完整记录 bug 信息、修复方案、验证结果，形成调试档案。

9.3 与常规调试的核心区别

对比项	普通调试	systematic-debugging
方式	经验驱动、随意试错	流程驱动、标准化步骤
复现	依赖人工手动复现	自动复现 + 门禁校验
修复	局部修改、易漏根因	根因定位、最小改动
验证	人工粗略验证	自动强制验证闭环
风险	易引入新 bug	自动回滚，安全可控

---

十、相关问题

10.1 中断继续

在 Superpowers 工作流中，任何阶段都可以安全中断并恢复，因为所有关键产物都已持久化。以下是各阶段的中断与继续方法汇总。

📊 各阶段中断与继续速查表

中断阶段	已保存的内容	继续工作的指令	注意事项
头脑风暴中 (brainstorming)	部分设计文档 (可能未完成)	"请读取 docs/superpowers/specs/ 中未完成的设计文档，继续 brainstorming 流程"	可能需要重新确认已批准的部分
设计文档已完成	完整设计文档 (*-design.md)	"请读取设计文档，先确认是否已创建 worktree，然后继续进入 writing-plans"	需要确认文档已获最终批准
编写计划中 (writing-plans)	设计文档 + 部分计划文档	"请读取设计文档，继续使用 writing-plans 技能完成实施计划"	AI 通常会重新生成完整计划
计划已完成	设计文档 + 完整计划文档	"请读取设计文档和计划文档，确认 worktree 状态，然后进入 subagent-driven-development"	计划文档存放在 plans/ 目录
开发执行中 (TDD)	设计文档 + 计划文档 + 已完成任务的代码和提交	"请读取计划文档，检查当前 git 状态和已完成任务，继续执行剩余任务"	使用 git log 和任务清单的 checkbox 状态定位
代码审查中	同上 + 审查报告	"请继续完成剩余的代码审查任务"	可按严重程度（Critical/Important/Minor）优先处理
分支收尾中	所有上述内容	"请检查当前分支状态，继续完成分支收尾流程"	可能需要决定 merge/PR/keep/discard

🚀 推荐的恢复命令（通用模板）

无论中断在哪个阶段，都可以使用这个模板让 AI 自动恢复：

"我们之前在 阶段名称 中断了。请扫描 docs/superpowers/ 目录下的设计和计划文档，定位当前进度，然后从中断处继续执行 Superpowers 工作流。"

AI 会自动：

1. 扫描 specs/ 和 plans/ 目录
2. 识别最新的设计文档和计划文档
3. 检查 git worktree list 和当前分支状态
4. 定位中断位置
5. 从中断点继续