# OpenSpec + Superpowers + gstack: A Three-Layer AI-Native Delivery Stack

OpenSpec, Superpowers, and gstack can be combined for clear gains in end-to-end software delivery efficiency and quality — but the recommended approach isn’t to mechanically chain the three pipelines together. Instead, use layered division of labor:

Layer	Primary tool	Core responsibility	Key artifacts
Spec and change-memory layer	OpenSpec	Records why, what, and how system behavior changes	proposal, design, tasks, delta specs
Engineering discipline and execution layer	Superpowers	Keeps agents working through TDD, debugging, verification, review	design confirmation, implementation plan, TDD evidence
Expert-role and delivery closed-loop layer	gstack	Dedicated product/engineering/design/QA/release personas	plan review, QA reports, PR, retro

In one sentence: OpenSpec as source of truth, Superpowers as execution discipline, gstack as specialist gears and shipping harness.

Why Three Layers Are Needed

The four problems most likely to spiral out of control in AI software delivery:

1. Requirement drift — OpenSpec leaves a trail via change proposals and delta specs
2. Long-session context decay — Superpowers splits work using skills, plans, subtasks, and verification gates
3. AI self-assessment being overly optimistic — gstack review/QA and Superpowers verification form an external check
4. Speed without quality — together, the three expand “code generation” into a spec → implementation → verification → release → retro closed loop

Where Each Layer Sits

OpenSpec — The Truth Layer

A brownfield-first, spec-driven change system. Command path:

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

openspec/specs/ records the current behavior of the system; openspec/changes/ records each active change. Well suited to owning the durable context in the combination — not a one-off plan, but a memory of system behavior that agents read and update before every change.

Superpowers — The Execution Governance Layer

Composable skills: brainstorming, writing-plans, test-driven-development, systematic-debugging, verification-before-completion, requesting-code-review, subagent-driven-development, and more.

It makes explicit the discipline a senior engineer would naturally follow: clarify before implementing, write a plan before executing, TDD and systematic debugging, verify before completion, parallelize with subagents.

gstack — The Expert Review and Release Layer

Explicit gears on top of Claude Code: /plan-eng-review, /plan-design-review, /qa, /ship, /retro, and more. It avoids having a single agent blend product, design, engineering, QA, and release cognitive modes; each workspace has independent browser state, making parallel browser testing easy.

Priority of Responsibility (Avoiding Conflicts)

If all three tools try to drive the entire workflow, you’ll get duplicate plans, duplicate reviews, and conflicting instructions. You must define who has final say:

1. OpenSpec is authoritative for spec truth — requirements, acceptance criteria, and behavior changes are written into openspec/changes/<change>/, then synced back to openspec/specs/ once complete
2. Superpowers is authoritative for execution discipline — writing code, changing tests, debugging, and completion declarations all follow its TDD, verification, and review skills
3. gstack is authoritative for expert review and release — product/design plan review, browser QA, release, retro

OpenSpec doesn’t own all engineering discipline; Superpowers doesn’t replace a long-lived spec repository; gstack doesn’t replace the source of truth for system behavior.

Recommended Workflow

0. AGENTS.md tool routing rules
   ↓
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

Suggested Directory Structure

repo/
├── openspec/           # business capabilities, system behavior, change history
├── docs/superpowers/   # user-confirmed design and implementation plans
├── .gstack/            # QA reports, browser state
├── AGENTS.md           # routing rules only, no duplicated tool documentation
└── src/

AGENTS.md Routing Example

## 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.

Quality Comes from Multiple Independent Checks

Check dimension	Owner
Requirement quality	OpenSpec proposal + delta specs (why/what/scenarios)
Design quality	gstack product/design/engineering review
Code quality	Superpowers TDD + systematic debugging + code review
Runtime quality	gstack /qa + Superpowers verification-before-completion
Organizational quality	OpenSpec /sync + /archive feeding into the long-term knowledge base

Relationship to Review Pipeline: Review Pipeline defines “how to review once AI has written 80% of the code”; this stack provides the actionable tool division of labor to realize spec-conformance acceptance and runtime evidence closure.

Risks and Mitigations

Risk	Mitigation
Process too heavy	Enable the full chain only for medium/high-risk changes; small changes take a lightweight path
Conflicting instructions	AGENTS.md spells out priority of responsibility
Duplicate artifacts	OpenSpec change id as the primary index; other files cross-reference it
OpenSpec not synced	Include /opsx:sync and /opsx:archive in the definition of done
Verification false positives	Superpowers completion gate + gstack QA + CI must all pass together

Minimum Viable Combination (2–4 Week Pilot)

Enable only:

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

Metrics: requirement clarification rounds, PR lead time, review defect count, test-failure fix rounds, pre/post-release defect count.

Full Delivery Chain

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

This is exactly the watershed between “AI helping an individual write code” and “AI elevating the end-to-end software delivery system.” See SDD Tools Comparison for background on SDD tool selection.

References

• OpenSpec
• Superpowers
• gstack