Superpowers 与 OpenSpec 使用指导手册Superpowers-lite 与 OpenSpec 通俗使用手册1. 先按你的真实开发方式理解2. 平时先用 Superpowers 的 5 个核心 skills2.1 Superpowers 全量 skills 有 14 个2.2 Superpowers 的命令和 skills 不是一回事3. 做到什么程度才需要 OpenSpec4. OpenSpec 第一次介入时会生成什么5. OpenSpec 命令为什么有 11 个和 19 个两种说法5.1 AI 聊天窗口里的 /opsx 命令11 个5.2 终端里的 openspec CLI你本机 1.3.1 有 19 个顶层命令6. 默认组合Superpowers 主导OpenSpec 记录6.1 分工6.2 流程图6.3 例子做登录功能7. 严格组合OpenSpec 主导Superpowers 辅助7.1 分工7.2 流程图7.3 例子做会员计费模块8. 两者会不会冲突9. 最短口诀Superpowers-lite 与 OpenSpec 通俗使用手册目标让你知道什么时候用 Superpowers什么时候拉 OpenSpec 进来以及两者一起用时怎么不打架。1. 先按你的真实开发方式理解你从 0 到 1 做东西时默认不要把流程搞重。最顺的方式是先让 Superpowers 管开发过程。 只有遇到值得长期记录的大功能再让 OpenSpec 介入做记录。也就是说平时你只需要记住一句话Superpowers 负责“怎么把代码做出来”。 OpenSpec 负责“哪些需求变化要留下规范记录”。后面所有命令和流程都围绕这句话展开。2. 平时先用 Superpowers 的 5 个核心 skillsSuperpowers 本质上是一组给 AI 用的 skills。它不是要求你每一步都手动敲命令而是让 AI 在合适的时候按这些 skills 工作。你当前最适合默认启用这 5 个顺序Skill什么时候用解决什么问题1brainstorming你只有一个想法还没讲清楚把需求、边界、取舍问清楚2writing-plans需求已经清楚准备开发前把需求拆成可执行计划3executing-plans已经有计划开始改代码按计划一步步实现4test-driven-development有核心逻辑、规则、算法、接口行为先写测试再写实现避免拍脑袋5verification-before-completion准备说“完成了”之前跑测试、构建、检查避免假完成这 5 个已经能覆盖个人开发最常见的完整闭环想法 - 需求 - 计划 - 实现 - 测试 - 验证2.1 Superpowers 全量 skills 有 14 个你不用一开始全装全用但要知道完整 Superpowers 里还有哪些能力分组Skills需求与计划brainstorming、writing-plans、executing-plans测试与验证test-driven-development、verification-before-completion调试systematic-debuggingGit / 分支using-git-worktrees、finishing-a-development-branch子代理 / 并行subagent-driven-development、dispatching-parallel-agentsReviewrequesting-code-review、receiving-code-review元能力using-superpowers、writing-skills为什么你现在不需要默认全用worktree、分支收尾、子代理、代码 review 更适合团队协作或大型任务。 你个人从 0 到 1 开发先用 5 个核心 skills 更轻。2.2 Superpowers 的命令和 skills 不是一回事你本机 Superpowers 仓库里能看到 3 个命令包装器命令包装器对应 skill作用brainstormbrainstorming显式进入需求澄清write-planwriting-plans显式要求写开发计划execute-planexecuting-plans显式要求按计划执行这里要分清楚skills 是 AI 的工作规则。 命令包装器是手动点名某个 skill 的入口。所以你不一定每次都要手动敲命令。你也可以直接对 AI 说用 Superpowers brainstorming 先帮我把这个功能需求梳理清楚。3. 做到什么程度才需要 OpenSpec如果只是改一个按钮、修一个小 bug、调一个样式不需要 OpenSpec。当你做到这类事情时再让 OpenSpec 介入场景是否建议用 OpenSpec原因登录、权限、计费、订单、数据模型建议会影响长期业务规则API 行为、数据库结构、核心流程建议后面别人或未来的你需要查依据一次性小改动、文案、样式微调不建议记录成本大于收益OpenSpec 介入时不是先让它开发而是先创建一条change。这里的change可以理解成一次值得记录的需求变化。 比如 add-login 就是一条“新增登录功能”的 change。4. OpenSpec 第一次介入时会生成什么当你在 AI 聊天窗口里说/opsx:propose add-loginOpenSpec 会围绕add-login这条 change 生成几类文件文件 / 目录作用你该怎么看proposal.md写为什么做、改什么、影响什么这是变更说明specs/写需求、行为规则、场景这是功能应该满足的规则design.md写技术方案、关键决策、风险取舍这是实现思路tasks.md写实现任务清单这是 OpenSpec 后续执行的依据这几个文件的关系很简单proposal.md 说明为什么做。 specs/ 说明做成什么样。 design.md 说明怎么做。 tasks.md 说明按什么步骤做。所以 OpenSpec 不只是“备忘录”。它也可以按tasks.md推进开发。问题在于如果你已经让 Superpowers 写计划并执行就不要再让 OpenSpec 同时执行第二套计划。5. OpenSpec 命令为什么有 11 个和 19 个两种说法这里不是冲突是入口不同。/opsx:* 是 AI 聊天窗口里的命令。 openspec 是终端 / PowerShell / CMD 里的 CLI 命令。5.1 AI 聊天窗口里的/opsx命令11 个日常最常用的是这 5 个命令作用/opsx:propose创建 change并生成proposal.md、specs/、design.md、tasks.md/opsx:explore先探索想法不急着创建 change/opsx:apply按tasks.md推进实现/opsx:sync把 change 里的specs/变化合并到主规范/opsx:archive功能完成后归档 change扩展流程里还有 6 个命令作用/opsx:new只创建 change 的基础结构/opsx:continue继续补下一类文件比如先有 proposal再补 specs/opsx:ff一次性补齐需要的 OpenSpec 文件/opsx:verify检查实现是否符合specs/、tasks.md、design.md/opsx:bulk-archive批量归档多个 changes/opsx:onboard引导式熟悉 OpenSpec 流程5.2 终端里的openspecCLI你本机 1.3.1 有 19 个顶层命令这些是在 PowerShell / CMD / 终端里敲的不是在 AI 聊天窗口里敲的CLI 命令作用openspec init初始化 OpenSpecopenspec update更新 OpenSpec 指令文件openspec list列出 changes或用--specs列出 specsopenspec view打开交互式视图openspec change管理 change proposalsopenspec archive归档完成的 change并更新主 specsopenspec spec管理和查看 specsopenspec config查看或修改全局配置openspec schema管理流程结构定义属于高级配置openspec validate校验 changes 或 specsopenspec show查看某个 change 或 specopenspec feedback提交反馈openspec completion管理 shell 自动补全openspec status查看某个 change 的文件完成状态openspec instructions输出创建文件或执行任务所需的指令openspec templates查看模板路径openspec schemas列出可用流程结构定义属于高级配置openspec new创建新项目openspec help查看帮助你日常不需要背 19 个。常用的是openspec list openspec show name openspec validate name --strict openspec archive name6. 默认组合Superpowers 主导OpenSpec 记录这是最适合你现在的方式。适合个人开发 从 0 到 1 需求还会变化 不想一开始就进入重流程6.1 分工工具负责什么不负责什么Superpowers澄清需求、写计划、执行计划、TDD、完成前验证不负责长期规范归档OpenSpec记录重要 change最后归档不执行/opsx:apply关键规则Superpowers 主导时不要用 /opsx:apply。 因为 Superpowers 的 executing-plans 已经在负责执行。6.2 流程图标记说明SP Superpowers skill OS OpenSpec /opsx 命令否是否是SP: brainstorming 梳理需求这次是否值得长期记录SP: writing-plans 写开发计划OS: /opsx:propose 创建 changeOpenSpec 生成 proposal/specs/design/tasksSP: executing-plans 按计划实现SP: test-driven-development 覆盖核心逻辑SP: verification-before-completion 跑验证是否创建过 OpenSpec change结束OS: /opsx:archive 归档 change6.3 例子做登录功能你可以这样对 AI 说我要做登录功能。 这次以 Superpowers-lite 为主流程。 先用 brainstorming 帮我澄清需求。 登录会影响长期业务规则所以用 /opsx:propose add-login 记录一条 OpenSpec change。 OpenSpec 只负责生成和维护 proposal/specs/design/tasks。 开发计划用 writing-plans 来写。 实现用 executing-plans 来做。 核心认证逻辑用 test-driven-development。 完成前用 verification-before-completion 跑测试和构建。 不要用 /opsx:apply。 验证通过后用 /opsx:archive add-login 归档。这套方式里只有一个开发主线开发听 Superpowers 的。 OpenSpec 只留下重要需求变化的记录。7. 严格组合OpenSpec 主导Superpowers 辅助如果你想让需求、设计、任务全部先落成文件再按文件执行就让 OpenSpec 主导。适合需求比较确定 功能影响面大 你想先写 proposal/specs/design/tasks 你愿意接受更强流程7.1 分工工具负责什么不负责什么OpenSpec创建proposal.md、specs/、design.md、tasks.md并用/opsx:apply推进实现不只是记录SuperpowersTDD 和完成前验证不再写第二套计划关键规则OpenSpec 主导时不要再用 writing-plans / executing-plans。 因为 OpenSpec 已经有 design.md、tasks.md 和 /opsx:apply。7.2 流程图标记说明OS OpenSpec /opsx 命令 SP Superpowers skillOS: /opsx:propose 创建 changeOpenSpec 生成 proposal/specs/design/tasksOS: /opsx:apply 按 tasks.md 实现SP: test-driven-development 补强核心逻辑测试SP: verification-before-completion 跑真实验证OS: /opsx:verify 检查实现是否符合 specs/tasks/designOS: /opsx:archive 归档 change7.3 例子做会员计费模块你可以这样对 AI 说我要做会员计费模块。 这次以 OpenSpec 为主流程。 请用 /opsx:propose add-membership-billing 生成 proposal/specs/design/tasks。 然后用 /opsx:apply 按 tasks.md 实现。 核心计费规则用 test-driven-development 辅助。 完成前用 verification-before-completion 跑测试和构建。 再用 /opsx:verify 检查实现是否符合 specs/tasks/design。 最后用 /opsx:archive add-membership-billing 归档。 不要再用 Superpowers writing-plans / executing-plans 写第二套计划。这套方式里也是只有一个开发主线开发听 OpenSpec 的。 Superpowers 只补测试纪律和完成前验证。8. 两者会不会冲突它们不会天然冲突冲突来自你让两边同时做同一件事。最容易重复的是这两组重复点SuperpowersOpenSpec怎么避免写计划writing-plansdesign.md、tasks.md只选一个作为主计划执行开发executing-plans/opsx:apply只选一个作为主执行所以核心规则不是“谁更强”而是一件事只选一个主流程。 另一个只能辅助不要抢主流程。9. 最短口诀小改动只用 Superpowers。 大功能但你想轻一点 Superpowers 主导OpenSpec 记录。 大功能而且你想严格按规范推进 OpenSpec 主导Superpowers 辅助。 永远不要 Superpowers 和 OpenSpec 同时各写一套计划、各执行一遍开发。
Superpowers 与 OpenSpec 使用指导手册
Superpowers 与 OpenSpec 使用指导手册Superpowers-lite 与 OpenSpec 通俗使用手册1. 先按你的真实开发方式理解2. 平时先用 Superpowers 的 5 个核心 skills2.1 Superpowers 全量 skills 有 14 个2.2 Superpowers 的命令和 skills 不是一回事3. 做到什么程度才需要 OpenSpec4. OpenSpec 第一次介入时会生成什么5. OpenSpec 命令为什么有 11 个和 19 个两种说法5.1 AI 聊天窗口里的 /opsx 命令11 个5.2 终端里的 openspec CLI你本机 1.3.1 有 19 个顶层命令6. 默认组合Superpowers 主导OpenSpec 记录6.1 分工6.2 流程图6.3 例子做登录功能7. 严格组合OpenSpec 主导Superpowers 辅助7.1 分工7.2 流程图7.3 例子做会员计费模块8. 两者会不会冲突9. 最短口诀Superpowers-lite 与 OpenSpec 通俗使用手册目标让你知道什么时候用 Superpowers什么时候拉 OpenSpec 进来以及两者一起用时怎么不打架。1. 先按你的真实开发方式理解你从 0 到 1 做东西时默认不要把流程搞重。最顺的方式是先让 Superpowers 管开发过程。 只有遇到值得长期记录的大功能再让 OpenSpec 介入做记录。也就是说平时你只需要记住一句话Superpowers 负责“怎么把代码做出来”。 OpenSpec 负责“哪些需求变化要留下规范记录”。后面所有命令和流程都围绕这句话展开。2. 平时先用 Superpowers 的 5 个核心 skillsSuperpowers 本质上是一组给 AI 用的 skills。它不是要求你每一步都手动敲命令而是让 AI 在合适的时候按这些 skills 工作。你当前最适合默认启用这 5 个顺序Skill什么时候用解决什么问题1brainstorming你只有一个想法还没讲清楚把需求、边界、取舍问清楚2writing-plans需求已经清楚准备开发前把需求拆成可执行计划3executing-plans已经有计划开始改代码按计划一步步实现4test-driven-development有核心逻辑、规则、算法、接口行为先写测试再写实现避免拍脑袋5verification-before-completion准备说“完成了”之前跑测试、构建、检查避免假完成这 5 个已经能覆盖个人开发最常见的完整闭环想法 - 需求 - 计划 - 实现 - 测试 - 验证2.1 Superpowers 全量 skills 有 14 个你不用一开始全装全用但要知道完整 Superpowers 里还有哪些能力分组Skills需求与计划brainstorming、writing-plans、executing-plans测试与验证test-driven-development、verification-before-completion调试systematic-debuggingGit / 分支using-git-worktrees、finishing-a-development-branch子代理 / 并行subagent-driven-development、dispatching-parallel-agentsReviewrequesting-code-review、receiving-code-review元能力using-superpowers、writing-skills为什么你现在不需要默认全用worktree、分支收尾、子代理、代码 review 更适合团队协作或大型任务。 你个人从 0 到 1 开发先用 5 个核心 skills 更轻。2.2 Superpowers 的命令和 skills 不是一回事你本机 Superpowers 仓库里能看到 3 个命令包装器命令包装器对应 skill作用brainstormbrainstorming显式进入需求澄清write-planwriting-plans显式要求写开发计划execute-planexecuting-plans显式要求按计划执行这里要分清楚skills 是 AI 的工作规则。 命令包装器是手动点名某个 skill 的入口。所以你不一定每次都要手动敲命令。你也可以直接对 AI 说用 Superpowers brainstorming 先帮我把这个功能需求梳理清楚。3. 做到什么程度才需要 OpenSpec如果只是改一个按钮、修一个小 bug、调一个样式不需要 OpenSpec。当你做到这类事情时再让 OpenSpec 介入场景是否建议用 OpenSpec原因登录、权限、计费、订单、数据模型建议会影响长期业务规则API 行为、数据库结构、核心流程建议后面别人或未来的你需要查依据一次性小改动、文案、样式微调不建议记录成本大于收益OpenSpec 介入时不是先让它开发而是先创建一条change。这里的change可以理解成一次值得记录的需求变化。 比如 add-login 就是一条“新增登录功能”的 change。4. OpenSpec 第一次介入时会生成什么当你在 AI 聊天窗口里说/opsx:propose add-loginOpenSpec 会围绕add-login这条 change 生成几类文件文件 / 目录作用你该怎么看proposal.md写为什么做、改什么、影响什么这是变更说明specs/写需求、行为规则、场景这是功能应该满足的规则design.md写技术方案、关键决策、风险取舍这是实现思路tasks.md写实现任务清单这是 OpenSpec 后续执行的依据这几个文件的关系很简单proposal.md 说明为什么做。 specs/ 说明做成什么样。 design.md 说明怎么做。 tasks.md 说明按什么步骤做。所以 OpenSpec 不只是“备忘录”。它也可以按tasks.md推进开发。问题在于如果你已经让 Superpowers 写计划并执行就不要再让 OpenSpec 同时执行第二套计划。5. OpenSpec 命令为什么有 11 个和 19 个两种说法这里不是冲突是入口不同。/opsx:* 是 AI 聊天窗口里的命令。 openspec 是终端 / PowerShell / CMD 里的 CLI 命令。5.1 AI 聊天窗口里的/opsx命令11 个日常最常用的是这 5 个命令作用/opsx:propose创建 change并生成proposal.md、specs/、design.md、tasks.md/opsx:explore先探索想法不急着创建 change/opsx:apply按tasks.md推进实现/opsx:sync把 change 里的specs/变化合并到主规范/opsx:archive功能完成后归档 change扩展流程里还有 6 个命令作用/opsx:new只创建 change 的基础结构/opsx:continue继续补下一类文件比如先有 proposal再补 specs/opsx:ff一次性补齐需要的 OpenSpec 文件/opsx:verify检查实现是否符合specs/、tasks.md、design.md/opsx:bulk-archive批量归档多个 changes/opsx:onboard引导式熟悉 OpenSpec 流程5.2 终端里的openspecCLI你本机 1.3.1 有 19 个顶层命令这些是在 PowerShell / CMD / 终端里敲的不是在 AI 聊天窗口里敲的CLI 命令作用openspec init初始化 OpenSpecopenspec update更新 OpenSpec 指令文件openspec list列出 changes或用--specs列出 specsopenspec view打开交互式视图openspec change管理 change proposalsopenspec archive归档完成的 change并更新主 specsopenspec spec管理和查看 specsopenspec config查看或修改全局配置openspec schema管理流程结构定义属于高级配置openspec validate校验 changes 或 specsopenspec show查看某个 change 或 specopenspec feedback提交反馈openspec completion管理 shell 自动补全openspec status查看某个 change 的文件完成状态openspec instructions输出创建文件或执行任务所需的指令openspec templates查看模板路径openspec schemas列出可用流程结构定义属于高级配置openspec new创建新项目openspec help查看帮助你日常不需要背 19 个。常用的是openspec list openspec show name openspec validate name --strict openspec archive name6. 默认组合Superpowers 主导OpenSpec 记录这是最适合你现在的方式。适合个人开发 从 0 到 1 需求还会变化 不想一开始就进入重流程6.1 分工工具负责什么不负责什么Superpowers澄清需求、写计划、执行计划、TDD、完成前验证不负责长期规范归档OpenSpec记录重要 change最后归档不执行/opsx:apply关键规则Superpowers 主导时不要用 /opsx:apply。 因为 Superpowers 的 executing-plans 已经在负责执行。6.2 流程图标记说明SP Superpowers skill OS OpenSpec /opsx 命令否是否是SP: brainstorming 梳理需求这次是否值得长期记录SP: writing-plans 写开发计划OS: /opsx:propose 创建 changeOpenSpec 生成 proposal/specs/design/tasksSP: executing-plans 按计划实现SP: test-driven-development 覆盖核心逻辑SP: verification-before-completion 跑验证是否创建过 OpenSpec change结束OS: /opsx:archive 归档 change6.3 例子做登录功能你可以这样对 AI 说我要做登录功能。 这次以 Superpowers-lite 为主流程。 先用 brainstorming 帮我澄清需求。 登录会影响长期业务规则所以用 /opsx:propose add-login 记录一条 OpenSpec change。 OpenSpec 只负责生成和维护 proposal/specs/design/tasks。 开发计划用 writing-plans 来写。 实现用 executing-plans 来做。 核心认证逻辑用 test-driven-development。 完成前用 verification-before-completion 跑测试和构建。 不要用 /opsx:apply。 验证通过后用 /opsx:archive add-login 归档。这套方式里只有一个开发主线开发听 Superpowers 的。 OpenSpec 只留下重要需求变化的记录。7. 严格组合OpenSpec 主导Superpowers 辅助如果你想让需求、设计、任务全部先落成文件再按文件执行就让 OpenSpec 主导。适合需求比较确定 功能影响面大 你想先写 proposal/specs/design/tasks 你愿意接受更强流程7.1 分工工具负责什么不负责什么OpenSpec创建proposal.md、specs/、design.md、tasks.md并用/opsx:apply推进实现不只是记录SuperpowersTDD 和完成前验证不再写第二套计划关键规则OpenSpec 主导时不要再用 writing-plans / executing-plans。 因为 OpenSpec 已经有 design.md、tasks.md 和 /opsx:apply。7.2 流程图标记说明OS OpenSpec /opsx 命令 SP Superpowers skillOS: /opsx:propose 创建 changeOpenSpec 生成 proposal/specs/design/tasksOS: /opsx:apply 按 tasks.md 实现SP: test-driven-development 补强核心逻辑测试SP: verification-before-completion 跑真实验证OS: /opsx:verify 检查实现是否符合 specs/tasks/designOS: /opsx:archive 归档 change7.3 例子做会员计费模块你可以这样对 AI 说我要做会员计费模块。 这次以 OpenSpec 为主流程。 请用 /opsx:propose add-membership-billing 生成 proposal/specs/design/tasks。 然后用 /opsx:apply 按 tasks.md 实现。 核心计费规则用 test-driven-development 辅助。 完成前用 verification-before-completion 跑测试和构建。 再用 /opsx:verify 检查实现是否符合 specs/tasks/design。 最后用 /opsx:archive add-membership-billing 归档。 不要再用 Superpowers writing-plans / executing-plans 写第二套计划。这套方式里也是只有一个开发主线开发听 OpenSpec 的。 Superpowers 只补测试纪律和完成前验证。8. 两者会不会冲突它们不会天然冲突冲突来自你让两边同时做同一件事。最容易重复的是这两组重复点SuperpowersOpenSpec怎么避免写计划writing-plansdesign.md、tasks.md只选一个作为主计划执行开发executing-plans/opsx:apply只选一个作为主执行所以核心规则不是“谁更强”而是一件事只选一个主流程。 另一个只能辅助不要抢主流程。9. 最短口诀小改动只用 Superpowers。 大功能但你想轻一点 Superpowers 主导OpenSpec 记录。 大功能而且你想严格按规范推进 OpenSpec 主导Superpowers 辅助。 永远不要 Superpowers 和 OpenSpec 同时各写一套计划、各执行一遍开发。
