Superpowers结合OpenSpec工作流
摘要：superpowers与openspec结合使用：superpowers负责流程化任务与子代理驱动开发，openspec负责沉淀核心规格。两者衔接点包括：头脑风暴澄清需求、明确规格、计划编写、完成度验证及规格归档，从而实现高效开发。
superpowers和openspec都是优秀的AI编程框架，但各有侧重，本文主要阐述如何结合使用。
- superpowers 侧重于让AI按照既定的流程完成任务，有TDD、子代理驱动开发等重量级特性
- openspec 则是SDD优秀框架，能更好地沉淀项目的核心规格，用文档承载规格。
头脑风暴
核心指令：/superpowers:brainstorming
新作需求，第一步是完成需求的澄清、边界对齐，在这一步，使用superpowers的头脑风暴能力。 在这一步，需要大致描述自己的新特性/修改，然后让AI帮我们理清思路，完成对新需求的设计。 比如：
/superpowers:brainstorming 我需要完成一个xxx需求，有xxx功能。
产物：superpowers/spec/日期-xxxxx-design.md设计文件。
需要仔细阅读设计文件，有问题在这一步及时澄清并修正，避免后续滚雪球般越走越偏。
明确规格
核心指令：/opsx:new <change-name>和/opsx:ff
完成头脑风暴后，在同一个session会话里，完成设计文件的规则明确，这是superpowers与openspec的第一个衔接点。 （在同一会话时，AI能自动读取上一步输出的设计文件，如果新会话则需要手动引用）
- 创建一个变更，这一步会由openspec帮我们自动创建一个空骨架，待后续完成
- 基于上一步头脑风暴输出的设计，一键补齐规格文件。（使状态追平到与
/opsx:propose相同的完成度）
示例：
/opsx:new new-feature-name
/opsx:ff 基于之前输出的设计文件，完成规格设计
产物：proposal.md、specs/、design.md、tasks.md。
与上一步同理，需要阅读规格文件，如果有问题及时澄清修正。
计划编写
核心指令：/superpowers:writing-plans
这是superpowers与openspec的第二个衔接点。 基于之前的设计与规格，完成接下来的所有编码计划。superpowers会帮我们拆分任务，保证每个子任务的耗时控制在小范围内。 （一样在同一会话里，或新开会话把之前的规格文件指定进去）
示例：
/superpowers:writing-plans 基于之前的需求设计与规格文件，完成实现计划编写
产物：superpowers/plans/日期-xxxxx.md计划文件。
这个是一个详细的实现计划，里面包含了很多细节，粗略看下方向不要跑偏（因为太细了，看完费老事了）
实施开发
核心指令：/superpowers:subagent-driven-development
这一步，就是使用了superpowers的强大执行能力，让他把我们之前编写的计划用子代理驱动开发的模式高效地完成。
因为与之前步骤可能会读取大量的无关文件和理解代码结构，会占用很多的上下文大小，而上一步的实施计划已经含有大量的实现细节了。
所以个人建议是新开一个session（或/clear）来重置上下文窗口，然后让agent帮我们实现计划。
示例：
/superpowers:subagent-driven-development 基于计划文件 @superpowers/spec/日期-xxxxx-design.md 完成代码编写
实现完成后，正常地进行测试验证，有问题直接提给AI，直到修复为止。 也可以通过一条条验证openspec生成的spec文件中的假设场景来帮我们覆盖场景。 （需要注意，完成编写后上下文通常都不多了，需要注意压缩。）
完成度验证
核心指令：/opsx:verify
这是superpowers与openspec的第三个衔接点。 当AI完成代码后，验证无问题后，我们通过openspec验证规格是否都通过，并输出验证报告。 报告不会阻塞后面流程，但如果觉得是问题，则可以让AI进一步修改。
因为之前superpowers是基于plan文件来开发的，所以对openspec编写的tasks.md计划文件不会去修改。 我们需要让其验证后帮我们勾选任务清单。
示例：
/opsx:verify 我已完成验证，帮我检查实现是否有遗漏。如果未遗漏，帮我勾选tasks.md清单。
规格归档
核心指令：/opsx:archive或/opsx:bulk-archive
- 如果是同时开发多个需求，可以在多个特性分支回合主分支后，在主分支完成一次批量归档，避免冲突。
- 如果只是开发一个特性，则可以在特性完成后，马上进行归档，然后再回合主分支。
在这一步，openspec会帮我们归档changes文件夹，并把规格同步到主spec中。 正是这一步，才会让项目在开发过程中“长”出规格文件。
收尾
通常，完成一个需求合入代码，我会依次压缩、rebase、合入，依次保证git历史的干净。
- 把这个分支上的开发过程commit压缩合并成一个commit，由AI自动总结。
- rebase到master（如果是工作树模式，则需要rebase到origin/master）。
- fast-forward合入。
- 检查没问题后推送远端。
示例：
帮我把自master以后的commit压缩成一个，然后rebase on master后fast-forward合入master