Menu
Use when creating or updating OpenArc feature specs with acceptance criteria, compatibility decisions, and technical direction.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when a new goal, feature request, migration, or non-trivial change needs focused clarification before PRD, spec, plan, or implementation work begins.
Use when implementing repository changes through the smallest safe path, from direct routine fixes to risk-driven clarification, specs, plans, task coordination, validation, and documentation updates.
Use when a user asks to use OpenArc generally, initialize governance, improve repository continuity, audit governance drift, migrate an existing workspace, or choose which OpenArc skill should handle a request.
Use when producing a lightweight implementation plan before coding, including scope, affected systems, migration, rollback, tests, reuse, and architecture impact.
Use when auditing repository governance read-only, or when explicitly initializing or repairing governance and patching an agent guide without destructive rewrites.
Use when a user proposes changes that may require patch, minor, or major version changes, release notes, changelog updates, or version confirmation.
| name | spec-workflow |
| description | Use when creating or updating OpenArc feature specs with acceptance criteria, compatibility decisions, and technical direction. |
Use this skill when behavior, acceptance criteria, compatibility, or product direction needs durable alignment before implementation. Routine work with clear behavior and validation does not need a spec.
Create lightweight specs that keep humans and coding agents aligned without adding heavy process overhead.
Use Clarification Gate output when available. If the feature behavior, non-goals, compatibility constraints, or acceptance criteria are not clear, run clarification-gate before drafting the spec.
Use docs/specs/ by default.
Recommended file names:
docs/specs/
auth-system.md
editor-upgrade.md
cloud-sync.md
Use a stable, descriptive kebab-case slug. Do not couple the file name to a release version or rename the spec when the release version changes.
Draft and name the spec without waiting for version confirmation.
Use version-governance only when the proposed change is release-visible. When useful, record an optional Release Impact section with:
The release manifest, release changelog, and tags remain authoritative for the released version.
Use templates/SPEC.template.md as the baseline:
docs/plans/* and active coordination in docs/TASKS.md instead of duplicating either inside the spec.