openspec-workflow

name	openspec-workflow
description	Use when a repository uses OpenSpec or a request needs spec-driven planning, OPSX workflows, change proposals, delta specs, design artifacts, task sequencing, apply readiness checks, or archive preparation.
argument-hint	Describe the change, the current OpenSpec state, or the workflow phase you need help with.

OpenSpec Workflow

Use this skill to route work into the correct OpenSpec phase before implementation drifts into ad hoc coding.

When To Use

• The repository contains openspec/
• The request is a new feature or a behavior-changing change
• The user asks for proposal, specs, design, tasks, OPSX, openspec status, or openspec instructions
• The work needs an apply-readiness check before code editing starts
• A change is moving toward validation, sync, or archive

Core Rules

• Treat OpenSpec artifacts as the source of truth over chat history.
• Prefer openspec status --json and openspec instructions <artifact-or-apply> --json when the CLI is available.
• Route artifact authoring and readiness analysis to OpenSpec DDD.
• Route implementation only to OpenSpec Implementer, and only after the apply gate is satisfied.
• If the gate is not satisfied, work on artifacts instead of product code.

Routing Procedure

1. Detect whether the repo uses OpenSpec.
   • Look for openspec/, openspec/config.yaml, openspec/specs/, or openspec/changes/.
2. Establish the current workflow state.
   • Prefer CLI state from openspec status --json and openspec instructions ... --json.
   • If the CLI is unavailable, inspect the OpenSpec filesystem directly.
3. Choose the phase agent.
   • Use OpenSpec DDD for proposal/spec/design/tasks authoring, change discovery, blocked-state analysis, and archive prep.
   • Use OpenSpec Implementer only when the change is apply-ready and implementation can proceed from tasks.
4. Keep the workflow tight.
   • If a request is small maintenance with no behavior change and no active OpenSpec change, normal workflow may continue.
   • If a request is feature-sized, architectural, or behavior-changing, OpenSpec should govern the work.

Minimum Apply Gate

Treat a change as not ready for implementation until the current workflow shows the equivalent of:

• a scoped proposal,
• at least one concrete delta spec,
• a design artifact when the schema expects it,
• and executable tasks for the apply phase.

References

• Core runtime model
• Phase routing guide