这份文档讲的是 OpenCode + superpowers 怎么更顺手地用。
相比 Cline，OpenCode 可以更自然地配合自己的 plan / build agent 使用。
- 简单说：这里优先借
OpenCode自己已经有的能力来承接superpowers的 workflow。 - 这句话的意思是：上游
superpowers虽然是按Claude Code写的，但到了OpenCode这里，我们优先借OpenCode自己已经有的skill、plan、build这些能力来承接。 - 为什么这样：如果
OpenCode自己已经有更顺手、更贴近本地使用习惯的实现，就没必要硬照抄上游那套工具名和动作名。 - 所以在
OpenCode里，重点是保留上游 workflow 的意图，例如“先分析、再计划、再实现、再验证”，而不是强迫它模仿Claude Code的字面写法。 - 并行和分阶段推进也能做，但仍建议把最后整合、验收和收尾放主线程。
OpenCode的plan/build能力适合阶段拆分，但不要把最终整合和验收完全交出去。- 文档型输出默认已经偏向中文；如果你特别在意，可以显式补一句“计划和结论用中文”。
- 代码、命令、路径、日志和接口名仍然建议保持原文。
- 写计划时不用固定写到某个目录；你如果指定了保存位置就按你的要求来，没指定时再沿用仓库现有文档习惯。
例如：
- “先做需求分析和总体设计”
- “把这个任务拆成几个工作面并行推进”
- “先跑完验证再说完成”
默认安装名带前缀 superpowers-，所以建议写完整名字：
superpowers-writing-planssuperpowers-dispatching-parallel-agentssuperpowers-finishing-a-development-branch
也优先写完整名字：
/superpowers-writing-plans/superpowers-finishing-a-development-branch
OpenCode有自己的plan/build能力，适合阶段拆分- 但最终整合、验收和收尾，仍建议放在主线程
你可以把它理解成：
- 这里不是“降级”，而是优先用
OpenCode自己更好的替代实现 superpowers负责告诉它该走什么 workflowOpenCode自己的原生能力负责承接规划和实现动作
flowchart LR
A["需求分析 / 方案讨论<br/>brainstorming"] --> B["实施计划<br/>writing-plans"]
B --> C["按计划推进<br/>executing-plans / subagent-driven-development"]
C --> D["代码评审<br/>requesting-code-review"]
D --> E["收尾前验证<br/>verification-before-completion"]
E --> F["开发分支收尾<br/>finishing-a-development-branch"]
这件事按 superpowers 工作流来。你先判断当前阶段该用哪些 skill，再结合 OpenCode 自己的 plan / build 能力推进。
这个需求先不要直接实现。先做需求澄清、方案对比和边界讨论，结论用中文输出；如果方案收敛了，再继续拆实施计划。
方向已经确定，直接把它拆成实施计划。保存位置如果我指定了就按我指定的来；没指定时按仓库现有文档习惯放，并明确告诉我计划文件是哪一份。步骤要具体到改哪些文件、怎么验证，中文输出。
按刚写好的那份计划继续实现，不要重新从 TODO 或任务清单改选范围。能拆成独立工作面的部分再分阶段推进，但最后由主线程统一整合和验证。
把这个任务拆成几个互不冲突的工作面并行推进：接口、数据层、测试补充。每一块都要汇报改动文件、验证结果和剩余风险。
这个问题先系统排查，不要先猜修复。先确认复现条件、缩小范围、收集证据，再决定怎么改。
这个问题按 TDD 修。先写失败测试，确认失败后再做最小修复，最后再看是否需要重构。
这批改动先做一次严格代码审查，重点看行为回归、边界条件、缺失测试和计划偏差，结论用中文。
先别说完成。先把验证清单跑完，把通过项、失败项和剩余风险分开写清楚，再决定是否可以收尾。