superpowers-openspec-superpowers-workflow

name	superpowers-openspec-superpowers-workflow
description	Use when the user explicitly wants this workflow, wants Superpowers exploration before OpenSpec artifacts, or is confirming or continuing tasks that this workflow already generated.

Superpowers -> OpenSpec -> Superpowers Workflow

Overview

Use this skill when the team wants a delivery path that feels calm, deliberate, and hard to derail:

1. Explore with Superpowers
2. Lock the change with OpenSpec
3. Return to Superpowers for implementation, testing, and verification
4. Archive the completed OpenSpec change

This skill is an orchestrator. It should delegate detail work to the existing workflow skills instead of duplicating them.

This is an explicit opt-in workflow. Do not use it by default. Only use it when the user explicitly asks for this workflow, names this skill, or a repository policy explicitly requires it.

If .superpowers-memory/ exists in the repository, read PROJECT_CONTEXT.md, CURRENT_STATE.md, DECISIONS.md, KNOWN_FAILURES.md, VERIFICATION_BASELINE.md, TEAM_PREFERENCES.md, USER_PROFILE.md, AGENT_NOTES.md, and the newest session journal entries at the start, then update the relevant files before final archive so the next session can resume with real context.

Required Order

1. Start with $superpowers-feature-workflow. Use it to clarify scope, compare approaches, confirm the solution shape, and capture the design draft.
2. Move to $openspec-feature-workflow. Use it to create the change and complete proposal.md, design.md, specs/.../spec.md, and tasks.md.
3. Present the generated OpenSpec task checklist to the user.
4. By default, wait for explicit confirmation before implementation planning starts.
5. After the user confirms tasks.md, pause once more and ask whether to continue execution development. Accept continue-dev as the primary continuation command.
6. Do not route the confirmed task handoff through OpenSpec apply.
7. If the user chooses execution development, return to $superpowers-feature-workflow. Use it to write the implementation plan, prefer a worktree, execute with TDD, and run fresh verification.
8. After execution development completes, pause again and ask whether to continue code review. Accept continue-review as the primary continuation command.
9. If implementation and specs are aligned after verification, use $openspec-archive-change to archive the completed change. Before that final step, you may pause and ask whether to continue archive. Accept continue-archive as the primary continuation command, or continue to use $openspec-archive-change.
10. If .superpowers-memory/ exists, perform a memory alignment check after verification and archive decisions: ensure durable facts, current state, decisions, failure patterns, and session outcome are reflected in the right files.
11. Prefer scripts/run-superpowers-memory-closeout.ps1 when you want one command to review the checklist, get update suggestions, and optionally run validation after execution or archive work.
12. Use scripts/suggest-superpowers-memory-updates.ps1 if it is still unclear which memory surfaces should be updated after implementation, verification, or archive work.
13. When memory quality matters for the project, run scripts/validate-superpowers-memory.ps1 before the final completion claim.

Decision Gates

• When the user names $superpowers-openspec-superpowers-workflow, this orchestrator controls routing; do not route first to $openspec-feature-workflow, openspec-propose, /opsx:propose, or any OpenSpec proposal skill.
• Mentioning OpenSpec in this workflow name is not permission to start OpenSpec proposal generation.
• Do not invoke $openspec-feature-workflow, openspec-propose, or any OpenSpec artifact-generation step before the Superpowers exploration gate is complete.
• The Superpowers exploration gate is complete only after context review, requirement clarification, approach comparison, user confirmation of the solution shape, and a design draft under docs/superpowers/specs/.
• Do not create implementation code during the exploration stage.
• Do not start coding until required OpenSpec artifacts are complete.
• Do not use OpenSpec apply as the implementation stage for this workflow.
• After OpenSpec tasks.md is complete, stop OpenSpec apply-style execution, summarize the generated tasks, and by default ask the user to confirm the OpenSpec task checklist before the post-task handoff.
• Do not stop after OpenSpec artifacts with a readiness message such as "run apply", "/opsx:apply", or "let me start implementation".
• Do not resume through OpenSpec apply after tasks.md is confirmed; the only allowed next-step prompt is whether to continue execution development.
• After the user confirms tasks.md, pause and ask whether to continue execution development.
• Do not continue directly into Superpowers execution after OpenSpec artifacts until the user has explicitly confirmed the generated tasks.md and chosen execution development as the next step.
• After Superpowers execution and verification complete, ask whether to continue code review.
• If archive is the next step, accept continue-archive, while $openspec-archive-change remains usable.
• Treat OpenSpec tasks as constraints and checklist input for the Superpowers implementation plan, not as permission to stay inside the OpenSpec apply flow.
• Do not claim success until fresh verification output exists.
• Do not archive the change until code, tests, and specs are aligned.
• Do not leave memory out of sync with the final archive decision when .superpowers-memory/ exists.

When to Use

• The user explicitly asks for "explore first, spec second, execute third"
• The user explicitly names $superpowers-openspec-superpowers-workflow
• The user explicitly asks for Superpowers exploration, OpenSpec locking, then Superpowers execution and archive
• The current turn is a follow-up that confirms, revises, or continues tasks.md that this workflow generated earlier in the same request
• A repository policy explicitly requires this workflow

Continuation Gate

• If this workflow already produced OpenSpec artifacts for the current request and the user is now confirming, revising, or continuing the generated tasks.md, keep this workflow active even if the user does not repeat the skill name.
• Treat task edits or confirmation as a continuation turn inside the same orchestrated flow, not as a fresh routing decision.
• After the user confirms the task checklist, keep this workflow active, pause for the explicit execution-development prompt, and do not fall back to OpenSpec apply.
• At that handoff, accept continue-dev as the continuation command.
• If the user chooses execution development, resume at the next incomplete stage by returning to $superpowers-feature-workflow for planning, TDD, and verification.
• After execution development completes, ask whether to continue code review as a separate follow-up step.
• At that later handoff, accept continue-review as the continuation command.
• If archive is the next aligned step, accept continue-archive, while $openspec-archive-change remains valid.
• If the user revises tasks instead of confirming them, update the OpenSpec task summary, confirm the revised checklist state if needed, then continue the same workflow rather than falling back to generic OpenSpec apply guidance.

Deliverables

• Design draft in docs/superpowers/specs/
• OpenSpec artifacts under openspec/changes/<change-name>/
• Implementation plan in docs/superpowers/plans/
• Code, tests, and fresh verification evidence
• Updated Superpowers memory and memory validation evidence when memory is in use
• Optional closeout helper output when the closeout helper was used
• Archived OpenSpec change when the work is complete

Recommended Prompt

Use $superpowers-openspec-superpowers-workflow for this feature: first explore with Superpowers, then lock the change with OpenSpec, then return to Superpowers for implementation, testing, verification, and archive.