Enterprise Workflow: Superpowers + OpenSpec Three‑Stage Process for Deliverable Results

Root problems addressed

Two recurring issues in enterprise projects cause rework and delays: unclear requirements and inconsistent specifications . The combined Superpowers + OpenSpec workflow tackles both by separating exploratory design from immutable specification.

When to apply the full three‑stage process

Adding a new interface or business capability

Modifying core business behavior

Changing permissions, audit, transaction, or data‑consistency logic

Cross‑module refactoring

Features that require thorough testing, acceptance, and traceability

When the full process is unnecessary

Simple Q&A content tweaks

Spelling corrections

Document formatting adjustments

Minor documentation updates that do not affect business logic

Overall execution flow (eight steps)

Business or product side submits a requirement.

Superpowers performs exploratory planning.

Team confirms the design direction.

OpenSpec locks the specification.

Team confirms proposal, design, spec, and tasks.

Superpowers executes coding, testing, and verification.

Team validates the results.

OpenSpec archives the completed change.

Four‑step detailed process

1. Superpowers – Exploratory Planning

Goal: turn vague requirements into a shared design direction. No code or spec is written at this stage.

Fully understand project context.

Define goals, boundaries, and out‑of‑scope items.

Clarify inputs, outputs, exception scenarios, and acceptance criteria.

Produce 2‑3 feasible solutions and compare pros and cons.

Recommend the best solution with justification.

Identify risks early and outline a testing approach.

Deliver a simple, easy‑to‑read design draft.

Proceed only after the whole team confirms the direction.

Recommended artifact structure:

<Feature Name> Exploration Design

## Background
## Goal
## Non‑Goal
## Requirement Boundary
## Solution Options
## Recommended Solution
## Risks & Trade‑offs
## Test Strategy
## Open Questions

2. OpenSpec – Locking the Specification

After design confirmation, OpenSpec creates immutable, executable documentation.

Create a change entry: openspec new change "<change-name>" Write a proposal explaining why the change is needed, what it does, and its impact.

Write a design describing the technical solution, alternatives, risks, and test strategy.

Write a spec that defines formal requirements and acceptance scenarios.

Write tasks that break the work into executable items.

Ensure all documents are complete before moving to coding.

Common OpenSpec commands:

openspec new change "<change-name>"
openspec status --change "<change-name>" --json
openspec instructions proposal --change "<change-name>" --json
openspec instructions design --change "<change-name>" --json
openspec instructions specs --change "<change-name>" --json
openspec instructions tasks --change "<change-name>" --json

Recommended file layout:

openspec/changes/<change-name>/proposal.md
openspec/changes/<change-name>/design.md
openspec/changes/<change-name>/specs/<capability>/spec.md
openspec/changes/<change-name>/tasks.md

3. Superpowers – Execution, Testing, Verification

With the spec locked, Superpowers switches to controlled execution.

Read the confirmed OpenSpec documents and task list carefully.

Write a clear implementation plan.

Develop in an isolated worktree to avoid affecting the main branch.

Follow TDD: write tests first, then code in small increments.

Run real verification commands after implementation.

Ensure all tasks are finished and code matches the spec.

Proceed to archiving only after successful verification.

Implementation‑plan template:

<Feature Name> Implementation Plan

Goal
Corresponding OpenSpec Change
Implementation Scope
Out‑of‑Scope
File Change Plan
Test Plan
Execution Steps

Worktree creation example:

git worktree add .worktrees/<change-name> -b codex/<change-name>

Typical verification commands (choose the one matching the stack):

mvn test
npm test
pnpm test
pytest
go test ./...
cargo test

4. OpenSpec – Archiving

The final step turns the completed change from “in‑progress” to a formal, archived specification.

All specification documents must be complete.

All tasks must be finished.

Tests must cover critical scenarios and pass.

Code implementation must exactly match the spec.

After verification, execute the archive command.

Archive command:

openspec archive "<change-name>"

Gate checks (must pass before advancing)

Design not confirmed → do not enter OpenSpec stage.

Spec documents incomplete → do not enter coding stage.

No real test results → cannot claim feature complete.

Code, tests, and spec mismatch → cannot archive.

Enterprise directory layout

openspec/
  changes/
  docs/
  superpowers/
    specs/
    plans/

Four‑week rollout roadmap

Week 1 – Pilot

Select a medium‑complexity requirement and run the full three‑stage process.

Week 2 – Template creation

Document templates for exploratory design, OpenSpec artifacts, implementation plans, and review checklists.

Week 3 – Integrate into team standards

Incorporate the rules into AGENTS.md, CONTRIBUTING.md, or PR templates.

Week 4 – Promotion

Enforce the process on non‑trivial features, collect feedback, and streamline as needed.

Reference implementation of the combined workflow is available at:

https://github.com/SYZ-Coder/superpowers-openspec-team-skills