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

Use this standalone skill when feature delivery should follow a calm but rigorous sequence:

1. Explore and converge with Superpowers
2. Lock the confirmed behavior and artifacts with OpenSpec
3. Return to Superpowers for implementation, testing, and verification
4. Archive the OpenSpec change when everything is aligned

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

If this workflow already produced tasks.md for the current request and the next user turn confirms, revises, or continues those tasks, keep this workflow active even if the skill name is not repeated.

If .superpowers-memory/ exists in the repository, read it at the start and update it before the session ends.

Workflow

1. Explore the repository context before proposing solutions.
2. Clarify requirements one question at a time until the scope and success criteria are clear.
3. Present 2-3 approaches, recommend one, and wait for approval before implementation work.
4. Write the approved design to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md.
5. Ask the user to confirm the written design before continuing.
6. Only after the confirmed Superpowers design exists, derive or confirm a kebab-case OpenSpec change name.
7. Run openspec status --change "<change-name>" --json to inspect required artifact order.
8. Before writing each artifact, run openspec instructions <artifact> --change "<change-name>" --json.
9. Complete the OpenSpec artifacts in dependency order:
   • proposal.md
   • design.md
   • specs/.../spec.md
   • tasks.md
10. Re-check openspec status --change "<change-name>" --json until all required artifacts are ready.
11. Stop OpenSpec apply-style execution.
12. Summarize the generated OpenSpec tasks.
13. By default, ask the user to confirm the OpenSpec task checklist before implementation planning starts.
14. After the user confirms tasks.md, pause again and ask whether to continue execution development.
15. Accept continue-dev as the primary continuation command for that handoff.
16. Do not route the confirmed handoff through OpenSpec apply.
17. If the user chooses execution development, write the implementation plan to docs/superpowers/plans/YYYY-MM-DD-<topic>.md.
18. Prefer a repo-local worktree when the task is non-trivial or risky.
19. Implement with TDD.
20. Run fresh verification commands before any completion claim.
21. After execution development and verification complete, pause again and ask whether to continue code review.
22. Accept continue-review as the primary continuation command for that later handoff.
23. If code, specs, and verification are aligned, archive the change with the OpenSpec archive flow.
24. Accept continue-archive as the continuation command when archive is the next aligned step, while $openspec-archive-change remains valid.
25. If .superpowers-memory/ exists, update CURRENT_STATE.md and add a short session journal entry.

Guardrails

• 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 artifact generation, openspec-propose, or $openspec-feature-workflow before Superpowers exploration is complete.
• Do not begin by listing available OpenSpec skills, proposing openspec-propose, or explaining how OpenSpec would usually work. Treat those responses as misroutes for this workflow request.
• Superpowers exploration 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 start implementation before the design is approved.
• 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 handing off to Superpowers execution.
• 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 or revises the generated tasks on a follow-up turn, treat that turn as the continuation of this workflow, keep the workflow active, 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.
• Accept continue-dev for the post-task execution handoff.
• Accept continue-review for the post-execution code-review handoff.
• If archive is the next aligned step, accept continue-archive, while $openspec-archive-change remains usable.
• After code review is complete and archive is not the next step, keep the workflow paused instead of silently finishing.