不是分散的小工具集合,而是从用户消息进入,到代码合并完成,每一步都既告诉 agent HOW,又预先封堵它在那一步偷懒的合理化路径。
一边告诉 agent 在这一步该做什么(HOW),一边抵抗 agent 在这一步偷懒的合理化冲动(DISCIPLINE)。
14 个 skill 按 五大功能分组:元 / 设计 / 执行 / 质量 / 协作。每一个都是工作流上的关节,缺一不可。
14 个 skill 是工序,但工序的真正价值在于:它们组合起来形成一个 agent 难以绕开的工作流闭环。
除 using-superpowers 外,全部 13 个 skill 在 2025-10-16 同一个 commit (9c9547c) 中确立 —— 这是 skill 体系的"创世日"。
按 agent 工作的不同阶段进行分组。每一组解决一类不同的"agent 失败模式"。
按编号、名称、类别、核心一句话、触发时机排列。每行对应一个 skill。
从用户提需求,到工作完成。其中 dispatching-parallel-agents 与 writing-skills 与主流程正交。
skill 体系的"操作系统"——告诉 agent 何时调用 skill、如何写新 skill。
它是什么:每次会话开始时强制注入的"调度器 skill"。决定 agent 在面对用户消息时,是否需要先调用其他 skill。
<EXTREMELY-IMPORTANT> 块:"If you think there is even a 1% chance a skill might apply ... YOU DO NOT HAVE A CHOICE."与其他 skill 关系:是所有其他 skill 的前置触发器——没有它,agent 就不会主动调用其他 skill。
为什么重要:单独调优最频繁的 skill 之一(20 commits)。
核心理念:"Writing skills IS Test-Driven Development applied to process documentation."
| TDD 阶段 | 写 skill 时的对应 |
|---|---|
| RED 写失败测试 | 派遣 subagent 在没有 skill 的情况下跑压力场景,逐字记录所有合理化论点 |
| GREEN 最小代码 | 写 skill 专门反驳那些合理化(不要为假设场景写多余内容) |
| REFACTOR 重构 | 找到新的合理化漏洞 → 显式封堵 → 重新测试至 bulletproof |
@(会强制加载 200K+ context),用 **REQUIRED SUB-SKILL:** 标记把"模糊需求"逐步固化为"可执行任务"。每一步都通过 HARD-GATE 防止 agent 提前跳进实现。
它是什么:通过对话式问答把模糊想法变成结构化 spec 文档,并写入 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md。
<HARD-GATE> 块:未批准不可调用任何 implementation skill演变之最:51 commits,本仓库被改最多的 skill。
它是什么:把 spec 转换成"假设工程师不知道任何上下文也能执行"的逐步任务列表。
把 plan 变成代码。隔离工作区 → 子代理驱动(推荐)/ 内联执行(备选)/ 并行调度(正交)。
它是什么:用 git worktree 创建独立工作目录,让 agent 的 feature 工作不污染主工作区。
git check-ignore 验证为已忽略.gitignore 并 commit| 文件 | 命令 |
|---|---|
| package.json | npm install |
| Cargo.toml | cargo build |
| requirements.txt / pyproject.toml | pip / poetry install |
| go.mod | go mod download |
它是什么:在同一个会话中,为每个 task 派遣一个 fresh subagent,每个 task 完成后做两阶段审查(先 spec 合规、再 code quality)。
| 状态 | 处置方式 |
|---|---|
| DONE | 进入 spec review |
| DONE_WITH_CONCERNS | 读 concerns 决定是否处理 |
| NEEDS_CONTEXT | 提供 context 重新 dispatch |
| BLOCKED | 评估是 context / capability / scope / plan 问题 |
它是什么:在当前会话内直接执行 plan 的简化版本,没有 subagent。
是当 subagent-driven-development 不可用时的降级路径。
| 维度 | subagent-driven | executing-plans |
|---|---|---|
| 上下文隔离 | ✓ fresh per task | ✗ 共享会话 |
| 双重审查 | ✓ 每 task 后 | ✗ 仅整体 |
| 平台要求 | 需要 subagent | 任何平台 |
| 推荐度 | ⭐⭐⭐ | ⭐ |
它是什么:面对多个互不依赖的问题时,不要顺序处理,而是一次性派遣多个 subagent 并行调查。
真实案例(SKILL.md 中的实例):6 个测试失败横跨 3 个文件 → 派 3 个 agent 并行 → 全部独立解决,0 冲突 → 时间从 sequential 缩到 parallel。
无论用哪种执行路径,这 3 个 skill 都贯穿其中。每一个都有自己的 Iron Law。
核心原则:"If you didn't watch the test fail, you don't know if it tests the right thing."
核心原则:"ALWAYS find root cause before attempting fixes. Symptom fixes are failure."
| 方法 | 修好时间 | 一次修好率 |
|---|---|---|
| 系统化方法 | 15-30 分钟 | 95% |
| 随机修 | 2-3 小时 | 40% |
核心原则:"Evidence before claims, always."
"If you haven't run the verification command in this message, you cannot claim it passes."
代码完成后的审查、应答、收尾。每一步都防止"取悦式同意"和"未验证就 merge"。
它是什么:派遣 superpowers:code-reviewer subagent 做审查,不让 reviewer 继承会话历史——只给精心 crafting 的上下文。
核心原则:"Review early, review often."
reviewer 错了怎么办:用技术理由 push back(不要无脑同意)。
核心原则:"Verify before implementing. Ask before assuming. Technical correctness over social comfort."
核心原则:"Verify tests → Present options → Execute choice → Clean up."
| 选项 | 行为 | Worktree |
|---|---|---|
| 1. Merge locally | checkout base + pull + merge + 验证 + 删 branch | 清理 |
| 2. Push + PR | push + gh pr create | 保留 |
| 3. Keep as-is | 报告状态 | 保留 |
| 4. Discard | 要求用户输入 "discard" 字符串确认 + 强删 | 清理 |
读完所有 14 个 SKILL.md 后,可以总结出这套体系共享的几个反复出现的设计模式。
<EXTREMELY-IMPORTANT><HARD-GATE><SUBAGENT-STOP>**REQUIRED SUB-SKILL:** — 让 agent 知道"必须调用另一个 skill"而不是"可能可以参考"。按"当你做什么"或"防止什么失败"反向查找。
Superpowers 的 14 个核心 skill 是一条完整的"AI 软件工程纪律"——从用户消息进入(using-superpowers),到代码合并完成(finishing-a-development-branch),每一步都既告诉 agent HOW,又预先封堵它在那一步偷懒的合理化路径。
14 个 skill 是工序,但工序的真正价值在于:它们组合起来形成一个 agent 难以绕开的工作流闭环。