Skip to content

办公/superpowers

Use when starting any Superpowers workflow, routing to the right process skill, or when the user mentions superpowers / 脑暴 / 写计划 / 执行计划 / 需求实现全流程. Master index for the full skill set and standard delivery pipeline.

Install with
npx skillsgist add https://skills.hfrjkf.cn/p/default/.well-known/agent-skills/superpowers
Run `npx -y skillsgist add https://skills.hfrjkf.cn/p/default/.well-known/agent-skills/superpowers --skill superpowers -g -y`. Read the complete output of that command, redirecting it to a temporary file first if necessary, then open the SKILL.md in the directory that output reports and follow the instructions in it now. Resolve relative paths from that directory.
Download zip
SKILL.mdv2, the latest version

Superpowers 总览

本文件是 skills/ 集合的总入口：先按场景选对 skill，再 Read 对应目录的 SKILL.md 并严格遵循。不要凭记忆跳过流程。

Announce： Using superpowers to route the workflow.

铁律

  1. 只要有约 1% 可能适用某 skill，就先读并执行该 skill。
  2. 流程类 skill（脑暴、调试）优先于实现类 skill。
  3. 宣称完成前必须有新鲜验证证据 → verification-before-completion。
  4. 用户明确指令可覆盖 skill；否则 skill 覆盖默认行为。

详细发现规则： using-superpowers

标准交付链路

创意/需求 → brainstorming → writing-plans
                ↓
         using-git-worktrees（需要隔离时）
                ↓
    ┌───────────┴───────────┐
    ↓                       ↓
subagent-driven-development   executing-plans
（推荐：每任务子代理+评审）    （本会话内联执行）
    ↓                       ↓
test-driven-development（贯穿实现）
    ↓
requesting-code-review / receiving-code-review
    ↓
verification-before-completion
    ↓
finishing-a-development-branch
用户说法 走哪条
做新功能 / 改行为 / 规划新东西 必须先 brainstorming
已有规格，动手前写实现计划 writing-plans
有计划，用子代理按任务推进 subagent-driven-development
有计划，自己本会话内联执行 executing-plans
Bug / 测试失败 / 异常行为 先 systematic-debugging，勿直接改
2+ 独立任务可并行 dispatching-parallel-agents
会话跑歪了 / 为何贵慢 / 技能没触发 diagnosing-superpowers

Skill 目录

入口与元能力

Skill 何时用
using-superpowers 会话开始；如何发现与强制调用 skill
diagnosing-superpowers 事后复盘失败会话、写维护者报告
writing-skills 新建/编辑/验证 skill 本身

设计 → 计划 → 执行

Skill 何时用
brainstorming 任何创意工作前：澄清目标、范围、验收
writing-plans 有规格后、动代码前：拆任务、路径、测试、提交粒度
using-git-worktrees 需要与当前工作区隔离的执行环境
subagent-driven-development 计划落地（推荐）：每任务新子代理 + 任务评审
executing-plans 计划落地（内联）：本会话自己执行全部任务
dispatching-parallel-agents 多个互不依赖的调查/修复并行派发

质量闸门

Skill 何时用
test-driven-development 任何功能/修 bug：先写失败测试再写最小实现
systematic-debugging 任意故障：先根因再修，禁止症状补丁
requesting-code-review 任务完成、大功能后、合并前：派发评审子代理
receiving-code-review 收到评审意见：先核实再改，勿表演式同意
verification-before-completion 声称完成/通过/已修前：跑命令并核对输出
finishing-a-development-branch 实现完成且测试绿：选集成方式并清理

路由决策（最短路径）

新功能 / 新行为？
  YES → brainstorming →（规格 OK）→ writing-plans → 执行 skill → 验证 → finishing
  NO ↓

Bug / 失败 / 怪现象？
  YES → systematic-debugging →（需改代码）→ TDD → 验证
  NO ↓

已有计划要执行？
  YES → worktree（如需）→ SDD 或 executing-plans
  NO ↓

多件独立事？
  YES → dispatching-parallel-agents
  NO → using-superpowers 再扫一遍是否漏了适用 skill

调用约定

  1. 选中 skill 后：Read 其 SKILL.md（及它要求的单据文件），不要只靠本总览摘要。
  2. 口头宣告：Using [skill] to [purpose]。
  3. skill 含 checklist 时，为每项建 todo 并跟踪。
  4. 子 skill 标注 REQUIRED SUB-SKILL / REQUIRED BACKGROUND 时，先满足再继续。
  5. 计划默认落盘：docs/superpowers/plans/YYYY-MM-DD-<feature>.md（用户偏好可覆盖）。

与「需求交付记录」的衔接

复杂需求：本总览链路（脑暴 → 写计划 → 执行）完成后，再补实现记录文档。
简单需求：可先实现，但交付后仍须补齐验收对照与验证证据（见团队 requirement-delivery-recorder）。

反合理化（摘自 using-superpowers）

想法 现实
这只是简单问题 问题也是任务，先查 skill
先探代码再谈流程 skill 规定如何探；先读 skill
我记得这个 skill skill 会演进；读当前版本
流程太重 简单事也会变复杂；照做