前置概念:理解 Using-Superpowers 的核心定位
using-superpowers 是 Superpowers 技能体系的入口级技能。与其他技能最大的区别在于——它不定义"如何执行某项具体任务",而是明确定义"何时、为何以及怎样加载其他技能"。简而言之,它是一个元技能(meta-skill),负责指导 AI agent 如何发现并运用整个技能系统本身。
整个技能仅 63 行代码,是 Superpowers 体系中篇幅最短的一个。但它要应对的是一个全局性难题:在默认情况下,agent 往往会倾向于"凡是自己能靠已有知识解决的问题,就不去查阅技能文档"。
逐层拆解:七层机制如何重塑 agent 行为
下面我们逐层深入剖析,看看每一层机制究竟在对抗 agent 的哪些固有倾向,以及如何扭转局面。
第 0 层:Description——强制技能加载断言
先关注 description 部分:
description: Use when starting any conversation - establishes how to find and use skills,requiring skill invocation before ANY response including clarifying questions
默认情况下,agent 接收到用户消息后的流程是:评估任务 → 直接开始回复。它不会主动思考"让我先查查有没有相关的技能可用"——因为技能检索根本不在它的默认推理路径之中。
这条 description 发挥了两方面的关键作用:
"Use when starting any conversation"——将触发条件设定为"每次新会话的第一条消息",确保该技能在对话伊始就被加载进来。"requiring skill invocation before ANY response including clarifying questions"——核心约束在于:在输出任何回复之前(包括"您指的是什么?"这类澄清性问题),必须先调用技能。这直接封堵了 agent 最惯常的绕行路径——agent 总是倾向于说"我先问清楚再说",但这里明确规定:先查技能,再提问题。
第 1 层:SUBAGENT-STOP——子 agent 豁免机制
<SUBAGENT-STOP>If you were dispatched as a subagent to execute a specific task, ignore this skill.SUBAGENT-STOP>
在默认情况下,子 agent 不会自行判断"我该加载哪个技能"——它直接执行主 agent 构建好的指令。但技能加载机制本身并不区分主 agent 和子 agent。若没有这条豁免规则,子 agent 会先加载 using-superpowers,然后开始自我追问"我该用哪个技能"——从而陷入无限递归。
这条指令的设计颇为精妙:
"If you were dispatched as a subagent to execute a specific task, ignore this skill."——一条精准的豁免条款。子 agent 的特征是"被派遣来执行某一特定任务",其作用范围已被主 agent(controller)限定,无需自行进行技能发现(skill discovery)。- 该标签被置于最开头(第 6-8 行),确保子 agent 在读到任何其他内容之前先看到豁免指令,直接跳过本技能。
第 2 层:EXTREMELY-IMPORTANT——绝对优先级覆盖
<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 HA VE A CHOICE. YOU MUST USE IT.This is not negotiable. You cannot rationalize your way out of this.EXTREMELY-IMPORTANT>
默认情况下,agent 判断"这项技能是否适用于当前任务"的阈值相当高。其默认阈值大约在 80%——只有"我非常确定这项技能完全匹配我的任务"时才会加载。对于 30-60% 匹配度的情况("好像有点关联但我不太确定"),agent 通常会选择跳过。
来看看这条指令是如何扭转局面的:
"even a 1% chance"——直接将阈值拉低到 1%。这是一种极端的过载触发策略:"宁可错杀一千,绝不放过一个。"因为加载一个不需要的技能成本极低(仅耗费几 KB token),而跳过所需的技能成本极高(可能导致整个流程偏离方向)。"ABSOLUTELY MUST invoke the skill"和"YOU DO NOT HA VE A CHOICE"——全大写加绝对化措辞,不留任何解释空间。agent 被剥夺了"是否加载"的判断权。"This is not negotiable. You cannot rationalize your way out of this."——直指 agent 的核心运作机制:agent 会对自己解释"这次不需要"。这句预先声明"你会发现各种理由——但那些理由都不成立。"
第 3 层:The Rule——行动顺序重排
## The Rule
**Invoke relevant or requested skills BEFORE any response or action** — including
clarifying questions, exploring the codebase, or checking files. If it turns out
wrong for the situation, you don't ha ve to use it.
**Before entering plan mode:** if you ha ven't already brainstormed, invoke the
brainstorming skill first.
Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has
a checklist, create a todo per item.
默认情况下,agent 的推理顺序是:理解问题 → 收集信息 → 制定方案 → 执行。技能检索被隐含在"理解问题"之后——agent 觉得自己已经理解了问题,才会去看"有没有更好的做事方式"。
这条 The Rule 是如何重塑执行顺序的:
"BEFORE any response or action"——将技能检索提前到所有动作之前。不是"先理解问题再看技能",而是"先看技能,再理解问题"。这个次序倒转从根本上改变了信息处理流程:agent 是带着技能的结构去理解问题,而不是凭借自身直觉去理解问题。"including clarifying questions, exploring the codebase, or checking files"——三个具体示例封堵了 agent 最常见的跳过理由。agent 不能再以"我只是探索代码库"、"我只是检查文件"为借口——这三者都属于"动作",都需要先查技能。"If it turns out wrong for the situation, you don't ha ve to use it."——一个巧妙的容错机制。强制加载,但允许在实际使用后发现不适用时放弃执行。这有效降低了加载门槛带来的心理阻力——因为加载并不等于必须执行。"Before entering plan mode: if you ha ven't already brainstormed, invoke the brainstorming skill first."——将两个技能硬性连接。这条规则确保 brainstorming 与 writing-plans 之间的链路不会被 agent 跳过。"announce 'Using [skill] to [purpose]'"——强制声明机制。这让技能加载对用户变得可见,用户可以据此判断 agent 是否加载了正确的技能。
第 4 层:Skill Priority——选择顺序约束
## Skill Priority
When multiple skills apply, process skills come first — they set the approach,
then implementation skills (frontend-design, etc.) carry it out.
- "Let's build X" → superpowers:brainstorming first, then implementation skills.
- "Fix this bug" → superpowers:systematic-debugging first, then domain skills.
默认情况下,agent 加载多个技能时,倾向于全部加载并同时应用。它不会主动排序"先走 brainstorming 再走 implementation"——它会尝试并行处理。
这里定义了两层优先级体系:process skills(设定方法的) > implementation skills(执行方法的)。这是一种拓扑排序——某些技能的输出是其他技能的输入,因此它们必须优先运行。
两个具体场景示例:
- "Let's build X":先 brainstorming(想清楚要做什么),再 implementation skills(开始动手实施)。顺序不可颠倒。
- "Fix this bug":先 systematic-debugging(定位根因),再 domain skills(在具体技术栈中修复)。顺序不可颠倒。
第 5 层:Red Flags 表——12 条合理化借口预击杀
## Red Flags
These thoughts mean STOP—you're rationalizing:
| Thought | Reality |
|---------|---------|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
这 12 条是 agent 在做出"不加载技能"的决定时,对自己说的真实原话。它们并非理论上的借口——而是从真实的"agent 跳过技能"的失败场景中逐条采集而来的。
这个 Red Flags 的设计堪称 Superpowers 体系"合理化预击杀模式"的典范:每一行都是一个「想法 → 反驳」对,覆盖了 agent 最常用的 12 种跳过技能的借口:
- 归类否定("这不是一个任务"、"这只是简单问题")→ 反驳:一切皆任务。
- 顺序借口("我先收集信息再查"、"我先探索再查")→ 反驳:技能告诉你怎么收集/探索。
- 自信借口("我记得这个技能"、"我知道那是什么意思")→ 反驳:技能会更新;知道概念 ≠ 会执行。
- 效率借口("技能是过度杀伤"、"我先做一件小事")→ 反驳:简单可能变复杂;先查再做。
- 直觉借口("这感觉很高效")→ 反驳:不守纪律的效率是无序的浪费。
关键设计思路:表格左侧是 agent 对自己说的原话(这些是真实采集的,并非编造)。当 agent 在思考过程中产生这些词句模式时,Red Flags 表格启动模式匹配——agent 识别到"我刚才想的这句话在表里"然后触发 STOP。无需高级元认知能力,只需底层模式匹配即可。
第 6 层:User Instructions——优先级层级
## User Instructions
User instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take
precedence over skills, which in turn override default beha vior. Only skip skill
workflows or instructions when your human partner has explicitly told you to.
默认情况下,agent 可能在不同优先级的指令之间产生困惑——技能说"必须先 brainstorming",用户的 CLAUDE.md 却说"这个项目总是直接写代码",冲突该如何解决?
这里建立了一个三级优先级链条:用户指令 > 技能指令 > agent 默认行为。但退出条款(exit clause)是关键:"Only skip skill workflows or instructions when your human partner has explicitly told you to"——用户没有明确说"跳过 brainstorming"就不能跳过。用户的沉默不等于豁免,用户必须明确说出豁免才生效。
总结:Using-Superpowers 的 7 层约束体系
| 层级 | 约束机制 | 对抗的 agent 默认行为 |
|---|---|---|
| 0 | description 强制会话启动加载 | 不知道应该先加载技能 |
| 1 | SUBAGENT-STOP 子 agent 豁免 | 子 agent 做递归技能查找 |
| 2 | 1% 概率即加载 + 不可协商 | 加载阈值太高 → 跳过 |
| 3 | 技能先于一切动作 | 先理解问题 → 再看技能 |
| 4 | process > implementation | 并行加载所有技能 |
| 5 | 12 条 Red Flags 预击杀 | 对自己合理化"不需要" |
| 6 | 三级优先级链 + exit clause | CL.md 和技能冲突时犹豫 |
核心设计理念:这个技能解决的是一个"元问题"——不是告诉 agent 如何执行某件事,而是告诉 agent "如何发现做这件事的正确方式"。它的 63 行代码量对应的是整个 Superpowers 生态的入口控制——如果这一关失效,其他 13 个技能将永远不会被加载。
它的两个核心创新点:
- 把加载阈值从"大概需要"拉低到"1% 可能"——极端过载触发策略确保不遗漏。
- 用 12 条真实采集的合理化借口进行模式匹配——不需要 agent 具备元认知能力,只需识别自己说过的原话。
附录:Using-Superpowers SKILL.md 完整原文
---
name: using-superpowers
description: Use when starting any conversation - establishes how to find and use
skills, requiring skill invocation before ANY response including clarifying questions
---
If you were dispatched as a subagent to execute a specific task, ignore this skill.
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 HA VE A CHOICE. YOU MUST USE IT.
This is not negotiable. You cannot rationalize your way out of this.
## The Rule
**Invoke relevant or requested skills BEFORE any response or action** — including
clarifying questions, exploring the codebase, or checking files. If it turns out
wrong for the situation, you don't ha ve to use it.
**Before entering plan mode:** if you ha ven't already brainstormed, invoke the
brainstorming skill first.
Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has
a checklist, create a todo per item.
## Skill Priority
When multiple skills apply, process skills come first — they set the approach,
then implementation skills (frontend-design, etc.) carry it out.
- "Let's build X" → superpowers:brainstorming first, then implementation skills.
- "Fix this bug" → superpowers:systematic-debugging first, then domain skills.
## Red Flags
These thoughts mean STOP—you're rationalizing:
| Thought | Reality |
|---------|---------|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
## Platform Adaptation
If your harness appears here, read its reference file for special instructions:
- Codex: `references/codex-tools.md`
- Pi: `references/pi-tools.md`
- Antigra vity: `references/antigra vity-tools.md`
## User Instructions
User instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take
precedence over skills, which in turn override default beha vior. Only skip skill
workflows or instructions when your human partner has explicitly told you to.
