OpenSpec + Superpowers 结合使用最佳实践
OpenSpec 负责“规格与治理”（proposal/spec/design/tasks/归档）
Superpowers 负责“执行与工程技能”（brainstorm、plan、TDD、review、finish）

1. 职责分离
OpenSpec 管“要做什么+验收标准”；Superpowers 管“怎么做+怎么保质量”。不要让两个框架都写计划，避免重复与冲突。

2. 单一事实源
需求、约束、验收标准只写在 openspec/changes/* 与 openspec/specs/*。
Superpowers 的执行计划要引用这些文件，不另起一套“平行文档”。

3. 固定节奏（建议）
先 /opsx:propose（必要时补 design/tasks）→ 再让 Superpowers 执行 writing-plans / executing-plans / TDD / code-review → 最后 /opsx:archive。
这样“先对齐再实现”，返工会明显减少。

4. 把规则注入 OpenSpec config
在 openspec/config.yaml 里写技术栈、测试基线、兼容性要求、回滚要求。
这样 Superpowers 在执行时也会间接受到稳定约束（通过 OpenSpec 产物）。

5. 在任务层做映射
OpenSpec tasks.md 的每个任务都对应一个 Superpowers 执行动作（实现、测试、review）。做到“一任务一证据”（测试结果/评审结论）。

6. 把评审门禁前置
每个任务完成后先跑 Superpowers 的 review，再进入下一个任务；不要攒到最后一次性 review。

7. 先小后大
先用一个中小 feature 跑通流程，再推广到多人协作和复杂改动。第一轮重点是把“流程摩擦点”调顺，而不是追求文档完美。