superpowers

目录

技能

using-superpowers

概述

它定义了整个系统的总规则：任何回复或动作前，都要先检查是否有相关 skill；而且还规定了 skill 与用户指令、默认系统提示之间的优先级（用户指令> superpowers > 默认系统提示）。

注意点

  • 子代理会忽略这个技能
  • 当多个技能可能适用时，按以下顺序：
    • 流程技能优先（头脑风暴、调试）——决定如何处理任务
    • 实现技能其次（前端设计、MCP 构建器）——指导执行
  • 技能本身会说明类型，一共有两种类型：
    • 刚性技能（TDD、调试）：严格遵循。不要偏离。
    • 灵活技能（模式）：可根据上下文调整原则。
  • 最好不要使用这个技能，因为 Agent 的能力还没有强到知道什么时候调用什么技能

brainstorming

概述

这是真正的入口 skill。它要求凡是“创建功能、加行为、改行为”的工作，都要先澄清需求、给方案、拿到设计确认；而且它明确写了，设计批准后唯一的下一步就是 writing-plans。

流程

主流程

  • 探索项目背景——检查文件、文档和最近提交
  • 提供视觉伴侣（如果话题涉及视觉问题）——这是独立消息，不与澄清性问题合并。见下方视觉伴侣部分。
  • 提出澄清性问题——一次一个，理解目的/约束/成功标准
  • 提出2-3种方案——包括权衡与推荐
  • 呈现设计——按复杂度分段，每段结束后获取用户批准
  • 编写设计文档——保存到 docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 并提交
  • 规范自查——快速检查占位符、矛盾、歧义、范围（见下文）
  • 用户审查已写规范——在继续前请用户审查规范文件
  • 过渡到实现——调用 writing-plans 技能创建实现计划

视觉伴侣流程

  • Agent 会先判断后续问题是否适合视觉呈现；如果适合，会先单独询问用户是否启用视觉伴侣
  • 如果用户同意，Agent 会先阅读 visual-companion.md，指导其绘画技巧（比如如何利用scripts下面的脚本）
  • 之后 Agent 按问题来判断：
    • 视觉问题就把 HTML mockup / 图示 / 对比页面写到浏览器里展示
    • 非视觉问题仍然回到终端交流

注意点

  • 在呈现设计并获得用户批准之前，不要调用任何实现技能、编写任何代码、搭建任何项目或采取任何实现行动。这适用于每个项目，无论其看起来多么简单。
  • docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md 这个路径可以被用户指定的路径覆盖
  • Agent 可能将设计规范提交到 git 上
  • spec-document-reviewer-prompt.md给被 dispatch 出去的“spec reviewer”子代理读的

using-git-worktrees

概述

这个 skill 负责建立隔离工作区（worktrees）、跑项目初始化、验证干净基线

流程

  • 确定工作树目录：
    • 判断.worktrees/是否存在，如果存在则使用，否则继续确定
    • 判断worktrees/是否存在，如果存在则使用，否则继续确定
    • 判断CLAUDE.md中是否指定了路径，如果存在则使用，否则继续确定
    • 直接询问用户来确定
  • 安全检查：如果工作树目录是项目本地目录（也就是.worktress/或者worktrees等），那么要验证工作树目录是否被忽略（如果没有被忽略，就可以被add，也就可以被提交；工作树目录只是一个草稿，是不应该被提交的），如果没有，那么就要在 .gitignore 中添加相应行并提交更改
  • 创建工作树并进行一些设置

注意点

  • 一般在brainstorming中间进行创建

writing-plans

概述

这是把 spec 变成可执行任务清单的技能

注意点

  • 计划保存默认目录是docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md ；这个路径可以被用户指定的路径覆盖

test-driven-development

概述

全局约束：任何 feature、bugfix、refactor 都先写 failing test，再写最小实现

注意点

  • 最好在writing-plans之后使用：
    • 如果准备使用executing-plans，那么这个技能是给主代理看的
    • 如果准备使用subagent-driven-development，那么这个技能是给子代理看的（父代理会给子代理看的）

subagent-driven-development

概述

为每个任务派发一个实施子代理来执行计划，每个任务之后进行两阶段审核：先是规范合规性审核，然后是代码质量审核

工作流程

  • 根据任务类型选择子代理模型：
    • 机械实现任务（孤立函数、明确规范、1-2 个文件）：使用快速、廉价模型。大多数实现任务在计划明确时属于机械任务
    • 集成与判断任务（多文件协调、模式匹配、调试）：使用标准模型
    • 架构、设计与审核任务：使用最强模型
  • 派发实施子代理：使用./implementer-prompt.md
  • 根据实施子代理的返回结果进行下一步决策：
    • DONE（完成）： 派发规范合规审核子代理，使用./spec-reviewer-prompt.md
    • DONE_WITH_CONCERNS（完成但有疑虑）： 实施者完成工作，但标注了疑虑。阅读疑虑再继续：
      • 如果疑虑关于正确性或范围，先处理再审核
      • 如果只是观察（如“此文件变大”），记录后继续审核
    • NEEDS_CONTEXT（需要上下文）： 实施者需要未提供的信息。提供缺失上下文后重新派发。
    • BLOCKED（阻塞）： 实施者无法完成任务。评估阻塞原因：
      • 如果是上下文问题，提供更多上下文并用相同模型重新派发
      • 如果任务需要更多推理，用更强模型重新派发
      • 如果任务过大，拆分成更小任务
      • 如果计划本身有问题，上报给用户
  • 派发代码质量审核子代理：使用./code-quality-reviewer-prompt.md

注意事项

  • 无论有没有独立的任务，都可以使用这个技能
  • 验证一下 Codex 能不能够直接使用这个技能（包括上下文注入什么的）

executing-plans

概述

加载计划，进行批判性审查，执行所有任务，完成后报告

工作流程

  • 加载并审查计划：
    • 阅读计划文件
    • 进行批判性审查——识别计划中的任何问题或疑虑
    • 如果有疑虑：在开始前向你的人工伙伴提出
    • 如果没有疑虑：创建 TodoWrite 并继续
  • 执行任务，对每个任务：
    • 标记为 in_progress（进行中）
    • 完全按照每一步执行（计划包含小而具体的步骤）
    • 按规定运行验证
    • 标记为 completed（已完成）
  • 完成开发，在所有任务完成并验证后：
    • 宣布：“我正在使用 finishing-a-development-branch 技能来完成此工作。”
    • 使用 superpowers:finishing-a-development-branch

注意点

  • 能用subagent-driven-development就尽量用

requesting-code-review

概述

在完成任务、实现主要功能或合并前，使用此模板以验证工作是否符合要求

注意点

  • 由主代理调用子代理的时候触发
  • 当然也可以手动触发，但是我感觉暂时用不到

receiving-code-review

概述

当收到代码审查反馈时使用，在实施建议之前，尤其是当反馈不清楚或技术上有疑问时——需要技术严谨和验证，而不是表面附和或盲目执行

注意点

  • 可以在手动调用了requesting-code-review之后再手动调用此技能
  • 也可以在subagent-driven-development的最后一步之后手动调用此技能

verification-before-completion

finishing-a-development-branch

概述

当实现完成、所有测试通过后，用于决定如何整合工作——通过提供结构化选项来完成开发分支的操作，包括合并、PR 或清理

工作流程

  • 验证测试，测试通过了再继续
  • 确定基础分支（比如说main还是master）
  • 提供选项：
    • 在本地合并回基础分支
    • 推送并创建 PR
    • 保留该分支等待用户处理
    • 直接删除这条分支
  • 执行用户的选择
  • （如果没有选择第三个选项）将工作树目录中的对应分支删除

systematic-debugging

概述

先查 root cause，再提修复；而且它会在 Phase 4 明确调用 TDD 去写 failing test

工作流程

  • 根本原因调查
  • 模式分析：
    • 寻找可工作的示例
    • 与参考实现对比
    • 识别差异
    • 理解依赖
  • 假设与测试：
    • 形成单一的原因假设
    • 最小化测试
    • 验证后再继续进入到下一阶段，否则重复“假设与测试”
    • 当不确定时寻求用户等帮助
  • 实施：
    • 创建失败测试用例
    • 实施单一修复
    • 验证修复
    • 修复失败时：
      • 重新尝试另一种假设或者修复
      • 如果重新尝试的次数超过了3，那么质疑架构
    • 质疑架构

dispatching-parallel-agents

writing-skills

工作流

普通工作流

  • 开始之前，请先确保项目下有Agent可以直接使用的环境目录；同时请熟悉每一个要用到的仓库（因为brainstorming总会涉及细节，对一些细节一直问Codex就很慢，而且其实最后节约不了什么时间，还学不了什么东西）
    • 对于一个仓库熟悉的粒度：
      • 项目的pipeline
      • 每个配置文件的字段的含义
      • 环境变量的含义
    • 一定要想清楚，准备怎么改，最后得到的东西一共有哪些，在脑暴过程中全部说清楚（最开始的提示词就要把所需要的东西给出去，脑暴过程中再慢慢完善）
  • 建立工作树分支目录
    • 验证被忽略：git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null 确认 .worktrees/ 被忽略
      • 成功执行的话，退出码为0，表示被忽略了
      • 执行失败的话，退出码非0，表示没有被忽略
    • 创建工作树：git worktree add -b feature/xxx .worktrees/xxx main
    • 不要进入工作树目录，之后要合并分支到主分支中的
    • 如果需要并行开发就创建多个分支，之后在每个分支中写spec和plan，然后由主代理作为主控派遣子代理分别执行
  • 禁止using-superpowers，verification-before-completion，dispatch-parallel-agents，using-git-worktrees和writing-plans
  • brainstorming（脑暴的部分可以使用公益站）：
    • 不要/fork，有什么问题直接问就行，也能让Codex理解更深
    • 不要让其派遣规范审查子代理和计划审查子代理
    • 当Agent给出测试的内容的时候，保证测试全面，包含单元测试和集成测试等
    • spec 文档最好还是看一下，也不长
    • plan 文档可以看一下大的步骤
  • subagent-driven-development或者executing-plans：
    • 首先提醒Agent可以使用的环境的目录（5.5好像不可以，容易看成是破限提示词）
    • 如果调用subagent-driven-development：
      • 需要写代码的时候，请派遣实施子代理，请使用./implementer-prompt.md里面提供的模板，注意在最开始提醒子代理阅读技能test-driven-development（模板的路径给绝对路径，下同）
      • 当实施子代理结束工作的时候，请使用./spec-reviewer-prompt.md里面提供的模板，派遣规格审查子代理
      • 当规格审查子代理结束之后，请你阅读技能requesting-code-review，并使用code-quality-reviewer-prompt.md中的模板派遣代码审查子代理
      • 在得到代码审查子代理的反馈结果之后，请你阅读技能receiving-code-review，并完成技能的指引
    • 如果调用executing-plans，手动执行上面的步骤
  • 如果执行完了之后还存在bug，可以fork了简单QA一下，如果这个bug值得修，直接systematic-debugging
  • 在主分支执行git pull
  • 如果主分支有更新，使用finishing-a-development-branch；否则直接手动合并：
    • git merge <feature-branch>
    • git worktree remove .worktrees/<feature-branch>
    • git branch -d <feature-branch>

查找 bug

  • using-git-worktrees
  • systematic-debugging
  • finishing-a-development-branch
posted @ 2026-04-05 16:47  最爱丁珰  阅读(351)  评论(0)    收藏  举报