/ospec

name: ospec
description: Document-driven OSpec workflow for initialization, change/goal routing, validation, archiving, and durable project knowledge.
tags: [cli, workflow, automation, ospec]

OSpec Router

Use this root skill as a compact router. Keep invariant safety and workflow-selection rules here; load detailed commands and stage protocols from the initialized project's indexed files only when that stage is active.

Default Entry

When the user asks to initialize a project, run `ospec init [path]`. In AI-assisted initialization, pass the explicit or conversational language with `--document-language`. If useful context is missing, ask once for a short project summary or tech stack; if the user skips it, continue with placeholders. Verify the generated files on disk and stop before creating work unless the user explicitly asks for a change or goal.

Initialization is change-ready only when `.skillrc`, the managed `.ospec/` or classic OSpec directory, active and archived change directories, `SKILL.md`, `SKILL.index.json`, the index builder, `for-ai/` protocol files, and baseline `docs/project/` knowledge files exist.

Do not hand-write an approximation of `ospec init`. Do not assume a web stack, apply business scaffold, generate `docs/project/bootstrap-summary.md`, create queue work, or create the first change without explicit intent.

Workflow Router

• Use `ospec change` / `ospec-change` when the user selects a Change. Its source of truth is `changes/active/<change>/proposal.md`, `changes/active/<change>/tasks.md`, `state.json`, `verification.md`, and `review.md`; `ospec new` remains a compatibility alias.
• Use `ospec goal` / `ospec-goal` only when the user selects a Goal. It additionally owns `changes/active/<change>/design.md`, `changes/active/<change>/implementation-plan.md`, `changes/active/<change>/artifacts/agents/task-graph.json`, worker/reviewer artifacts, and evidence gates.
• Never auto-promote, reject, or replace a user-selected Change because of complexity, risk, file count, parallelism, or batch size. The user's explicit profile choice is authoritative.
• Enter queue mode only when the user explicitly asks to queue or execute multiple changes.

For an initialized project, read in this order:

1. `.skillrc` for layout, language, workflow policy, plugins, and model profiles. 2. `ospec index query <keyword...>` as the router into `SKILL.index.json` and `docs/project/feature-index.md`; never read the whole index file — it grows without bound as changes archive. 3. The current session brief, bootstrap, dispatch, review, or repair packet. 4. Only the indexed project documents, change files, and target files named by that packet.

Do not load every historical change or every protocol file by default. Open `for-ai/ai-guide.md` for general execution rules and `for-ai/execution-protocol.md` only when entering the full goal controller layer. Use `ospec help` or subcommand help instead of carrying the complete CLI catalog in context.

Visibility And Decisions

• `Announce-Before-Act`: before workflow actions, state the OSpec workflow and stage, the command and artifact it writes, native agent count/mechanism, and any blocking gate.
• `Brainstorm-First`: before locking a goal design, surface open direction, architecture, API, data, UI, risk, and scope decisions one at a time. Prefer a durable required decision over a silent assumption.
• `Zero-Setup`: the user states the requirement; the AI runs OSpec controller commands and the user only answers decisions. Do not ask the user to operate routine setup commands.
• Required pending decisions block worker dispatch. Preserve `PENDING`, `NEEDS_CONTEXT`, `BLOCKED`, `DONE_WITH_CONCERNS`, and `DONE` rather than hiding uncertainty.

In Claude Code, install the managed hook once with `ospec session hook --target claude --apply` when missing. Static workflow context is injected on startup, clear, and compact; prompt hooks should stay silent unless a required decision is pending. `PreToolUse(Task)` remains the hard dispatch gate.

Goal Controller Invariants

Use the full `ospec execute ...` task-graph/controller layer only for Goal work. A classic Change may use the shared `ospec execute decision` command for durable user choices, but it must not enter Goal bootstrap, workspace, dispatch, review, evidence, or Loop commands.

• Start or resume with `ospec session` and `ospec execute bootstrap`.
• Run `ospec execute preflight ... --stage design`, then `--stage plan`, before deriving the task graph. These zero-token checks validate document readiness, required decisions, ordering, and provenance inline and never launch reviewer children.
• After task graph derivation, let Loop issue one independent combined planning review across proposal, design, plan, tasks, graph, and acceptance-to-verification coverage. `NEEDS_CHANGES` permits one grouped planning repair and at most one delta-scoped re-review; a repair executor failure with no planning edits re-arms instead of consuming the allowance, all-medium-or-lower findings settle deterministically as `APPROVED_WITH_CONCERNS` after the repair, and another semantic failure is a stable blocker.
• Progress checklists track reality: tick proposal.md acceptance criteria as verification evidence passes (`[verify:<id>]`-tagged lines are auto-ticked by `ospec execute sync`); unchecked items block archiving. Goal review.md is derived from the final review by sync; never edit it by hand.
• Resolve required decisions and workspace isolation before dispatch.
• Dispatch scoped worker packets, use the launch plan with the current harness native agent mechanism, record completion, then perform one combined task review.
• Treat each task's canonical `artifacts/agents/worker-reports/<task-id>.md` as review-bound evidence. A fresh task review snapshots it alongside declared targets; a repair may edit only that same task's exact report path. If a finding names an unsnapshotted canonical report, let L