brainstorming 需求头脑风暴（流程起点，不可跳过）

核心作用

维度	说明
何时用	任何「创意性工作」之前：新功能、新组件、改行为、加能力
做什么	先理解项目上下文 → 逐条澄清需求 → 对比 2--3 种方案 → 输出设计 → 你确认后再进入实现
硬约束	设计未批准前，禁止写代码、改文件、搭脚手架
产出物	设计文档 `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`

一句话：先想清楚再动手，避免「说加登录，Agent 直接开写，结果和需求对不上」。

举例说明

例子 1：你当前仓库 --- 加「记住我」

没有 brainstorming 时：

你说：「加个记住我」

Agent 直接改 LoginPage.tsx，用 localStorage 存密码 ❌

有 brainstorming 时：

探索上下文：已有 AuthContext + token 存 localStorage，OpenSpec 有 user-auth spec
澄清问题（一次一个）：「记住我」是指延长 session（7 天），还是预填用户名？
三种方案：
- A. 只记住 identifier（推荐，安全）
- B. 延长 token 过期时间
- C. 两者都要（复杂度高）
设计输出：改哪些文件、API 要不要动、错误处理、如何测
你确认 → 写 spec

using-git-worktrees 隔离开发工作区（保护主分支）

核心作用

维度	说明
何时用	开始新功能、需要与当前 workspace 隔离，或执行 `writing-plans` / `executing-plans` 之前
做什么	用 `git worktree` 新建独立目录 + 新分支，自动 `npm install` 等，并跑基线测试
原则	目录选择有优先级 + 安全校验（尤其 `.gitignore`）
配对技能	完成后用 `finishing-a-development-branch` 决定合并/PR/清理

一句话：主目录继续跑 npm run dev，另一边在干净分支里改「记住我」，互不干扰。

举例

例子 1：你的仓库 --- 实现「记住我」

现状：终端 1 跑着 npm run dev（5173 + 3002），主目录可能还有未提交文件。

不用 worktree：

Agent 在主目录改 AuthContext.tsx → dev server 热更新乱跳 → 难对比改前改后

用 worktree：

Agent 会先做安全检查，再创建

git worktree add .worktrees/remember-me -b feature/remember-me

cd .worktrees/remember-me

npm install

npm run build # 基线验证

writing-plans 生成原子级开发计划

@superpowers/writing-plans 的作用：在动手写代码之前，把已确认的设计/规格拆成可逐步执行、可验证的实现计划。

核心作用

维度	说明
何时用	已有 spec / 设计文档，且任务不止一两步
产出	计划文件：`docs/superpowers/plans/YYYY-MM-DD-<feature>.md`
写给谁看	假设执行者不了解你的代码库，需要完整路径、代码片段、命令、预期输出

一句话：brainstorming 想清楚「做什么」，writing-plans 写清楚「怎么做、按什么顺序、怎么验」。

没有 writing-plans	有 writing-plans
Agent 直接改 5 个文件，漏测 edge case	每步有文件路径 + 测试命令 + 预期结果
「加 remember me」语义模糊	明确 `authStorage.ts`、改哪些行、怎么手动验
难以 review / 回滚	可按 Task 1、2、3 分 commit

例子 1：你的「记住我」功能（最贴切）

输入：已批准的设计

docs/superpowers/specs/2026-06-26-remember-me-design.md

writing-plans 会产出类似：

Task 1: authStorage 模块

**Files:**

Create: `src/lib/authStorage.ts`
Step 1: 创建 getToken / setSession / clearSession
Step 2: npm run build --- 预期 exit 0
Step 3: commit

Task 2: AuthContext 接入

**Files:**

Modify: `src/context/AuthContext.tsx`
Step 1: login 增加 rememberMe 参数
Step 2: init/logout 走 authStorage

...

Task 3: LoginPage UI

**Files:**

Modify: `src/pages/LoginPage.tsx`
Modify: `src/pages/LoginPage.module.css`

...

@superpowers/subagent-driven-development 的作用：在当前会话里，按 writing-plans 产出的计划逐 Task 派新的子代理实现，且每个 Task 完成后做两轮审查（先规格符合性，再代码质量）。

核心作用

维度	说明
何时用	已有实现 plan，Task 之间相对独立，且想留在本会话里推进
怎么做	每个 Task → 新 implementer 子代理 → spec 审查 → 质量审查 → 下一 Task
原则	子代理不继承主对话上下文；主 Agent 只给该 Task 的完整文字 + 必要背景
质量	双阶段 review，防止「做多了 / 做少了 / 做歪了」
收尾	全部 Task 完成后 → 总 review → `finishing-a-development-branch`

一句话：一个 Task 一个「干净大脑」的程序员 + 两个审查员，主 Agent 当项目经理。

和 `executing-plans` 的对比

	subagent-driven-development	executing-plans
执行者	每 Task 新子代理	当前 Agent 自己一步步做
审查	每 Task 后自动两轮 review	主要靠 plan 里的验证步骤
上下文	子代理隔离，不易被前面 Task 干扰	长对话可能「记混」
速度	Task 间不用你点头，连续推进	同样在本会话，但无独立 review
成本	子代理调用多（implement + 2 reviewers / task）	更省 token
适用	Task 多、要质量门禁	plan 简单、想全程自己跟

举例

例子 1：你的「记住我」plan（3 个 Task）

假设 plan 有：

Task 1: authStorage.ts
Task 2: AuthContext.tsx
Task 3: LoginPage + CSS

主 Agent：

I'm using Subagent-Driven Development to execute this plan.

一次性提取 3 个 Task 全文 \to TodoWrite

Task 1 --- implementer 子代理：

收到 Task 1 完整步骤 + 「这是存储层，AuthContext 会依赖它」
创建 authStorage.ts，跑 npm run build
自检后回报 DONE

Task 1 --- spec reviewer：

读代码：是否有 getToken / setSession / clearSession？
未勾选写 sessionStorage、勾选写 localStorage、logout 清两者？
✅ 通过 → 进入质量 review

Task 1 --- code quality reviewer：

例如：storage key 是否集中定义？有无重复逻辑？
✅ 通过 → Task 1 完成

Task 2 --- 新 implementer（全新上下文）：

只拿到 Task 2 + 「authStorage 已在 Task 1 完成，接口如下...」
改 AuthContext，不会误改 LoginPage

若 spec reviewer 发现：login() 没加 rememberMe 参数 → implementer 修 → 再 spec review，通过后才 Task 3。

@superpowers/test-driven-development 的作用：在写任何实现代码之前，先写测试、看测试失败、再写最少代码让测试通过（经典 Red → Green → Refactor）。

核心作用

维度	说明
何时用	新功能、修 bug、重构、改行为 --- 默认都要用
铁律	没有先失败的测试，就不写生产代码
关键验证	必须亲眼看到测试失败，否则不知道测的是不是对的

一句话：先定义「应该怎样」，再写「怎样实现」；测试失败过，才算真测到了。

举例

例子 1：你的「记住我」--- `authStorage`（最贴切）

RED --- 先写测试：

// src/lib/authStorage.test.ts

import { describe, it, expect, beforeEach } from 'vitest';

import { setSession, getToken, clearSession } from './authStorage';

describe('authStorage', () => {

beforeEach(() => {

localStorage.clear();

sessionStorage.clear();

});

it('stores token in sessionStorage when rememberMe is false', () => {

setSession('tok-1', { id: '1', name: 'Admin' }, false);

expect(sessionStorage.getItem('auth_token')).toBe('tok-1');

expect(localStorage.getItem('auth_token')).toBeNull();

});

验证 RED：

npm test src/lib/authStorage.test.ts

预期：FAIL --- Cannot find module './authStorage' 或 getToken 未定义

GREEN --- 最少实现：

// src/lib/authStorage.ts

export function setSession(token: string, user: object, rememberMe: boolean) {

const storage = rememberMe ? localStorage : sessionStorage;

const other = rememberMe ? sessionStorage : localStorage;

other.removeItem('auth_token');

other.removeItem('auth_user');

storage.setItem('auth_token', token);

storage.setItem('auth_user', JSON.stringify(user));

}

验证 GREEN：同上命令 → PASS

REFACTOR：抽出 AUTH_TOKEN_KEY 常量，测试仍绿。

@superpowers/requesting-code-review 的作用：在功能完成、合并前，主动派 code-reviewer 子代理审查代码，对照 plan/spec 找问题，避免 bug 和 scope 漂移层层叠加。

核心作用

维度	说明
何时用	完成 Task/大功能、合并前；可选：卡住、大 refactor 前、复杂 bug 修完后
怎么做	取 git 范围 → 派 reviewer 子代理 → 按严重级别处理反馈
原则	早审、常审；reviewer 不继承你的对话历史，只看 diff + 你给的上下文
配对	收到别人 review 时用 `receiving-code-review`（你是被审方读意见）

一句话：你是作者，主动请人看 diff；不是等 merge 才发现问题

@superpowers/finishing-a-development-branch 的作用：功能做完、测试通过后，用固定 4 个选项引导你如何合并/提 PR/保留/丢弃，并处理 worktree 清理。

核心作用

维度	说明
何时用	实现完成、测试通过，要决定怎么合回主分支
流程	验证测试 → 确认 base 分支 → 给你 4 选 1 → 执行 → 按需清 worktree
原则	先证据后选项；丢弃必须你打 `discard` 确认
从哪来	`executing-plans` / `subagent-driven-development` 的最后一步
配对	开头用 `using-git-worktrees` 建的隔离目录，这里负责收尾

一句话：开发在 worktree 里做完，这个技能负责「怎么收场」，而不是默认直接 merge。

四个固定选项

Implementation complete. What would you like to do?

Merge back to <base-branch> locally
Push and create a Pull Request
Keep the branch as-is (I'll handle it later)
Discard this work

Which option?

选项	做什么	worktree
1 本地合并	checkout base → pull → merge → 再跑测试 → 删 feature 分支	删除
2 推 PR	push + `gh pr create`	保留（PR 期间还要改）
3 先不动	只报告分支名和 worktree 路径	保留
4 丢弃	需输入 `discard` 确认 → 强删分支	删除

一、标准完整 7 步官方主流程（90% 开发场景推荐）

核心铁律：未完成 brainstorming 审批前，禁止写任何代码，全程强制 TDD、代码评审、Git 隔离，杜绝 AI 自由发挥。

完整执行顺序 + 对应技能 + 产出 + 门禁卡点

Step1 brainstorming 需求头脑风暴（流程起点，不可跳过）

技能：@superpowers/brainstorming

Step2 using-git-worktrees 隔离开发工作区（保护主分支）

技能：@superpowers/using-git-worktrees

Step3 writing-plans 生成原子级开发计划

技能：@superpowers/writing-plans

Step4 executing-plans + subagent-driven-development 子代理分步执行

技能：@superpowers/executing-plans

Step5 test-driven-development TDD 强制编码（贯穿所有实现）

技能：@superpowers/test-driven-development 铁律：红→绿→重构循环

Step6 requesting-code-review 需求合规 + 代码双重评审

技能：@superpowers/requesting-code-review

Step7 finishing-a-development-branch 分支收尾交付

技能：@superpowers/finishing-a-development-branch

二、轻量精简流程（小修改、bug 修复、单行函数改动）

适用场景：修复线上 bug、工具函数微调、简单样式修改、配置变更，跳过 Git 隔离与复杂设计环节

@superpowers/systematic-debugging（bug 场景）/ @brainstorming（简单需求快速确认）
@writing-plans 极简任务拆分
@executing-plans + TDD 实现
@requesting-code-review 快速评审
验证测试完成，直接提交代码

OpenSpec 固化可归档的标准化需求文档，Superpowers 负责标准化工程落地，需求永久留存、迭代可追溯

OpenSpec 和 Superpowers 解决的是不同层的问题：一个管「项目里变更与规格怎么存、怎么归档」，一个管「Agent 怎么有纪律地把它做出来」。

一句话对比

	OpenSpec	Superpowers
是什么	项目内的变更与规格管理体系（含 CLI + 仓库目录）	Cursor 插件里的 Agent 工作流技能库
核心问题	做什么、为什么、规格是什么、变更何时归档	怎么讨论、怎么计划、怎么实现、怎么验证、怎么收尾
产物在哪	`openspec/changes/`、`openspec/specs/`（进 Git）	`docs/superpowers/`（可选）+ 插件自带技能
面向谁	团队、产品、长期维护者	你 + AI 的日常开发过程

完整 7 步联动顺序

OpenSpec 提案固化需求

plaintext
复制代码
```
/opsx:propose "开发后台角色权限模块，支持数据行权限、批量导入导出"
```
产出：openspec/changes/xxx/ proposal/design/specs/tasks.md
/opsx:continue 增量修改需求，更新所有 spec 文档
@superpowers/brainstorming 严格读取 openspec 全部规范，校验需求边界，禁止私自修改设计
@superpowers/writing-plans 基于 OpenSpec 规范生成细粒度开发计划
@superpowers/executing-plans + TDD，代码 100% 对齐 spec 接口、字段、异常场景
@superpowers/requesting-code-review 以 openspec 文档为唯一评审标准
OpenSpec 归档闭环

superpowers指南

brainstorming 需求头脑风暴（流程起点，不可跳过）

核心作用

举例说明

例子 1：你当前仓库 --- 加「记住我」

核心作用

举例

例子 1：你的仓库 --- 实现「记住我」

Agent 会先做安全检查，再创建

核心作用

例子 1：你的「记住我」功能（最贴切）

Task 1: authStorage 模块

Task 2: AuthContext 接入

Task 3: LoginPage UI

核心作用

和 executing-plans 的对比

举例

例子 1：你的「记住我」plan（3 个 Task）

核心作用

举例

例子 1：你的「记住我」--- authStorage（最贴切）

预期：FAIL --- Cannot find module './authStorage' 或 getToken 未定义

核心作用

核心作用

四个固定选项

一、标准完整 7 步官方主流程（90% 开发场景推荐）

完整执行顺序 + 对应技能 + 产出 + 门禁卡点

Step1 brainstorming 需求头脑风暴（流程起点，不可跳过）

Step2 using-git-worktrees 隔离开发工作区（保护主分支）

Step3 writing-plans 生成原子级开发计划

Step4 executing-plans + subagent-driven-development 子代理分步执行

Step5 test-driven-development TDD 强制编码（贯穿所有实现）

Step6 requesting-code-review 需求合规 + 代码双重评审

Step7 finishing-a-development-branch 分支收尾交付

二、轻量精简流程（小修改、bug 修复、单行函数改动）

一句话对比

完整 7 步联动顺序

和 `executing-plans` 的对比

例子 1：你的「记住我」--- `authStorage`（最贴切）