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 跑通流程，再推广到多人协作和复杂改动。第一轮重点是把“流程摩擦点”调顺，而不是追求文档完美。
