AI 编码代理必须强制检查并加载相关 Superpowers 技能，这是整个方法论生效的纪律基础。核心机制是：代理收到任何任务后，必须先判断是否有哪怕 1% 的概率适用任何技能，并调用对应的 Skill（或平台等效工具）加载内容，而非自行探索或直接回答。本文将拆解 using-superpowers/SKILL.md 中定义的强制规则、不同平台的工具适配方案以及具体的执行流程。
using-superpowers 工作机制：为什么代理必须先加载相关技能
在 Superpowers 工作流 中，using-superpowers 技能是启动纪律。它不指导具体编码，而是规定了代理如何发现和加载其他所有技能。缺少这一步，brainstorming、writing-plans、test-driven-development 等后续流程便无从触发，AI 很容易回到自由探索、即兴回应的低效状态。
核心规则：1% 可能性，100% 强制调用
using-superpowers/SKILL.md 通过一个醒目的 <EXTREMELY-IMPORTANT> 块确立了非谈判性规则：
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill. IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
这意味着代理必须将用户的任何输入都视为潜在任务，并在思考或行动前执行技能检查。该规则旨在根除代理的几种常见错误行为，文件中的 Red Flags 表对此有清晰对照：
| 代理常有的想法 | 事实 |
|---|---|
| “这只是一个简单问题” | 问题也是任务。需要检查技能。 |
| “我需要先获取更多上下文” | 技能检查优先于澄清提问。 |
| “让我先探索一下代码库” | 技能会告诉你如何探索。先检查。 |
| “这个技能我记得” | 技能会迭代。必须读取当前版本。 |
| “感觉这样有生产力” | 无纪律的行动浪费时间。技能防止这种情况。 |
强制检查的执行流程
当代理收到用户消息时，它必须遵循 SKILL.md 中描述的决策流：
- 判断是否有技能可能适用：代理评估用户请求，哪怕有微小的关联可能（1%），都必须进入下一步。
- 调用
Skill工具：在 Claude Code 中，这意味着使用Skill工具加载相关技能的SKILL.md文件。 - 宣布使用技能：代理应告知用户它正在使用哪个技能来处理任务。
- 执行技能内容：加载的技能可能包含检查清单。代理应为每个清单项创建待办事项（如使用
TodoWrite工具），然后严格按照技能指导行动。
如果代理明确判断没有技能适用，它才能直接回应用户。即便判断错误，调用了不相关的技能，过程也是可逆的——代理确认后无需使用该技能。整个流程确保了技能被主动发现和使用。
指令优先级与用户控制
Superpowers 的技能并非铁律。SKILL.md 明确了指令的优先级层次：
- 用户明确指令（如
CLAUDE.md、GEMINI.md中的设置或直接对话）— 最高优先级。 - Superpowers 技能 — 覆盖默认系统行为。
- 默认系统提示 — 最低优先级。
例如，如果用户的 GEMINI.md 配置禁用 TDD，即使 test-driven-development 技能要求必须遵循 TDD，代理也应服从用户指令。这确保了用户对工作流的最终控制权。
跨平台适配：不同的“钥匙”
using-superpowers 技能的核心是调用一个“技能工具”，但这个工具在不同平台有不同名称和机制。SKILL.md 提供了入口，并指向具体的映射文件。理解这些适配是让技能在非 Claude Code 平台上生效的关键。Gemini CLI 与 GitHub Copilot CLI 如何适配 SuperPowers 技能工具名 文章对此有更深入的探讨。
Claude Code：原生 Skill 工具
在 Claude Code 中，代理直接使用其内置的 Skill 工具来加载技能内容。这是最直接的路径。
其他平台的工具映射
对于非 Claude Code 的平台，代理需要遵循映射表，使用各自的等效工具：
- Codex：根据
codex-tools.md，Codex 原生支持技能加载。代理只需遵循加载后的指令。但对于子代理派发，需要将Task工具替换为spawn_agent。 - Copilot CLI：根据
copilot-tools.md，使用skill工具。技能从已安装的插件中自动发现。 - Gemini CLI：根据
gemini-tools.md，使用activate_skill工具。工具映射会通过GEMINI.md文件自动加载。 - OpenCode：通过插件
.opencode/plugins/superpowers.js实现。该插件会在会话开始时，将using-superpowers的核心内容和 OpenCode 专用的工具映射（如Task-> OpenCode 子代理系统，TodoWrite->todowrite）直接注入到第一条用户消息中，并确保技能路径被加入配置。
Gemini CLI 的特殊入口
Gemini CLI 通过 GEMINI.md 文件中的 @import 指令来加载 using-superpowers 技能及其工具映射参考，实现了技能的自动引入。相关映射详情可参考 gemini-tools.md。
OpenCode 的引导注入
OpenCode 版 SuperPowers 插件源码解析中详细说明了，插件通过 config hook 自动将技能目录加入配置，并通过消息变换 hook 将 using-superpowers 内容注入第一条用户消息，而非系统消息，以避免 token 膨胀和兼容性问题。它同时注入了针对 OpenCode 的工具替换说明。
验证“先加载技能”是否生效
作为开发者或用户，你可以通过以下迹象验证代理是否遵守了 using-superpowers 规则：
- 明确声明：代理的回复中会包含类似“正在使用 brainstorming 技能来…”的语句。
- 流程合规：代理不会直接开始编码或给出方案，而是先进行需求澄清（头脑风暴）或询问更多细节。
- 工具调用记录：在支持日志的平台（如 Claude Code）中，你应能看到
Skill工具被调用的记录。 - 错误处理：当代理试图跳过技能检查时（例如，直接开始写代码而未询问设计），这通常意味着规则未被正确加载或执行。检查插件或技能文件的安装路径。
技能类型与执行严格度
using-superpowers 还定义了技能的两种类型，代理需据此调整行为：
- 严格型技能（如
test-driven-development、systematic-debugging）：必须完全遵循，不得偏离纪律。 - 灵活型技能（如某些设计模式）：可将原则适应于具体上下文。
技能本身会说明其类型。
using-superpowers 通过一套明确的、可验证的强制检查流程，确保了 Superpowers 技能库不再是可选参考，而是代理行为的基本约束。它是连接用户意图与标准化开发流程的第一座桥梁，也是整个工作流闭环得以运转的起点。
FAQ
Q: 为什么代理不能“先回答简单问题，再检查技能”？
A: 因为“简单问题”可能涉及上下文、代码结构或后续任务，这些恰恰是技能（如 brainstorming、systematic-debugging）所管理的领域。先回答可能误导代理进入错误路径，消耗更多 token 并降低质量。
Q: 在不支持子代理的平台（如 Gemini CLI）上，涉及 subagent-driven-development 的流程会如何？
A: 技能会识别平台能力并自动降级。根据 gemini-tools.md，Gemini CLI 不支持传统的子代理派发，因此相关技能会回退到使用其原生工具（如 @generalist）和提示词模板来模拟子代理工作流，或引导用户采用单会话执行模式。
Q: OpenCode 插件为什么将引导内容注入用户消息而非系统消息？
A: 根据插件源码 .opencode/plugins/superpowers.js 的注释，这是为了避免系统消息带来的 token 重复膨胀，并防止多条系统消息破坏某些模型（如 Qwen）的处理逻辑，确保引导内容稳定生效。