Superpowers技能使用优化：仅保留三个关键技能

背景

在 AI 辅助编程的工作流中，Superpowers 是一套为 Coding Agents 设计的「技能」集合，旨在让模型在特定场景下调用预设的 playbook（如系统性调试、代码审查等）。用户在使用过程中发现，这些技能存在默认启用后容易串联执行的问题，导致任务流程膨胀、不必要地消耗上下文和推理资源。为此，用户向 Sol（可能指某 AI 助手或社区成员）寻求优化建议，并最终调整了技能的启用策略，形成了一套更精简、按需激活的规则。

核心内容

用户最终只保留了三个技能，其余均被明确禁用：

• receiving-code-review：收到 review 意见时使用，先核实意见是否适用于当前代码，再决定接受、调整或说明理由。
• systematic-debugging：遇到真实 bug、测试失败、复现不稳定、根因不明或异常行为无法解释时使用，先取证和定位，不靠猜测修改。
• verification-before-completion：准备声明完成、修复、通过、可提交或可合并前使用，验证必须来自当前改动状态和当前回合的实际证据。

用户原先在 AGENTS.md 中设置了全局规则和判断矩阵，让 Coding Agents 根据任务流程自动选择适当的 Superpowers 技能。优化后的局部片段强调了以下原则：

• Skill 是按需 playbook，不是所有任务的默认入口。只选与当前风险直接相关的最小集合，不为了使用 Skill 而使用 Skill。
• 使用会显著改变工作流的 Skill 时，简要说明名称和原因；轻量任务不必声明“未使用 Skill”。
• 三个保留技能各自有明确的使用触发条件（见上方）。
• 其他工程方法（如 brainstorming、详细 planning、TDD、worktree、主动 code review、multi-agent 编排）是可选方法，不因 Superpowers 存在而自动串联；是否采用由用户要求、项目规则和实际风险决定。
• 用户明确点名某个可用 Skill 时按要求使用；若该 Skill 未启用或不可用，说明状态并采用不扩大范围的最短替代路径。

用户还讨论了非 Sol 的 Ultra 情况（如 high/xhigh，甚至 Terra）是否需要其他技能，以及为什么选择禁用而非按需艾特启用。原因在于 Superpowers 的技能缺少 OpenAI 所支持的元数据机制——OpenAI 允许在元数据中定义技能默认禁用但可显式艾特启用，而 Superpowers 不支持。如果保留这些技能，它们会再次串联起来，破坏精简后的工作流。

关键要点

• 优化后只保留三个技能：receiving-code-review、systematic-debugging、verification-before-completion，其余全部禁用。
• 技能不再是默认入口，而是基于当前任务的风险和具体场景按需选择最小集合。
• 使用技能时需简要说明名称和原因；轻量任务无需声明未使用。
• 三个保留技能有明确的触发条件，避免过度使用。
• 其他工程方法（如 brainstorming、TDD、multi-agent 等）与 Superpowers 解耦，由用户、项目规则和风险决定是否采用。
• 用户点名技能时须执行，若不可用则说明状态并采用最短替代路径。
• 禁用而非保留的原因是 Superpowers 缺少 OpenAI 式的元数据支持（默认禁用+显式艾特启用），保留会导致技能自动串联，违背按需原则。

意义与影响

这一优化显著提升了 Coding Agents 在复杂任务中的效率和可控性。通过将技能从默认启用的「自动串联」模式转变为「按需显式调用」，避免了不必要的上下文消耗和推理偏差，让模型专注于当前任务的核心风险点。同时，精简后的技能集合（仅保留三个高频、高价值技能）降低了认知负担，用户和模型都能更清晰地判断何时该调用什么能力。对于依赖 Superpowers 的 AI 辅助编程工作流而言，这一实践提供了一种可复用的模式：利用 AGENTS.md 中的规则矩阵实现精细控制，同时通过禁用非必要技能来防止技能间的意外串联。此外，它揭示了 Superpowers 与 OpenAI 在元数据能力上的差异，促使社区考虑在未来的工具链中补全类似功能，以支持更灵活的默认禁用+显式启用机制。