Superpowers 教程：Claude Code 插件安装、技能触发与实战流程

Claude Superpowers 是什么？

Superpowers 是 Jesse Vincent 开发的一套工程技能库，并附有引导编程智能体使用这些技能的指令。 Claude Code 是 Anthropic 推出的、能在代码仓库中工作的编程助手；Superpowers 为它提供需求理解、变更规划、测试、调试、任务委派和分支收尾等工作流程。可以把它看成车间的操作手册：工具已经齐备，手册规定的是先做什么、后做什么，以及交付前要检查什么。Superpowers README

**核验于 2026 年 10 月 18 日：**源码中的插件清单标注版本为 7.0.0，仓库内有 15 个包含 SKILL.md 文件的顶层技能文件夹。这些信息对应本文查阅的源码；实际使用时，还要确认所选插件市场安装的是哪个修订版本。插件清单、技能目录

它在实际使用中的吸引力，是让一连串决策变得可见。修改功能前，Claude 可以先明确预期行为；宣布完成前，可以要求重新运行测试并拿出结果。这些指令提供了具体、可检查的依据，但并不能证明需求本身或测试本身就是正确的。

如何在 Claude 中安装 Superpowers？

在 Claude Code 内，选择项目 README 中的一种安装方式即可。 以下命令原样摘自 README 的 Claude Code 章节，属于交互式斜杠命令，不能直接粘贴到普通 shell 中运行。README 安装说明

通过官方插件市场安装 Claude Superpowers

/plugin install superpowers@claude-plugins-official

作者也提供了自己的插件市场。如果选择这条安装路径，先添加市场，再安装插件：

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

选择一个便于持续追踪的来源即可。安装同一个插件，没有必要把这两套流程都执行一遍。

安装完成后，新开一个 Claude Code 会话，让启动钩子运行起来。给它一个范围明确的功能需求，例如为现有任务列表增加筛选功能。此时应观察：它是否说明正在使用哪项合适的技能，以及后续行为是否符合该技能的要求。安装命令执行成功，与工作流程按预期运行，是两回事。

安装后，会话会发生什么变化？

首先变化的是上下文：启动钩子会把 Superpowers 的使用指令放进对话。 配置中的 SessionStart 匹配范围包括 startup、clear 和 compact。脚本读取 using-superpowers，注入其中的文本，再指引 Claude 通过 Skill 工具加载其他技能。它不会在启动消息里塞入所有技能的完整内容。钩子配置、启动脚本

Claude Superpowers 如何选择技能？

Claude 会根据技能描述匹配任务，再读取相应指令。 插件的技能编写指南要求，描述应说明技能适用于什么场景。引导指令则要求智能体在回复或行动前先检查可用技能，说明将使用哪一项，并优先使用流程类技能，再使用实现类技能。技能发现指南

因此，开发新功能的请求通常对应 brainstorming，测试失败则对应 systematic-debugging，之后再由领域技能指导具体实现。也可以直接点名要用的技能，例如：“先用 superpowers:systematic-debugging 排查这次故障，再提出修复方案。”使用指令

自动选择依靠的是给模型的指令，并非确定性的关键词开关。 钩子提供引导文本，智能体仍需识别当前场景，并遵循所选技能的要求。如果选错流程，可以纠正任务范围，或直接要求使用相关技能。

Superpowers 有哪些技能，何时触发？

技能库覆盖整个开发周期，但每次会话只应加载适合当前工作的技能。 下表保留了所查阅文件中的技能原名。“适用场景”是对描述和指令的概括，并不保证说出某句话就一定触发某个技能。当前技能目录

不用背下整张清单。处理常规功能时，关注各阶段是否顺利衔接：理解需求，必要时形成具体计划，完成经过测试的实现，审查变更，再决定如何集成。处理缺陷时，则应从排查问题入手，而非展开新功能的设计讨论。

它如何与原生计划模式、个人技能配合？

Superpowers 为规划工作规定了一套流程；其中的 writing-plans 技能，与 Claude Code 原生计划模式是不同的机制。 当前引导指令明确要求：如果还没有进行需求构思与澄清，就应在进入计划模式前调用 brainstorming。它规定了操作顺序，并没有把原生模式与自己的计划编写技能当成可互换的功能。当前规划指令

writing-plans 会在代码仓库中生成文档，通常放在 docs/superpowers/plans/ 下，记录实现决策和检查事项。交接时，它会请用户审阅计划并选择执行方式，除非用户已经给出选择。仅切换模式，并不会自动提供这份文档或这些任务指令。关于 Claude Code 本身的控制方式与行为，可参阅单独的 Claude Code 计划模式指南。

个人技能仍然可以发挥作用。 插件的 writing-skills 文件将 ~/.claude/skills/ 标为 Claude Code 的个人技能目录；引导指令也明确规定，用户指令的优先级高于技能指令，包括 CLAUDE.md 和用户的直接要求。因此，可以让项目专属技能承载团队约定，由 Superpowers 提供开发流程。如果两者都规定了测试或审查方式，就要把分工说明白。技能编写文件、指令优先级

想了解底层的指令文件机制，可阅读智能体技能介绍。Superpowers 就是基于这套机制构建、具有明确方法取向的一组技能。

Superpowers 教程：一个功能从想法到合并的全过程

一个“隐藏已完成任务”开关，就足以展示完整流程。 以下是根据技能文件推演的示例，并非真实测试会话的记录。其中的文件名、验收用例和结果均为假设。

假设现有任务列表应用已经有测试。用户希望增加一个开关，隐藏已完成的任务，但不删除它们。在本例中，用户明确要求书面计划，并要求子智能体参与任务审查。若没有这些要求，这么小的改动原本可以考虑采用在聊天中完成需求确认的简化路径。

明确功能行为：brainstorming

关键问题是：“隐藏”只影响当前视图，还是会改变已存储的任务？本例约定仅做视图筛选：开关默认关闭，关闭后已完成的任务重新显示；筛选结果为空时，提示没有待完成任务。

Claude 复述范围并取得确认。由于用户选择了书面流程，设计会写入 docs/superpowers/specs/ 下的文档，交接前还要经过实现者检查。按这项技能通常的小改动路径，需求说明和确认可以直接留在聊天中。需求构思与澄清规则

这里要检查的产出，是双方对功能行为的约定。如果其中悄悄增加了保存用户偏好的要求，或者改变了任务存储方式，说明还没开始写代码，需求范围就已经扩大了。

让工作可以逐项核验：writing-plans

计划将功能拆成可分别检查的交付项。一项是在示例文件 src/tasks/filterTasks.ts 中实现筛选函数，并测试混合任务列表、空列表和全部已完成的列表。另一项是在 src/tasks/TaskList.tsx 中接入支持无障碍操作的开关，使用已约定的函数接口，并测试界面上可见的结果。

计划写明文件、接口、测试断言、项目测试命令和预期结果，同时明确筛选不能改动底层任务集合。用户审阅计划后，确认采用子智能体执行方式。到这一步，模糊指令才转化为足够具体的要求，让实现者与审查者能够准确指出分歧。计划编写指令

准备工作区：using-git-worktrees

开始执行时，Claude 先检查当前工作是否已经隔离。Git worktree 是同一仓库的另一个工作目录，通常对应独立分支。这项技能优先使用宿主工具原生的 worktree 机制，并遵循用户已有的偏好；如果没有既定偏好，则会在创建前询问。

本例中，用户同意为功能创建 worktree。Claude 在修改应用前，先在其中运行项目现有测试。如果基线测试就失败，必须先处理，才能判断之后的失败是否由新开关引起。工作区指令

实现任务：subagent-driven-development 与 test-driven-development

主控智能体先为筛选任务分派一个新的实现智能体，再安排该任务的审查；通过这一检查节点后，才继续处理 UI 任务。当前的子智能体技能会在任务审查中检查是否符合需求规格，以及代码质量是否达标，随后还要求对完成的整个分支做更全面的审查。进度和决策也会记入该计划专属的记录文件。子智能体工作流程

在具体实现中，test-driven-development 提供“红灯—绿灯—重构”循环。本例先通过测试展示问题：请求筛选后的视图时，结果仍然包含已完成任务。实现者确认测试确实失败后，才添加筛选逻辑，重新运行测试，再在保持测试通过的前提下整理代码。TDD 指令

对于 UI 交付项，有价值的断言应检查用户操作开关后看到了什么。只检查某个函数是否被调用，并不能证明界面行为符合预期。

另一条路径是 executing-plans：Claude 在当前会话中自行实现计划；如果能够使用子智能体，最后再由一个新的审查智能体检查整个分支。如果不需要逐项交接和审查的组织方式，可以选择这条路径。当前会话执行指令

处理审查发现：审查技能与 systematic-debugging

最终分支审查时，requesting-code-review 负责向审查者交接信息。假设审查者发现，关闭开关后，已完成的任务并未恢复显示。receiving-code-review 要求先结合代码和预期行为核实这一发现，再动手修改。发起审查、处理审查反馈

如果故障可以复现，就由 systematic-debugging 指导排查。它的阶段依次是根因调查、模式分析、假设验证和实现修复。在本例中，可以提出这样的假设：代码用筛选结果替换了原始集合。接着检查数据流，复现数据丢失，并配合回归测试修复根因，不能只强行把开关的视觉状态调正确。调试指令

验证完成，再决定如何合并

verification-before-completion 要求在宣称成功前提供最新的命令输出。对于这个功能，需要拿出筛选行为、开关交互及相关项目检查的验证依据，并明确说明尚未解决的失败项。验证指令

随后，finishing-a-development-branch 会验证完整测试集，并列出集成选项。在普通的命名分支上，当前文件提供的选择包括：本地合并、推送并创建拉取请求，或保留分支。它会等待用户决定；审查通过，并不意味着已经获得合并授权。

为了走完本例，用户选择在本地合并到已确认的基准分支。Claude 完成合并后测试合并结果，只有测试通过，才清理功能 worktree 和分支。如果选择创建拉取请求，工作则会进入仓库后续的合并流程。分支收尾指令

小任务什么时候该简化流程？

如果流程反复要求决定需求中已经确定的事项，它就成了额外负担。 用户已经给出准确替换文本，只需修改一个可见标签，这种任务不应和改变任务状态存储方式做同等程度的准备。这里评价的是流程增加了哪些工作，并非实测耗时结论。

当前 brainstorming 文件将任务分为三种规模：

• **简单明确的任务：**请求本身已包含必要说明，直接执行。
• **小改动：**在聊天中确认需求说明，再按常规流程实现。
• **项目：**先批准书面设计，再形成完整的软件实施计划。

同一文件也允许用户明确要求跳过提问，从而结束这一需求澄清环节。但跳过它，并不代表后续的测试或验证指令也自动取消。任务规模与跳过提问的规则

可以这样下指令：“这是一个小改动。需求说明留在聊天中，沿用现有测试配置，不要扩展功能。”如果只是已经定稿的文案修正，就明确给出替换文本和修改范围。这些是插件指令层级认可的任务约束，并非隐藏的绕过命令。

这里的局限是流程开销：额外的讨论、计划文档、任务分派和审查，可能与任务剩余的不确定性不成比例。源码记录了这些步骤，却无法告诉你某次具体修改要花多少分钟。如果会话反复忽略既定范围，仓库还提供了 diagnosing-superpowers，用于依据会话记录检查实际发生了什么。会话诊断技能

关于 Superpowers，哪些期待被夸大了？

规定了工作流程，不等于证明软件正确，也不等于证明速度更快。 一个失败的测试可能写错了需求，计划可能遗漏集成约束，负责审查的智能体也可能漏掉缺陷。应检查断言和代码差异，不能只看完成消息说得多有把握。

由子智能体驱动开发，也不意味着所有实现任务都同时进行。当前技能明确禁止在这套流程中并行使用负责实现的子智能体，以避免冲突。dispatching-parallel-agents 是另一项技能，面向的是彼此独立的问题。实现任务分派规则

安装插件，也不会免除你对任务范围或集成决策的责任。插件自己的收尾流程仍把是否合并的决定权交给用户。它最有力的承诺体现在流程上：告诉 Claude 应检查什么、出示什么证据。实际是否有用，取决于工作本身，也取决于智能体有没有遵循这些指令。

谁适合安装，接下来可以怎么试？

如果反复遇到的问题是智能体跳过工程决策，就值得安装。 对于独立开发者，如果智能体总是急着写代码、略过需求，可以先选一个范围明确、具有实际失败场景的功能。观察它是否在实现前明确行为，并在完成后提供证据。

对于已有成熟流程的开发团队，先协调团队在计划、测试和审查方面的约定与插件指令。如果现有技能已经规定了想要的流程，再增加一套通用工作流程可能只是重复。若大多数工作都是极小、规格完全明确的修改，仅为完成这些任务而引入整套方法，必要性就较低。

周一可以挑一个范围有限的改动，写下验收标准。使用 Superpowers，检查它选择的技能，审阅最终代码差异，再判断每一份额外产出是否帮助你做出了决定。留下这套流程，应当因为检查有用，而非因为它写出了一份长计划。

如果想了解解决其他问题的相关工具，可参阅 Claude Code 插件推荐。

Claude Superpowers 常见问题

想获得更多使用 AI 开发的实用建议，欢迎订阅邮件通讯。