菜单
Use when creating or updating OpenArc feature specs with acceptance criteria, compatibility decisions, and technical direction.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.