SYZ-Coder/superpowers-openspec-team-skills

# OpenSpec Feature Workflow

Use this standalone skill when the feature needs OpenSpec artifacts before implementation.

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

## Workflow

1. Derive or confirm a kebab-case change name.
2. Create the change under `openspec/changes/<change-name>/`.
3. Run `openspec status --change "<change-name>" --json`.
4. Before writing each artifact, run `openspec instructions <artifact> --change "<change-name>" --json`.
5. Complete artifacts in dependency order:
   - `proposal.md`

# OpenSpec + Superpowers Workflow

Use this standalone skill when a feature should start with OpenSpec proposal, design, specs, and tasks before handing off to Superpowers implementation planning, TDD, and verification.

This is an explicit opt-in workflow. Do not use it by default. Only use it when the user explicitly asks for it, names `$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 before planning and update it before closing the workflow.

## Workflow

1. Explore the repository context enough to understand the requested behavior change.
2. Clarify requirements one question at a time only as needed to write accurate OpenSpec artifacts.

# Superpowers Feature Workflow

Use this standalone skill when you want disciplined feature delivery without OpenSpec artifact generation.

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-feature-workflow`, or a repository policy explicitly requires it.

## Workflow

1. Explore project context first. If `.superpowers-memory/` exists, read `PROJECT_CONTEXT.md`, `CURRENT_STATE.md`, and the latest session journal entries before asking questions.
2. Clarify requirements one question at a time.
3. Present 2-3 approaches and recommend one.
4. Write the approved design to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`.
5. Ask the user to confirm the written design.
6. Write the implementation plan to `docs/superpowers/plans/YYYY-MM-DD-<topic>.md`.

# Superpowers Learning Workflow

Use this standalone skill when the user wants to preserve lessons from recent work in the repository.

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-learning-workflow`, or a repository policy explicitly requires it.

## Workflow

1. Review recent work, decisions, and verification evidence.
2. Classify what was learned into durable facts, current state, session outcome, and reusable lessons.
3. If `.superpowers-memory/` exists, update `PROJECT_CONTEXT.md`, `CURRENT_STATE.md`, recent journal files, and `LEARNING_BACKLOG.md` as appropriate.
4. If `.superpowers-memory/` does not exist, tell the user to install the memory scaffold or keep the learning summary in a normal project document.
5. Keep stable facts separate from temporary notes.
6. Summarize what the next session should remember.

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

# OpenSpec Feature Workflow

Use this standalone skill when the feature needs OpenSpec artifacts before implementation.

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

## Workflow

1. Derive or confirm a kebab-case change name.
2. Create the change under `openspec/changes/<change-name>/`.
3. Run `openspec status --change "<change-name>" --json`.
4. Before writing each artifact, run `openspec instructions <artifact> --change "<change-name>" --json`.
5. Complete artifacts in dependency order:
   - `proposal.md`

# OpenSpec + Superpowers Workflow

Use this standalone skill when a feature should start with OpenSpec proposal, design, specs, and tasks before handing off to Superpowers implementation planning, TDD, and verification.

This is an explicit opt-in workflow. Do not use it by default. Only use it when the user explicitly asks for it, names `openspec-superpowers-workflow` or `$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 before planning and update it before closing the workflow.

## Workflow

1. Explore the repository context enough to understand the requested behavior change.
2. Clarify requirements one question at a time only as needed to write accurate OpenSpec artifacts.

# Superpowers Feature Workflow

Use this standalone skill when you want disciplined feature delivery without OpenSpec artifact generation.

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-feature-workflow` or `$superpowers-feature-workflow`, or a repository policy explicitly requires it.

## Workflow

1. Explore project context first. If `.superpowers-memory/` exists, read `PROJECT_CONTEXT.md`, `CURRENT_STATE.md`, and the latest session journal entries before asking questions.
2. Clarify requirements one question at a time.
3. Present 2-3 approaches and recommend one.
4. Write the approved design to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`.
5. Ask the user to confirm the written design.
6. Write the implementation plan to `docs/superpowers/plans/YYYY-MM-DD-<topic>.md`.

# Superpowers Learning Workflow

Use this standalone skill when the user wants to preserve lessons from recent work in the repository.

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-learning-workflow` or `$superpowers-learning-workflow`, or a repository policy explicitly requires it.

## Workflow

1. Review recent work, decisions, and verification evidence.
2. Classify what was learned into durable facts, current state, session outcome, and reusable lessons.
3. If `.superpowers-memory/` exists, update `PROJECT_CONTEXT.md`, `CURRENT_STATE.md`, recent journal files, and `LEARNING_BACKLOG.md` as appropriate.
4. If `.superpowers-memory/` does not exist, tell the user to install the memory scaffold or keep the learning summary in a normal project document.
5. Keep stable facts separate from temporary notes.
6. Summarize what the next session should remember.

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

# OpenSpec Feature Workflow

## Overview

Use this skill for the OpenSpec half of feature delivery. It creates and completes the change artifacts needed before implementation.

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.

## Workflow

1. Derive or confirm a kebab-case change name.
2. Create the change under `openspec/changes/<change-name>/`.
3. Run `openspec status --change "<change-name>" --json` to inspect artifact order.
4. Read `openspec instructions <artifact> --change "<change-name>" --json` before writing each artifact.

# OpenSpec + Superpowers Workflow

## Overview

Use this skill as the OpenSpec-first feature delivery entrypoint. It creates and validates OpenSpec change artifacts first, then hands the completed task checklist to Superpowers for implementation planning, TDD, and verification.

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, treat it as shared project memory: read it before planning and update it before closing the workflow.

## Required Order

1. Run `$openspec-feature-workflow` first.
   Use it to clarify the change enough to create and complete `proposal`, `design`, `specs`, and `tasks`.

# Superpowers Feature Workflow

## Overview

Use this skill for the Superpowers half of feature delivery. It covers clarification, design, plan, worktree, TDD, verification, and repo-persisted memory, but it does not manage OpenSpec artifacts.

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.

## Workflow

1. Explore project context before proposing solutions. If `.superpowers-memory/` exists, 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 latest session journal entries first.
2. Clarify requirements one question at a time.
3. Present 2-3 approaches with a recommendation.
4. Write the approved design to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`.

# Superpowers Learning Workflow

## Overview

Use this workflow after meaningful work to capture what should survive the current session. It is a lightweight, repo-owned learning loop inspired by reflective agent systems, but scoped for safe use inside normal project workflows.

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.

## Workflow

1. Review the recent work, decisions, and verification evidence.
2. Classify what was learned into four buckets:
   - durable project facts
   - current working state

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