菜单
Use when running OpenSpec propose, continue, apply, verify, archive, or worktree workflows where proposal artifacts, branches, merges, or archive timing affect git history.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when authoring or reviewing specs, requirements, design docs, ADRs, tasks, glossary entries, domain terms, technical terms, or wording consistency across artifacts
Use when rules or instructions mention "adversarial-authoring", "adversarial authoring", "must use adversarial-authoring skill", "model council", "cross-model review", or "mixture of models"; coordinates adversarial authoring and review subagents and records council notes.
Use when documenting, drafting, reviewing, or updating architectural decisions, ADRs, decision logs, tradeoffs, rationale, consequences, alternatives, or architecture decision history.
Use when explaining existing code architecture, visualizing a new system before detailed design, mapping software boundaries, or creating C4-style diagrams in ASCII or Mermaid.
Use when drafting, reviewing, or improving Gherkin, Cucumber scenarios, BDD acceptance criteria, feature examples, Scenario Outlines, Backgrounds, Rules, Doc Strings, Data Tables, tags, or Gherkin embedded in Markdown.
Use when multiple active OpenSpec changes should be applied concurrently in isolated worktrees with delegated verification and no merge.
| name | openspec-git-discipline |
| description | Use when running OpenSpec propose, continue, apply, verify, archive, or worktree workflows where proposal artifacts, branches, merges, or archive timing affect git history. |
| license | MIT |
| compatibility | Requires git and OpenSpec workflow artifacts. |
Every OpenSpec state change must cross main before the next lifecycle phase depends on it.
main before apply starts.main, a branch, or a worktree only if that exact proposal change is already available on main.main after implementation is merged back.Never create commits, branches, or merges unless the user explicitly asks.
| Moment | Gate |
|---|---|
| Before propose | Prefer main; if not, warn and ask whether to continue intentionally. |
| During continue | Before creating the next artifact, ask the user to commit completed artifact changes or explicitly continue without that checkpoint. |
| After propose | Ask the user to commit proposal artifacts; offer to create a PR branch for review. |
| Before apply | Confirm the proposal change is committed on main; then apply may run from main, a branch, or a worktree. |
| Before archive | Stop unless implementation is merged back to main and archive is running from main. |
| After archive | Ask the user to commit archive/spec sync changes. |
Before apply:
git status --short.openspec/changes/<change>/ has no uncommitted proposal files.main before applying from any branch/worktree.Use this language if the proposal has not reached main:
I should not apply this yet because the proposal change has not reached
main. A proposal can be drafted on a branch, but apply must start only after that proposal state is available onmain. Please merge or commit the proposal tomainfirst, then I can apply frommain, a branch, or a worktree.
Before archive:
git branch --show-current and git status --short.main.main.Use this language:
I should not archive this yet because archive must run from
mainafter implementation is merged back. Verify makes a change eligible to merge; it does not replace the merge.
main.main.All of these mean: pause, explain the boundary, and ask the user to make the git state explicit.