# OpenSpec + Superpowers + gstack：三层 AI 原生交付栈

OpenSpec、Superpowers、gstack 可以组合使用，对端到端软件开发效率和质量有明确价值——但推荐方式不是把三套流程机械串联，而是 分层分工：

层级	主工具	核心职责	关键产物
规格与变更记忆层	OpenSpec	记录为什么做、做什么、系统行为如何变化	proposal、design、tasks、delta specs
工程纪律与执行层	Superpowers	约束 agent 按 TDD、调试、验证、评审流程工作	设计确认、实施计划、TDD 证据
专家角色与交付闭环层	gstack	产品/工程/设计/QA/发布专门模式	plan review、QA 报告、PR、retro

一句话：OpenSpec 作为 source of truth，Superpowers 作为 execution discipline，gstack 作为 specialist gears and shipping harness。

为什么需要三层

AI 软件交付中最容易失控的四个问题：

1. 需求漂移 — OpenSpec 用变更提案和 delta specs 留痕
2. 长会话上下文衰减 — Superpowers 用技能、计划、子任务和验证门禁切分工作
3. AI 自评过度乐观 — gstack review/QA 与 Superpowers verification 形成外部检查
4. 只提速不提质 — 三者共同把「生成代码」扩展为规格→实现→验证→发布→复盘闭环

各层定位

OpenSpec — 事实层

Brownfield-first 的规格驱动变更系统。命令路径：

/opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive

openspec/specs/ 记录系统当前行为；openspec/changes/ 记录每个活跃变更。适合承担组合中的 durable context——不是一次性计划，而是 agent 每次变更前读取和更新的系统行为记忆。

Superpowers — 执行治理层

可组合技能：brainstorming、writing-plans、test-driven-development、systematic-debugging、verification-before-completion、requesting-code-review、subagent-driven-development 等。

把资深工程师会自然执行的纪律显性化：先澄清再实现、写计划再执行、TDD 与系统化调试、完成前验证、子代理并行。

gstack — 专家审查与发布层

Claude Code 上的显式 gears：/plan-eng-review、/plan-design-review、/qa、/ship、/retro 等。不让同一个 agent 混合产品、设计、工程、QA、发布认知模式；每个 workspace 有独立浏览器状态，便于并行浏览器测试。

职责优先级（避免冲突）

如果三个工具都尝试主导完整工作流，会出现重复计划、重复 review、指令冲突。必须定义 谁拥有最终解释权：

1. 规格真相以 OpenSpec 为准 — 需求、验收标准、行为变化写入 openspec/changes/<change>/，完成后 sync 回 openspec/specs/
2. 执行纪律以 Superpowers 为准 — 写代码、改测试、调试、完成声明时遵循其 TDD、验证、评审技能
3. 专家审查与发布以 gstack 为准 — 产品/设计 plan review、浏览器 QA、发布、复盘

OpenSpec 不负责定义所有工程纪律；Superpowers 不替代长期规格库；gstack 不替代系统行为 source of truth。

推荐工作流

0. AGENTS.md 工具路由规则
   ↓
1. OpenSpec：/opsx:propose <change>
   ↓
2. Superpowers：brainstorming / writing-plans
   ↓
3. gstack：/plan-eng-review /plan-design-review
   ↓
4. Superpowers：TDD / systematic-debugging / subagent-driven-development
   ↓
5. gstack：/qa /review
   ↓
6. OpenSpec：/opsx:sync
   ↓
7. gstack：/ship
   ↓
8. OpenSpec：/opsx:archive + gstack：/retro

目录结构建议

repo/
├── openspec/           # 业务能力、系统行为、变更历史
├── docs/superpowers/   # 用户确认的设计与实施计划
├── .gstack/            # QA 报告、浏览器状态
├── AGENTS.md           # 只写路由规则，不重复大段工具说明
└── src/

AGENTS.md 路由示例

## Tool Routing

- OpenSpec is the source of truth for feature intent and behavior changes.
- Superpowers governs implementation: planning, TDD, debugging, verification.
- gstack is used for specialist reviews, browser QA, shipping, retros.
- Do not create parallel task lists unless they cross-reference the active OpenSpec change id.

质量来自多重独立检查

检查维度	承担者
需求质量	OpenSpec proposal + delta specs（why/what/scenarios）
设计质量	gstack product/design/engineering review
代码质量	Superpowers TDD + systematic debugging + code review
运行质量	gstack /qa + Superpowers verification-before-completion
组织质量	OpenSpec /sync + /archive 进入长期知识库

与 Review Pipeline 的关系：Review Pipeline 定义「AI 写了 80% 代码后如何评审」；本栈提供 可操作的工具分工 来实现规格对照验收与运行证据收口。

风险与应对

风险	应对
流程过重	仅对中高风险变更启用完整链路；小改走轻量路径
指令冲突	AGENTS.md 写清职责优先级
重复 artifact	OpenSpec change id 作为主索引，其他文件 cross-reference
OpenSpec 未 sync	将 /opsx:sync 和 /opsx:archive 纳入完成定义
验证假阳性	Superpowers completion gate + gstack QA + CI 共同通过

最小可行组合（2–4 周试点）

只启用：

• OpenSpec：propose、sync、archive
• Superpowers：planning、TDD、debugging、verification-before-completion、code review
• gstack：/plan-eng-review、/qa、/ship

度量：需求澄清轮次、PR lead time、review 缺陷数、测试失败修复轮次、发布前后缺陷数。

完整交付链路

Intent → Spec → Plan → TDD Build → Review → Runtime QA → Ship → Sync Specs → Retro

这正是从「AI 帮个人写代码」走向「AI 提升端到端软件交付系统」的分水岭。SDD 工具选型背景见 SDD 工具横向对比。

参考

• OpenSpec
• Superpowers
• gstack