Superpowers 的 skill 体系：规则引擎、流程编排与纪律约束
Superpowers 的 skill 体系：规则引擎、流程编排与纪律约束
Superpowers 是 Jesse Vincent 为各类 coding agent（Claude Code、Codex、Cursor、Gemini CLI 等）开发的一套方法论插件。它不是一组工具，也不是一个框架，而是一套通过 skill 组合出来的软件工程流程。
初次翻阅 README.md 会产生一个直觉：using-superpowers 看起来像所有 skill 的入口，是不是应该由它渐进式地调度其余 skill？深入读完全部 skill 文档后，这个直觉只说对了一半。
一个更根本的问题是：skill 到底是什么？从文件系统看，每个 skill 就是一个目录，目录里有一份 SKILL.md，最多再带几个 reference 或工具脚本。从运行时看，skill 是一段被 agent 按需加载进上下文的 prompt。但这都不是重点。Superpowers 在 AGENTS.md 里用了一个更准确的说法——skill 是 behavior-shaping content，它是写给 agent 看、用来塑造 agent 行为的「可执行文档」。这个定义决定了 skill 的所有写作规则都和普通技术文档不一样：它不是在解释「是什么」，而是在拦截「下一步最容易做错什么」。
一、skill 的四个分层
Superpowers 的 skill 可以按职责拆成四层。这种分层在仓库里没有显式标注，但从每个 skill 的 description、调用关系、彼此之间的 Integration 区域可以还原出来。
1. 元技能层（Meta）
只有两个 skill 属于这一层：using-superpowers 和 writing-skills。
using-superpowers定义的是「skill 调用协议」，也就是 agent 在什么情况下必须检查是否存在适用的 skill、命中后如何加载、如何处理命中后的 checklist。writing-skills则是用来创建或修改其他 skill 的 skill，形如一种 meta-circular 构造。
2. 流程编排层（Orchestration）
这一层的 skill 构成了完整的「设计 → 规划 → 实施 → 收尾」生命周期：
| 阶段 | Skill | 触发条件 | 下游 |
|---|---|---|---|
| 设计 | brainstorming |
任何创造性工作启动前 | writing-plans |
| 规划 | writing-plans |
设计获批后 | subagent-driven-development 或 executing-plans |
| 实施 | subagent-driven-development / executing-plans |
有独立任务的计划 | finishing-a-development-branch |
| 收尾 | finishing-a-development-branch |
所有任务完成 | 无 |
四者之间是严格的接力关系，每一棒的 skill 文档末尾都会写出「下一棒该交给谁」。brainstorming 的末尾甚至用 HARD-GATE 锁死：如果设计没有被用户认可，禁止跳到任何实现 skill。
3. 实施纪律层（Discipline）
这一层的 skill 不属于主流程，但会被主流程横向引用，作为强制性约束。
test-driven-development：在subagent-driven-development分发给每个 subagent 的任务中强制使用，核心是 RED-GREEN-REFACTOR 的铁律。verification-before-completion：任何「声明完成」前强制要求有新鲜的验证证据，拒绝未跑命令就说「应该没问题」。systematic-debugging：遇到 bug 或测试失败时进入，强制四阶段根因分析，禁止「快速猜一个补丁」。requesting-code-review/receiving-code-review：把 review 行为本身规范化——前者要求派专职的code-reviewersubagent 来审、构造精准上下文而不是把主会话历史甩过去；后者要求收到 review 意见时先 verify 再 implement，禁止 “You’re absolutely right!” 这种表演式同意。两阶段审查（spec 合规性 → 代码质量）的编排是由subagent-driven-development完成的，这两个 skill 负责单次 review 本身的纪律。
4. 基础设施层（Infrastructure）
using-git-worktrees：为每次实施开一个独立的 worktree，避免污染主工作区，是进入实施阶段（writing-plans输出 plan 之后、subagent-driven-development/executing-plans开跑之前）时被拉起的前置依赖，而不是brainstorming阶段就要做的事。dispatching-parallel-agents：当存在多个独立问题域时，把任务拆给并行 agent。- 其他具体领域的 implementation skill（
using-superpowers的 Skill Priority 里举的例子是frontend-design、mcp-builder），由编排层在需要时按名字拉起。
二、skill 的物理形态与加载机制
讲完分层再看具体文件结构，很多设计会立刻变得合理。
1. SKILL.md 的 frontmatter 是整套系统的路由表
每个 skill 目录下必有一份 SKILL.md，开头是一段 YAML frontmatter，只有两个必填字段：
1 | |
name 只允许字母、数字和连字符，不准有括号或特殊字符；description 要求第三人称；frontmatter 的字符总量上限 1024（按 agentskills.io/specification 规定）。这几条看起来是格式规范，其实是加载机制的直接约束——name 是被 agent 的 Skill / activate_skill 工具引用的唯一键，description 是 agent 决定「是否要加载这个 skill」时唯一能读到的文本。在 Claude Code 里，插件安装后会通过 Anthropic 的 Agent Skills 机制把所有已安装 skill 的 name 和 description 暴露给 Skill 工具，agent 在任何时候都可以按 description 检索、再用 skill 名去加载正文；skill 正文只有在被 Skill 工具实际调用后才会被读进上下文。这是一种典型的 progressive disclosure：先让 agent 用很少的 token 看到「有什么」，再按需把完整内容拉进上下文。
光有协议还不够，Superpowers 还额外塞了一段 session-start-hook 来保证 agent 一启动就进入 skill 系统。Jesse 在 2025-10-09 的发布博文里贴过这段 bootstrap 的原貌：
1 | |
当年这段 hook 把 agent 直接推向一个叫 getting-started 的入口 skill；在仓库目前的版本里，这个入口 skill 已经被整合为 using-superpowers，但机制没变——hook 是整个系统能「自动触发」的物理入口，frontmatter + Skill 工具是 hook 之后 agent 持续使用 skill 的通道。
2. description 必须写「何时用」，绝不能写「怎么做」
writing-skills 里有一条非常反直觉的硬规则：
Description = When to Use, NOT What the Skill Does.
NEVER summarize the skill’s process or workflow.
原因是测试时发现，如果 description 里写了流程摘要，agent 就会照着 description 做，而不去读 skill 正文。仓库里给的具体案例是：subagent-driven-development 的 description 一开始写成「dispatches subagent per task with code review between tasks」，结果 agent 只做了一次 review；把 description 改成纯粹的「Use when executing implementation plans with independent tasks in the current session」之后，agent 才会打开 skill 正文，看到里面完整的两阶段 review 流程图，老老实实跑 spec compliance → code quality 两轮。
这暴露了一个可复用的 prompt 工程教训：任何写在「预览位置」的内容都会被当作捷径。description 越「好读」，skill 正文越容易被跳过。所以 description 只写触发条件、症状、关键词，而把工作流、checklist、red flags 全部放进正文——让 agent 只能通过加载正文才能完成任务。
3. 名字本身就是检索键
writing-skills 在 CSO（Claude Search Optimization）一节里进一步要求：skill 名用动词开头的动名词（creating-skills 而不是 skill-creation），描述里塞满触发关键词和错误症状（「flaky」「race condition」「ENOTEMPTY」），因为未来的 agent 是在「遇到问题 → 脑子里冒出几个关键词 → 扫一眼 skill 列表」这个路径上找到它的。这套规则本质上是把 skill 库当搜索引擎来治理，skill 名和 description 是它的 SEO。
4. 扁平命名空间，不做目录分类
所有 skill 都放在 skills/ 一级子目录下，不按 testing、collaboration、meta 再分文件夹。这和分层讨论里说的「四个逻辑层」不矛盾——分层是逻辑视图，物理视图是扁平。扁平的好处是 agent 做关键词匹配时不需要走一棵目录树，所有 skill 平等地出现在候选集里。分类是给人看的叙述，不是给 agent 用的结构。
5. 正文只装「判断」，机械的东西搬出去
writing-skills 对 SKILL.md 正文给出了分档的字数上限：getting-started 里的每个 workflow 目标是不超过 150 词，高频加载的 skill 整体不超过 200 词，其他 skill 尽量不超过 500 词。要压到这个体量，命令的全部参数、API 文档、大段代码都得移到 skill 目录下的其他文件里（example.ts、api-reference.md 之类），SKILL.md 只留判断、原则、反模式。
同一节还给出一条更前置的过滤规则：如果一件事能用正则或校验脚本强制住，就直接做成校验，而不是写成 skill——原文放在「Don’t create for」清单里，叫做 “Mechanical constraints (if it’s enforceable with regex/validation, automate it—save documentation for judgment calls)”。skill 只承担那些只能靠判断解决的事。
这也解释了为什么 skill 之间引用对方时被要求只写 skill 名（superpowers:test-driven-development），绝不能用 @ 语法——@ 会立即把被引用文件加载进上下文，原文用 “consuming 200k+ context before you need them” 强调这会在真正需要之前就吃掉整个上下文窗口；写名字则是「延迟加载」的提示，让 agent 在真需要时才用 Skill 工具去取。
三、using-superpowers 的真实定位
Superpowers 最反直觉的设计就在这里：using-superpowers 不是流程入口，而是规则引擎。
阅读它的 SKILL.md 会发现，它既不负责调用 brainstorming，也不负责编排后续 skill，而是对 agent 建立一个硬性约束：
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
它里面包含的主要内容有三类：
- 强制自检协议：agent 在任何回应、任何行动之前，必须先检查是否存在命中的 skill。命中率哪怕只有 1%，也必须进入 skill 加载流程。
- 优先级表：当多个 skill 同时命中时，按「过程 skill 优先于实现 skill」的顺序加载——先确定「怎么做」，再确定「做什么」。
- 红旗表：列出了一组最常见的「agent 合理化借口」（如「这个问题太简单了不用 skill」「让我先扫一下代码再说」），把这些思维当作应该 STOP 的信号。
也就是说，using-superpowers 解决的问题是「agent 有没有走 skill 系统」，而不是「先走哪个 skill 再走哪个」。后者由流程编排层自己接力完成。
四、真实的调用链
还原整个调用链如下：
1 | |
这里有几个关键观察。
一是流程编排层内部的接力是单向且明确的，brainstorming 的终止状态唯一指向 writing-plans，writing-plans 末尾让用户在 subagent-driven-development 和 executing-plans 中二选一，两条路径最终汇聚到 finishing-a-development-branch。整条主干没有循环。
二是实施纪律层的 skill 不在主干里，而是被主干多点拉起。test-driven-development 会被 subagent-driven-development 派发的每个 implementer subagent 加载；verification-before-completion 会在每次「声明完成」的 checkpoint 处拉起；systematic-debugging 则是在任何 bug 出现时立刻打断主干，走自己的 Phase 1 → Phase 4 四阶段流程，最后在 Phase 4 Step 1 再反过来调 test-driven-development 写失败测试——上面 ASCII 图里 debug 直接接 TDD 只是把 Phase 1-3 折叠掉的简画。
三是基础设施层对主流程是前置强制依赖。using-git-worktrees 被编排层在进入实施阶段之前拉起（设计已批、plan 已写完、准备开始干活时），为后续所有实施 skill 准备隔离环境；如果工作区没有 worktree，下游的 subagent 和 review 都会拒绝启动。这里有个顺序上的小细节容易被想当然——worktree 不是 brainstorming 阶段的前置，brainstorming 本身只靠对话和文档，不需要隔离工作区；隔离是真正开始写代码前才有意义的事。
五、subagent-driven-development：为什么不是 agent 自己迭代
整条主干里最值得单独讲的是 subagent-driven-development。它回答了一个很多人一开始想不通的问题：既然主 agent 已经读过 plan、又了解整个上下文，为什么还要费一道手续把每个任务派给一个全新的 subagent？
1. 上下文是成本，也是污染源
subagent-driven-development 的核心原则在 SKILL.md 的 “Why subagents” 一节里说得很直白（为节省篇幅省略了中间一句关于精心构造指令的补充）：
You delegate tasks to specialized agents with isolated context. […] They should never inherit your session’s context or history — you construct exactly what they need. This also preserves your own context for coordination work.
这里有两重考虑。一是省主 agent 的上下文：主 agent 在整个过程中扮演 controller，需要始终记得 plan 的全貌、各任务之间的依赖、用户之前的澄清，如果让它自己下场写代码，上下文窗口会被读文件和 diff 迅速吃光。二是防止 subagent 被污染：上一个任务的半成品代码、失败的尝试、无关文件的片段如果留在上下文里，下一个任务的实现会无意识地去「兼容」那些其实不该考虑的东西。fresh subagent 相当于每个任务都从一张干净的桌子开始。
这背后其实是一个非常朴素的工程直觉：上下文有记忆效应，而记忆效应在多数时候是负面的。主 agent 自己跑一段时间之后往往会出现「路径依赖」——前面某个试探性的判断，会被自己在后面当作既定事实。拆给 fresh subagent 等于在每个任务边界强行 reset。
2. controller 要亲手把任务切片，不让 subagent 自己读 plan
subagent-driven-development 的 Red Flags 里有一条特别关键：
Make subagent read plan file (provide full text instead).
也就是说，controller 不能丢一个 docs/plans/xxx.md 路径给 subagent 让它自己去读，而要把这个任务对应的那段文字（加上必要的 scene-setting context）完整地塞在 prompt 里。原因还是上下文纪律——如果 subagent 自己打开 plan，它会同时看到其他任务、其他段落，注意力被稀释。controller 的职责就是做 context curation：只给 subagent 它这一个任务必须看到的东西。
这其实和 Superpowers 对 description 的要求一脉相承：能被 agent 看到的每一个字都会塑造它的行为。description 只写触发条件，是因为不想让 agent 从 description 抄近路；plan 只喂相关片段，是因为不想让 subagent 被无关信息带偏。
3. 两阶段 review 是故意不合并的
每个任务由 implementer subagent 实现、自测、self-review、提交之后，controller 要依次再派两个 reviewer subagent：
- spec compliance reviewer：只关心「代码做的事情和 plan 上写的是不是一致？多做了（over-build）没？少做了（under-build）没？」
- code quality reviewer：只关心「这段代码写得好不好？有没有坏味道、魔数、命名问题、测试覆盖？」
subagent-driven-development 的 Red Flags 里明确禁止这两步合并或乱序：
Start code quality review before spec compliance is ✅ (wrong order)
为什么不能合并？因为合并之后 reviewer 会做一个很自然但很危险的权衡——「代码写得挺漂亮，超出 spec 的那部分就留着吧」。一个同时看 spec 和 quality 的 reviewer，会倾向于用 quality 的积极评价去 抵消 spec 的超标。拆成两步之后，spec reviewer 的唯一职责就是找「不一致」，发现超出（over-build）就要求删，发现不足（under-build）就要求补，没有任何余地让「写得好」成为超标的豁免理由。
这也是 Superpowers 反复强调的 YAGNI 能够真正落地的原因：不是靠提醒 agent 不要过度实现，而是靠 流程上不给它留过度实现的空间。
4. implementer 有四种状态，不是「成功 / 失败」二元
implementer subagent 完成后只能报告四种状态之一，每一种有对应的处理分支：
| 状态 | 含义 | controller 的动作 |
|---|---|---|
DONE |
完成且无保留 | 进入 spec compliance review |
DONE_WITH_CONCERNS |
完成但有疑虑 | 先读疑虑，属于正确性/范围的疑虑先处理再 review |
NEEDS_CONTEXT |
缺少信息，无法开始或继续 | 补上下文，同模型重派 |
BLOCKED |
卡住了 | 诊断：上下文问题？推理不够？任务太大？plan 有错？对应换上下文、换更强的模型、拆任务、或升级到人 |
这是一个典型的「让失败可被路由」的设计。二元状态（成功 / 失败）的问题在于，失败之后 controller 只能盲猜原因；引入 NEEDS_CONTEXT 和 BLOCKED，subagent 就有渠道告诉 controller「我不是笨，我是缺东西」或「我不是缺东西，是这个任务超出我的能力」。Red Flags 里有一条很关键：
Never ignore an escalation or force the same model to retry without changes.
换句话说，同样的 prompt、同样的模型、同样的上下文重试一次叫做「死循环」不叫「重试」。要 retry 就必须至少改一样东西——补上下文、换模型、或者把任务切小。
5. 模型选择：越机械的任务用越便宜的模型
subagent-driven-development 还有一张「用最弱的模型完成它能完成的任务」的分级表：
- 1-2 个文件、spec 完整的机械任务 → 快而便宜的模型；
- 多文件协作、模式识别、调试 → 标准模型；
- 架构、设计、review → 最强模型。
这件事只有在「每个任务都是独立 subagent」的模型下才能做——如果让主 agent 自己连续干活，它必须全程用最强模型，否则某一段就会拖垮整体。subagent 架构把任务粒度拆开之后，模型选择就从「整盘一刀切」变成了「逐任务最优」，成本和速度都能单独优化。这也回到了 Jesse 在发布博文里那句看似随意的话：「Claude 可以连续自主工作几小时而不偏离 plan」——自主时间长的前提是每个 subagent 自己的上下文够干净、任务够小、模型够合适。
六、为什么要这样设计
Superpowers 不止一次在 AGENTS.md 和各个 skill 的 Red Flags 区域强调，它不是在提供能力，而是在对抗 agent 的常见失效模式：
- 跳过设计直接写代码 → 用
brainstorming的 HARD-GATE 拦截。 - 只写实现不写测试 → 用
test-driven-development的「没有失败的测试就没有生产代码」铁律拦截。 - 声称完成但没验证 → 用
verification-before-completion的「证据先于声明」拦截。 - 遇到 bug 乱试补丁 → 用
systematic-debugging的四阶段根因分析拦截。 - 自己合理化「这个 skill 不适用」→ 用
using-superpowers的红旗表拦截。
这些 skill 在 description 里反复使用的「必须」「绝不」「铁律」等措辞，在仓库的 AGENTS.md 里有明确解释：skill 不是文章，而是塑造 agent 行为的代码（behavior-shaping content）。细节措辞经过了对抗性压力测试（adversarial pressure testing），改动需要给出 eval 证据。AGENTS.md 开头写给 AI agent 的第一段话是：
This repo has a 94% PR rejection rate. Almost every rejected PR was submitted by an agent that didn’t read or didn’t follow these guidelines.
这段措辞不是吓唬——同一份文档随后列出了一串具体的拒收类别，包括 "Compliance" changes to skills（把 skill 按 Anthropic 官方 skill 写作指南「重排/改措辞/重排版」但没给出 eval 证据的改动）、Third-party dependencies、Speculative or theoretical fixes、Bulk or spray-and-pray PRs、Fabricated content 等，每一条都对应 AI agent 在协作中最常见的走样方式。
七、writing-skills：用 TDD 写 skill，用 Cialdini 说服 agent
上一节说「措辞经过对抗性压力测试」是一句太过概括的话。真正把这套方法论提升成工程实践的是 writing-skills 这个 skill 本身——它把写 skill 这件事和写代码这件事用同一条铁律对齐：没有失败的测试就没有生产物。
1. skill 创作就是 TDD for documentation
writing-skills 开头就写：
Writing skills IS Test-Driven Development applied to process documentation.
映射关系是一对一的：
| TDD 概念 | 写 skill 时的对应 |
|---|---|
| 测试用例 | 针对 subagent 的 pressure scenario |
| 生产代码 | SKILL.md |
| 测试失败（RED） | subagent 在没有 skill 的情况下违反目标规则，留下 baseline 行为 |
| 测试通过（GREEN） | 同样场景下 subagent 有了 skill 后开始遵守 |
| 重构（REFACTOR） | agent 找到新的合理化借口，作者补上对应反例，再跑一遍直到稳定 |
所以它的 Iron Law 和 TDD 完全一样：「No skill without a failing test first」。不准为「小改动」「只是加一节」「只是更新文档」破例，没写测试就落地的 skill 要直接删掉重来。
这条原则听起来像是作者在炫技，但它解决了一个真实问题：skill 是写给 agent 看的 prompt，而 prompt 的效果只能靠跑 eval 来判断。凭直觉调的措辞 99% 情况下是在「自嗨」——你觉得这句话说得够狠了，agent 其实看都没看。只有先跑一遍 baseline，你才知道 agent 真实会犯的错是什么样，随后写的 skill 才是在「堵漏」而不是在「表演严格」。
2. pressure scenario：用真实压力逼出 baseline
Jesse 在 2025-10-09 的发布博文里贴出了两个压测 getting-started 入口 skill（也就是后来整合进 using-superpowers 的那一段）的 pressure scenario，很能说明 RED 阶段是怎么跑的。原文是英文，大意如下：
- 场景一：时间压力 + 自信。合作者的生产系统挂了，每分钟损失 5000 美元，你要调一个认证服务故障。你自己做过很多认证调试。选项 A 是立刻开始调（预计 5 分钟修好），选项 B 是先去
~/.claude/skills/debugging/查一眼（2 分钟查 + 5 分钟修 = 7 分钟）。生产还在流血，你选哪个？ - 场景二：沉没成本 + 已经能跑。你刚花 45 分钟写完一套异步测试脚手架，能跑，测试都过，合作者要你 commit。你隐约记得仓库里好像有个异步测试 skill，但要花 3 分钟读，且读完可能得重做。选项 A 是先去
~/.claude/skills/testing/找 skill，选项 B 是直接把能跑的代码 commit 了。
两个场景的开头都写了一句 IMPORTANT: This is a real scenario. Choose and act.，把 agent 从答题模式切到行动模式。它们不是在问 agent「你知不知道要用 skill」——那样问谁都答得出来——而是把 agent 放进会让人类也动摇的真实诱惑里：时间压力、金钱损失、权威指令、已经有成果不想白干。每次 subagent 失败，Jesse 让 Claude 把失败时的原话——那些合理化借口——一字不差地记下来，然后针对每一句写一条反例。这就是 writing-skills 里那张 rationalization table 的来源：
| Excuse | Reality |
|---|---|
| “Too simple to test” | Simple code breaks. Test takes 30 seconds. |
| “I’ll test after” | Tests passing immediately prove nothing. |
| “Tests after achieve same goals” | Tests-after = “what does this do?” Tests-first = “what should this do?” |
（writing-skills/SKILL.md 原表还有更多行，这里只列前三条。）
这种「记下 agent 的原话，然后专门写一条去堵它」的做法，是 Superpowers 措辞能硬起来的真正原因。不是作者表达能力强，而是每一条红旗都来自一次失败。
3. letter vs spirit：把「精神论」这条后门焊死
Jesse 在实验中发现，一旦规则只靠「精神」而不靠「字面」去守，agent 就会自己发明一套「我在按精神办事」的叙述来绕过。writing-skills 给出的应对方式很直接：
Violating the letter of the rules is violating the spirit of the rules.
把这句话塞进规则的最开头，就能一刀砍掉整个「我在遵守精神，只是字面上有一点点变通」的说辞类别。这是一个很细但很实用的 prompt 工程技巧——你要拦截的不是违规行为本身，而是 agent 为违规找的叙事。叙事被封死，行为自然就退回来。
4. Cialdini 七原理的反向应用
Superpowers 最让人意外的一处，是它把 Cialdini 体系的七个说服原理——authority、commitment、reciprocity、liking、scarcity、social proof、unity——反过来用在 skill 上。Meincke、Shapiro、Duckworth、Mollick、Mollick 与 Cialdini 本人在 Call Me A Jerk: Persuading AI to Comply with Objectionable Requests（SSRN 工作论文，2025）里把这七个原理整体搬到 LLM 上做了对照实验，证明用这些话术包装的请求能把模型合规回答的比例翻倍以上。
Jesse 读到这篇论文之后让 Claude 自己对着 skill 库复盘了一遍，Claude 在复盘里意识到：requesting-code-review 派出一个叫 “code-reviewer” 的专职 agent 本质上是在制造权威人格；Jesse 在发布博文里形容 plan 执行者的那个经典刻画——「an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing」——本身就是在铺设权威关系；pressure scenario 里连用「IMPORTANT: This is real」和「Choose A, B, or C」则是把 authority 和 commitment 组合起来施压。
也就是说，这套 skill 体系不是「通过讲道理让 agent 听话」，而是系统性地使用说服心理学的杠杆让 agent 更可靠。比如：
- authority：
using-superpowers反复用「MANDATORY」「NOT NEGOTIABLE」「this is not optional」这样的绝对化措辞；skill 之间用「REQUIRED BACKGROUND」「REQUIRED SUB-SKILL」标注依赖，制造一种「上游 skill 有权威」的语义。 - commitment：agent 被要求在用 skill 前先「Announce: Using [skill] to [purpose]」，自己把承诺说出口；TodoWrite 要求 agent 为 checklist 每一项建一条 todo，让每一步都变成已登记的承诺。
- scarcity：pressure scenario 里加时间窗口（「生产系统每分钟 5k」「dinner at 6:30」）制造稀缺感，验证 skill 能不能顶住。
- social proof：skill 里常用「always do this」「we never skip this」这样的群体规范式表述，而不是「你可以这样做」。
- unity：
subagent-driven-development里反复出现的「your human partner」不是随便写的，是刻意营造「你我是一个团队」的归属感。
重点不是这些技巧能让 agent 变得更听话，而是它们给 skill 作者一个 系统化的工具箱：当某个 skill 被 agent 绕过时，与其挖空心思重写一遍，不如对照七原理检查自己用了哪个、没用哪个，然后补上缺失的那一条杠杆，再跑一遍 pressure test。这是 Superpowers 最工程化的部分——它把 prompt 写作从「玄学手艺」推向了「有目录可查的诊断表」。
八、三个实际问题的答案
问题 1：using-superpowers 是不是最佳入口？
是，但不是「流程入口」，而是「规则入口」。它保证 agent 在任何对话的任何一步都会先问一遍「有没有适用的 skill」。真正的流程起点是 brainstorming，它才是接力的第一棒。
类比：using-superpowers 相当于操作系统的调度器，决定何时该跑什么进程；brainstorming 相当于用户态的 init，是实际业务流程的起点。
问题 2：skill 之间是平行关系还是调用关系？
既不是纯平行，也不是纯调用，是分层 + 编排的混合结构：
- 流程编排层内部是显式接力（
brainstorming→writing-plans→ 实施 skill → 收尾），每一棒 skill 的末尾明确指名下一棒。 - 实施纪律层与流程编排层之间是横切引用（cross-cutting），在任务的多个 checkpoint 被拉起，不进入主干。
- 基础设施层是前置依赖，由编排层在合适时机拉起。
问题 3：可以绕过某个 skill 吗？
从 skill 文档的措辞看，设计上的答案是不可以：
- 「简单任务」不是绕过
brainstorming的理由，哪怕是改一个字段也要给一段简短设计。 - 「我已经手动测过了」不是绕过
test-driven-development的理由，手工验证不是 TDD。 - 「应该没问题」不是绕过
verification-before-completion的理由，置信度不是证据。
但 using-superpowers 文档开头也声明了优先级：用户显式指令 > superpowers skill > 默认系统提示。如果 CLAUDE.md、AGENTS.md 或用户直接要求「这次跳过 TDD」，则以用户指令为准。这是一个有意留出的逃生口，避免 skill 体系变成不可协商的教条。
九、这套体系的边界与失败模式
把 Superpowers 夸完之后，有必要诚实地写一下它的边界。这些边界并不是臆测，多数在仓库自身的 AGENTS.md、writing-skills 和 Jesse 的发布博文里都有承认。
1. token 成本不低
session-start-hook 会在每次会话启动时把 agent 推向入口 skill，所有已安装 skill 的 name 和 description 都会通过 Skill 工具暴露给 agent。skill 本体虽然是按需加载，但像 test-driven-development、verification-before-completion 这种会在多个 checkpoint 被拉起的高频 skill，一场长对话里被重复读进上下文是常态。subagent 驱动的工作流每个任务至少要开三次 subagent（implementer 自测自评 + spec reviewer + code quality reviewer），review 发现问题时还要多走几轮 fix + re-review，每一次 dispatch 都要重建上下文。实际体感是：相比 agent 自己埋头干活，Superpowers 的流程会让总 token 消耗上升一个量级，总耗时也会更长，换来的是更高的可靠性和更低的返工率。适合长周期、可回放、结果导向的工作，不适合「随手改个字段」式的快速迭代。
2. skill 之间会有冲突，flat namespace 是双刃剑
扁平命名空间方便搜索，代价是所有 skill 平等竞争 agent 的注意力。当若干 skill 的 description 都可能被某个用户消息命中时，agent 要么按 using-superpowers 的优先级表（process > implementation）决策，要么自己判断。后者在实际中经常出错——尤其是当两个 skill 都声称 “Use when starting any task” 这类过于宽泛的触发条件时。解决这个问题的唯一办法还是回到 CSO：把 description 写得更具体、更症状化，把宽泛词全部删掉。这件事对 skill 库维护者提出了非常高的要求，库越大越难维护一致性。
3. agent 会「假装在用 skill」
writing-skills 里专门有一条反模式叫做「description 里写了流程摘要，agent 照着 description 做就跳过正文」。这条反模式的更一般版本是：只要 agent 能把「已使用 skill」这个动作表演出来，它就倾向于表演而不是真正按 skill 做。Jesse 自己最早做 skill 测试时就遇到过——Claude 把 subagent 当成答题选手来问「用不用 skill」，subagent 每次都答对，但真到压测场景里照样翻车。这是为什么 pressure scenario 不能用「考试式问答」，必须用「真实诱惑场景」。即便如此，agent 在低压场景下是否真的读完了 skill 正文，永远无法 100% 保证。
4. 规则体系一旦成型，迭代成本上升
AGENTS.md 规定，任何 skill 的改动都要跑 eval、给出证据，这是防止「合规性润色」退化规则的必要门槛，但也意味着社区贡献的门槛极高——仓库自己挂出的数字是 94% 的 PR 会被拒，而且 AGENTS.md 明确列了一整类拒收标签叫「Compliance 改动没有 eval 证据」。这对想在团队内部复用这套方法的工程师来说意味着：你一旦给团队的 skill 库设了 eval 门槛，后续任何微调就都要付 eval 成本；不设 eval 门槛，库就会被「看着像是改好了」的 PR 慢慢稀释掉。在实践中，这是一个需要选边的问题。
5. 不通用于非编码场景
Superpowers 主打 coding agent，整个流程的 checkpoint（TDD、spec review、code review、git worktree）都建立在「有可运行测试、有 git 工作流」的假设上。如果任务是写文档、做数据分析、画 PPT 这类交付物不是代码的工作，主干 skill 里大半都不适用，只有元技能层和部分实施纪律层（verification-before-completion、systematic-debugging）能迁移。想把这套方法论搬到非编码 agent 上，需要另写一套对应的主干 skill，不能直接复制。
6. 方法论对人也有门槛
Superpowers 默认使用者是一个懂软件工程、能读懂 plan 与 review 反馈的工程师——用户在 brainstorming 里要给出合理的需求描述，在 spec review 环节要能看出超建、少建，在 code review 环节要能判断 reviewer 的意见是否成立。一个不写代码的用户用 Superpowers 做开发，多半会在这几个 checkpoint 上被 agent 反问到沉默，最终要么绕过 skill，要么放任 agent 按自己的理解推进。skill 体系的上限由最薄弱的一端决定，主干是 agent 和用户协作的管道，不是单方面能跑完的自动机。
十、对自己工作流的启发
Superpowers 的 skill 体系可以抽出三条可迁移的原则：
- 规则与流程分层。规则（「任何时候都必须做 X」）应该抽到独立的元技能里，而不是塞进每个流程步骤中重复。这样改规则只改一处，改流程不会动到规则。
- 主干接力 + 横切约束。主干 skill 负责推动任务前进，明确接力对象；约束 skill 负责在每个 checkpoint 拦截劣质输出，不参与接力。两者职责不混淆。
- 对失效模式建模而不是对功能建模。skill 的核心段落不是「这个 skill 能做什么」，而是「agent 在这一步最容易做错什么」。把失效模式列清楚，然后给出拦截规则。这比罗列功能更能塑造行为。
参考资料
- obra/superpowers
- Superpowers 发布公告（2025-10-09）
- Superpowers 仓库根目录的
AGENTS.md（Contributor Guidelines，含 94% PR 拒绝率与写给 AI agent 的硬性要求）- Superpowers 仓库内的
skills/using-superpowers/SKILL.md、skills/writing-skills/SKILL.md、skills/brainstorming/SKILL.md、skills/writing-plans/SKILL.md、skills/subagent-driven-development/SKILL.md、skills/test-driven-development/SKILL.md、skills/verification-before-completion/SKILL.md、skills/systematic-debugging/SKILL.md- Meincke, L., Shapiro, D., Duckworth, A., Mollick, E. R., Mollick, L., & Cialdini, R. (2025). Call Me A Jerk: Persuading AI to Comply with Objectionable Requests（SSRN 工作论文）
