Superpowers 可以引导 Claude Code 用户在自己管理的 Git 仓库中完成较大的更改：确定设计、批准任务计划、通过测试实施、审查每项任务并检查最终分支。本指南依据2026年10月20日核查的 Superpowers 7.0.0 官方手册。BIG CHANGE 阅读了文档，但未安装插件，也未用它实际运行项目。

关键变化

  • 发生了什么变化：经过批准的设计和实施计划，让编码代理在修改仓库前获得明确任务和约束。
  • 为什么重要：文档中的任务流程将实际观察到的测试失败与通过，结合一名审查者分别给出的规格符合性和质量结论，随后再审查整个分支。
  • 需要关注：负责人仍须检查完整 diff 和最新验收结果，并决定分支的处理方式。代理流程完成后，仍可能保留已披露的问题。

开始之前

在自己拥有或有权编辑的仓库中，选择一项已获授权的多步骤代码更改。它应能拆成可审查的任务，并具备可测试的行为。写下所需行为、涉及区域、排除事项、原始验收命令和起始 commit。开始前运行该命令及相关现有检查。如果基线已经失败，先明确该故障；后续红色或绿色结果都需要已知的起点。

你需要 Git、已认证的 Claude Code 安装、安装插件及创建分支或 worktree 的权限，以及足够支持 Claude Code 和子代理的套餐或 API 额度。核查组织对源代码访问和插件使用的规定。启用前审查插件内容、实际权限、供应商数据条款和支出控制。Anthropic 提醒，插件 hook 和服务器进程可能以用户权限在工具调用沙箱外运行；一般工具授权提示并不覆盖所有此类代码。机密、依赖、外部写入、推送和发布都必须处于实际授权范围内。Claude Code 插件安全文档解释了这项边界。

下文使用 Superpowers 的 subagent-driven-development 技能处理包含多项任务的更改。手册也介绍内联的 executing-plans 路径，并允许小型工作使用更简化的设计约定。实施前与负责人选定路径，不要认定所有项目都必须走完整流程。

1. 安装插件并核查活动版本

在交互式 Claude Code 会话中，输入官方市场命令：

Text
/plugin install superpowers@claude-plugins-official

Claude Code 会在安装前打开插件详情面板。检查内容并选择获准的作用域。本地作用域仅为你在该仓库中启用；项目作用域会影响协作者的仓库设置。阅读安装摘要和 Errors 选项卡。遵循会话中的激活指示或重启，然后检查 Installed 选项卡，并在终端运行 claude plugin list。记录显示的 Version、Scope 和 Status，确认活动会话中可用 Superpowers 技能。市场命令不会固定本指南研究使用的 commit。如果实际版本或技能内容与7.0.0不同，先按该安装版本核对流程，再继续。安装失败或被禁用就应停止，不能视为流程已加载。Claude Code 安装指南说明了这些检查。

2. 批准设计，再批准计划

向 Claude Code 提供真实更改、验收标准、基线结果和禁止修改的内容。使用 Superpowers 的 brainstorming 流程明确意图、设计选择和约束。针对这项多步骤更改，检查书面设计及构建者检查结果，解决应由负责人决定的问题，并批准完整说明。批准应明确要实现的行为；不能因为代理继续对话就认为已获批准。设计手册允许较小工作采用简化约定或明确选择跳过，因此这里为较大任务有意选择完整路径。

接着请 writing-plans 流程将设计拆成任务。审查计划中的文件边界、接口、全局约束、测试命令和 Review Focus。每项任务应足够小以便检查，其测试应衡量已约定行为。代码更改开始前，批准计划和子代理执行方式。规划手册规定了交接。合理的计划不等于获准添加依赖或修改无关文件。

执行时，using-git-worktrees会查找合适的现有工作区，或在取得必要同意后准备隔离工作区。记录实际分支、基准 commit 和干净基线。可用时采用 Claude Code 的原生 worktree 支持。工作区若有其他更改，先明确归属再继续。worktree 手册描述了检查与创建流程。

3. 观察每次测试和任务审查

计划批准后，使用 subagent-driven-development 处理可独立审查的任务。当前手册为任务分配实施者，再将实施内容及 diff 交给一名任务审查者。该审查者给出两项判断：任务是否符合规格，以及实施质量是否可接受。这是一次审查中的两个结论，不是依次运行两个审查代理。相同类型的小任务可按手册规则合并处理。任务流程与审查者提示词规定了这个顺序。

对适合先写测试的每项行为，要求可观察的红绿循环：添加行为测试、运行并看到预期失败；进行最小实施、再次运行并看到通过；随后在检查保持通过的情况下重构。导入错误或测试框架损坏不是预期的红色结果。保留每项任务的命令、输出及相关 commit 或 diff。测试驱动开发手册列出需要人类同意的例外；本指南假定任务适合常规的测试先行路径。

阅读审查者的两项结论和实际 diff。接受任务前，结合计划和仓库解决所有“无法从 diff 验证”的事项。检查修复及其限定范围的复审；新一次声称成功不等于新的测试结果。7.0.0流程限制修复循环次数，并可用书面裁定暂缓处理问题。保留这些问题供后续审查。任务标记完成并不必然意味着审查没有问题。

任务完成后，检查单独的完整分支审查。它可识别任务间的相互影响，并重新审查任务审查者无法从单个 diff 解决的暂缓问题。要求提供每个未结事项背后的证据和裁定。插件清理临时工作区前，保留设计、计划、测试输出、审查报告和完整 diff。如果预期技能未触发，核查活动插件状态、版本及文档中的诊断路径；不能仅凭已安装插件就认为流程得到执行。

4. 检查分支并决定处理方式

在最终代码上重新运行原始验收命令以及项目完整测试套件。检查最新输出、完整分支 diff 和所有未结问题。Superpowers 验证手册要求在声称完成前取得当前状态的证据。若测试套件失败，明确具体故障并修复，或保留分支供审查；套件失败时不会进入文档规定的分支结束菜单。

在命名分支上，finishing-a-development-branch提供本地合并、推送并创建 pull request，或原样保留分支的选项。分离的 HEAD 有 pull request 和保留选项。丢弃仅在负责人明确要求并键入确认后单独处理，不是常规第四选项。分支结束手册说明了这些选择。负责人决定前，向其展示检查结果、diff 和残留问题。合并、推送、删除或发布都需要对应操作的授权。

有用的输出是与原始需求关联、可供审查的分支：获批设计和计划、实际观察的测试结果、任务审查的两项结论、完整分支审查、完整 diff，以及最新验收结果。如果安装、访问、预算或某项检查使执行停止，保留已验证产物并说明最后完成阶段。文档描述的是流程，不能证明本指南尚未运行的更改更快、更便宜或缺陷更少。

来源与延伸阅读

若只需修复一项验收检查，参阅 BIG CHANGE 的仓库失败检查验证指南。本文流程从更早阶段开始，为多任务更改确定设计与计划。