核心思想
作者的设计原则、与同类项目的差异化定位、关键工作流的简要介绍。文中提到的技能名称会自动链接到对应技能页。
Superpowers 的设计核心是把"软件开发方法论"拆解成一个个单一职责、可插拔、模型无关的微技能，再由一段 session 级引导在恰当时机自动触发它们，从而在不改变 Agent 底层能力的前提下系统性塑造其开发行为。
核心理念
- 小而精：每个技能只做一件事，例如 /test-driven-development 只强制 RED-GREEN-REFACTOR 循环，/systematic-debugging 只负责四阶段根因定位。
- 可组合：技能像乐高一样按需拼装，不强制全用；用户可按项目需要挑选组合。
- 模型与宿主无关：同一套技能适配 Claude Code、Codex、Gemini CLI、OpenCode、Cursor 等多种编码 Agent。
- 行为塑造优先：技能面向真实 Agent 行为反复调优，属于"代码而非散文"，改动需经 eval 验证。
工作方法
当用户向 AI 提出开发需求，Agent 不会直接写代码，而是按流程自动触发技能链：
- 需求澄清：/brainstorming 通过提问梳清意图与需求，分块展示设计供确认，产出设计文档。
- 隔离工作区：/using-git-worktrees 在独立分支上建立隔离工作区并验证干净的测试基线。
- 拆解计划：/writing-plans 把任务拆成 2-5 分钟的极小步骤，每步含精确文件路径、完整代码与验证步骤。
- 执行开发：/subagent-driven-development 或 /executing-plans 为每步派发独立子 Agent 或成批执行，并做两阶段评审。
- 测试驱动：/test-driven-development 落实先写失败测试、再写通过代码、再重构。
- 代码评审：/requesting-code-review 与 /receiving-code-review 规范评审与反馈处理。
- 收尾合入：/finishing-a-development-branch 在完成时决定 merge/PR/保留/丢弃并清理工作区。 另有一组���技能：/writing-skills（编写新技能）与 /using-superpowers（启动引导，负责任何响应前先定位并使用技能）。
使用建议
- 安装后首次工作即触发引导，用户无需每次手动调用；典型工作流参照 README 的 Basic Workflow 顺序推进即可。
- 贡献或修改技能时应遵循 /writing-skills，并经 eval 验证后再合入。
技能关系
Skill → Skill 的使用关系，可跨层指向。同色块表示同一类技能形态。
技能组成
每个技能都为某种调用者设计——有的必须由你点名触发，有的则由模型自动按上下文加载。下面的两张卡片一眼看清整个技能集的触发分工。
技能清单
通过协作对话将模糊创意转化为完整的设计方案和规格说明。通过逐步提问理解需求、提出2-3种方案并权衡、分节呈现设计、编写设计文档并提交审查，最终触发实现计划生成。核心产出是结构化的设计文档（spec）和可执行的实现计划。
将两个以上独立的问题域派发给专门的子 Agent 并行处理。核心方法是为每个独立问题域（如不同测试文件/子系统的故障）构建自包含的 Agent 任务指令，一次并发派发多个子 Agent，最后汇总审查并整合修复。大幅提升多故障排查效率。
负责执行已编写好的实现计划。先加载并审查计划，确保隔离的工作空间就绪，然后按步骤执行每个任务并验证，最后调用 finishing-a-development-branch 技能完成开发分支的收尾工作。遇到阻塞时停止并请求澄清，不猜测。
在实现完成、测试通过后，负责开发分支的收尾工作。核心流程：验证全量测试→检测工作空间环境（普通仓库/工作树/detached HEAD）→确认基分支→向用户呈现集成选项（合并/创建PR/保留）→执行选择→清理工作空间。确保每次集成前测试是绿色的。
当收到代码审查反馈时，先技术验证而非盲从执行。遵循「阅读→理解→验证→评估→回应→逐个实施」的模式，禁止表演性同意。对不清晰的反馈必须澄清全部后再实施，对外部审查者的建议持审慎态度，可基于技术理由反驳。产出是经过严格验证的、高质量的代码修改，避免盲目采纳错误建议带来的回归缺陷。
主动请求代码审查：通过分派子 Agent 审查者来审查代码差异，在问题级联之前发现缺陷。核心原则是「尽早审查、经常审查」。为审查者提供精心构造的上下文（而非会话历史），让其专注于工作产品评估。输出是审查结果（关键/重要/次要问题）及评估结论，帮助开发者在合并前验证工作是否满足需求。
通过为每个任务分派独立的实施子 Agent 来执行开发计划，每个任务完成后进行规范合规性和代码质量审查，最后进行全分支审查。核心原则：每个任务使用全新子 Agent + 任务审查 + 最终审查 = 高质量、快速迭代。使用账本文件跟踪进度以抵抗上下文压缩导致的进度丢失。产出是经过多轮审查验证的、高质量的实现代码。
系统化调试技能，严格遵守「先找根因，再修 bug」的铁律。分四个阶段：根因调查（重现、检查更改、追溯数据流）、模式分析（找工作示例对比）、假设验证（最小改动测试）、实施修复（先创建失败测试，再单次修复验证）。超过3次修复失败则质疑架构。产出是经过根本原因分析的、可靠且经过测试的修复，避免症状性修复导致的反复失败。
测试驱动开发（TDD）技能，强制在编写任何生产代码之前先写失败测试，遵循红-绿-重构循环。核心原则是：没有生产代码能先于失败测试存在。通过红阶段写失败测试、验证失败原因正确、绿阶段写最小通过代码、重构阶段清理代码，确保代码可测试、行为被覆盖。产出高置信度的代码和可靠的回归测试集。
Git Worktrees 使用技能，确保开发工作在隔离的工作空间中进行。优先检测是否已在隔离环境中，然后使用平台原生 worktree 工具，最后回退到 git worktree 手动创建。包含三步流程：检测现有隔离（Step 0）、创建隔离工作空间（Step 1）、项目设置与基线测试验证（Step 2-3）。保证主分支不受开发过程中变更的影响。
Superpowers 入口技能，规定在任何响应或行动之前必须检查并调用相关技能（含明确的红色标志清单防止理性化逃避）。核心规则是：只要存在 1% 的可能某个技能适用，就必须调用它。在进入计划模式前，必须先调用 brainstorming 技能。技能优先级方面，流程技能先于实现技能。同时包含平台适配（Codex/Pi/Antigravity）的引用文件。
完成前验证技能，核心原则是：证据先于断言。铁律要求：没有新鲜的验证证据就不能声称完成。在声明任何状态（测试通过、构建成功、Bug 修复等）之前，必须先识别证明该声明的命令、完整运行该命令、读取完整输出和退出码、确认输出是否支撑声明。适用于所有成功/完成声明、满意度表达、提交/PR 创建等场景。
该技能用于将需求或规格说明书拆解为可执行的实施计划。通过范围检查、文件结构映射、任务粒度细化（每个步骤2-5分钟）和自审等步骤，生成结构化的Markdown计划文档。关键产出是一份包含全局约束、任务分解、精确代码示例和验证步骤的完整计划，确保后续执行者能够零决策地按步骤实施。
该技能将测试驱动开发（TDD）方法论应用于技能文档的创建和编辑。核心流程：先编写测试用例（压力场景）观察无技能时的Agent行为（RED阶段），然后编写技能文档（GREEN阶段），最后重构关闭漏洞。通过这种方式确保技能文档能有效引导Agent行为。同时提供技能命名、目录结构、描述优化（Skill Discovery Optimization）和跨技能引用等最佳实践指导。
