mirror of
https://github.com/Fission-AI/OpenSpec.git
synced 2026-10-03 22:13:19 +08:00
Compare commits
2
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 TabishB
|
3a88186909 | ||
|
TabishB
|
493605756f |
@@ -1,46 +0,0 @@
|
||||
---
|
||||
name: draft-openspec-docs
|
||||
description: Collaborative page-drafting mode for the OpenSpec docs. Builds a scratch plan inside the target page (purpose, structure, numbered draft steps), iterates on it with the user, then drafts one section per approved step and cleans up after itself. Use when a page needs a from-scratch rewrite or a new page is being shaped with the user in the loop.
|
||||
argument-hint: target page
|
||||
---
|
||||
|
||||
# Draft OpenSpec docs (scratch-plan workflow)
|
||||
|
||||
You are shaping a docs page with the user in the loop. The page is planned and reviewed inside the page itself, then drafted one section at a time. Load `write-openspec-docs` (the style authority) and `no-ai-slop` before drafting anything.
|
||||
|
||||
## 1. Set up the scratch section
|
||||
|
||||
Strip the page to its title and `>` goal line, then add a working section below them:
|
||||
|
||||
```md
|
||||
## Scratch: page plan (delete before publish)
|
||||
|
||||
### Purpose
|
||||
|
||||
### Structure
|
||||
```
|
||||
|
||||
- **Purpose**: 3-5 dot points. Who the reader is and what they come to look up, what the page covers, what it links out to. Check `docs-lab/README.md` (the page's goal line) and `docs-lab/message-map.md` (the questions routed here) before writing it.
|
||||
- **Structure**: a numbered list of the page's sections, one line each naming the section and the shape of its content (table, fence, tree, bullets).
|
||||
- Say what the page will do, never what it won't. Plain words and short bullets; the user reads this in their editor.
|
||||
|
||||
## 2. Iterate until the plan is approved
|
||||
|
||||
- Plan edits are cheap; page edits aren't. Reshape the plan as many times as the user asks before drafting.
|
||||
- Record every decision in the plan itself, not only in chat. Add a `### Notes` list for follow-ups that belong to other pages and product observations found along the way.
|
||||
- The user may edit the file directly between turns; their edits are decisions, not drift to revert.
|
||||
- Surface one open call at a time, with a recommendation.
|
||||
|
||||
## 3. Add the draft plan, then draft step by step
|
||||
|
||||
Once the structure holds, add a `### Draft plan` below the notes: one step per page section, each with an ID and a readable title (`**D1. Goal line and intro**`), ending with a consolidation step (cross-page updates) and a cleanup step. Then:
|
||||
|
||||
- Wait for the user to call a step ID. Draft exactly that step, into the page above the scratch block.
|
||||
- Verify each fact against source before writing it; a cheap grep beats trust. Reference content shows the raw contract (templates, instructions, config) verbatim in fences, linked to the file on GitHub, rather than paraphrasing it.
|
||||
- Keep sibling sections on a repeatable sub-structure so the page scans as one system.
|
||||
- Mark the step `(done)` in the plan, report what landed, and name the next step.
|
||||
|
||||
## 4. Consolidation and cleanup
|
||||
|
||||
- **Consolidation**: update everything that points at the page. The README goal line (verbatim match with the page's `>` line), the message map, the sync config (`website/docs.sync.config.mjs`), and any cross-links found by grepping the tree. Run `node website/scripts/sync-docs.mjs` to validate.
|
||||
- **Cleanup**: delete the scratch block, run the retrievability and glance tests from `write-openspec-docs` at desktop and narrow widths, and flip the page's message-map row to Answered if its prose landed.
|
||||
@@ -1,180 +0,0 @@
|
||||
---
|
||||
name: release-openspec
|
||||
description: >-
|
||||
Use this skill when releasing OpenSpec: audit merged work and changeset
|
||||
coverage, decide whether a catch-up changeset PR is needed, prepare or resume
|
||||
the Changesets Version Packages PR, cut a beta or stable release, verify
|
||||
publishing, and polish GitHub release notes. Also use when asked whether an
|
||||
open release PR is complete, what the next release step is, or to continue a
|
||||
release paused for human approval.
|
||||
---
|
||||
|
||||
# Release OpenSpec
|
||||
|
||||
Run the OpenSpec release workflow as a resumable state machine. Inspect live GitHub state on every invocation and take only the next safe action. Do not assume an earlier invocation completed.
|
||||
|
||||
## Principles
|
||||
|
||||
- Treat `Fission-AI/OpenSpec` and `origin/main` as the release source of truth.
|
||||
- Default to a read-only audit when the user asks for status, readiness, or advice.
|
||||
- Treat a request to release, prepare a release, continue, or resume as authorization to perform the applicable release actions.
|
||||
- Preserve the user's checkout. Never discard unrelated changes or switch their current branch just to prepare a changeset.
|
||||
- Use a temporary worktree from current `origin/main` for release-authored commits when the checkout is dirty or not on `main`.
|
||||
- Never approve your own PR. Human review is a deliberate gate.
|
||||
- Treat merge-queue entry as an intermediate state, not a merge. Advance only after GitHub reports `mergedAt` and the commit is present on `main`.
|
||||
- Never create the automated Version Packages PR manually. The Changesets action owns it.
|
||||
- Never push an empty commit merely to retrigger CI. Diagnose the failed or missing run first.
|
||||
- Report URLs, the state reached, and the exact human action needed whenever pausing.
|
||||
|
||||
## Know the two PR types
|
||||
|
||||
Keep these distinct in output and decisions:
|
||||
|
||||
- **Changeset PR**: A normal human-authored PR that adds one or more `.changeset/*.md` files. Prefer adding a changeset to the feature/fix PR; create a catch-up changeset PR only for already-merged work that should be included.
|
||||
- **Version Packages PR**: The automated `changeset-release/main` PR titled `chore(release): version packages`. Merging or adding changesets to `main` updates this same PR. Merging it publishes the stable release.
|
||||
|
||||
An open Version Packages PR does not prohibit a catch-up changeset PR. It means a catch-up PR is useful only when the audit finds missing release-worthy work. Once that PR merges, wait for the existing Version Packages PR to update.
|
||||
|
||||
## Start with a release audit
|
||||
|
||||
1. Verify the repository and tools:
|
||||
- Resolve the GitHub repository with `gh repo view --json nameWithOwner,url`.
|
||||
- Require authenticated `gh`, `git`, and `pnpm` before write actions.
|
||||
- Stop before release mutations if the canonical repository is not `Fission-AI/OpenSpec`.
|
||||
2. Refresh without modifying the worktree:
|
||||
|
||||
```bash
|
||||
git fetch origin main
|
||||
```
|
||||
|
||||
Do not fetch every tag indiscriminately. This repository may contain a conflicting historical local tag, which can make `git fetch --tags` fail even though `origin/main` fetched successfully.
|
||||
|
||||
3. Find the latest stable GitHub release. Exclude drafts and prereleases; do not use `git describe`, because a beta tag may be newer than the stable baseline.
|
||||
|
||||
```bash
|
||||
gh release list --repo Fission-AI/OpenSpec \
|
||||
--exclude-drafts --exclude-pre-releases --limit 100 \
|
||||
--json tagName,publishedAt \
|
||||
--jq 'max_by(.publishedAt) | {tagName, publishedAt}'
|
||||
```
|
||||
|
||||
Ensure that exact stable tag resolves locally before using it as a `git log` boundary. Fetch only that tag if it is missing. If a same-named local tag disagrees with the canonical remote, report the mismatch and use a separately resolved canonical commit; never force-rewrite the user's tag as part of an audit.
|
||||
|
||||
4. Find open release-related PRs:
|
||||
|
||||
```bash
|
||||
gh pr list --repo Fission-AI/OpenSpec --state open \
|
||||
--head changeset-release/main \
|
||||
--json number,title,headRefName,baseRefName,url,reviewDecision,statusCheckRollup
|
||||
```
|
||||
|
||||
Identify the Version Packages PR by `headRefName == "changeset-release/main"`, not title alone. Separately list likely changeset PRs and inspect their files; require positive additions to `.changeset/*.md`. Do not mistake the Version Packages PR's changeset deletions for authored changesets, and do not rely on titles because a feature/fix PR may add release tracking.
|
||||
5. Read the live release policy in `.changeset/README.md`, pending `.changeset/*.md` files on `origin/main`, and the Version Packages PR body/files when it exists.
|
||||
6. List first-parent commits since the latest stable tag:
|
||||
|
||||
```bash
|
||||
git log --first-parent --date=short \
|
||||
--pretty=format:'%h%x09%ad%x09%s' <stable-tag>..origin/main
|
||||
```
|
||||
|
||||
7. Map release-worthy merged PRs to existing changesets. Use PR files and changeset history; do not infer coverage from similar wording alone.
|
||||
8. Classify the audit as:
|
||||
- `missing-tracking`: user-facing work intended for this release lacks a changeset;
|
||||
- `awaiting-changeset-review`: a suitable changeset PR already exists;
|
||||
- `awaiting-merge-queue`: an approved changeset or Version Packages PR is queued but has not landed on `main`;
|
||||
- `awaiting-version-update`: required changesets are on `main`, but the Version Packages PR has not incorporated them;
|
||||
- `awaiting-version-review`: the Version Packages PR is current but lacks approval;
|
||||
- `ready-to-publish`: the Version Packages PR is current, approved, and green;
|
||||
- `publishing`: the Version Packages PR merged but artifacts are incomplete;
|
||||
- `needs-finalization`: npm, tag, and GitHub Release exist but notes are still raw;
|
||||
- `complete`: package, tag, GitHub Release, and polished notes agree.
|
||||
|
||||
Present a compact audit with the stable baseline, proposed version, covered changes, possible omissions, intentionally skipped internal/docs work, open PRs, and next action.
|
||||
|
||||
## Decide changeset coverage
|
||||
|
||||
Follow `.changeset/README.md` rather than assuming every merged PR needs a changeset.
|
||||
|
||||
Include work selected for release tracking, especially:
|
||||
|
||||
- new user-facing features or commands;
|
||||
- notable fixes or hotfixes;
|
||||
- breaking changes or deprecations;
|
||||
- user-visible performance improvements.
|
||||
|
||||
Normally skip documentation-only work, tests, CI/tooling, and internal refactors. Flag ambiguous user-visible changes instead of silently excluding them. Ask the user only when the ambiguity materially changes release scope or the semantic version; otherwise use best judgment and let PR review be the approval gate.
|
||||
|
||||
## Create or continue a changeset PR
|
||||
|
||||
Do this only for `missing-tracking`.
|
||||
|
||||
1. If an open changeset PR already covers the missing work, reuse it. Inspect its `headRefName`, head repository, and `maintainerCanModify`; fetch that exact head branch from its owning repository into a temporary worktree, make the update there, and push back to the same PR head. Stop if the branch is not writable. Do not create a duplicate PR or replacement branch.
|
||||
2. Read `.changeset/README.md` immediately before authoring.
|
||||
3. Only when no suitable PR exists, create a short `changeset-<scope>` branch from current `origin/main`. Use a temporary worktree so the operator's checkout remains untouched.
|
||||
4. Prefer one changeset per coherent release unit. A single catch-up changeset may summarize several small items selected for the same release.
|
||||
5. Use the exact package name `"@fission-ai/openspec"`, the highest required semantic bump, only relevant headings, and user-focused descriptions.
|
||||
6. Validate before pushing:
|
||||
|
||||
```bash
|
||||
pnpm exec changeset status
|
||||
```
|
||||
|
||||
7. Commit, push, and open a PR whose body lists the covered merged PRs and explains why the catch-up is needed.
|
||||
8. Stop after returning the PR URL and request human approval. Do not approve it yourself.
|
||||
|
||||
On a later invocation, if the PR is approved and checks are green, merge or enqueue it only when the user asked to continue or complete the release. If GitHub uses a merge queue, inspect `mergeQueueEntry`, queue checks, and `mergedAt`; remain in `awaiting-merge-queue` until the PR actually lands on `main`. Then wait for the Changesets action on `main` to update the existing Version Packages PR. Poll with concise progress updates; do not push an empty commit or another branch update, because that can dismiss approval and restart the queue.
|
||||
|
||||
## Validate the Version Packages PR
|
||||
|
||||
Before calling it ready:
|
||||
|
||||
1. Confirm it targets `main` from `changeset-release/main` and is generated by the expected automation.
|
||||
2. Enumerate every pending `.changeset/*.md` file on current `main`, excluding `.changeset/README.md`. Verify the PR consumes every one and contains the corresponding changelog content. If any pending changeset should be deferred, stop: remove or revise it through a separately reviewed change and wait for automation to regenerate the Version Packages PR before continuing.
|
||||
3. Fetch `baseRefOid` and `headRefOid` with `gh pr view`, require `baseRefOid` to equal current `origin/main`, and create clean detached temporary worktrees for both revisions. If the head object is missing locally, fetch the immutable `pull/<number>/head` ref first. Never validate from the operator's current worktree.
|
||||
4. In the base worktree, run `pnpm exec changeset status --output changeset-status.json` and read the expected package/version from that file. Install locked dependencies in the temporary worktree first if the Changesets CLI is unavailable.
|
||||
5. Compare the base status and complete pending-changeset set against the head worktree: `package.json`, `CHANGELOG.md`, removed changeset files, PR body, and proposed version must all agree. This is a base-to-head comparison because the head has already consumed the changesets and cannot calculate the pending release itself.
|
||||
6. Remove the temporary worktrees after validation, then inspect all required checks and review state with `gh pr view` / `gh pr checks`.
|
||||
|
||||
If current but unapproved, return the URL and pause for human approval. If approved and green, merge or enqueue only when the user asked to release or continue. With merge queue enabled, do not treat approval, auto-merge enablement, or queue entry as the stable publish trigger; wait for `mergedAt` and confirmation that the merge reached `main`.
|
||||
|
||||
## Verify stable publishing
|
||||
|
||||
After the Version Packages PR merges:
|
||||
|
||||
1. Find the release workflow run for the merge commit and wait for completion.
|
||||
2. Verify all three artifacts independently:
|
||||
- `npm view @fission-ai/openspec@<version> version`
|
||||
- remote tag `v<version>` points at the expected commit;
|
||||
- `gh release view v<version>` exists and is not a prerelease.
|
||||
3. If only some artifacts exist, report partial state and resume verification before retrying any publish action. Never republish a version already on npm.
|
||||
4. Once all artifacts exist, read [references/release-notes.md](references/release-notes.md), polish the GitHub Release, and verify the saved title/body.
|
||||
|
||||
## Cut a beta
|
||||
|
||||
Only enter this path when the user explicitly asks for a beta or prerelease.
|
||||
|
||||
1. Run the same audit and confirm pending changesets produce a next stable version.
|
||||
2. Explain that beta publishing does not consume changesets or replace the stable Version Packages PR.
|
||||
3. Trigger the existing `release-prepare.yml` workflow on `main`; do not calculate or set the beta version locally.
|
||||
4. Verify the workflow-selected version, npm `beta` dist-tag, remote tag, and prerelease GitHub Release.
|
||||
5. Do not merge the stable Version Packages PR as part of a beta request.
|
||||
|
||||
## Handle failures
|
||||
|
||||
- For failed CI, inspect the failing check and logs before proposing a rerun or code change.
|
||||
- For a stale Version Packages PR, first confirm a successful `push` run of `release-prepare.yml` occurred after the latest changeset reached `main`.
|
||||
- For branch divergence, let the Changesets action update its branch. Do not force-push `changeset-release/main`.
|
||||
- For a queued PR, inspect merge-group checks and queue state. Do not re-enqueue, update the branch, or rerun unrelated checks while it is progressing normally.
|
||||
- For a version that already exists on npm, stop and reconcile the tag/GitHub Release rather than incrementing or republishing implicitly.
|
||||
- For missing GitHub permissions or required review, report the exact gate and URL; preserve the detected state so the next invocation can resume by inspection.
|
||||
|
||||
## Completion report
|
||||
|
||||
Report:
|
||||
|
||||
- released version and stable/beta channel;
|
||||
- changeset PR and Version Packages PR URLs, when applicable;
|
||||
- release workflow result;
|
||||
- npm package, tag, and GitHub Release verification;
|
||||
- release-notes finalization status;
|
||||
- any intentionally deferred changes.
|
||||
@@ -1,4 +0,0 @@
|
||||
interface:
|
||||
display_name: "Release OpenSpec"
|
||||
short_description: "Audit, prepare, publish, and finalize releases"
|
||||
default_prompt: "Use $release-openspec to audit the current release state and take the next safe release step."
|
||||
@@ -1,89 +0,0 @@
|
||||
# GitHub release notes
|
||||
|
||||
Read this file only after the npm package, tag, and GitHub Release exist, or when the user explicitly asks to preview or polish release notes.
|
||||
|
||||
## Gather source material
|
||||
|
||||
1. Bind the release values once and fetch the current release. Replace the example values, but keep every expansion quoted:
|
||||
|
||||
```bash
|
||||
tag="vX.Y.Z"
|
||||
previous_tag="vA.B.C"
|
||||
gh release view "$tag" --repo Fission-AI/OpenSpec \
|
||||
--json body,name,isPrerelease,url
|
||||
```
|
||||
|
||||
2. For a stable release, find the preceding stable release by excluding drafts and prereleases. For a beta, compare against the preceding tag in the same beta series when one exists; otherwise compare against the latest stable release.
|
||||
3. Fetch GitHub-generated notes to recover first-time contributor attribution and the full changelog link:
|
||||
|
||||
```bash
|
||||
gh api repos/Fission-AI/OpenSpec/releases/generate-notes \
|
||||
-f "tag_name=$tag" -f "previous_tag_name=$previous_tag" -q '.body'
|
||||
```
|
||||
|
||||
4. Cross-check the final content against the released `CHANGELOG.md` section and the merged Version Packages PR. Never invent an item from commit titles alone.
|
||||
|
||||
## Title
|
||||
|
||||
Use:
|
||||
|
||||
```text
|
||||
<tag> - <one-to-four-word theme>
|
||||
```
|
||||
|
||||
Lead with the most notable user-facing addition. For two similarly important additions, comma-separate them. For a fix-only release, name the primary fixed area.
|
||||
|
||||
## Body
|
||||
|
||||
Use only the sections that contain content:
|
||||
|
||||
```markdown
|
||||
## What's New in <tag>
|
||||
|
||||
<One direct sentence describing the release theme.>
|
||||
|
||||
### New
|
||||
|
||||
- **Feature** - What users can now do and when it helps.
|
||||
|
||||
### Improved
|
||||
|
||||
- **Area** - What became easier, safer, faster, or more consistent.
|
||||
|
||||
### Fixed
|
||||
|
||||
- **Area** - What now behaves correctly.
|
||||
|
||||
## New Contributors
|
||||
|
||||
* @username made their first contribution in #PR
|
||||
|
||||
**Full Changelog**: <compare-link>
|
||||
```
|
||||
|
||||
## Voice and cleanup
|
||||
|
||||
- Write for developers using OpenSpec with AI coding assistants.
|
||||
- Be direct and practical; avoid marketing language.
|
||||
- Lead with user capability or impact, not implementation.
|
||||
- Keep each item to one or two sentences.
|
||||
- Remove commit hashes, changeset wrappers, raw semantic-bump headings, and inline `Thanks @user` boilerplate.
|
||||
- Omit internal CI, test, and refactor details unless users experience the result.
|
||||
- Keep contribution credit in `New Contributors`, not inside feature bullets.
|
||||
- Preserve GitHub's first-contribution wording and PR link.
|
||||
- Exclude core maintainer `@TabishB` from `New Contributors`. If no external first-time contributors remain, omit that section.
|
||||
- Always retain the full changelog compare link.
|
||||
|
||||
## Apply and verify
|
||||
|
||||
Create a temporary file, write the body to it with the available file-editing tool, bind the final title, then update:
|
||||
|
||||
```bash
|
||||
notes_file="$(mktemp)"
|
||||
title="$tag - Release Theme"
|
||||
# Write the polished Markdown body to "$notes_file" before continuing.
|
||||
gh release edit "$tag" --repo Fission-AI/OpenSpec \
|
||||
--title "$title" --notes-file "$notes_file"
|
||||
```
|
||||
|
||||
When the user asked only for a preview or audit, show the proposed title/body without editing. When the user asked to run, continue, or complete the release, apply the polished notes without an extra confirmation pause, then fetch the release again and verify the saved title/body.
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
name: verify-openspec-docs
|
||||
description: Fact-checks OpenSpec user documentation with a fresh-context subagent that re-runs commands and checks claims against source. Manually triggered; not part of the drafting loop. Use when the user asks to verify, fact-check, or accuracy-check a docs page, section, or set of changed claims.
|
||||
argument-hint: page or section
|
||||
---
|
||||
|
||||
# Verify OpenSpec docs
|
||||
|
||||
Check finished docs prose against reality. The point of a fresh context is that the reviewer hasn't watched the prose get written, so it can't be talked into the author's assumptions.
|
||||
|
||||
This skill runs only when the user asks for it. Drafting is owned by `write-openspec-docs`; don't invoke this from inside a drafting session unless the user requests a verification pass.
|
||||
|
||||
## Scope the run
|
||||
|
||||
1. Confirm the target: a page, one `##` section, or a list of changed claims. If invoked without a target, ask.
|
||||
2. Read the README at the root of the docs tree the target lives in; its invariants and page map are part of what gets checked.
|
||||
3. One subagent per unit (one `##` section, or the stated claim list). A full page is several subagents, run in parallel.
|
||||
|
||||
## Spawn the reviewer
|
||||
|
||||
General-purpose subagent. Subagents don't inherit skills, so the prompt hands the reviewer everything by path. Fill every placeholder, make every path absolute, and send:
|
||||
|
||||
```
|
||||
You are reviewing one unit of OpenSpec's user documentation before it reaches the docs owner. Be the two hardest readers it will meet: a skeptical developer reading it cold, and a fact-checker with the repo open.
|
||||
|
||||
Repo root: <ABSOLUTE REPO ROOT>. Use absolute paths with every tool.
|
||||
|
||||
Read first:
|
||||
1. <DOCS TREE ROOT>/README.md: the page map and standing invariants.
|
||||
2. <ABSOLUTE REPO ROOT>/.agents/skills/write-openspec-docs/writing.md: the house writing rules.
|
||||
3. <PAGE PATH>: review only <the section "<HEADING>" | these changed claims: <LIST>>; read the rest of the page for context.
|
||||
|
||||
Then check, in this order:
|
||||
|
||||
1. Facts. Every command, flag, path, config key, output block, default, and behavior claim. Re-run the terminal commands shown: read-only commands anywhere, anything that mutates state in a scratch directory or not at all. Commands for the AI chat surface (like /opsx:propose) can't run in a shell; verify their names and behavior against the skill sources this repo ships. Check names against src/ and the CLI's own --help. An output block must match what the command actually prints.
|
||||
2. Examples. Any example spec or change must pass `openspec validate`. Run it when the example exists on disk.
|
||||
3. Structure. Flag anything that re-explains a topic whose canonical home is another page, or breaks a rule the docs tree's README states.
|
||||
4. Job fit. Does the unit serve the page's stated job (the one-line statement under the title, if present)? Does the arriving reader get what they came for quickly?
|
||||
5. Trust and slop. Flag: hype or comfort adjectives (easy, simple, powerful, seamless), claims with no shown evidence, vague generalization where a specific fact belongs, binary contrasts ("not X, it's Y"), colon reveals, importance puffery, summary endings, em dashes, bullet lists that should be prose, and three parallel punchy sentences in a row.
|
||||
|
||||
Report findings only, most severe first. For each: quote the line, say what is wrong, and give the fix in one line. For every fact you verified, say how (the command you ran, or the file and line you checked). List any claim you could not verify and why. Do not rewrite the unit. If the unit is clean, say so and list exactly what you verified.
|
||||
```
|
||||
|
||||
## Handle the report
|
||||
|
||||
- Default is report, not rewrite: show the user the findings ranked most severe first, each with the quoted line and one-line fix, plus what was verified and how, and any claim the reviewer couldn't verify.
|
||||
- Apply fixes only when the user asked for a verify-and-fix run or approves the findings. A verifier can also be wrong: rejections go in the report with your reason, so the user can overrule you.
|
||||
- If an applied fix changed a factual claim, verify again, scoped to the changed claims. Typo and wording fixes don't need a second pass.
|
||||
- Two passes without converging means stop and take it to the user. Don't polish in a loop.
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
name: write-openspec-docs
|
||||
description: Switches into OpenSpec docs-writing mode; loads the house style guide and drafts or revises pages in its voice (action-first, no preamble, scannable). Use when writing or editing pages in the OpenSpec docs tree.
|
||||
argument-hint: page or section
|
||||
---
|
||||
|
||||
# Write OpenSpec docs
|
||||
|
||||
You are now writing OpenSpec's user docs. Read [writing.md](writing.md); it is the style authority for everything drafted here. The short version, in effect immediately:
|
||||
|
||||
- A page is a retrieval surface, not an essay. Structure decides whether the reader finds the answer; prose only decides how it reads. Open every section with the answer, never a running story.
|
||||
- Choose the page type before the outline. Guides follow the reader's task; reference mirrors the product's structure and uses exact field, command, and file names as scan anchors. Reference needs complete coverage without compressing several facts into one sentence, cell, or paragraph.
|
||||
- Draft the shortest version that answers; expanding a spare page is cheap, cutting a bloated one is a rewrite. Plain words, the fewest of them: an idea that fits in one line takes one line. Depth most readers skip goes behind a link, and the payload (commands, real output, failures and fixes) stays whole.
|
||||
- Dumb sentences, smart structure. Write the obvious sentence (actor, verb, object, stating the literal event); never compress extra facts in or take an angle. No hype adjectives, no preamble, no em dashes.
|
||||
- One job per slot: one fact per sentence, list intros only announce the list, one reader question or lookup target per section. A related fact gets its own slot, never a ride in someone else's.
|
||||
- Ground items in what the reader can verify: path or folder first, concept as the gloss, real output shown honestly.
|
||||
- No house template. Inventories open with a list naming every item, then expand each in its own unit after the list, never inline. Sequences take numbered steps (numbers mean order; inventories take bullets). Single ideas and reasoning stay in short prose.
|
||||
- Every load-bearing fact sits on a scan anchor: code fence, numbered bold lead-in, `**Term**: fact` bullet, table, file tree. Never only mid-paragraph.
|
||||
- Before finishing, run two backstop tests. Retrievability: can each question or exact product name be found by scanning alone? The glance: inspect the rendered page as shapes; does it look finishable, or like work? Check table-heavy changes at desktop and narrow widths. A failure means a slot got written without being earned; fix it now, don't leave it for review.
|
||||
|
||||
## Ground rules
|
||||
|
||||
- Load the `no-ai-slop` skill before drafting; it owns the generic slop patterns, while [writing.md](writing.md) owns what OpenSpec's docs specifically look and sound like.
|
||||
- Read the target page in full before editing it.
|
||||
- Real facts only: flags, paths, and output as they exist in source. If a claim can't be checked cheaply, still write it, but name it as unchecked when you show the work; never bridge a gap with a plausible-sounding sentence.
|
||||
- A fact lives on one page; everywhere else links to it. The docs tree's README owns the page map and structural invariants; check it before restructuring or adding pages.
|
||||
- For reference pages, inventory the contract from source before drafting prose. Follow the reference process in [writing.md](writing.md#reference-pages).
|
||||
- When unsure how something should scan or sound, match the exemplars: `docs-lab/start/setup.md` for section shape and inventories, `docs-lab/start/installation.md` (Uninstalling) for multi-step tasks.
|
||||
|
||||
## When done
|
||||
|
||||
Show the user what changed and name any unchecked claims.
|
||||
|
||||
If the user asks for the deep, evidence-first drafting session (run every command, one section per sitting, formal checkpoints), follow [full-process.md](full-process.md).
|
||||
@@ -1,49 +0,0 @@
|
||||
# Full drafting process (opt-in)
|
||||
|
||||
The evidence-first, checkpointed way to draft a page. Use this only when the user asks for the deep process; the default mode is SKILL.md alone.
|
||||
|
||||
## Orient (every session, before any writing)
|
||||
|
||||
1. Read the README at the root of the docs tree you're writing in. Where it states invariants or a page map, it wins over this skill.
|
||||
2. Read the target page top to bottom, plus anything its comments cite.
|
||||
3. Read the sibling pages this page links to or overlaps with, enough to know what must stay a link rather than become an explanation.
|
||||
4. Write down the page's job in one line: who arrives, trying to do what, and what they leave able to do. If the page carries a job statement (docs-lab pages use a `>` blockquote under the title), test against it. If the unit you're about to write doesn't serve that job, stop and raise it instead of drafting around it.
|
||||
|
||||
## Work in small units
|
||||
|
||||
- The default unit is one `##` section. A page is several sittings, not one.
|
||||
- For revisions to existing prose, the unit is the requested change, however many headings it touches.
|
||||
- Draft the next unit only after the user has reviewed the current one. When the user asks for fixes, fix only that; don't smuggle in the next unit.
|
||||
|
||||
## Evidence before prose
|
||||
|
||||
Before drafting a unit, know where its claims come from.
|
||||
|
||||
- Run the terminal commands the unit will show when they're cheap: read-only commands anywhere, anything that mutates state in a scratch directory or not at all. Paste real output; trim it, never retouch it.
|
||||
- Check names against source: flags, paths, config keys, and defaults come from `src/` and the CLI's own help, not from older docs. When docs and source disagree, source wins; note the conflict for the user.
|
||||
- Never bridge a gap with a plausible-sounding sentence. A claim you couldn't check gets flagged at the checkpoint, not silently shipped. Don't let one expensive check stall the draft.
|
||||
|
||||
## Strip the slop
|
||||
|
||||
Invoke the `no-ai-slop` skill on the drafted unit and apply its edit pass. Docs prose gets no exemption: the patterns it names read as machine-written to exactly the audience these docs must win over.
|
||||
|
||||
## Does it do the job?
|
||||
|
||||
Reread the unit cold, as the reader the job line names, arriving with their actual problem. Answer three questions:
|
||||
|
||||
1. Can they act? Every step is runnable as written, and nothing depends on knowledge the page hasn't given or linked.
|
||||
2. Do they know it worked? Where success could be in doubt, the unit shows something visible: output, a file, what the agent does next. Where the outcome is obvious, no success line is owed.
|
||||
3. What can they do now that they couldn't before? If the honest answer is "they read some context", the unit is explaining instead of solving; cut it back to what serves the job or raise it with the user.
|
||||
|
||||
A unit that fails here gets fixed before the checkpoint, not annotated.
|
||||
|
||||
## Checkpoint
|
||||
|
||||
End the unit by showing the user:
|
||||
|
||||
- the file path and the unit written;
|
||||
- the page's job in one line, and what this unit lets the reader do toward it;
|
||||
- which claims you checked and how (commands run, files read);
|
||||
- any claim still unchecked.
|
||||
|
||||
Then stop. The next unit starts when the user says so.
|
||||
@@ -1,204 +0,0 @@
|
||||
# OpenSpec docs: the style guide
|
||||
|
||||
Structure, voice, tone, and language for OpenSpec's user docs. This file is the primary style authority for the docs tree. The tree's own README owns structure (the page map and which page teaches what); when this file and that README disagree, the README wins. `no-ai-slop` owns the generic slop patterns; this file owns what OpenSpec's docs specifically look and sound like.
|
||||
|
||||
## Six principles
|
||||
|
||||
Every rule below applies one of these; when rules collide, the principles decide.
|
||||
|
||||
- **A page is a retrieval surface, not an essay.** The reader arrives mid-task with a question, scans for the answer, and leaves. Structure decides whether they find it; prose only decides how it reads. Structure wins.
|
||||
- **The shortest version that answers is the right length, drafted that way from the start.** Expanding a spare page is cheap; cutting a bloated one is a rewrite. Plain words, and the fewest of them: an idea that fits in one line takes one line.
|
||||
- **Dumb sentences, smart structure.** Write the obvious sentence: actor, verb, object, stating the literal event ("Running init creates two things in your project"). Never the version that compresses facts in or takes an angle ("Everything init creates is meant to be committed"). If a sentence needs unpacking, it failed.
|
||||
- **One job per slot.** A sentence carries one fact (one carrying three hides two). A list intro only announces its list. A section owns one reader question or lookup target. Related facts get their own slot, never a ride in someone else's.
|
||||
- **Ground everything in what the reader can verify.** Name things by path, file, or real output: what the reader could match against `ls`. The concept is the gloss, never the name.
|
||||
- **No house template.** Shape follows content: inventories get overview-then-expand, sequences get numbered steps, a single idea gets short paragraphs, and reasoning lives in prose. The universal check is the retrievability test, not bullet count.
|
||||
|
||||
## The retrievability test
|
||||
|
||||
Name the questions or exact product terms a reader would bring to the section ("does init touch `.gitignore`?", "how do I add a tool later?", `generates`). Each answer or term must be findable by scanning, heading to anchor to fact, without reading paragraphs. If finding a fact means reading sentences, restructure; prose that passes needs no bullets, and no amount of bullets saves a section that fails.
|
||||
|
||||
## The shortest draft
|
||||
|
||||
Brevity happens at drafting time, not review. A page that needs heavy cutting in review gets rewritten, and a rewrite costs more than writing it spare the first time. Start from the shortest version that answers and expand only where a real reader question goes unanswered.
|
||||
|
||||
Every slot is earned before it's written:
|
||||
|
||||
- **The unit**: it answers a reader question or documents a lookup target, or it doesn't go in. Tight prose on the wrong scope is still the wrong scope.
|
||||
- **The sentence**: would any reader come back for it? If not, it spends attention without buying anything; don't write it.
|
||||
- **The depth**: an edge case or rationale most readers skip goes behind a link to its canonical page, not inline. The docs keep the depth; this page doesn't charge every reader for it.
|
||||
- **The payload**: the command, the real output, the failure and its fix stay whole. Spare means no wind-up and no commentary, never fewer facts.
|
||||
|
||||
The glance test is the backstop, not the method. Scroll the rendered page and read it as shapes: short units, air between anchors, no screen-filling block of anything. A page that looks like work loses its reader before the first sentence; if yours does, something above got in without earning its slot. For table or layout changes, check both desktop and narrow widths; the Markdown source can't show cramped columns, poor wrapping, or horizontal scrolling.
|
||||
|
||||
## Shape of a section
|
||||
|
||||
- **Answer first**: open with the command, the inventory, or the fact in one line. Context and rationale come after, never first.
|
||||
- **Inventory, then expand**: when a section covers several things (what init installs, what an uninstall leaves behind), open with a list naming every item in one line each, then expand each in its own unit after the list (a subsection or bold lead-in).
|
||||
- **The overview only names**: a count ("two things:") is not an inventory, and expansion never happens inline in the list; the reader sees the whole footprint, then the detail.
|
||||
- **Place first, meaning second**: name each on-disk item by its path or folder ("an `openspec/` folder at the repo root"), never by concept alone ("the planning folder"). The concept gloss can wait for the item's expansion. When a location varies (per tool, per OS), anchor it with a real folder or two ("`.agents/`, `.claude/`") and link the full list.
|
||||
- **Core before nuance**: inside every unit, the answer, then what to expect, then edge cases last. A reader who stops early still leaves with the core.
|
||||
- **One unit per target**: task pages separate different reader questions. Reference pages separate different product elements when readers look them up independently. Two facts with different targets get separate units, even when one elegant sentence could join them.
|
||||
|
||||
## Scan anchors
|
||||
|
||||
Every load-bearing fact sits on an anchor: something the eye lands on without reading. A fact a reader might come back for never lives only in the middle of a paragraph. The anchors these docs use:
|
||||
|
||||
- Code fences, for commands and real output.
|
||||
- Numbered steps with bold lead-ins (`**1. Remove the package.**`) for multi-step tasks.
|
||||
- `**Term**: fact` bullets for options, properties, and locations.
|
||||
- Tables, when several items share the same attributes (mostly reference pages).
|
||||
- File trees with inline annotations for layouts.
|
||||
|
||||
A full screen of content with no anchor is a wall, even when every sentence in it is true.
|
||||
|
||||
## Choosing the shape
|
||||
|
||||
No house template: facts go on anchors (enumerable content defaults to a list or table); explanation, reasoning, and judgment go in prose. The content picks the form:
|
||||
|
||||
- **Sequences**: numbered steps, one bounded action each. Numbers mean order of execution; an inventory of things takes bullets, never numbers. Restate any value a step needs rather than pointing back three steps.
|
||||
- **Options, properties, locations**: `**Term**: fact` bullets.
|
||||
- **Items sharing the same attributes**: a table.
|
||||
- **A single idea** (why a store is worth it, what sync treats as drift): a couple of short paragraphs; that is the right shape.
|
||||
- **Connected reasoning**: a paragraph. Shredding a thought into fragments makes it harder to read, not easier; a bullet list of full explanatory sentences is a paragraph in costume, so write the paragraph.
|
||||
|
||||
Across every form:
|
||||
|
||||
- Cap lists at about five items. Longer than that, split by priority: common path first, edge cases into their own list or a linked page.
|
||||
- Keep items parallel: same internal order (name, fact, catch, link), same grammatical shape. Repetition across items is what makes scanning work; never vary structure between items for the sake of the prose.
|
||||
- Uniformity is right when the content is uniform (a reference table, an install matrix). When every section on a varied page resolves to the same pattern, some of those lists are disguised paragraphs.
|
||||
|
||||
## Prose budget
|
||||
|
||||
Paragraphs are glue between anchors, not containers for facts.
|
||||
|
||||
- One to three lines. Three is the ceiling; a glue line between two anchors is often enough.
|
||||
- The list intro has exactly one job: say what the list is ("Running init creates two things in your project:"). Never spend that slot on a different fact, however related; it gets its own line after the list.
|
||||
- Parentheses and semicolon riders are for true asides only (a version caveat, a pointer). If a reader might return for the fact, it gets its own anchor.
|
||||
- A section that is mostly paragraphs is misshaped, unless the page is genuinely conceptual (Concepts, explanations of the model). Even there, front-load each paragraph and leave air between them.
|
||||
|
||||
## Sentences
|
||||
|
||||
- Short sentences, active voice. Default subject is "you" or the tool by name.
|
||||
- No preamble. The first sentence of any unit states the thing itself, never wind-up ("Before we get into...", "It's worth understanding that...").
|
||||
- No em dashes anywhere in these docs. Use a colon, a comma, parentheses, or two sentences.
|
||||
- Write the sentence you would say out loud. A draft that splices clauses with semicolons or colon-stacked fragments ("different documents: fewer of them, different names, different structure") gets rewritten as the spoken version ("when you want these to be different documents, whether that means fewer of them, different names, or a different structure"). Colons still introduce lists, fences, and labels. They don't splice prose.
|
||||
- Contractions are fine ("you're set", "doesn't come along"). These docs talk, they don't proclaim.
|
||||
- Inside narrative paragraphs, vary sentence length so the prose doesn't read staccato. Paragraphs only; list items stay parallel even when the cadence repeats.
|
||||
|
||||
## Voice
|
||||
|
||||
The narrator is a colleague who has run every command on the page, hit the failure modes personally, and is telling you what they know. Not a marketer, not a tutorial host, not a manual.
|
||||
|
||||
- Calm and specific. The reader wants the fact, the command, and the catch, in that order.
|
||||
- Confidence comes from precision, not emphasis. Never "very", "extremely", "critical", bold-for-importance, or exclamation marks.
|
||||
- Plain judgment is welcome. The docs may tell the reader what to do and what to skip: "The `openspec/` folder: pause first."
|
||||
- Address the reader as "you". OpenSpec, the CLI, and init do things. "We" appears only for project decisions ("we say skills"), never as a tour guide.
|
||||
- Dry beats chirpy. No cheerleading, no apologizing, no drama around failures. A failure is a fact with a fix.
|
||||
|
||||
## Structure and tone by page type
|
||||
|
||||
Same voice everywhere; structure and temperature shift:
|
||||
|
||||
- **Start pages**: numbered steps and short units, nothing assumed, every step ends in something visible. Warmest the docs get, which is still plain.
|
||||
- **Guides**: peer to peer, skip re-orientation. The judgment calls are the reason guides exist; put them on anchors so they scan.
|
||||
- **Reference**: mirror the product, use its exact names as anchors, and cover the contract without compressing it. Tables and fragments are common, but scan speed decides the shape. No motivation or persuasion; the reader is here to look something up and leave.
|
||||
- **Troubleshooting**: symptom, cause, fix, in that order, one unit per symptom. Name the error the reader sees. Never "you may notice" or "sometimes it can happen that".
|
||||
|
||||
Guides and Customize pages share one skeleton: a one-line what, a link to the Quickstart (never a recap), the 80% path, then Advanced. The exception is the concepts page, which is an explanation, not a task guide; its shape follows its concerns.
|
||||
|
||||
## Reference pages
|
||||
|
||||
Reference describes the product for a reader who is already working with it. The outline follows the machinery: file, block, field; command group, command, option; object, property, value. Use the product's exact names as headings when readers will search for those names. Reader-question headings belong to task pages unless the question itself is the established lookup term.
|
||||
|
||||
Cover the full contract without packing several facts into one sentence, cell, or paragraph.
|
||||
|
||||
### Draft the contract first
|
||||
|
||||
Before writing prose:
|
||||
|
||||
1. Inventory the product elements from source.
|
||||
2. Arrange them in the same hierarchy as the product.
|
||||
3. Write the smallest complete contract for each element.
|
||||
4. Expand only the elements whose behavior needs more room.
|
||||
5. Add examples that illustrate one rule at a time.
|
||||
6. Audit defaults, constraints, failures, ignored input, and validation gaps.
|
||||
|
||||
For each field, option, command, or file, record the identity facts that apply:
|
||||
|
||||
- Exact name and syntax
|
||||
- Type or accepted values
|
||||
- Required state and default
|
||||
- Scope, location, or base path
|
||||
|
||||
Then record the behavior facts that apply:
|
||||
|
||||
- Behavior and side effects
|
||||
- Constraints
|
||||
- Failure and ignored-input behavior
|
||||
- What validation catches and misses
|
||||
|
||||
Don't create empty sections or table columns for facts that don't apply.
|
||||
|
||||
### Inventory, then expand
|
||||
|
||||
Open with a complete table or list. Expand an item below the inventory only when its behavior can't fit cleanly in the overview. Put the expansion under the item's exact name so the table of contents works as an index.
|
||||
|
||||
For field and option references, `Field | Contract` is the safe table shape when definitions need sentences. Add more columns only when every cell is short and comparable. If columns split one coherent definition into fragments or wrap badly at a narrow width, use fewer columns or move the detail below the inventory.
|
||||
|
||||
### Examples and edge cases
|
||||
|
||||
An example illustrates one mapping, rule, or result. It doesn't become a sequence the reader follows or a narrative about completing a task. A complete example may follow the contract when seeing the elements together helps lookup.
|
||||
|
||||
Put the concrete default path or value in the primary slot. Put environment variables and uncommon overrides afterward.
|
||||
|
||||
State the observable consequence of a limit. If OpenSpec ignores a misspelled field, say that validation passes and the field has no effect. If a value falls back, name the value OpenSpec uses.
|
||||
|
||||
## Two surfaces
|
||||
|
||||
OpenSpec spans the terminal and the AI chat, and readers mix them up. Label every snippet:
|
||||
|
||||
```
|
||||
In your terminal:
|
||||
openspec init
|
||||
|
||||
In your AI chat:
|
||||
/opsx:propose add-rate-limit
|
||||
```
|
||||
|
||||
Where the reader could doubt it worked (a fresh install, a first run, a command with no output of its own), end with the concrete success signal: the line the command prints, the file that now exists, what the agent says next. Where the outcome is obvious, stop; an unneeded success line is noise.
|
||||
|
||||
## Authoring mechanics
|
||||
|
||||
Pages are plain markdown; GitHub and the site both render them. JSX components (`<Callout>`, `<Tabs>`, `<details>`) don't render; never use them.
|
||||
|
||||
- **Install commands**: write the global npm command once, in a fence whose language is `npm`; the site renders it as npm/pnpm/yarn/bun tabs with a copy button per tab (`remarkNpm` in `website/source.config.ts`, which also persists the reader's choice across blocks). On GitHub the fence degrades to the plain npm command.
|
||||
- **Callouts**: GitHub-style blockquote alerts (`> [!NOTE]`, `> [!TIP]`, `> [!IMPORTANT]`, `> [!WARNING]`, `> [!CAUTION]`); GitHub styles them natively and the site renders them as callouts (`remarkGfmAlert` in `website/lib/remark-gfm-alert.ts`). Never place one directly under the page title: the sync lifts the leading blockquote into the page description.
|
||||
|
||||
## What earns a developer's trust
|
||||
|
||||
- Show the real command and its real output, trimmed honestly. A retouched output is a lie the reader catches on their first run.
|
||||
- No hype and no comfort adjectives: easy, simple, just, powerful, seamless, robust. Three lines that show the thing beat any adjective about it.
|
||||
- State limits plainly. A named limitation builds more trust than praise: "Your assistant does need to be able to run shell commands; a few IDE integrations can't."
|
||||
- Don't generalize. Where you're tempted to write what OpenSpec "helps" with, write what actually happens: which file appears, what the diff shows, what the agent does next.
|
||||
- Don't define what you can show. An unfamiliar term whose instances explain themselves (the workflow list: propose, explore, apply...) is introduced by showing the instances with one-phrase glosses; the abstraction can wait.
|
||||
- Exact names: flags, paths, config keys, and versions as they exist in source, linked to their canonical page on first use.
|
||||
|
||||
## Naming and terms
|
||||
|
||||
- One term per concept, the glossary's term if the tree has one; today that means "skills", never "slash commands".
|
||||
- No invented taxonomy. Product terms (spec, change, delta, profile, store) name real things; use them freely. Any other organizing word in a heading or goal ("layers", "levers", "pillars") must pass one test: would a reader use it to ask their own question? If not, write the reader's question or the plain enumeration ("What you can customize", never "The three layers").
|
||||
- Examples invoke workflows by skill: the ask that triggers it ("ask your agent to propose a change") or the skill's name (`openspec-propose`), which is the same in every tool. A command spelling (`/opsx:propose`) appears only as a labeled per-tool example, never as the generic instruction; commands are headed for deprecation and their spellings vary per tool.
|
||||
- Prefer the shared `.agents/` folder in file-path examples; a tool-specific folder (`.claude/`) appears only when the example is about that tool.
|
||||
- Headings lead with a verb when the section is something the reader does ("Initialize your project"). Found content takes a plain noun phrase ("Install methods"). Never a vague verb ("Understand it") and never a pun.
|
||||
- If the page carries a one-line job statement under the title (docs-lab uses a `>` blockquote the site lifts into the page description), keep it plain, concrete, and true of the finished page.
|
||||
|
||||
## One canonical home
|
||||
|
||||
A fact lives on exactly one page; everywhere else links to it. A second copy is a future contradiction. The tree's README says which page owns what; when in doubt, link.
|
||||
|
||||
## Exemplars
|
||||
|
||||
When unsure how something should scan or sound, match these:
|
||||
|
||||
- `docs-lab/start/setup.md`: section shape, inventory-then-expand, enumerable facts on bullets.
|
||||
- `docs-lab/start/installation.md`, the Uninstalling section: multi-step tasks with bold numbered lead-ins.
|
||||
+11
-13
@@ -12,12 +12,11 @@ Follow the prompts to select version bump type and describe your changes.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Choose the release path**: Maintainers decide whether a PR follows the normal release cadence or gets dedicated release tracking.
|
||||
2. **Add dedicated release tracking**: When a maintainer asks for a changeset, run `pnpm changeset` locally before or after your PR.
|
||||
3. **Version PR**: CI opens/updates a "Version Packages" PR when changesets merge to main.
|
||||
4. **Release**: Merging the Version PR triggers npm publish and GitHub Release.
|
||||
1. **Add a changeset** — Run `pnpm changeset` locally before or after your PR
|
||||
2. **Version PR** — CI opens/updates a "Version Packages" PR when changesets merge to main
|
||||
3. **Release** — Merging the Version PR triggers npm publish and GitHub Release
|
||||
|
||||
> **Note:** The default path is the normal release cadence. Add a changeset when a maintainer or release owner wants dedicated release notes and version tracking for the PR. Versioning (`changeset version`) and publishing happen automatically in CI.
|
||||
> **Note:** Contributors only need to run `pnpm changeset`. Versioning (`changeset version`) and publishing happen automatically in CI.
|
||||
|
||||
## Template
|
||||
|
||||
@@ -55,23 +54,22 @@ Include only the sections relevant to your change.
|
||||
|
||||
| Type | When to use | Example |
|
||||
|------|-------------|---------|
|
||||
| `patch` | Release-tracked bug fixes, small improvements | Fixed crash when config missing |
|
||||
| `patch` | Bug fixes, small improvements | Fixed crash when config missing |
|
||||
| `minor` | New features, non-breaking additions | Added `--verbose` flag |
|
||||
| `major` | Breaking changes, removed features | Renamed `init` to `setup` |
|
||||
|
||||
## When to Create a Changeset
|
||||
|
||||
**Use dedicated release tracking for:**
|
||||
- New features or commands selected for release
|
||||
- Notable bug fixes or hotfixes requested by a maintainer/release owner
|
||||
**Create one for:**
|
||||
- New features or commands
|
||||
- Bug fixes that affect users
|
||||
- Breaking changes or deprecations
|
||||
- Performance improvements users would notice and that are planned for release
|
||||
- Performance improvements users would notice
|
||||
|
||||
**Use the normal release cadence for:**
|
||||
- Routine bug fixes that fit the normal release cadence
|
||||
**Skip for:**
|
||||
- Documentation-only changes
|
||||
- Test additions/fixes
|
||||
- Internal refactoring that preserves user behavior
|
||||
- Internal refactoring with no user impact
|
||||
- CI/tooling changes
|
||||
|
||||
## Writing Good Descriptions
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "OpenSpec Development",
|
||||
"image": "mcr.microsoft.com/devcontainers/typescript-node:1-22-bookworm",
|
||||
"image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm",
|
||||
|
||||
// Additional tools and features
|
||||
"features": {
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
# The skills.sh distribution files are generated LF-only and compared
|
||||
# byte-for-byte by test/core/templates/skillssh-parity.test.ts. Force LF on
|
||||
# checkout so Windows autocrlf doesn't turn them into CRLF and fail parity.
|
||||
skills/** text eol=lf
|
||||
+1
-4
@@ -1,5 +1,2 @@
|
||||
# Default code ownership
|
||||
* @Fission-AI/openspec-maintainers
|
||||
|
||||
# Route docs-lab changes to the docs owner for review
|
||||
/docs-lab/ @TabishB
|
||||
* @TabishB
|
||||
|
||||
@@ -1,68 +0,0 @@
|
||||
name: Bug report
|
||||
description: Something in OpenSpec does not work the way it should.
|
||||
labels: ['bug', 'needs-triage']
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Thanks for reporting this.
|
||||
|
||||
You can also run `openspec feedback "your report"` to submit an issue
|
||||
immediately with your version and platform, or get a submission link
|
||||
if GitHub CLI is unavailable or unauthenticated.
|
||||
|
||||
- type: textarea
|
||||
id: what_happened
|
||||
attributes:
|
||||
label: What happened
|
||||
description: The actual behavior. Paste the command you ran and its output if you have it.
|
||||
placeholder: |
|
||||
I ran `openspec archive add-login` and it exited 0 without writing the main spec.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: expected
|
||||
attributes:
|
||||
label: What you expected instead
|
||||
placeholder: The main spec at openspec/specs/auth/spec.md should have been updated.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: repro
|
||||
attributes:
|
||||
label: Minimal steps to reproduce
|
||||
description: The shortest path from a fresh project to the problem. This is the single most useful thing you can give us.
|
||||
placeholder: |
|
||||
1. `openspec init` in an empty directory
|
||||
2. ...
|
||||
3. ...
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: version
|
||||
attributes:
|
||||
label: OpenSpec version
|
||||
description: Output of `openspec --version`, or "unknown" if installation failed or the command cannot run.
|
||||
placeholder: '1.11.0'
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: agent
|
||||
attributes:
|
||||
label: Coding agent and model
|
||||
description: Which agent and model were driving OpenSpec, if any. Behavior often differs between them.
|
||||
placeholder: Claude Code, Opus 4.6
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: input
|
||||
id: environment
|
||||
attributes:
|
||||
label: OS and Node version
|
||||
placeholder: macOS 15.6, Node 22.11.0
|
||||
validations:
|
||||
required: false
|
||||
@@ -1,12 +0,0 @@
|
||||
# Keep the prefilled blank-issue URL from `openspec feedback` working.
|
||||
blank_issues_enabled: true
|
||||
contact_links:
|
||||
- name: Core design change
|
||||
url: https://github.com/Fission-AI/OpenSpec/discussions/categories/ideas
|
||||
about: Anything that changes how OpenSpec works at its core starts as a discussion, per CONTRIBUTING step 1.
|
||||
- name: Question or help with your setup
|
||||
url: https://github.com/Fission-AI/OpenSpec/discussions/categories/q-a
|
||||
about: Not sure whether it is a bug? Ask here and we will help you narrow it down.
|
||||
- name: Discord
|
||||
url: https://discord.gg/YctCnvvshC
|
||||
about: Chat with the community and the maintainers.
|
||||
@@ -1,44 +0,0 @@
|
||||
name: Feature request
|
||||
description: Something OpenSpec should do that it does not do yet.
|
||||
labels: ['enhancement', 'needs-triage']
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
If this would change OpenSpec's core design, open a
|
||||
[discussion](https://github.com/Fission-AI/OpenSpec/discussions) instead — see
|
||||
[CONTRIBUTING.md](https://github.com/Fission-AI/OpenSpec/blob/main/CONTRIBUTING.md).
|
||||
|
||||
- type: textarea
|
||||
id: problem
|
||||
attributes:
|
||||
label: The problem, in one or two sentences
|
||||
description: What you were trying to do, and where OpenSpec got in the way. Describe the problem, not the solution.
|
||||
placeholder: There is no way to tell which change a spec came from after it is archived.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: who
|
||||
attributes:
|
||||
label: Who this affects
|
||||
description: Just you, everyone on a particular agent, everyone using a particular workflow, or everyone. OpenSpec serves many agents and models, so this shapes whether a change fits.
|
||||
placeholder: Anyone archiving more than a handful of changes.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: tried
|
||||
attributes:
|
||||
label: What you tried
|
||||
description: Existing commands, flags, or workarounds you reached for, and why they fell short.
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: textarea
|
||||
id: proposal
|
||||
attributes:
|
||||
label: What you have in mind
|
||||
description: Optional. A sketch is fine — we will agree on the approach before anyone builds it.
|
||||
validations:
|
||||
required: false
|
||||
@@ -1,30 +0,0 @@
|
||||
Closes #
|
||||
|
||||
<!--
|
||||
No issue yet? Every change starts with one (CONTRIBUTING step 1).
|
||||
Run `openspec feedback "your report"` to submit immediately, or open one here:
|
||||
https://github.com/Fission-AI/OpenSpec/issues/new/choose
|
||||
|
||||
Already discussed instead of filed? Replace the line above with a link to the discussion.
|
||||
-->
|
||||
|
||||
## What this changes
|
||||
|
||||
<!-- What was wrong or missing, and what the new behavior is. Plain language. -->
|
||||
|
||||
## How you verified it
|
||||
|
||||
<!--
|
||||
The failing-then-passing test, repro steps, or before/after output.
|
||||
Run the core checks for code changes:
|
||||
pnpm build && pnpm test && pnpm exec tsc --noEmit && pnpm lint
|
||||
-->
|
||||
|
||||
## Notes
|
||||
|
||||
<!-- Optional: scope limits, follow-ups, anything non-blocking. -->
|
||||
|
||||
---
|
||||
|
||||
- [ ] Ran `pnpm changeset` if this affects users, and committed the file
|
||||
- [ ] If a coding agent wrote this, named the agent and model in the Notes section, and verified the result myself
|
||||
@@ -1,106 +0,0 @@
|
||||
version: 2
|
||||
|
||||
# Dependabot does not manage two dependency surfaces in this repo:
|
||||
# 1. pnpm `overrides` (pnpm-workspace.yaml, root and website) — transitive
|
||||
# version pins that remediate advisories Dependabot can't otherwise reach.
|
||||
# It never bumps or removes these; each carries an inline advisory comment
|
||||
# noting the removal condition (see pnpm-workspace.yaml). They live in
|
||||
# pnpm-workspace.yaml only, because Dependabot *does* rewrite a plain-name
|
||||
# override (`postcss: ^8.5.26`) mirrored under package.json's `pnpm.overrides`
|
||||
# — and that block replaces the workspace list rather than merging with it,
|
||||
# so the mirror displaces the real pins. See #1812.
|
||||
# 2. The Nix flake (flake.nix / flake.lock). Update nixpkgs manually with
|
||||
# `nix flake update`; there is no Dependabot ecosystem for Nix. Note that the
|
||||
# pnpmDeps FOD hash in flake.nix must be regenerated on any root lockfile change.
|
||||
|
||||
updates:
|
||||
# Published CLI package
|
||||
- package-ecosystem: npm
|
||||
directory: /
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
# Let a freshly published version sit before adopting it. Security updates
|
||||
# ignore the cooldown, so this only delays routine bumps — long enough for a
|
||||
# compromised release to be yanked before it reaches this repo.
|
||||
cooldown:
|
||||
default-days: 7
|
||||
semver-major-days: 30
|
||||
semver-minor-days: 7
|
||||
semver-patch-days: 3
|
||||
open-pull-requests-limit: 5
|
||||
ignore:
|
||||
- dependency-name: "@types/node"
|
||||
update-types:
|
||||
- version-update:semver-major
|
||||
# Chalk 6 requires Node 22, while the published CLI supports Node 20.19.
|
||||
- dependency-name: "chalk"
|
||||
update-types:
|
||||
- version-update:semver-major
|
||||
- dependency-name: "typescript"
|
||||
update-types:
|
||||
- version-update:semver-major
|
||||
commit-message:
|
||||
prefix: chore
|
||||
include: scope
|
||||
groups:
|
||||
production-dependencies:
|
||||
dependency-type: production
|
||||
update-types:
|
||||
- minor
|
||||
- patch
|
||||
development-dependencies:
|
||||
dependency-type: development
|
||||
update-types:
|
||||
- minor
|
||||
- patch
|
||||
|
||||
# Documentation site (not published to npm)
|
||||
- package-ecosystem: npm
|
||||
directory: /website
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
# Let a freshly published version sit before adopting it. Security updates
|
||||
# ignore the cooldown, so this only delays routine bumps — long enough for a
|
||||
# compromised release to be yanked before it reaches this repo.
|
||||
cooldown:
|
||||
default-days: 7
|
||||
semver-major-days: 30
|
||||
semver-minor-days: 7
|
||||
semver-patch-days: 3
|
||||
open-pull-requests-limit: 3
|
||||
ignore:
|
||||
- dependency-name: "@types/node"
|
||||
update-types:
|
||||
- version-update:semver-major
|
||||
- dependency-name: "typescript"
|
||||
update-types:
|
||||
- version-update:semver-major
|
||||
commit-message:
|
||||
prefix: chore
|
||||
include: scope
|
||||
groups:
|
||||
website-dependencies:
|
||||
patterns:
|
||||
- "*"
|
||||
update-types:
|
||||
- minor
|
||||
- patch
|
||||
|
||||
# CI workflow actions
|
||||
- package-ecosystem: github-actions
|
||||
directory: /
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
# Actions are not semver-versioned the way packages are, so this ecosystem
|
||||
# accepts default-days only.
|
||||
cooldown:
|
||||
default-days: 7
|
||||
commit-message:
|
||||
prefix: ci
|
||||
groups:
|
||||
github-actions:
|
||||
patterns:
|
||||
- "*"
|
||||
+94
-165
@@ -25,12 +25,10 @@ jobs:
|
||||
nix: ${{ steps.filter.outputs.nix }}
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Check for Nix-related changes
|
||||
uses: dorny/paths-filter@ceb8a2b8f2d89434be7ff52d3de7ec3738c5cc9d # v4
|
||||
uses: dorny/paths-filter@v3
|
||||
id: filter
|
||||
with:
|
||||
filters: |
|
||||
@@ -39,19 +37,53 @@ jobs:
|
||||
- 'flake.lock'
|
||||
- 'package.json'
|
||||
- 'pnpm-lock.yaml'
|
||||
- 'pnpm-workspace.yaml'
|
||||
- 'scripts/update-flake.sh'
|
||||
- '.github/workflows/ci.yml'
|
||||
# The Nix build runs `openspec completion generate`, so a change to
|
||||
# the generator can break packaging without touching flake.nix.
|
||||
- 'src/commands/completion.ts'
|
||||
- 'src/core/completions/**'
|
||||
|
||||
test_pr:
|
||||
name: Test
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 10
|
||||
if: github.event_name == 'pull_request' || github.event_name == 'merge_group'
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Install dependencies
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Build project
|
||||
run: pnpm run build
|
||||
|
||||
- name: Run tests
|
||||
run: pnpm test
|
||||
|
||||
- name: Upload test coverage
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: coverage-report-pr
|
||||
path: coverage/
|
||||
retention-days: 7
|
||||
|
||||
test_matrix:
|
||||
name: Test (${{ matrix.label }})
|
||||
runs-on: ${{ matrix.os }}
|
||||
timeout-minutes: 15
|
||||
if: github.event_name == 'pull_request' || github.event_name == 'merge_group' || github.event_name == 'push' || github.event_name == 'workflow_dispatch'
|
||||
if: github.event_name == 'push'
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
@@ -59,15 +91,12 @@ jobs:
|
||||
- os: ubuntu-latest
|
||||
shell: bash
|
||||
label: linux-bash
|
||||
vitest_workers: 4
|
||||
- os: macos-latest
|
||||
shell: bash
|
||||
label: macos-bash
|
||||
vitest_workers: 4
|
||||
- os: windows-latest
|
||||
shell: pwsh
|
||||
label: windows-pwsh
|
||||
vitest_workers: 2
|
||||
|
||||
defaults:
|
||||
run:
|
||||
@@ -75,18 +104,19 @@ jobs:
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
persist-credentials: false
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20.19.0'
|
||||
node-version: '20'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Print environment diagnostics
|
||||
@@ -100,48 +130,32 @@ jobs:
|
||||
run: pnpm run build
|
||||
|
||||
- name: Run tests
|
||||
env:
|
||||
VITEST_MAX_WORKERS: ${{ matrix.vitest_workers }}
|
||||
run: pnpm test
|
||||
|
||||
- name: Upload test coverage
|
||||
if: matrix.os == 'ubuntu-latest'
|
||||
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: coverage-report-${{ github.event_name }}
|
||||
name: coverage-report-main
|
||||
path: coverage/
|
||||
retention-days: 7
|
||||
|
||||
test_pr_required:
|
||||
name: Test
|
||||
runs-on: ubuntu-latest
|
||||
needs: [test_matrix]
|
||||
if: always() && (github.event_name == 'pull_request' || github.event_name == 'merge_group')
|
||||
steps:
|
||||
- name: Verify matrix tests passed
|
||||
run: |
|
||||
if [[ "${{ needs.test_matrix.result }}" != "success" ]]; then
|
||||
echo "Matrix test job failed"
|
||||
exit 1
|
||||
fi
|
||||
echo "All matrix tests passed!"
|
||||
|
||||
lint:
|
||||
name: Lint & Type Check
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20.19.0'
|
||||
node-version: '20'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Install dependencies
|
||||
@@ -175,81 +189,13 @@ jobs:
|
||||
if: needs.changes.outputs.nix == 'true'
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Install Nix
|
||||
uses: DeterminateSystems/nix-installer-action@3138316df39ed29be04236d7ffc686fa525866aa # v23
|
||||
uses: DeterminateSystems/nix-installer-action@v21
|
||||
|
||||
- name: Setup Nix cache
|
||||
uses: DeterminateSystems/magic-nix-cache-action@84c0677f58dcedf3b91f8223ce36a9ea5b3c84b7 # v15
|
||||
with:
|
||||
# Dependabot runs cannot access the FlakeHub credentials available to
|
||||
# regular CI, so keep those runs on the GitHub Actions cache.
|
||||
use-flakehub: ${{ github.event.pull_request.user.login == 'dependabot[bot]' && 'disabled' || 'no-preference' }}
|
||||
use-gha-cache: ${{ github.event.pull_request.user.login == 'dependabot[bot]' && 'enabled' || 'no-preference' }}
|
||||
|
||||
# Run the update script before `nix build`, not after. The script recomputes
|
||||
# the pnpmDeps hash from pnpm-lock.yaml and rewrites flake.nix in place, so a
|
||||
# stale hash is reported here as the exact value to paste. Built first, the
|
||||
# same staleness surfaces as pnpm's ERR_PNPM_NO_OFFLINE_TARBALL — which names
|
||||
# a missing tarball, not the hash — and the script never runs to say otherwise.
|
||||
# Every root lockfile change needs this value, and Dependabot cannot produce it.
|
||||
- name: Verify pnpmDeps hash matches the lockfile
|
||||
run: |
|
||||
bash scripts/update-flake.sh
|
||||
if git diff --quiet flake.nix; then
|
||||
echo "✅ flake.nix pnpmDeps hash is up to date"
|
||||
exit 0
|
||||
fi
|
||||
# Scoped to the pnpmDeps block: a bare first-match would report some other
|
||||
# FOD's hash if one is ever added above it.
|
||||
HASH=$(sed -n '/pnpmDeps = /,/};/p' flake.nix \
|
||||
| sed -nE 's/.*hash = "(sha256-[^"]+)".*/\1/p' | head -1)
|
||||
git diff flake.nix
|
||||
echo "::error file=flake.nix::Stale pnpmDeps hash. Set pnpmDeps.hash to $HASH and push."
|
||||
exit 1
|
||||
|
||||
- name: Restore flake.nix
|
||||
if: always()
|
||||
run: git checkout -- flake.nix || true
|
||||
|
||||
- name: Test downstream overlay composition
|
||||
run: |
|
||||
# Interpolation belongs to Nix, not the shell.
|
||||
# shellcheck disable=SC2016
|
||||
nix eval --impure --expr '
|
||||
let
|
||||
flake = builtins.getFlake (toString ./.);
|
||||
system = builtins.currentSystem;
|
||||
pkgs = import flake.inputs.nixpkgs {
|
||||
inherit system;
|
||||
overlays = [ flake.overlays.default ];
|
||||
};
|
||||
composed = import flake.inputs.nixpkgs {
|
||||
inherit system;
|
||||
overlays = [
|
||||
flake.overlays.default
|
||||
(_final: prev: {
|
||||
nodejs_22 = prev.nodejs_22.overrideAttrs (_: {
|
||||
pname = "openspec-test-nodejs";
|
||||
});
|
||||
})
|
||||
];
|
||||
};
|
||||
overridden = pkgs.openspec.overrideAttrs (_: { version = "0.0.0-test"; });
|
||||
in
|
||||
assert pkgs.openspec.drvPath == flake.packages.${system}.default.drvPath;
|
||||
assert pkgs.openspec.drvPath == flake.packages.${system}.openspec.drvPath;
|
||||
# stdenv selects the dev output of multi-output native build inputs.
|
||||
assert builtins.any (input: input.drvPath == composed.nodejs_22.drvPath)
|
||||
composed.openspec.nativeBuildInputs;
|
||||
assert composed.openspec.drvPath != pkgs.openspec.drvPath;
|
||||
assert overridden.version == "0.0.0-test";
|
||||
assert overridden.pnpmDeps.version == "0.0.0-test";
|
||||
true
|
||||
'
|
||||
uses: DeterminateSystems/magic-nix-cache-action@v13
|
||||
|
||||
- name: Build with Nix
|
||||
run: nix build
|
||||
@@ -264,19 +210,6 @@ jobs:
|
||||
echo "Error: openspec binary not found in build output"
|
||||
exit 1
|
||||
fi
|
||||
for completion in \
|
||||
"share/bash-completion/completions/openspec.bash" \
|
||||
"share/fish/vendor_completions.d/openspec.fish" \
|
||||
"share/zsh/site-functions/_openspec"; do
|
||||
if [ ! -s "result/$completion" ]; then
|
||||
echo "Error: completion script missing or empty: $completion"
|
||||
exit 1
|
||||
fi
|
||||
done
|
||||
if [ "$(head -1 result/share/zsh/site-functions/_openspec)" != "#compdef openspec" ]; then
|
||||
echo "Error: zsh completion is not autoloadable (missing #compdef header)"
|
||||
exit 1
|
||||
fi
|
||||
echo "✅ Build output verified"
|
||||
|
||||
- name: Test binary execution
|
||||
@@ -289,71 +222,67 @@ jobs:
|
||||
fi
|
||||
echo "✅ Binary execution successful"
|
||||
|
||||
- name: Validate update script
|
||||
run: |
|
||||
echo "Testing update-flake.sh script..."
|
||||
bash scripts/update-flake.sh
|
||||
echo "✅ Update script executed successfully"
|
||||
|
||||
- name: Check flake.nix modifications
|
||||
run: |
|
||||
if git diff --quiet flake.nix; then
|
||||
echo "ℹ️ flake.nix unchanged (hash already up-to-date)"
|
||||
else
|
||||
echo "✅ flake.nix was updated by script"
|
||||
git diff flake.nix
|
||||
fi
|
||||
|
||||
- name: Restore flake.nix
|
||||
if: always()
|
||||
run: git checkout -- flake.nix || true
|
||||
|
||||
validate-changesets:
|
||||
name: Validate Release Tracking
|
||||
name: Validate Changesets
|
||||
runs-on: ubuntu-latest
|
||||
if: github.event_name == 'pull_request' || github.event_name == 'merge_group'
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
persist-credentials: false
|
||||
|
||||
- name: Determine release tracking
|
||||
id: changed-changesets
|
||||
run: |
|
||||
changed_changesets="$(git diff --name-only --diff-filter=ACMRT origin/main...HEAD -- '.changeset/*.md' ':!.changeset/README.md')"
|
||||
if [[ -n "$changed_changesets" ]]; then
|
||||
echo "has_changesets=true" >> "$GITHUB_OUTPUT"
|
||||
# Run-unique delimiter: the value is a list of PR-authored paths, so a
|
||||
# fixed "EOF" would let a crafted path close the block early and append
|
||||
# its own key=value outputs.
|
||||
delim="EOF_$(openssl rand -hex 16)"
|
||||
{
|
||||
echo "files<<$delim"
|
||||
echo "$changed_changesets"
|
||||
echo "$delim"
|
||||
} >> "$GITHUB_OUTPUT"
|
||||
else
|
||||
echo "has_changesets=false" >> "$GITHUB_OUTPUT"
|
||||
echo "This PR follows the normal release cadence; continuing with standard validation"
|
||||
fi
|
||||
|
||||
- name: Setup pnpm
|
||||
if: steps.changed-changesets.outputs.has_changesets == 'true'
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9
|
||||
|
||||
- name: Setup Node.js
|
||||
if: steps.changed-changesets.outputs.has_changesets == 'true'
|
||||
uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '24'
|
||||
node-version: '20'
|
||||
cache: 'pnpm'
|
||||
|
||||
- name: Install dependencies
|
||||
if: steps.changed-changesets.outputs.has_changesets == 'true'
|
||||
run: pnpm install --frozen-lockfile
|
||||
|
||||
- name: Validate release-tracked changesets
|
||||
if: steps.changed-changesets.outputs.has_changesets == 'true'
|
||||
env:
|
||||
CHANGESET_FILES: ${{ steps.changed-changesets.outputs.files }}
|
||||
- name: Validate changesets
|
||||
run: |
|
||||
echo "Validating changed changesets:"
|
||||
printf '%s\n' "$CHANGESET_FILES"
|
||||
pnpm exec changeset status --since=origin/main
|
||||
if command -v changeset &> /dev/null; then
|
||||
pnpm exec changeset status --since=origin/main
|
||||
else
|
||||
echo "Changesets not configured, skipping validation"
|
||||
fi
|
||||
|
||||
required-checks-pr:
|
||||
name: All checks passed
|
||||
runs-on: ubuntu-latest
|
||||
needs: [test_matrix, lint, nix-flake-validate]
|
||||
needs: [test_pr, lint, nix-flake-validate]
|
||||
if: always() && (github.event_name == 'pull_request' || github.event_name == 'merge_group')
|
||||
steps:
|
||||
- name: Verify all checks passed
|
||||
run: |
|
||||
if [[ "${{ needs.test_matrix.result }}" != "success" ]]; then
|
||||
echo "Matrix test job failed"
|
||||
if [[ "${{ needs.test_pr.result }}" != "success" ]]; then
|
||||
echo "Test job failed"
|
||||
exit 1
|
||||
fi
|
||||
if [[ "${{ needs.lint.result }}" != "success" ]]; then
|
||||
|
||||
@@ -1,15 +1,12 @@
|
||||
name: Release
|
||||
name: Release (prepare)
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
workflow_dispatch: # manually cut a beta prerelease from main
|
||||
|
||||
# Floor for both jobs. The prepare job widens this to pull-requests: write for
|
||||
# the Version Packages PR; the beta job only tags/releases + publishes via OIDC
|
||||
# and needs no PR access, so it inherits this narrower default.
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: write
|
||||
id-token: write # Required for npm OIDC trusted publishing
|
||||
|
||||
concurrency:
|
||||
@@ -18,31 +15,29 @@ concurrency:
|
||||
|
||||
jobs:
|
||||
prepare:
|
||||
if: github.repository == 'Fission-AI/OpenSpec' && github.event_name == 'push'
|
||||
if: github.repository == 'Fission-AI/OpenSpec'
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: write # changesets opens/updates the Version Packages PR
|
||||
id-token: write # Required for npm OIDC trusted publishing
|
||||
steps:
|
||||
# Generate GitHub App token first - used for checkout and changesets
|
||||
# This allows git operations to trigger CI workflows on the version PR
|
||||
# (GITHUB_TOKEN cannot trigger workflows by design)
|
||||
- name: Generate GitHub App Token
|
||||
id: app-token
|
||||
uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3
|
||||
uses: actions/create-github-app-token@v2
|
||||
with:
|
||||
app-id: ${{ vars.APP_ID }}
|
||||
private-key: ${{ secrets.APP_PRIVATE_KEY }}
|
||||
|
||||
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
token: ${{ steps.app-token.outputs.token }}
|
||||
|
||||
- uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
- uses: pnpm/action-setup@v4
|
||||
with:
|
||||
version: 9
|
||||
|
||||
- uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '24' # Node 24 includes npm 11.5.1+ required for OIDC
|
||||
cache: 'pnpm'
|
||||
@@ -53,140 +48,13 @@ jobs:
|
||||
# Opens/updates the Version Packages PR; publishes when the Version PR merges
|
||||
- name: Create/Update Version PR
|
||||
id: changesets
|
||||
uses: changesets/action@ae32849d5ba541f9ae29e40e22a623bc13562f51 # v2.1.2
|
||||
uses: changesets/action@v1
|
||||
with:
|
||||
github-token: ${{ steps.app-token.outputs.token }}
|
||||
pr-title: 'chore(release): version packages'
|
||||
create-github-releases: true
|
||||
# Preserve the v1 release path: pushes use the GitHub App token from
|
||||
# checkout so version PR updates trigger their normal CI workflows.
|
||||
push-with-git-cli: true
|
||||
title: 'chore(release): version packages'
|
||||
createGithubReleases: true
|
||||
# Use CI-specific release script: relies on version PR having been merged
|
||||
# so package.json already contains the bumped version.
|
||||
publish-script: pnpm run release:ci
|
||||
publish: pnpm run release:ci
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
|
||||
# npm authentication handled via OIDC trusted publishing (no token needed)
|
||||
|
||||
# Manually-dispatched beta prerelease from main: version is the next stable
|
||||
# release per pending changesets with a -beta.N suffix (e.g. v1.6.0-beta.1),
|
||||
# published to npm under the `beta` dist-tag and posted as a prerelease-flagged
|
||||
# GitHub Release. Changesets are left unconsumed, so the stable flow above is
|
||||
# unaffected. This job lives in this file because npm trusted publishing
|
||||
# authorizes a single workflow file per package.
|
||||
#
|
||||
# Users opt in with: npm install -g @fission-ai/openspec@beta
|
||||
beta:
|
||||
if: github.repository == 'Fission-AI/OpenSpec' && github.event_name == 'workflow_dispatch' && github.ref == 'refs/heads/main'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
fetch-depth: 0
|
||||
|
||||
- uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
|
||||
- uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
with:
|
||||
node-version: '24' # Node 24 includes npm 11.5.1+ required for OIDC
|
||||
cache: 'pnpm'
|
||||
registry-url: 'https://registry.npmjs.org'
|
||||
|
||||
- run: pnpm install --frozen-lockfile
|
||||
|
||||
# Beta version = next stable version per pending changesets, plus a
|
||||
# -beta.N suffix that increments over existing beta tags for that version.
|
||||
- name: Compute beta version
|
||||
id: version
|
||||
env:
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
run: |
|
||||
git fetch --tags --force origin
|
||||
pnpm exec changeset status --output=changeset-status.json
|
||||
NEXT=$(node -p "JSON.parse(require('fs').readFileSync('changeset-status.json','utf8')).releases[0]?.newVersion ?? ''")
|
||||
rm changeset-status.json
|
||||
if [ -z "$NEXT" ]; then
|
||||
echo "No pending changesets on main - nothing to cut a beta from."
|
||||
exit 1
|
||||
fi
|
||||
N=1
|
||||
while true; do
|
||||
VERSION="${NEXT}-beta.${N}"
|
||||
TAG="v${VERSION}"
|
||||
TAG_EXISTS=false
|
||||
NPM_EXISTS=false
|
||||
RELEASE_EXISTS=false
|
||||
|
||||
if git rev-parse -q --verify "refs/tags/${TAG}" >/dev/null; then
|
||||
TAG_EXISTS=true
|
||||
fi
|
||||
if npm view "@fission-ai/openspec@${VERSION}" version >/dev/null 2>&1; then
|
||||
NPM_EXISTS=true
|
||||
fi
|
||||
if gh release view "${TAG}" >/dev/null 2>&1; then
|
||||
RELEASE_EXISTS=true
|
||||
fi
|
||||
|
||||
if [ "$TAG_EXISTS" = false ] && [ "$NPM_EXISTS" = false ] && [ "$RELEASE_EXISTS" = false ]; then
|
||||
break
|
||||
fi
|
||||
if [ "$RELEASE_EXISTS" = false ]; then
|
||||
echo "Resuming incomplete beta ${TAG}"
|
||||
break
|
||||
fi
|
||||
|
||||
N=$((N + 1))
|
||||
done
|
||||
echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
|
||||
echo "Cutting ${TAG}"
|
||||
|
||||
- name: Set package version
|
||||
env:
|
||||
VERSION: ${{ steps.version.outputs.version }}
|
||||
run: npm version "$VERSION" --no-git-tag-version
|
||||
|
||||
# prepublishOnly runs the build. npm authentication handled via OIDC
|
||||
# trusted publishing (no token needed).
|
||||
- name: Publish to npm under the beta dist-tag
|
||||
env:
|
||||
VERSION: ${{ steps.version.outputs.version }}
|
||||
run: |
|
||||
if npm view "@fission-ai/openspec@${VERSION}" version >/dev/null 2>&1; then
|
||||
echo "@fission-ai/openspec@${VERSION} is already on npm; skipping publish."
|
||||
exit 0
|
||||
fi
|
||||
npm publish --tag beta
|
||||
|
||||
- name: Tag and create GitHub prerelease
|
||||
env:
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
VERSION: ${{ steps.version.outputs.version }}
|
||||
run: |
|
||||
TAG="v${VERSION}"
|
||||
HEAD_SHA=$(git rev-parse HEAD)
|
||||
|
||||
if git rev-parse -q --verify "refs/tags/${TAG}" >/dev/null; then
|
||||
TAG_SHA=$(git rev-list -n 1 "${TAG}")
|
||||
if [ "$TAG_SHA" != "$HEAD_SHA" ]; then
|
||||
echo "${TAG} already exists at ${TAG_SHA}, not current HEAD ${HEAD_SHA}."
|
||||
exit 1
|
||||
fi
|
||||
else
|
||||
git tag "${TAG}"
|
||||
fi
|
||||
|
||||
if git ls-remote --exit-code --tags origin "refs/tags/${TAG}" >/dev/null 2>&1; then
|
||||
echo "${TAG} already exists on origin; skipping tag push."
|
||||
else
|
||||
git push origin "${TAG}"
|
||||
fi
|
||||
|
||||
if gh release view "${TAG}" >/dev/null 2>&1; then
|
||||
echo "GitHub Release ${TAG} already exists; skipping release creation."
|
||||
else
|
||||
gh release create "${TAG}" \
|
||||
--prerelease \
|
||||
--generate-notes \
|
||||
--title "${TAG}" \
|
||||
--notes "Beta prerelease. Install with \`npm install -g @fission-ai/openspec@beta\`."
|
||||
fi
|
||||
|
||||
@@ -1,120 +0,0 @@
|
||||
name: Security
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
paths:
|
||||
- '**/package.json'
|
||||
- '**/pnpm-lock.yaml'
|
||||
- '**/pnpm-workspace.yaml'
|
||||
- '.github/workflows/security.yml'
|
||||
pull_request:
|
||||
branches: [main]
|
||||
schedule:
|
||||
# Weekly, so a newly published advisory surfaces even with no commits.
|
||||
- cron: '17 6 * * 1'
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
concurrency:
|
||||
group: security-${{ github.ref }}
|
||||
cancel-in-progress: true
|
||||
|
||||
jobs:
|
||||
# Blocks a pull request that introduces a vulnerable or badly licensed dependency.
|
||||
dependency-review:
|
||||
name: Dependency Review
|
||||
if: github.event_name == 'pull_request'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
|
||||
# No PR comment: that needs `pull-requests: write`, which a fork's token
|
||||
# never gets. The failed check plus its log is the signal.
|
||||
- name: Review dependency changes
|
||||
uses: actions/dependency-review-action@a1d282b36b6f3519aa1f3fc636f609c47dddb294 # v5.0.0
|
||||
with:
|
||||
fail-on-severity: high
|
||||
|
||||
audit:
|
||||
name: Audit
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
|
||||
# No dependency cache: `pnpm audit` reads the lockfile, nothing is installed,
|
||||
# so a cache-save step would fail on the missing store path.
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
with:
|
||||
node-version: '20.19.0'
|
||||
|
||||
# Advisory on pull requests: a newly published advisory should not stop an
|
||||
# unrelated change, and the step depends on registry availability.
|
||||
# Blocking everywhere else — on the weekly schedule and on pushes to main
|
||||
# — so a high-severity advisory in a shipped dependency still fails a run
|
||||
# even when no dependency changed.
|
||||
- name: Audit published dependencies
|
||||
continue-on-error: ${{ github.event_name == 'pull_request' }}
|
||||
run: pnpm audit --prod --audit-level high
|
||||
|
||||
# Build and test tooling never reaches an installed copy of OpenSpec, so an
|
||||
# advisory here is a scheduled-update item.
|
||||
- name: Audit build and test tooling
|
||||
continue-on-error: true
|
||||
run: pnpm audit --audit-level high
|
||||
|
||||
# The docs site keeps its own lockfile and is not a workspace member, so
|
||||
# neither audit above can see it. Without this step a website advisory is
|
||||
# invisible — which is how two of them sat open long enough to need a
|
||||
# manual override.
|
||||
#
|
||||
# Same blocking rule as the published-dependency audit: advisory on pull
|
||||
# requests, blocking on the weekly schedule and on pushes to main. Green
|
||||
# here has to mean the site is clean, or the step just relocates the blind
|
||||
# spot into a passing log. `!cancelled()` because the two audits above can
|
||||
# fail hard, and a root advisory must not silently skip this one.
|
||||
- name: Audit documentation site
|
||||
if: ${{ !cancelled() }}
|
||||
continue-on-error: ${{ github.event_name == 'pull_request' }}
|
||||
run: pnpm audit --audit-level high --dir website
|
||||
|
||||
# The website keeps its own lockfile and is never installed or built elsewhere
|
||||
# in CI, so a website/package.json change — e.g. a security override — that is
|
||||
# not reflected in website/pnpm-lock.yaml goes unnoticed: the override you think
|
||||
# patches an advisory may not be in the committed graph at all, and `pnpm audit`
|
||||
# would happily audit the stale (possibly still-vulnerable) tree. A frozen-lockfile
|
||||
# install fails fast on that drift. Root drift is already caught by the
|
||||
# `--frozen-lockfile` installs in ci.yml; this closes the same gap for the website.
|
||||
# `--ignore-scripts` skips sharp's native build (irrelevant to lockfile validation
|
||||
# and the usual source of install flake).
|
||||
website-lockfile:
|
||||
name: Website Lockfile Drift
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
|
||||
with:
|
||||
persist-credentials: false
|
||||
|
||||
- name: Setup pnpm
|
||||
uses: pnpm/action-setup@ea17c68df8912ef543352723c149a84f56e3d413 # v6.1.0
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
|
||||
with:
|
||||
node-version: '20.19.0'
|
||||
|
||||
- name: Verify website lockfile matches package.json
|
||||
run: pnpm install --frozen-lockfile --ignore-scripts --dir website
|
||||
@@ -148,7 +148,6 @@ CLAUDE.md
|
||||
|
||||
# Pnpm
|
||||
.pnpm-store/
|
||||
/package-lock.json
|
||||
result
|
||||
|
||||
# OpenCode
|
||||
@@ -160,9 +159,3 @@ opencode.json
|
||||
|
||||
# Bob
|
||||
.bob/
|
||||
|
||||
# Trae
|
||||
.trae/
|
||||
|
||||
# Cursor
|
||||
.cursor/
|
||||
|
||||
-810
@@ -1,815 +1,5 @@
|
||||
# @fission-ai/openspec
|
||||
|
||||
## 1.14.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#883](https://github.com/Fission-AI/OpenSpec/pull/883) [`c879d13`](https://github.com/Fission-AI/OpenSpec/commit/c879d13d5f5d045c532a08523316d2d74f2db99a) Thanks [@Code-Studio-Team](https://github.com/Code-Studio-Team)! - Add Code Studio as an `init` and `update` target, with project skills and `.prompt.md` commands under `.codestudio/`.
|
||||
|
||||
- [#1672](https://github.com/Fission-AI/OpenSpec/pull/1672) [`297092c`](https://github.com/Fission-AI/OpenSpec/commit/297092cb25d9831a408d2ce9bfd55daec1431b74) Thanks [@DarkskyX15](https://github.com/DarkskyX15)! - - **DeepSeek Harness** — `openspec init --tools dsh` (command-line id `dsh`) installs the OpenSpec workflow skills into `.dsh/skills/` for DeepSeek Harness. It is skills-only (no command adapter or command files): dsh discovers the generated `SKILL.md` files as its highest-priority project root and surfaces them through its skill catalog, `skill` tool, and `/openspec-*` user invocations.
|
||||
|
||||
- [#1961](https://github.com/Fission-AI/OpenSpec/pull/1961) [`3c3e6e3`](https://github.com/Fission-AI/OpenSpec/commit/3c3e6e3d423625ffe554ff050c09bb530f17dc5e) Thanks [@fresh-fx59](https://github.com/fresh-fx59)! - Add GigaCode as a supported `--tools` target, with skills in `.gigacode/skills/openspec-*/SKILL.md` and Markdown commands in `.gigacode/commands/opsx-<id>.md`.
|
||||
|
||||
- [#1211](https://github.com/Fission-AI/OpenSpec/pull/1211) [`3de7c72`](https://github.com/Fission-AI/OpenSpec/commit/3de7c72c267c40ff89809d2ae08b7bf6ac6faf8c) Thanks [@hu-qi](https://github.com/hu-qi)! - Add AtomCode support through `openspec init --tools atomcode`, with project skills in `.atomcode/skills/` and `/opsx-<id>` commands in `.atomcode/commands/`. Generated commands declare `args: optional` and receive `$ARGUMENTS` when the workflow reads invocation input, and `args: none` when it does not, so AtomCode runs them straight from the slash menu. Follows the selected workflow profile and delivery mode.
|
||||
|
||||
- [#1082](https://github.com/Fission-AI/OpenSpec/pull/1082) [`a7f08b8`](https://github.com/Fission-AI/OpenSpec/commit/a7f08b8a462db5eeddae4e0b03f427987e3806a2) Thanks [@Storm-Chaser](https://github.com/Storm-Chaser)! - ### New Features
|
||||
|
||||
- **GSD support**: Install OpenSpec workflows as project skills with `openspec init --tools gsd`.
|
||||
|
||||
- [#420](https://github.com/Fission-AI/OpenSpec/pull/420) [`070de01`](https://github.com/Fission-AI/OpenSpec/commit/070de01dfac4ea343747fbd37b9bb9e77acdf7d0) Thanks [@jeanduplessis](https://github.com/jeanduplessis)! - ### New Features
|
||||
|
||||
- **Amp support**: select `amp` during init to install OpenSpec workflows as project skills under `.agents/skills/`.
|
||||
|
||||
- [#2001](https://github.com/Fission-AI/OpenSpec/pull/2001) [`56528ea`](https://github.com/Fission-AI/OpenSpec/commit/56528ea454a926159d05eb7c9ec1b687d7544b56) Thanks [@clay-good](https://github.com/clay-good)! - ### New Features
|
||||
|
||||
- **Version reports** — Run `openspec version` to inspect the installed version and install type, or add `--check` and `--json` for structured update information that tools can consume.
|
||||
|
||||
- [#1352](https://github.com/Fission-AI/OpenSpec/pull/1352) [`d1642cb`](https://github.com/Fission-AI/OpenSpec/commit/d1642cb58cb4ce2cda0a140cf2322aded53f4e46) Thanks [@redknox](https://github.com/redknox)! - Add EasyCode support to init and update, with project-local skills and TOML commands invoked as `/opsx:<id>`.
|
||||
|
||||
- [#399](https://github.com/Fission-AI/OpenSpec/pull/399) [`ded99e2`](https://github.com/Fission-AI/OpenSpec/commit/ded99e27de71c32647ae7fc2f51112219420b5d5) Thanks [@ZEDce](https://github.com/ZEDce)! - Add `openspec list --archived` and `--all` to browse archived changes, including JSON output and sorting. Show archived changes separately in the `openspec view` dashboard.
|
||||
|
||||
- [#848](https://github.com/Fission-AI/OpenSpec/pull/848) [`5a360c2`](https://github.com/Fission-AI/OpenSpec/commit/5a360c2088ad3094a092c34993eab97b43c25124) Thanks [@Columpio](https://github.com/Columpio)! - ### New Features
|
||||
|
||||
- **Veai support**: select `veai` during init to install OpenSpec workflows as project skills under `.veai/skills/`.
|
||||
|
||||
- [#1439](https://github.com/Fission-AI/OpenSpec/pull/1439) [`f197804`](https://github.com/Fission-AI/OpenSpec/commit/f197804a38057eee2272952b74d89884a9d3b7a4) Thanks [@jmuchovej](https://github.com/jmuchovej)! - Expose OpenSpec as a reusable Nix overlay through `overlays.default`.
|
||||
|
||||
- [#1349](https://github.com/Fission-AI/OpenSpec/pull/1349) [`e232080`](https://github.com/Fission-AI/OpenSpec/commit/e232080d0943bd535388bdc2304b3301f1496226) Thanks [@0x6d6e647a](https://github.com/0x6d6e647a)! - Add Grok Build as a skills-only tool. Run `openspec init --tools grok` to install skills in `.grok/skills`, then invoke them with `/openspec-propose` and other skill names. Existing Grok installations are refreshed by `openspec update`.
|
||||
|
||||
- [#1738](https://github.com/Fission-AI/OpenSpec/pull/1738) [`781c7f9`](https://github.com/Fission-AI/OpenSpec/commit/781c7f9447b4eeb6fdc69fa745ff46f6168f3edf) Thanks [@clay-good](https://github.com/clay-good)! - Add Warp support through project-local skills. Select `warp` during init to install OpenSpec workflows in `.warp/skills`, invoke them with `/openspec-*`, and refresh them with `openspec update`. Skills remain available in every delivery mode.
|
||||
|
||||
- [#807](https://github.com/Fission-AI/OpenSpec/pull/807) [`c21d897`](https://github.com/Fission-AI/OpenSpec/commit/c21d897261b5daf0c61c49ccd0862288d4664db4) Thanks [@Million-mo](https://github.com/Million-mo)! - ### New Features
|
||||
|
||||
- **Dashboard workflow status**: `openspec view` now shows each active change's schema and which artifacts are done, ready, blocked, or skipped. Task progress remains visible if a workflow cannot be loaded. Thanks to @Million-mo for the original contribution in [#807](https://github.com/Fission-AI/OpenSpec/issues/807).
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1977](https://github.com/Fission-AI/OpenSpec/pull/1977) [`7728194`](https://github.com/Fission-AI/OpenSpec/commit/772819417a2aa8a90cd50743139f402261628d21) Thanks [@clay-good](https://github.com/clay-good)! - The `openspec-archive-change` skill no longer tells the agent to run the `openspec-sync-specs` skill when that skill is not installed. It merges the delta specs into the main specs itself instead, as the `/opsx:archive` command already did ([#1975](https://github.com/Fission-AI/OpenSpec/issues/1975)).
|
||||
|
||||
- [#1722](https://github.com/Fission-AI/OpenSpec/pull/1722) [`817cdb6`](https://github.com/Fission-AI/OpenSpec/commit/817cdb64be744d4ee65d1a9922b23edc0c4699b8) Thanks [@caseyg](https://github.com/caseyg)! - ### Bug Fixes
|
||||
|
||||
- IBM Bob now appears by its full product name in the tool picker and success messages. Existing `bob` selections, configuration, skills, and slash-command paths continue to work unchanged.
|
||||
|
||||
- [#1999](https://github.com/Fission-AI/OpenSpec/pull/1999) [`bda8556`](https://github.com/Fission-AI/OpenSpec/commit/bda85565ef974d07c1c202c0ac4b2613241dd184) Thanks [@clay-good](https://github.com/clay-good)! - Guide users through an AI-assisted migration from legacy `project.md` to `config.yaml`.
|
||||
|
||||
- [#1997](https://github.com/Fission-AI/OpenSpec/pull/1997) [`e70dcc7`](https://github.com/Fission-AI/OpenSpec/commit/e70dcc7c82a3b100145795d32ea9930dca7b4073) Thanks [@clay-good](https://github.com/clay-good)! - Guide proposal authors toward durable, behavior-based capability names.
|
||||
|
||||
- [#2018](https://github.com/Fission-AI/OpenSpec/pull/2018) [`81c2f9f`](https://github.com/Fission-AI/OpenSpec/commit/81c2f9fce30d103bd22377042af1d428453b0bbc) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Apply edits the right task** — `openspec instructions apply --json` now gives each task its `sourcePath` and `line`. The apply workflow checks the checkbox at that location before marking the task done and rechecks progress afterward, so agents update the exact task, even when tasks span several files.
|
||||
- **Archive stops on a failed spec sync** — When the spec sync inside `/opsx:archive` reports a blocking condition, such as a capability retirement it could not complete, the archive now stops and leaves the change in place instead of archiving it with the main specs unchanged. The same applies to bulk archive.
|
||||
- **Aligned `openspec view` progress bars** — Active change names up to 48 characters now line up their progress bars instead of pushing each bar out of line.
|
||||
|
||||
- [#1969](https://github.com/Fission-AI/OpenSpec/pull/1969) [`9557b43`](https://github.com/Fission-AI/OpenSpec/commit/9557b43aaff05af8bd9862c4755f7ac7b7f43cf1) Thanks [@flcrom](https://github.com/flcrom)! - ### Bug Fixes
|
||||
|
||||
- Let store-only repositories run `openspec init` at the repo root to install integrations without changing the external-store config or creating local planning directories.
|
||||
|
||||
- [#2004](https://github.com/Fission-AI/OpenSpec/pull/2004) [`d4e1c77`](https://github.com/Fission-AI/OpenSpec/commit/d4e1c77ebae0bd96a7c649fa35edef997989450a) Thanks [@clay-good](https://github.com/clay-good)! - Warn that files listed for legacy cleanup are deleted entirely and ask users to back up custom content first. The `openspec/AGENTS.md` check detects the file by existence alone.
|
||||
|
||||
- [#1995](https://github.com/Fission-AI/OpenSpec/pull/1995) [`baad449`](https://github.com/Fission-AI/OpenSpec/commit/baad4494b48f1497ec2f73a457210c5567176942) Thanks [@clay-good](https://github.com/clay-good)! - Guide agents to keep project documentation and codebase facts out of `config.yaml` context.
|
||||
|
||||
- [#1978](https://github.com/Fission-AI/OpenSpec/pull/1978) [`1872982`](https://github.com/Fission-AI/OpenSpec/commit/187298289dc5a7a63df87425151981586cbe5d7e) Thanks [@clay-good](https://github.com/clay-good)! - The specs instruction now tells agents the 500-character requirement length that `openspec validate` flags as an informational hint, and how to stay under it when writing new requirements without splitting existing ones. The validator's too-long message now explains how to split a requirement too.
|
||||
|
||||
- [#1972](https://github.com/Fission-AI/OpenSpec/pull/1972) [`d28fb49`](https://github.com/Fission-AI/OpenSpec/commit/d28fb49c1ca901fe19fa443a56ede37ff8b8c61a) Thanks [@ryandemelo](https://github.com/ryandemelo)! - `show --json` now includes each requirement's and scenario's `name`, matching the header names archive uses, so JSON readers can cite a requirement without parsing the markdown again ([#1971](https://github.com/Fission-AI/OpenSpec/issues/1971)).
|
||||
|
||||
- [#2014](https://github.com/Fission-AI/OpenSpec/pull/2014) [`cf2859a`](https://github.com/Fission-AI/OpenSpec/commit/cf2859a52089dd6dd37f9b3388db90c2ca3f06e7) Thanks [@clay-good](https://github.com/clay-good)! - Fix `status --json` for store-backed changes: `actionContext.allowedEditRoots` now lists the project on the current path that declares the store alongside the store, so apply no longer stops on a store-only edit scope. When no project on the current path declares the store, the constraint tells the agent to ask which repository to edit instead of naming the store.
|
||||
|
||||
- [#1984](https://github.com/Fission-AI/OpenSpec/pull/1984) [`42671df`](https://github.com/Fission-AI/OpenSpec/commit/42671df890fab730058fee108a2090e7c1e491b9) Thanks [@Yi-111-a](https://github.com/Yi-111-a)! - Name the offending index when a `rules:` list is not an array of strings
|
||||
|
||||
A rule item containing an unquoted `": "` is valid-looking YAML but parses as a
|
||||
mapping, so the artifact's whole rule set is dropped with only a stderr warning
|
||||
naming the artifact. The warning now also names the index and the shape YAML
|
||||
produced there, plus the quoting fix, so the bad item can be found without
|
||||
bisecting the list by hand.
|
||||
|
||||
- [#1925](https://github.com/Fission-AI/OpenSpec/pull/1925) [`88692b3`](https://github.com/Fission-AI/OpenSpec/commit/88692b3bb42262d30172819936847ed10f42a98f) Thanks [@kevin9327](https://github.com/kevin9327)! - ### Bug Fixes
|
||||
|
||||
- **Change metadata** — Warn when `.openspec.yaml` contains unrecognized keys such as `skip_design`. Those keys were stripped with no signal, so `status` still demanded the design artifact and `validate --strict` exited 0. `status`, `validate`, and `archive` now name the ignored keys; `validate --strict` fails.
|
||||
|
||||
- [#2016](https://github.com/Fission-AI/OpenSpec/pull/2016) [`cd4f9e4`](https://github.com/Fission-AI/OpenSpec/commit/cd4f9e4a5f99e7b48f2c452ef0fa3769db4dde4a) Thanks [@huiq777](https://github.com/huiq777)! - Make `openspec completion uninstall zsh` hand `.zshrc` back exactly as `completion install zsh` found it. Uninstall stripped every blank line at the top of the file, so a `.zshrc` that started with blank lines lost them after an install/uninstall round trip, even when the OpenSpec block had been moved further down. Uninstall now drops only the separator line install added, and only when the block sits at the top of the file, matching the bash installer.
|
||||
|
||||
## 1.13.2
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1940](https://github.com/Fission-AI/OpenSpec/pull/1940) [`0b5ce44`](https://github.com/Fission-AI/OpenSpec/commit/0b5ce44b55e0d793a312290ba5a41170a78e47c6) Thanks [@clay-good](https://github.com/clay-good)! - Keep fast-forward clarification guidance and onboarding task approval consistent across generated skills and commands. Fast-forward now asks only when context is critically unclear, while onboarding asks users to approve the task breakdown before saving it and separately asks whether to begin implementation.
|
||||
|
||||
- [#1926](https://github.com/Fission-AI/OpenSpec/pull/1926) [`f2812f6`](https://github.com/Fission-AI/OpenSpec/commit/f2812f6d185f47cb577055f2fe243f12000d6cd2) Thanks [@kevin9327](https://github.com/kevin9327)! - ### Bug Fixes
|
||||
|
||||
- **Archive** — When Windows `EPERM` blocks renaming a change directory that still has children, copy from the original source instead of requiring a staging rename that fails the same way. That lets archive finish instead of rolling back the spec write and leaving an empty capability directory git cannot see. A staging failure that is not `EPERM`/`EXDEV` still leaves the source untouched.
|
||||
|
||||
The source of that unstaged copy is still the live change directory, which the archive claim does not cover, so cleanup removes only the entries it copied and verified rather than whatever is present when it runs. A file written in that window is left alone and the complete destination is retained for recovery, instead of being deleted without ever reaching the archive.
|
||||
|
||||
An edit to a file that was already verified is covered too. Cleanup claims each entry with an atomic rename before reading it, then compares what it claimed against the copy. A rewrite that lands first is caught by that comparison and the file is put back; one that lands after creates a new file at the original path, which is never deleted. Either way the newer bytes stay on disk and archive reports the move as incomplete rather than succeeding with the older copy.
|
||||
|
||||
Rollback of a newly created spec now also prunes the capability directory it created — and only that one. An empty capability directory that was already there is left in place with its own permissions.
|
||||
|
||||
- [#1795](https://github.com/Fission-AI/OpenSpec/pull/1795) [`fb1b876`](https://github.com/Fission-AI/OpenSpec/commit/fb1b87613b7cdbe8d74e8147833904f46f0468c6) Thanks [@runsonmypc](https://github.com/runsonmypc)! - Archive workflows now use schema-aware task progress from `openspec list --json`, so custom task files and globs still trigger incomplete-task warnings.
|
||||
|
||||
- [#1885](https://github.com/Fission-AI/OpenSpec/pull/1885) [`fd56e12`](https://github.com/Fission-AI/OpenSpec/commit/fd56e12c9e7fdbbfdc2dcd0a5ef3fab04840909d) Thanks [@philo-x](https://github.com/philo-x)! - Fix artifact output resolution to recognize brace expansion and extglob patterns while preserving literal output filenames and confining brace-expanded paths to the change directory.
|
||||
|
||||
- [#1964](https://github.com/Fission-AI/OpenSpec/pull/1964) [`7ac58dc`](https://github.com/Fission-AI/OpenSpec/commit/7ac58dc7905a4eeaaad7eff2b2b64cf971fd6ec7) Thanks [@clay-good](https://github.com/clay-good)! - Continue commands now open with an instruction to follow the active OpenSpec workflow directly, so local models no longer try to call a tool named after it ([#1944](https://github.com/Fission-AI/OpenSpec/issues/1944)).
|
||||
|
||||
- [#1964](https://github.com/Fission-AI/OpenSpec/pull/1964) [`7ac58dc`](https://github.com/Fission-AI/OpenSpec/commit/7ac58dc7905a4eeaaad7eff2b2b64cf971fd6ec7) Thanks [@clay-good](https://github.com/clay-good)! - Generate Kilo Code commands in `.kilo/command/`, the directory Kilo Code reads, instead of `.kilocode/workflows/` ([#1938](https://github.com/Fission-AI/OpenSpec/issues/1938)). `openspec init` and legacy cleanup remove the workflow files OpenSpec generated there, matched by their known file names (including copies you edited), and leave files with other names in place.
|
||||
|
||||
- [#1958](https://github.com/Fission-AI/OpenSpec/pull/1958) [`1d35e90`](https://github.com/Fission-AI/OpenSpec/commit/1d35e908804dbb3c4a1851516759c5de190aa4d5) Thanks [@clay-good](https://github.com/clay-good)! - Preserve a file's existing line endings when rewriting it, so Windows users no longer get whole-file diffs. Applying a delta to a CRLF spec (the default on a Windows checkout with `core.autocrlf=true`) rewrote the file to LF, turning a one-requirement change into a diff that touched every line. `openspec archive` now writes the spec back with the convention it already used; a spec that does not exist yet is still written with LF.
|
||||
|
||||
The same fix covers marker-managed files: installing or updating shell completions in a CRLF `.bashrc` or `.zshrc` no longer leaves the file with mixed endings, which `bash` reports as `$'\r': command not found`.
|
||||
|
||||
Removing a managed block is fixed the same way: the blank-line collapse in `removeMarkerBlock` rebuilt its separator as a bare LF, so cleaning up legacy artifacts left a lone LF inside an otherwise-CRLF `CLAUDE.md` or rc file. Both write paths now read the file the same way, by dominant ending, so one stray CRLF in an otherwise-LF file no longer pulls the whole rewrite to CRLF.
|
||||
|
||||
`scripts/pack-version-check.mjs` now spawns `npm` through `cross-spawn`, so the release guard can run on Windows, where `npm` is `npm.cmd` and cannot be resolved by `execFile`.
|
||||
|
||||
- [#1912](https://github.com/Fission-AI/OpenSpec/pull/1912) [`8826c0c`](https://github.com/Fission-AI/OpenSpec/commit/8826c0c4a17d3511947b7c5e0934257f153f0ed2) Thanks [@Tyagiquamar](https://github.com/Tyagiquamar)! - Fix `validate --strict` reporting `PURPOSE_IS_PLACEHOLDER` for a Purpose that opens with the ordinary word "Todo" followed by prose, as in Spanish ("Todo el…") and Portuguese ("Todo o…") specs ([#1897](https://github.com/Fission-AI/OpenSpec/issues/1897)).
|
||||
|
||||
- Case now separates the marker from the word. `TBD`/`TODO` in capitals is still a placeholder marker whatever follows it, so `TODO write this later` is still reported.
|
||||
- In any other case it counts as a marker only when followed by the end of the Purpose, a line break, or marker punctuation (`todo -`, `tbd.`), so an authored Spanish or Portuguese sentence is not reported.
|
||||
|
||||
- [#1744](https://github.com/Fission-AI/OpenSpec/pull/1744) [`5b55263`](https://github.com/Fission-AI/OpenSpec/commit/5b5526377506c2f0179674a869c1ac64ca9ab72d) Thanks [@javigomez](https://github.com/javigomez)! - Clarify the Codex setup hint for CLI, IDE, and desktop app users.
|
||||
|
||||
- [#1809](https://github.com/Fission-AI/OpenSpec/pull/1809) [`a5ceea3`](https://github.com/Fission-AI/OpenSpec/commit/a5ceea32cf110b6d8bbfea0bf1c65fe55abb133b) Thanks [@ryandemelo](https://github.com/ryandemelo)! - Say what a `MODIFIED` block adds when the scenario-loss guard fires ([#1809](https://github.com/Fission-AI/OpenSpec/pull/1809)). `openspec validate` and `openspec archive` already named the scenarios a block omits. They now also print how many scenarios each side has and which ones the block introduces, capped at three names, so a rename and a truncation read differently without opening either file. The guard catches exactly what it did before, and no exit code changes.
|
||||
|
||||
- [#1731](https://github.com/Fission-AI/OpenSpec/pull/1731) [`d6bdef6`](https://github.com/Fission-AI/OpenSpec/commit/d6bdef6577a077614382ef47b64100852182d6a6) Thanks [@runsonmypc](https://github.com/runsonmypc)! - Stop workflows from displaying schema names that `openspec list --json` does not return. Update and continue no longer fabricate a `spec-driven` picker label, while bulk archive and explore describe only the change fields the list command actually provides.
|
||||
|
||||
- [#1955](https://github.com/Fission-AI/OpenSpec/pull/1955) [`ed5d386`](https://github.com/Fission-AI/OpenSpec/commit/ed5d386a559c0215af1182d479d7f99b309fdcd2) Thanks [@clay-good](https://github.com/clay-good)! - Task guidance now requires each task group to land its own tests and documentation updates instead of deferring them to a trailing group. The onboarding walkthrough teaches the same rule, and the published schema reference no longer quotes stale instruction text.
|
||||
|
||||
- [#1939](https://github.com/Fission-AI/OpenSpec/pull/1939) [`a64303f`](https://github.com/Fission-AI/OpenSpec/commit/a64303fe1e24f08dbf44f78032fadbeac3a6f7fa) Thanks [@clay-good](https://github.com/clay-good)! - Return a nonzero exit status when `openspec update --force` cannot replace a legacy-only Codex installation.
|
||||
|
||||
- [#1733](https://github.com/Fission-AI/OpenSpec/pull/1733) [`72fbe4c`](https://github.com/Fission-AI/OpenSpec/commit/72fbe4c904707396151921a20b506d081a9dc024) Thanks [@runsonmypc](https://github.com/runsonmypc)! - Let `/opsx:update` fill a missing file under an already-satisfied glob artifact. A glob artifact is complete once one file matches it, and `/opsx:continue` only picks up `ready` artifacts, so the previous "point the user to `/opsx:continue`" handoff was unreachable and the missing file could never be created through the documented flow.
|
||||
|
||||
- [#1962](https://github.com/Fission-AI/OpenSpec/pull/1962) [`3364146`](https://github.com/Fission-AI/OpenSpec/commit/336414665f3f987ae424177ab1b6891a4304baeb) Thanks [@ryandemelo](https://github.com/ryandemelo)! - Stop `/opsx:verify` from reporting a correctly removed requirement as missing. Verify now reads which delta section each requirement sits under: ADDED and MODIFIED requirements are checked for an implementation as before, a REMOVED requirement passes once its behavior is gone and is flagged only while it is still present, and the old name of a RENAMED requirement is no longer reported as missing.
|
||||
|
||||
- [#1732](https://github.com/Fission-AI/OpenSpec/pull/1732) [`072de6b`](https://github.com/Fission-AI/OpenSpec/commit/072de6bc39b1c47b9aacf4d484be16345ca4f38e) Thanks [@runsonmypc](https://github.com/runsonmypc)! - Stop `/opsx:verify` from reporting skipped checks as passing. Task completion now uses the schema-aware `tasks` and `progress` fields returned by apply instructions, while absent spec or design inputs are mapped to every check they prevent. Apply instructions aggregate every file matched by the configured task path or glob, regardless of the tracked artifact ID. Verification stays advisory and does not require optional or intentionally omitted artifacts. The scorecard identifies each skipped check, and the final assessment does not claim archive readiness when any check did not run.
|
||||
|
||||
- [#1769](https://github.com/Fission-AI/OpenSpec/pull/1769) [`d3d7707`](https://github.com/Fission-AI/OpenSpec/commit/d3d770736fc01bb246b4f12a7cef7e3572ec1fb6) Thanks [@kikeprzn](https://github.com/kikeprzn)! - Fix `openspec archive` leaving `.openspec-archive.lock` behind on Windows. Node can report `dev: 0n` from a path stat while the open file handle reports the real volume id, so the claim-ownership check never matched and the stale lock blocked every later archive. The check now treats an absent device id as unavailable while still requiring the inode and the claim's contents to match before unlinking.
|
||||
|
||||
## 1.13.1
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1864](https://github.com/Fission-AI/OpenSpec/pull/1864) [`767d63c`](https://github.com/Fission-AI/OpenSpec/commit/767d63c926ab1996170f2d101acac0bac6da0287) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop archive adding a second copy of an existing requirement under a name that differs only in case or spacing. ADDED and the RENAMED target compared requirement names exactly, while REMOVED and the RENAMED source already treated a case or whitespace variant as a mistyped header, so an ADDED `late fees` beside an existing `Late Fees`, or a rename to `LATE FEES`, archived cleanly and left two contradicting requirements in the main spec, which `validate` then accepted. Both now refuse with an error naming the existing requirement, in the same form REMOVED already used. The exact-duplicate error is unchanged, a case-only rename of a requirement to its own name still works, and a variant of a requirement the same delta removes or renames away is still allowed, because ADDED is checked against the spec as it stands after the earlier operations, as the exact check already was.
|
||||
|
||||
- [#1872](https://github.com/Fission-AI/OpenSpec/pull/1872) [`72bf760`](https://github.com/Fission-AI/OpenSpec/commit/72bf7600a5f7bdf74d6387e163577086fb4c68e0) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Make `openspec completion uninstall bash` hand `.bashrc` back exactly as `completion install bash` found it. Install adds the OpenSpec block at the top of the file followed by a blank separator line; uninstall removed the block but kept that blank line at the top, then stripped every trailing blank line and wrote the file back without its final newline. The byte count happened to come out unchanged, but the next tool to append to `.bashrc` with `>>` (the nvm, conda and rustup installers all do) merged its first line into the user's last line and broke both. Uninstall now also drops the separator line install added when the block sits at the top of the file, and leaves the rest untouched: the final newline, trailing blank lines and CRLF line endings all survive the round trip. A block the user moved elsewhere in the file is still removed, and the zsh, fish and PowerShell installers are unchanged.
|
||||
|
||||
- [#1829](https://github.com/Fission-AI/OpenSpec/pull/1829) [`e67ac47`](https://github.com/Fission-AI/OpenSpec/commit/e67ac47f3a164cf6d87ddcd9f50272b88f39ee0c) Thanks [@choi138](https://github.com/choi138)! - Fix bulk archive nesting a change inside an existing archive target. The workflow now checks every archive target before it writes any main spec, the same order `openspec archive` uses. A change whose target already exists, or that shares a target with another selected change, is reported as failed and is never synced or moved, while the rest of the batch continues. The check runs again just before each move.
|
||||
|
||||
- [#1878](https://github.com/Fission-AI/OpenSpec/pull/1878) [`2ef6fbd`](https://github.com/Fission-AI/OpenSpec/commit/2ef6fbde3da95f6e471bcb504d13711308091be0) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Let `openspec config edit` run an `EDITOR` or `VISUAL` that carries arguments. The whole value was passed to `spawn` as the program name, so common settings such as `code --wait`, `subl -w` or `emacsclient -t` failed with `spawn code --wait ENOENT`, and because that error was never caught the command died with a raw Node stack trace. The value is now split into a program and its arguments, honoring quoted paths with spaces, and the config path is appended as its own argument. No shell is involved, so shell metacharacters in the value are passed through literally. On Windows, `.cmd` shims such as `code.cmd` are found. A value that is itself the absolute path of an existing file is still run as-is, so an unquoted editor path containing spaces keeps working. An editor that cannot be started, exits non-zero or is killed is now reported as a one-line error naming the editor, with an install hint when the program was not found, and the command exits 1 instead of throwing. `EDITOR` still takes precedence over `VISUAL`, and the file is still validated after the editor closes.
|
||||
|
||||
- [#1773](https://github.com/Fission-AI/OpenSpec/pull/1773) [`11a9691`](https://github.com/Fission-AI/OpenSpec/commit/11a9691524bad84a575854bf6dc5124f630479ba) Thanks [@clay-good](https://github.com/clay-good)! - Stop dropping checkbox lines whose marker the task parser does not recognise. A `tasks.md` whose remaining work used a marker other than `[ ]`/`[x]`/`[X]`, for example `- [~] 1.2 Deferred`, reported `✓ Complete` in `openspec list`/`status` and archived with no incomplete-task warning, because unmatched lines counted toward neither the numerator nor the denominator. An empty `[]` and a padded `[ x]` were lost the same way. Only a box holding `x` or `X` means done (spacing inside the brackets is ignored, so `[ x]` is done), and every other marker now reads as unfinished, across progress, the apply task list, archive's gate and validate's task-numbering check. The archive, bulk-archive and verify workflows now tell agents the same rule, so a hand-counted tally cannot disagree with the CLI, and the `tasks` instruction in the `spec-driven` schema states it where agents author the file. Markdown link bullets stay out of the count: `- [Some doc](./doc.md)` and the one-character `- [A](https://example.com)` are not tasks.
|
||||
|
||||
- [#1701](https://github.com/Fission-AI/OpenSpec/pull/1701) [`92fb72d`](https://github.com/Fission-AI/OpenSpec/commit/92fb72d1dcd5fa6e43802c5b2f74b5e78416e545) Thanks [@clay-good](https://github.com/clay-good)! - Agent-driven archive and sync workflows now create a missing main spec from `ADDED` requirements instead of treating it as already synced. They block sync rather than inventing `MODIFIED` or `RENAMED` requirements or writing an empty spec for a `REMOVED`-only delta, while preserving the user's explicit choice to archive without syncing. A REMOVED-only delta with `retire_capabilities: true` remains already synced when its main spec is gone. Fixes [#1222](https://github.com/Fission-AI/OpenSpec/issues/1222) and [#1264](https://github.com/Fission-AI/OpenSpec/issues/1264).
|
||||
|
||||
- [#1804](https://github.com/Fission-AI/OpenSpec/pull/1804) [`a5bf5c6`](https://github.com/Fission-AI/OpenSpec/commit/a5bf5c68447f03e4f99206e49e00b5d9111301a4) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Say so when a requirement in a delta sits outside every delta section. A well-formed `### Requirement:` block written under `## Notes`, under a misspelled header such as `## Add Requirements`, or above the first `## ` header was dropped with no diagnostic: `openspec validate` reported the change valid and `openspec archive` exited 0 without applying it. `openspec validate` now reports each one as a WARNING naming the section and line, and archive prints the same warning. Nothing else changes: the block is still not applied, the verdict stays valid outside `--strict`, and requirements shown inside a code fence are not reported. Fixes [#1803](https://github.com/Fission-AI/OpenSpec/issues/1803).
|
||||
|
||||
- [#1832](https://github.com/Fission-AI/OpenSpec/pull/1832) [`4c369e0`](https://github.com/Fission-AI/OpenSpec/commit/4c369e022b1d397842d2b85675e34da6287f5801) Thanks [@clay-good](https://github.com/clay-good)! - Resolve the contradiction that left explore mode's capture branch without a governing rule. Explore states twice that the agent must ask a direct yes/no question and wait for confirmation in a separate user message before its first write-capable action, naming `openspec new change` as an example, while the capture branch tells the agent to transition "seamlessly" into running `openspec new change` and creating artifacts with no confirmation step. Both readings were defensible from the text, so the same "capture this as a change" request either wrote `.openspec.yaml` plus several artifacts immediately or stopped and asked, depending on which passage the agent weighed, which made the [#1715](https://github.com/Fission-AI/OpenSpec/issues/1715) guarantee unenforceable in the one explore path that writes files. An explicit capture request is now stated to be that confirmation, covering the change and the artifacts the request names and nothing else. The guardrail keeps its teeth for the case [#1715](https://github.com/Fission-AI/OpenSpec/issues/1715) actually reported: when the agent is the one proposing the capture, or when the work would go beyond the requested scope, it still asks first, and answers to design or clarifying questions are still never consent to write. Both explore delivery surfaces and the committed skill carry the same wording. Fixes [#1828](https://github.com/Fission-AI/OpenSpec/issues/1828).
|
||||
|
||||
- [#1788](https://github.com/Fission-AI/OpenSpec/pull/1788) [`62106f4`](https://github.com/Fission-AI/OpenSpec/commit/62106f40e3b7b7364529a2f928717e23e37282eb) Thanks [@clay-good](https://github.com/clay-good)! - Name the workflow where explore hands off. Explore mode refuses to implement, but every place it said what to do instead described the next step as prose ("create a change proposal") without naming the workflow that does it: the refusal itself, the "flow into a proposal" ending, the closing summary, and the do-not-implement guardrail. Its seamless capture path was worse: it scaffolded a change, wrote artifacts, and then said nothing at all about what came next. With no named exit, agents finished the discovery questions and started writing code, which is the failure reported through GitHub Copilot in [#869](https://github.com/Fission-AI/OpenSpec/issues/869), and which the docs already promised would not happen ("when the picture is clear, it hands off to `/opsx:propose`").
|
||||
|
||||
The explore skill and command now name `/opsx:propose` at all four prose handoffs, and the capture path ends by naming `/opsx:propose` for the remaining planning artifacts and `/opsx:apply` for implementation, with an explicit note that capturing artifacts is not permission to implement them. The references are written in the canonical `/opsx:<id>` form so each tool renders the invocation it actually registers (`/openspec-propose` for skills-only delivery, `/opsx-propose`, `/opsx:propose`, or `@opsx-propose` for command surfaces). The handoffs follow the installed workflow set: a custom profile without `propose` or `apply` gets explore's own capture path and the `openspec instructions apply` CLI instead of a command it never installed. Fixes [#869](https://github.com/Fission-AI/OpenSpec/issues/869).
|
||||
|
||||
- [#1787](https://github.com/Fission-AI/OpenSpec/pull/1787) [`9827762`](https://github.com/Fission-AI/OpenSpec/commit/9827762d2d18d8076acf90be79d64894255099ea) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- Generated skills and commands no longer adopt a project that never ran `openspec init`. Every workflow now checks `root` from `openspec list --json` before its first write, and `"root": null` means the project is not set up. What happens next depends on how the workflow was reached. A skill the agent picked on its own drops OpenSpec and answers the request normally, without asking about setup. A workflow the user asked for by name, or ran as a slash command, stops and asks whether to initialize the project, target a store, or handle the request without OpenSpec. A project whose `openspec/config.yaml` names a store this machine cannot resolve (not registered, or a malformed `store:` line) is not mistaken for an uninitialized one: the workflow stops and shows the store error. Neither path lets `openspec new change` create `openspec/` in the current directory as a side effect. Skill descriptions now name OpenSpec so hosts stop offering these workflows in unrelated repositories. `openspec new change` also says when it had to create the root itself, so a directory that was never set up no longer picks up an `openspec/` directory in silence (human output only; `--json` is unchanged).
|
||||
|
||||
- [#1902](https://github.com/Fission-AI/OpenSpec/pull/1902) [`eb03b9e`](https://github.com/Fission-AI/OpenSpec/commit/eb03b9e93320cf74a0df9043577d8023116cb1aa) Thanks [@clay-good](https://github.com/clay-good)! - Harden the CLI against repositories you have cloned but not yet read ([#1835](https://github.com/Fission-AI/OpenSpec/pull/1835)).
|
||||
|
||||
- A `config.yaml` value can no longer close the project context block and inject its own directives into the instructions an agent receives.
|
||||
- A crafted delta or skill file no longer stalls `openspec update` or `openspec archive` with catastrophic regex backtracking.
|
||||
- A repository's `.npmrc` can no longer point the update check at a cleartext or attacker-controlled registry; a rejected registry now disables the check instead of falling back.
|
||||
- `openspec update` now notices a generated `SKILL.md` that was edited by hand and restores it, instead of reporting every tool as up to date.
|
||||
- `DO_NOT_TRACK=true` and other common spellings of an opt-out now turn telemetry off, and nothing is sent until the first-run notice has been shown.
|
||||
- Shell-completion installs quote directory paths safely, git probes run with bounded time and output, and dependencies are cleared of known advisories.
|
||||
|
||||
- [#1874](https://github.com/Fission-AI/OpenSpec/pull/1874) [`388d344`](https://github.com/Fission-AI/OpenSpec/commit/388d34473a40529320b2b7b9c5bb6723d18322b0) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop legacy cleanup deleting the user's own files. The six pre-skills tools that kept their commands in a `<tool>/commands/openspec/` folder (Claude Code, CodeBuddy, Qoder, Lingma, Crush and Gemini CLI) had that whole folder removed recursively whenever it existed, so a command the user kept there, such as a team review checklist, was deleted along with OpenSpec's files, and the summary named only the folder. Because `openspec init` cleans up automatically when there is no TTY, an agent or CI running plain `openspec init` did this without `--force` and without a prompt, and `openspec update --force` did the same. Cleanup now deletes only the files OpenSpec wrote there: `proposal`, `apply` and `archive` files that still carry the OpenSpec markers every legacy command was generated with, so a same-named file the user wrote is kept. It never follows a symlinked command folder, removes the folder only once nothing else is left in it, and lists each thing it kept. A folder holding nothing OpenSpec wrote is no longer reported as legacy at all. A folder holding only OpenSpec's files, or nothing, is still removed exactly as before, with the same summary line.
|
||||
|
||||
- [#1866](https://github.com/Fission-AI/OpenSpec/pull/1866) [`8146be5`](https://github.com/Fission-AI/OpenSpec/commit/8146be5546918cdffce860f1e327d929c5a49bd3) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop one unresolvable file from breaking `openspec list`. To sort changes by recency, `list` stats every file inside each change, and any entry it could not stat failed the whole command: a dangling symlink, such as the `.#tasks.md` lock Emacs keeps beside every file with unsaved edits, or a symlink loop made `list` exit 1 and `list --json` report `"changes": []`, so agents discovering work through it saw no changes at all. An entry that no longer resolves (removed mid-walk, a dangling symlink, or a loop) is now skipped when computing a change's last-modified time. Valid symlinks are dated as before, and any other error, such as a permission failure, still fails the listing.
|
||||
|
||||
- [#1849](https://github.com/Fission-AI/OpenSpec/pull/1849) [`09a999b`](https://github.com/Fission-AI/OpenSpec/commit/09a999bbb258c2ad6d7cdc33436c698c15d4eebe) Thanks [@clay-good](https://github.com/clay-good)! - Report a change directory nested in a namespace folder instead of silently listing the folder around it as a change. Specs can be nested by domain (`specs/mobile/tutorial-videos/spec.md`), so it looks reasonable to lay changes out the same way, but a change is only ever a directory directly under `changes/`: `changes/mobile/refresh-token/` left the real change invisible while `mobile` was reported as a task-less change everywhere. `openspec archive mobile` then moved the unfinished change into the archive under the namespace's name and applied none of its deltas. `openspec list` now marks the folder `not a change` and names the nested directories and a flat alternative, `openspec show`, `openspec status --change` and `openspec status --all` say the same instead of reporting a missing proposal or a full artifact plan, `openspec validate` reports it instead of "must have at least one delta", `openspec list --json` carries a `warnings` entry, and `openspec archive` refuses the folder outright. Detection looks up to three directory levels below `changes/`, which covers every namespace layout seen in practice; a change buried deeper than that behaves as it did before. Fixes [#1846](https://github.com/Fission-AI/OpenSpec/issues/1846).
|
||||
|
||||
- [#1902](https://github.com/Fission-AI/OpenSpec/pull/1902) [`eb03b9e`](https://github.com/Fission-AI/OpenSpec/commit/eb03b9e93320cf74a0df9043577d8023116cb1aa) Thanks [@clay-good](https://github.com/clay-good)! - Install shell completions with the Nix flake package ([#1785](https://github.com/Fission-AI/OpenSpec/pull/1785)). The package now ships bash, zsh and fish completions in their standard `share/` locations, so Nix users get tab completion without running `openspec completion install` against their home directory.
|
||||
|
||||
- [#1775](https://github.com/Fission-AI/OpenSpec/pull/1775) [`626269e`](https://github.com/Fission-AI/OpenSpec/commit/626269ed732250492d8bd220a83df23dd756ee5d) Thanks [@clay-good](https://github.com/clay-good)! - Generated skills and commands no longer point at workflows the active profile does not install. On the default `core` profile, the update workflow told agents to hand off to `/opsx:continue` for missing artifacts and to `/opsx:new` for a change of intent, neither of which `core` generates. Every cross-workflow handoff is now decided at generation time against the installed workflow set, and renders a concrete CLI fallback (`openspec status`, `openspec instructions`, `openspec archive`) when the workflow it would name is absent, rather than relying on a runtime availability check the agent had to perform. The onboarding tutorial's command tables are likewise built from the workflows you actually have.
|
||||
|
||||
Also folds in [#1735](https://github.com/Fission-AI/OpenSpec/issues/1735), which fixed the same issue ([#1734](https://github.com/Fission-AI/OpenSpec/issues/1734)) by removing the optional handoffs outright. The CLI's own runtime instructions no longer name the `openspec-continue-change` skill either, since those strings are chosen at run time and cannot be resolved against a profile; and the blocked-state fallback now carries the full CLI recovery (select the next `ready` artifact from `openspec status`, read its rules with `openspec instructions`, keep the selected `--store`) rather than a one-line pointer.
|
||||
|
||||
- [#1870](https://github.com/Fission-AI/OpenSpec/pull/1870) [`e01ed07`](https://github.com/Fission-AI/OpenSpec/commit/e01ed070f18e15529f82563d4c5af35d8124bad3) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop archiving a change whose delta was written somewhere `archive` never reads. `validate` and `archive` read a change's deltas only from `specs/<capability-path>/spec.md`, but the spec-driven artifact graph counts any markdown file under `specs/` as the specs being written, so a delta at `specs/user-auth.md`, or in a second file beside a capability's `spec.md`, was reported done by `status` and ready by `instructions apply` with no warning, rejected by `validate` only as "no deltas found", and then archived with exit 0 and nothing merged into `openspec/specs/`. A markdown file that carries delta sections but is not a capability's `spec.md` is now a validation error naming the file and the `spec.md` its requirements belong in; `archive` runs that validation and refuses the change instead of archiving it unmerged, and `instructions apply` lists each such file in its `warnings`. `--no-validate` still archives as before, a change with no spec files still archives, and notes without delta sections under `specs/` are not affected.
|
||||
|
||||
- [#1806](https://github.com/Fission-AI/OpenSpec/pull/1806) [`6e62b1d`](https://github.com/Fission-AI/OpenSpec/commit/6e62b1d522cfadb4b9836b63d5afa127bc950743) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Refuse a `## RENAMED Requirements` section whose `FROM:` and `TO:` lines do not pair up, instead of guessing. The reader kept one pending pair and dropped whatever did not fit: a `TO:` before its `FROM:`, a `FROM:` displaced by a second `FROM:`, or a trailing `FROM:` vanished with no diagnostic. Listing the old names and then the new ones paired the second `FROM:` with the first `TO:`, so `openspec archive` renamed a requirement the delta never named, under a name written for a different one, and exited 0. `openspec validate` now reports each unpaired line as an ERROR with its line number, and archive refuses the change until the pairing is fixed. Well-formed renames, including several consecutive pairs, are unchanged. A change that used to archive with a malformed RENAMED section is now rejected. Fixes [#1805](https://github.com/Fission-AI/OpenSpec/issues/1805).
|
||||
|
||||
- [#1860](https://github.com/Fission-AI/OpenSpec/pull/1860) [`4b5c07a`](https://github.com/Fission-AI/OpenSpec/commit/4b5c07a0c2e5a4a1dcb3ed9f3a040f826eb7d457) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Read a requirement heading written with a CommonMark closing sequence, such as `### Requirement: Late Fees ###`, as the requirement it renders as. The trailing `#` run stayed in the name, so a REMOVED written that way looked for "Late Fees ###", missed the requirement, and archive exited 0 with a false "treating it as already removed" warning while the requirement stayed in the spec; a closed MODIFIED or RENAMED heading failed as "not found", and a closed and an open heading of one requirement were not reported as duplicates. Requirement names now drop the closing run wherever they are read, exactly as scenario names already did: only a run preceded by a space or tab counts, so a name such as `C#` keeps its `#`. Headings without a closing run are unaffected.
|
||||
|
||||
- [#1868](https://github.com/Fission-AI/OpenSpec/pull/1868) [`7090e16`](https://github.com/Fission-AI/OpenSpec/commit/7090e16d74dfe588dad72bc4fda9bf124e71b0af) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Reject a schema whose `apply.requires` names an artifact that does not exist. `parseSchema` checked every artifact's `requires` but never `apply.requires`, so `openspec schema validate` passed a one-character typo there, and apply then skipped the unknown id: `apply.requires: [desgin]` turned the apply gate off and told the agent "Proceed with implementation" with only a proposal written. That is now a schema error, raised wherever the schema is loaded, exactly like an unknown artifact `requires`, and it names the bad id and the artifacts the schema declares. `openspec schema validate` also warns, without failing, when `apply.tracks` isn't exactly equal to some artifact's `generates` value, because OpenSpec finds the tracked artifact by comparing those two strings and can otherwise not tell which artifact's progress the file belongs to. That covers a typo such as `task.md` and also `tracks: tasks/main.md` against `generates: tasks/*.md`, where the glob does produce the file but the strings still differ. Apply reads that path as written either way, so schemas that track a hand-written file keep loading and working. Every built-in schema parses as before.
|
||||
|
||||
- [#1856](https://github.com/Fission-AI/OpenSpec/pull/1856) [`46ff91f`](https://github.com/Fission-AI/OpenSpec/commit/46ff91f2d626ef2c3f9f55ff345aa23cd44a6e95) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Make `openspec show --json --deltas-only` report the deltas archive applies. `ChangeParser`, which backs `show --json`, the `change list` delta counts and archive's proposal warnings, read delta specs with its own section lookup instead of `parseDeltaSpec`, the reader archive uses, and the two disagreed. A REMOVED written in the bullet form (`` - `### Requirement: X` ``) was invisible to it, so it fell back to the proposal's "What Changes" prose and reported an invented MODIFIED while archive deleted the requirement; a repeated section header was read only once; and a RENAMED line written with `*` or `+` was dropped. The inspection command OpenSpec's own error text recommends therefore misreported a deletion. `ChangeParser` now derives every operation from `parseDeltaSpec`, and a change whose delta spec files carry a delta section is described by them alone, so proposal prose is never reported in place of what archive applies. Requirement text and scenarios are read exactly as before, header-form deltas produce the same output, and a change with no delta spec files, or a legacy change whose spec files carry no delta section, still falls back to the "What Changes" bullets.
|
||||
|
||||
- [#1786](https://github.com/Fission-AI/OpenSpec/pull/1786) [`8b99c07`](https://github.com/Fission-AI/OpenSpec/commit/8b99c07bd0d455f72e746d3950f03e52a025d655) Thanks [@clay-good](https://github.com/clay-good)! - `openspec status` now names the command that moves the change forward.
|
||||
|
||||
The text output reported state and stopped there, so picking a change back up (after a lost session, or on a change you did not start) meant already knowing which command came next. The JSON surface had carried that command all along in `nextSteps`; the text surface never printed it.
|
||||
|
||||
Status now ends with a `Next:` line: the next ready artifact's `openspec instructions` command while planning is unfinished, and `openspec instructions apply` once every planning artifact exists. It carries `--store <id>` when the resolved root is a store, and it is built from the same source as the JSON `nextSteps` sentence, so the two surfaces cannot name different commands.
|
||||
|
||||
- [#1882](https://github.com/Fission-AI/OpenSpec/pull/1882) [`208b5b5`](https://github.com/Fission-AI/OpenSpec/commit/208b5b55106fbeda2ed9f099671b8ce85a01cbaa) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop a store named `specs` or `changes` from taking over root selection. Stores are placed at `~/openspec/<id>`, so a store with one of those ids is itself `~/openspec/specs` or `~/openspec/changes`, and that made `$HOME` look like a planning root. Every command run anywhere under the home directory then resolved `$HOME` as the nearest root: the global `defaultStore` was never consulted, and `new change` wrote into `~/openspec/changes`, outside any store. A `specs/` or `changes/` directory that carries store metadata no longer counts as planning content of the directory above it, so these stores resolve like any other. A real project's `openspec/specs/` and `openspec/changes/` are unaffected.
|
||||
|
||||
- [#1880](https://github.com/Fission-AI/OpenSpec/pull/1880) [`9f8dec5`](https://github.com/Fission-AI/OpenSpec/commit/9f8dec5dd937da78bbdaeff5e5dfd041bb43cf5c) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop `openspec store remove` deleting a store the user did not name. Remove deletes the target's folder recursively, but it checked only the target's own metadata, so any other registered store living inside that folder was deleted with it, uncommitted planning work included, while its registry entry was left pointing at a path that no longer existed. The natural way to get there is a shared store vendored into another as a git submodule, a layout `store register` accepts. Remove now refuses when another registration points inside the folder, checked under the same registry lock that commits the removal, and the error names each nested store with the `openspec store unregister` command to run first. Removing a store whose other registrations are siblings is unchanged, and `store register` still accepts nested checkouts.
|
||||
|
||||
- [#1884](https://github.com/Fission-AI/OpenSpec/pull/1884) [`5d22145`](https://github.com/Fission-AI/OpenSpec/commit/5d221456e57feb9277de40482fade427201b9bdb) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Let `openspec store setup --no-init-git` create a store inside an existing Git repository. Setup refuses a path inside another repository because initializing the store there would nest one repository in another, but it ran that check even with `--no-init-git`, which creates no repository at all. Users who keep their home directory as a dotfiles repository therefore could not set up a store at the recommended `~/openspec/<id>` path with any flag. With `--no-init-git` the check is now skipped, and the store never records the enclosing repository's remote. The default setup and an explicit `--init-git` still refuse a path inside another repository.
|
||||
|
||||
- [#1862](https://github.com/Fission-AI/OpenSpec/pull/1862) [`8fc65b7`](https://github.com/Fission-AI/OpenSpec/commit/8fc65b7f70c4bd730a1dbe500cbe165d156f3c58) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Count task checkboxes under every CommonMark list marker. The task counter shared by `list`, `status`, `view`, `instructions apply`, `validate --archived` and archive's incomplete-task check recognized only `-` and `*` bullets, so a task written as an ordered item (`1. [ ]`, `1) [ ]`) or under a `+` bullet was invisible to all of them: a change with unfinished ordered tasks reported "✓ Complete", and `openspec archive` archived it without its incomplete-task warning. Task lines under `+` and ordered markers (`.` or `)`, up to nine digits, as CommonMark allows) now count exactly like `-` and `*` ones, including nested sub-tasks, CRLF files and the existing tolerance of a missing space after the marker, and task-numbering checks now see them too. Ordered and `+` items without a checkbox are still ignored, and `-` and `*` tasks count as before.
|
||||
|
||||
- [#1777](https://github.com/Fission-AI/OpenSpec/pull/1777) [`3312af4`](https://github.com/Fission-AI/OpenSpec/commit/3312af4799eb162d3ddb7804d643ace5282c22cb) Thanks [@clay-good](https://github.com/clay-good)! - Start generated proposal, spec, design, and tasks files with a top-level heading, so artifacts are complete markdown documents instead of files whose first line is a section header. Editors that run markdownlint no longer flag every OpenSpec artifact with MD041. `openspec schema init` scaffolds custom templates the same way.
|
||||
|
||||
`openspec show --json` and `openspec change list --json` keep naming a change by its id when its proposal opens with the template's bare `# Proposal` title.
|
||||
|
||||
- [#1778](https://github.com/Fission-AI/OpenSpec/pull/1778) [`7de2404`](https://github.com/Fission-AI/OpenSpec/commit/7de24044ef4c635f634b78fa6bc4b5905967bfd8) Thanks [@clay-good](https://github.com/clay-good)! - Make the vendor-neutral tool target findable when your assistant is not on the list. `openspec init` now shows it as "Other / Universal (shared .agents skills)"; the picker's search box matches it on `universal`, `other`, `generic`, `custom`, `proprietary`, `unlisted`, `unsupported`, `vendor-neutral` and `agents.md`; a search that matches nothing points at it instead of ending at "No matches"; and `--tools <unknown>` names it in the error. The search box also accepts punctuation, so `.agents` and `amazon-q` filter instead of silently dropping their `.` and `-`.
|
||||
|
||||
- [#1876](https://github.com/Fission-AI/OpenSpec/pull/1876) [`605d9e7`](https://github.com/Fission-AI/OpenSpec/commit/605d9e7a2bb5c1bab90268933f9b84ff1eb8807c) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop OpenSpec rewriting a global config file it cannot parse. After a hand edit left a typo such as a trailing comma in `config.json`, the next command of any kind, including read-only ones like `openspec list`, read the fallback defaults as telemetry consent, minted a new anonymous ID and wrote it back, replacing the whole file: a `telemetry.enabled false` opt-out, the chosen profile and the workflow list were all lost, and usage events were sent. A config file that exists but does not hold a JSON object, whether it failed to parse or its root is something else such as `null`, an array or a string, is now never written implicitly, and telemetry and the update check treat it as opted out. `config set`, `config unset` and `config profile` refuse with an error that names the file and points to `openspec config edit`, and `openspec config reset --all` still replaces it. The existing "Invalid JSON" warning is unchanged, and valid or missing config files behave exactly as before.
|
||||
|
||||
- [#1840](https://github.com/Fission-AI/OpenSpec/pull/1840) [`fede536`](https://github.com/Fission-AI/OpenSpec/commit/fede536c27e03c1aaa3c17caffa837f483d9e9b9) Thanks [@clay-good](https://github.com/clay-good)! - Resolve the contradiction that left `/opsx:update`'s only write path without a governing rule. Step 4 told the agent to "Apply the requested edit", while step 5 and the guardrails told it to write only after the user confirms each revision, so the same `/opsx:update "the design now uses X"` either wrote immediately or stopped and showed the proposed revision first, depending on which passage the agent weighed. Step 4 now drafts the edit in the conversation and step 5 owns every artifact write, matching the workflow's own specified behavior: propose each revision and apply it only after user confirmation. Fixes [#1836](https://github.com/Fission-AI/OpenSpec/issues/1836).
|
||||
|
||||
- [#1858](https://github.com/Fission-AI/OpenSpec/pull/1858) [`db560ae`](https://github.com/Fission-AI/OpenSpec/commit/db560ae33f565b76ebbc040782ec7007295e8133) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop `validate` accepting a requirement whose only scenario is a bare header. The delta scenario counter counted every `####` header, while the spec path that archive uses to validate the rebuilt spec keeps a scenario only when its body has content, so `validate` called such a change valid and `archive` then refused it with a generic "Requirement must have at least one scenario" that did not name the requirement. Both paths now share one rule, `hasScenarioBody`, and read a scenario's body up to the same boundary, so `validate` rejects exactly what archive rejects, naming the requirement and saying that a header with no body under it does not count. A scenario whose body is only a fenced block or a deeper header still counts, a requirement with one real scenario is still accepted even when another is empty, and main-spec validation is unchanged.
|
||||
|
||||
- [#1774](https://github.com/Fission-AI/OpenSpec/pull/1774) [`09984b8`](https://github.com/Fission-AI/OpenSpec/commit/09984b824254f9e35bcdf628fdb052a689a57f37) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Task lists without checkboxes are now caught**: a `tasks.md` written as plain bullets or a numbered list counts as zero tasks, so `openspec list` and `openspec status` reported "No tasks" and `openspec archive` had no unfinished work to warn about. `openspec validate` now warns when a change's tracked task files contain list items but no checkbox at all, and points at the first offending line.
|
||||
|
||||
- [#1852](https://github.com/Fission-AI/OpenSpec/pull/1852) [`5f5914e`](https://github.com/Fission-AI/OpenSpec/commit/5f5914e7f7a817262c7564ac92694db833564978) Thanks [@clay-good](https://github.com/clay-good)! - Match the natural "openspec <verb>" phrasing to the workflow it names. Users and agents say "openspec propose" or "do an openspec apply", but no workflow skill's description contained that phrasing (and a skill's description is what an agent matches on), so the phrase read as an invitation to hand-build the artifacts with the CLI instead of running the workflow. Every workflow skill's description now names the phrasings a user actually types ("openspec propose", "opsx apply", and so on). Run `openspec update` to pick it up. `openspec update` itself is deliberately left unclaimed: it is a real CLI command that refreshes generated files, unrelated to the update-change workflow, which claims "openspec update change" instead. Commands-only installs write no skills and are unchanged. Fixes [#1221](https://github.com/Fission-AI/OpenSpec/issues/1221).
|
||||
|
||||
## 1.13.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1783](https://github.com/Fission-AI/OpenSpec/pull/1783) [`8ba4ac1`](https://github.com/Fission-AI/OpenSpec/commit/8ba4ac1b16a33830a766f0c03d224d516b6a90ce) Thanks [@clay-good](https://github.com/clay-good)! - Apply now says when a change has no delta specs. Apply gates on the schema's `apply.requires` alone, so a change whose `tasks.md` was written ahead of its specs read as ready to implement even though it had no spec deltas at all — the state `openspec validate` rejects. `openspec instructions apply` now reports that gap as a warning (text and `--json`), naming both ways out: write the specs, or declare `skip_specs: true`. Changes that have specs, declare `skip_specs`, or are still blocked on their own required artifacts are unaffected.
|
||||
|
||||
A blocked apply also names the whole chain now, not just the first hop: a change holding only a proposal reported `Missing artifacts: tasks` while the specs that `tasks` depends on were missing too, which reads as an instruction to write the tracking file straight from the proposal. The full build order is reported as `missingPrerequisites` in `--json`. The remedies these messages give are CLI commands (`openspec instructions <artifact> --change <name>`) rather than the `openspec-continue-change` skill, which the `core` profile never installs.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1798](https://github.com/Fission-AI/OpenSpec/pull/1798) [`aedf4d0`](https://github.com/Fission-AI/OpenSpec/commit/aedf4d0c64c4bdde2e21f199aee93fa0d598c33e) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop archive rewriting the inside of fenced code blocks. The final assembly in `buildUpdatedSpec` collapsed runs of blank lines across the whole rebuilt document to tidy the seams between the slices it rejoins, but the pass was not fence-aware, so a requirement documenting a sample with two or more consecutive blank lines had that sample silently edited on archive, and edited again on every later archive. That matters wherever whitespace carries meaning: YAML block scalars, Python, expected-output fixtures, Markdown inside Markdown. Blank runs are now collapsed only outside fenced blocks, using the same `buildCodeFenceMask` every other structural pass in the module already used. Behavior outside fences is unchanged, including that only a truly empty line counts as blank, so a line of spaces is still never a collapse boundary. Fixes [#1797](https://github.com/Fission-AI/OpenSpec/issues/1797).
|
||||
|
||||
- [#1800](https://github.com/Fission-AI/OpenSpec/pull/1800) [`fadac3e`](https://github.com/Fission-AI/OpenSpec/commit/fadac3e1c927bf5180ce82c806435c61db5d5adb) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Read a removal or rename written with `*` or `+` as the operation it is. CommonMark opens a bullet list with `-`, `*` or `+`, but the bullet form of `## REMOVED Requirements` and the `FROM:`/`TO:` lines of `## RENAMED Requirements` both hardcoded `-`, so either other marker matched nothing at all. The operation then silently never happened: `openspec validate` reported the change valid, `openspec archive` exited 0 with "Specs updated successfully", and the requirement that was supposed to be deleted or renamed stayed exactly as it was. The change archived as complete, leaving the spec quietly disagreeing with the delta that was meant to update it. Both forms now accept `[-*+]`, the `FROM:`/`TO:` bullet stays optional, and the plain `### Requirement:` header form is unchanged. Fixes [#1799](https://github.com/Fission-AI/OpenSpec/issues/1799).
|
||||
|
||||
- [#1802](https://github.com/Fission-AI/OpenSpec/pull/1802) [`8251763`](https://github.com/Fission-AI/OpenSpec/commit/8251763ecdc349a0a1484f09da85f7e5c33f4836) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Apply every delta section, not just one copy of each. A delta file that wrote the same header twice, two `## ADDED Requirements` sections say, silently kept one of them: sections were collected into a record keyed by title, so a repeated title overwrote the earlier body, and the case-insensitive lookup returned only the first entry that folded to the target, so `## ADDED Requirements` beside `## Added Requirements` left the second unread. Every requirement under the discarded copy was gone before validation or the merge could see it, so `openspec validate` reported zero issues and `openspec archive` exited 0 having applied less than the author wrote, then moved the change to the archive with the live spec quietly diverging from what was reviewed. Sections are now kept as a list and every body whose title matches is read, each keeping its own line numbers so diagnostics still point at the right copy. Rename pairs are read per section, so a `FROM:` in one copy of the header can never pair with a `TO:` in another. An author does not have to repeat a header on purpose to hit this: a delta documenting OpenSpec's own syntax inside a fenced example produces the duplicate on its own. Fixes [#1801](https://github.com/Fission-AI/OpenSpec/issues/1801).
|
||||
|
||||
- [#1657](https://github.com/Fission-AI/OpenSpec/pull/1657) [`6d2dbe6`](https://github.com/Fission-AI/OpenSpec/commit/6d2dbe62d3386ac0df576136759775678102acf2) Thanks [@clay-good](https://github.com/clay-good)! - Load project context before proposal planning, using the selected project or store root and honoring config precedence and validation limits. When no root exists, stop without writing files and offer initialization instead of creating an implicit root.
|
||||
|
||||
- [#1700](https://github.com/Fission-AI/OpenSpec/pull/1700) [`3915db7`](https://github.com/Fission-AI/OpenSpec/commit/3915db763ad5394b29cdd895c87a91c837313ae8) Thanks [@clay-good](https://github.com/clay-good)! - Teach the generated guidance how to find and read a project's specs. `openspec list --specs` appeared in no generated skill, command, or artifact instruction, while `openspec list --json` (the in-flight *change* list) appeared throughout, so an agent asked to read the existing specs first enumerated changes instead and reported the step complete against the wrong object. The explore skill and command now list the spec inventory alongside the change list and say which is which, and the spec-driven `proposal` and `specs` instructions name the command where they ask for existing capabilities to be researched and for a delta's path to match an existing one. Both steps carry `--store "<id>"`, and capabilities are read with `openspec show "<spec-id>" --type spec --json --no-scenarios` so the read resolves against the same root the listing came from. Fixes [#1689](https://github.com/Fission-AI/OpenSpec/issues/1689).
|
||||
|
||||
The filtered read is only an overview. Agents read relevant specs in full, including scenarios, before deciding what is already covered or what should change.
|
||||
|
||||
- [#1779](https://github.com/Fission-AI/OpenSpec/pull/1779) [`3c6d318`](https://github.com/Fission-AI/OpenSpec/commit/3c6d318b837f443d1aabf969ce368e78ae12e891) Thanks [@clay-good](https://github.com/clay-good)! - `openspec init` and `openspec update` now name the workflows your profile left out and how to add them, so a command that was never installed no longer reads as a broken setup.
|
||||
|
||||
- [#1808](https://github.com/Fission-AI/OpenSpec/pull/1808) [`d9e1a28`](https://github.com/Fission-AI/OpenSpec/commit/d9e1a28c38927e6d649781976cd1a753e28973af) Thanks [@dwin-gharibi](https://github.com/dwin-gharibi)! - Stop `openspec update` reporting a tool up to date while a damaged command file sits on disk. The check read the `generatedBy` version marker in a tool's skill files alone, which proves only that the skill files came from this CLI and says nothing about the command files written beside them, so a hand-edited or truncated command file left update printing "All 1 tool(s) up to date" and repairing nothing; the file could be restored only by knowing to pass `--force`. A deleted command file was already detected, so the claim was false only for a damaged one. Update now also compares command-file content, using the comparison that already existed and was simply never consulted once a skill file supplied a version. Scoped to tools configured for both skills and commands, so the commands-only path is unchanged, and skipped when the delivery mode generates no commands for the tool. Fixes [#1807](https://github.com/Fission-AI/OpenSpec/issues/1807).
|
||||
|
||||
- [#1782](https://github.com/Fission-AI/OpenSpec/pull/1782) [`c170dc7`](https://github.com/Fission-AI/OpenSpec/commit/c170dc77adbe868ce731e07df2806a7ca8fcb4ec) Thanks [@clay-good](https://github.com/clay-good)! - Fix `retire_capabilities` refusing any spec whose scenario bullets wrap onto a second line. The continuation line was counted as content the merge could not account for, which blocked the retirement and suppressed the hint that names the marker ([#1780](https://github.com/Fission-AI/OpenSpec/issues/1780)). A spec bulleted with `+` is covered too: naming only `-` and `*` as list markers reported every one of its scenario bullets as unaccounted content, so that capability could not be retired at all either.
|
||||
|
||||
## 1.12.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1171](https://github.com/Fission-AI/OpenSpec/pull/1171) [`44a39eb`](https://github.com/Fission-AI/OpenSpec/commit/44a39eb24b7ca0f2cf08df697888c3b1e9818a5a) Thanks [@aleksandr4842](https://github.com/aleksandr4842)! - Add SourceCraft Code Assistant as a supported tool for project skills and commands in its VS Code extension.
|
||||
|
||||
- [#1713](https://github.com/Fission-AI/OpenSpec/pull/1713) [`db03c6c`](https://github.com/Fission-AI/OpenSpec/commit/db03c6c4b0ef8a05308497482bdc5fc4dd151569) Thanks [@Marzx13](https://github.com/Marzx13)! - ### New Features
|
||||
|
||||
- Add `openspec validate --report findings` for explicit bulk scopes. It returns only items with errors, warnings, or information while keeping full-run totals and exit codes. JSON output identifies the report and its scope; human output includes each finding's path and message. The default full report is unchanged.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1710](https://github.com/Fission-AI/OpenSpec/pull/1710) [`a4fcdbe`](https://github.com/Fission-AI/OpenSpec/commit/a4fcdbece6f4f7ce86fbd57230be2753945020ba) Thanks [@ryandemelo](https://github.com/ryandemelo)! - Report delta merge conflicts during validation as informational findings, including in successful text reports, without changing validation exit codes. Preserve filesystem read errors so unreadable main specs are not mistaken for missing specs.
|
||||
|
||||
Keep the validation report intact when the advisory merge preflight cannot resolve its inputs.
|
||||
|
||||
- [#1017](https://github.com/Fission-AI/OpenSpec/pull/1017) [`b976106`](https://github.com/Fission-AI/OpenSpec/commit/b976106d954a0eebbf94ec26b056208968313a4d) Thanks [@DanRioDev](https://github.com/DanRioDev)! - Improve explore mode guidance so it asks more useful dependency-aware questions, recommends defaults, and checks the codebase before asking for facts the repo can answer.
|
||||
|
||||
- [#1737](https://github.com/Fission-AI/OpenSpec/pull/1737) [`98bf53e`](https://github.com/Fission-AI/OpenSpec/commit/98bf53e59ec91eb71de4ed0e8036459de7352585) Thanks [@clay-good](https://github.com/clay-good)! - Guide propose and fast-forward workflows to inspect relevant project code, tests, and documentation before drafting artifacts, so plans reflect the existing implementation instead of deferring basic discovery to implementation tasks.
|
||||
|
||||
- [#786](https://github.com/Fission-AI/OpenSpec/pull/786) [`0296401`](https://github.com/Fission-AI/OpenSpec/commit/0296401b823726ae6a8d8505104e95c7899b3056) Thanks [@Br1an67](https://github.com/Br1an67)! - Preserve empty OpenSpec directories in Git after initialization. Re-running init restores missing directory markers without overwriting existing files or following marker symlinks.
|
||||
|
||||
- [#1725](https://github.com/Fission-AI/OpenSpec/pull/1725) [`cd72444`](https://github.com/Fission-AI/OpenSpec/commit/cd724449aced1655eb513f3207600bec074c7588) Thanks [@aron-intframe](https://github.com/aron-intframe)! - `openspec init` and `openspec update` now share the IDE restart hint: "Restart your IDE to refresh commands." or "Restart your IDE to refresh skills." The message also covers removing workflows, without claiming that new files were generated.
|
||||
|
||||
## 1.11.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1301](https://github.com/Fission-AI/OpenSpec/pull/1301) [`a7353ae`](https://github.com/Fission-AI/OpenSpec/commit/a7353aea9a0b23762602badf5055a157a76f62b1) Thanks [@m-tanner](https://github.com/m-tanner)! - Add `openspec status --all`, which reports every active change in one process instead of one CLI spawn per change. `--all --json` emits a single `{ "changes": [ <status>, ... ], "root" }` envelope sorted by change name; a change that fails to load contributes `{ "changeName", "status": [diagnostic] }` in place rather than aborting the sweep. A partial failure exits 1 in both text and JSON modes while preserving the complete JSON envelope. Mutually exclusive with `--change`.
|
||||
|
||||
- [#980](https://github.com/Fission-AI/OpenSpec/pull/980) [`dd7cea3`](https://github.com/Fission-AI/OpenSpec/commit/dd7cea3ffed4a22421dce02f54c37c4f076b44f0) Thanks [@bsmedberg-xometry](https://github.com/bsmedberg-xometry)! - show: add `--diff`, which renders each delta requirement against the requirement it replaces in the main spec instead of reprinting the whole block. A MODIFIED requirement has to carry every scenario it keeps, so reviewers could not see what a change actually altered without diffing files by hand. `openspec show <change> --diff` now prints a colorized unified diff per requirement (additions green, removals red), the full text of ADDED requirements, the authored Reason/Migration text of REMOVED ones, and FROM/TO for RENAMED ones; a requirement that is renamed and modified in the same delta is diffed against its old name. `--json --diff` keeps the existing payload shape and adds each applicable `diff` and `warning` field to MODIFIED deltas only. Main specs resolve against the same root as the change, so `--store <id>` diffs against that store. Without `--diff`, `openspec show <change>` prints exactly what it printed before.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#830](https://github.com/Fission-AI/OpenSpec/pull/830) [`109f81f`](https://github.com/Fission-AI/OpenSpec/commit/109f81f17d3bb99eb6fb2c9a33ec9e8ab0680bb2) Thanks [@alfred-openspec](https://github.com/alfred-openspec)! - Write Antigravity skills and workflows to `.agents/`, arbitrate its shared skill tree with other tools, and safely migrate an existing `.agent/` install.
|
||||
|
||||
- [#1712](https://github.com/Fission-AI/OpenSpec/pull/1712) [`04b37ac`](https://github.com/Fission-AI/OpenSpec/commit/04b37ac1d5c852385d2effbff196ddb4fdd1700c) Thanks [@Marzx13](https://github.com/Marzx13)! - archive: preserve a requirement's original position when renaming it instead of moving the renamed block to the end of the spec.
|
||||
|
||||
- [#1716](https://github.com/Fission-AI/OpenSpec/pull/1716) [`7010e26`](https://github.com/Fission-AI/OpenSpec/commit/7010e268907598c385eb6686699928fbd5a3a733) Thanks [@aymanxdev](https://github.com/aymanxdev)! - explore: require explicit, scope-bound confirmation before the skill uses any command or tool that can create, edit, move, or delete a file. The explore skill's guardrails let "if the user asks" cover answers to its own clarifying questions, so an agent could treat a design discussion as a go-ahead and start creating schemas or editing `openspec/config.yaml` uninvited. The skill and the `/opsx:explore` command now instruct the agent to name the proposed artifacts or files, ask a direct yes/no question, and wait for confirmation in a separate message before writing. Read-only commands and tools remain available without confirmation, and expanding the confirmed scope requires another confirmation.
|
||||
|
||||
- [#1199](https://github.com/Fission-AI/OpenSpec/pull/1199) [`ab81a4b`](https://github.com/Fission-AI/OpenSpec/commit/ab81a4b43a7bd769b1d2a33457b7b708b8c52516) Thanks [@leo-ar](https://github.com/leo-ar)! - Improve Fish completions so command, subcommand, flag, and indexed positional completions no longer fall back to filesystem suggestions unless the target is a real path.
|
||||
|
||||
- [#1010](https://github.com/Fission-AI/OpenSpec/pull/1010) [`e5e350d`](https://github.com/Fission-AI/OpenSpec/commit/e5e350d04b5d635b56846f46a212b097cd00eeb6) Thanks [@Dansyuqri](https://github.com/Dansyuqri)! - Draw explore-mode diagrams with plain ASCII. The worked examples in the explore skill and `/opsx:explore` command used Unicode box-drawing, arrow, and marker glyphs, whose display width varies across terminals, fonts, and locales. Agents copied the style, causing padded boxes and aligned tables to drift.
|
||||
|
||||
- [`2fa679f`](https://github.com/Fission-AI/OpenSpec/commit/2fa679f180424d46ce7d8789eb85138397844a89) Thanks [@ryandemelo](https://github.com/ryandemelo)! - Make `schema init --default` validate and stage config changes before installing a schema, and roll back both files if either install fails. The staging and backup directories it creates are excluded from schema discovery, so they are never offered as real schemas.
|
||||
|
||||
- [#1671](https://github.com/Fission-AI/OpenSpec/pull/1671) [`126c5d6`](https://github.com/Fission-AI/OpenSpec/commit/126c5d6c59d63b7e70314bcc776104c7cc548819) Thanks [@kitimark](https://github.com/kitimark)! - `openspec validate` now reports a `## Purpose` that is still the placeholder archive writes for a new capability, instead of passing it. The placeholder is longer than the 50-character brevity floor, so until now the one check meant to catch a Purpose nobody wrote was satisfied by the exact text saying nobody wrote one — a spec whose Purpose read `Does stuff.` failed `--strict` while a spec whose Purpose said nothing at all passed. A capability could carry the placeholder indefinitely while every command reported success.
|
||||
|
||||
It is a warning, so a project that already has placeholders on disk keeps validating by default and only `--strict` fails. The message says to edit the main spec directly, since a `## Purpose` in a delta is read only when the capability is created and cannot replace an existing one.
|
||||
|
||||
Detection is narrow. The placeholder archive generates is recognised through the same definition that writes it, wherever it appears in the Purpose. Otherwise only a `TBD` or `TODO` opening the Purpose counts, so `The retry budget is TBD pending benchmarks` is still a valid Purpose and a word like `TBDs` is not a marker. Fenced code inside the Purpose is quoted material rather than the Purpose speaking, so a spec that documents the placeholder keeps passing. An empty Purpose is unchanged, and a Purpose reported as a placeholder is no longer also reported as too brief, so a bare `TBD` yields one finding rather than two.
|
||||
|
||||
`openspec archive` is unaffected: it validates rebuilt specs without `--strict`, so a spec archive writes still passes the validation it would have passed before, and the text archive writes is unchanged.
|
||||
|
||||
## 1.10.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1685](https://github.com/Fission-AI/OpenSpec/pull/1685) [`c747ed1`](https://github.com/Fission-AI/OpenSpec/commit/c747ed1f34459ca6bc15d43ad9f68dfdf7750875) Thanks [@clay-good](https://github.com/clay-good)! - Add `openspec init --language <language>` to configure the language used for artifacts in new projects.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1704](https://github.com/Fission-AI/OpenSpec/pull/1704) [`7276c6c`](https://github.com/Fission-AI/OpenSpec/commit/7276c6c26832f699a63544302d38b1af8ddb9844) Thanks [@clay-good](https://github.com/clay-good)! - Drop the npm `postinstall` script. Its only job was printing a one-line tip about opt-in shell completions, but shipping any install script made `npm install -g @fission-ai/openspec` emit an `allow-scripts` warning that reads as a packaging fault (and `npm approve-scripts` then fails with `ENOMATCH` on a global install, since it looks in the local project). The tip now prints from the CLI on its first run — to stderr, in an interactive terminal, once, and not at all if you already have completions installed — and the published package declares no `preinstall`/`install`/`postinstall` script, so a registry install runs no OpenSpec code. Suppress the tip with `OPENSPEC_NO_COMPLETIONS=1`.
|
||||
|
||||
- [#1656](https://github.com/Fission-AI/OpenSpec/pull/1656) [`a72a74d`](https://github.com/Fission-AI/OpenSpec/commit/a72a74de6571c26fd79a193bb33fa3b8e1a767fb) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- `openspec update` now suggests restarting an IDE only when it updates an IDE-resident tool. CLI tools such as Claude Code, Codex, and Gemini CLI no longer show an unnecessary restart hint.
|
||||
|
||||
- [#1703](https://github.com/Fission-AI/OpenSpec/pull/1703) [`9643888`](https://github.com/Fission-AI/OpenSpec/commit/9643888a7525467c7a076bfec9bb075910e78bb8) Thanks [@clay-good](https://github.com/clay-good)! - Point the spec-driven `specs` instruction's main-spec read and edit at the store-aware root. It named `openspec/specs/<capability-path>/spec.md`, a path relative to the current directory, for both step 1 of the MODIFIED workflow ("locate the existing requirement") and the edit that fixes a leftover `TBD` Purpose. When the change lives in a store — whether selected with `--store`, a project `store:` pointer, or a global default store — the main spec is under the store root, so that read missed it, or silently returned a different capability when a local one happened to share the name, and the MODIFIED block was then copied from the wrong requirement. Both operations now use `<planningHome.root>/openspec/specs/...`, the root already returned by `openspec instructions ... --json` and the same convention the sync and archive workflows use. Fixes [#1702](https://github.com/Fission-AI/OpenSpec/issues/1702).
|
||||
|
||||
- [#1699](https://github.com/Fission-AI/OpenSpec/pull/1699) [`18688c8`](https://github.com/Fission-AI/OpenSpec/commit/18688c8b27820da3435a47a7f11e90073724b728) Thanks [@clay-good](https://github.com/clay-good)! - archive: tell the author how to retire a capability when the emptied spec also holds content the merge cannot account for. That combination printed only "Spec must have at least one requirement" and no guidance at all; the abort now names the blocking lines and reports a `retire_capabilities` marker that is present but cannot be honored. Authored content quoted in those messages - the blocking lines, and the marker's own reason, which `openspec validate` prints too - is stripped of control characters and bounded in length before it reaches the terminal.
|
||||
|
||||
- [#1660](https://github.com/Fission-AI/OpenSpec/pull/1660) [`7da3f34`](https://github.com/Fission-AI/OpenSpec/commit/7da3f34fb66d602bd987caa7dddcf3d6621e7d44) Thanks [@clay-good](https://github.com/clay-good)! - Require generated tasks to state how their completion can be verified.
|
||||
|
||||
## 1.9.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1622](https://github.com/Fission-AI/OpenSpec/pull/1622) [`59c16a4`](https://github.com/Fission-AI/OpenSpec/commit/59c16a4461254ed984d1d5e29d00af1a5610035a) Thanks [@clay-good](https://github.com/clay-good)! - ### New Features
|
||||
|
||||
- **Command Code command adapter** — Command Code is now a first-class, adapter-backed tool. `openspec init` generates OpenSpec commands under `.commandcode/commands/opsx-<id>.md` (invoked as `/opsx-<id>`) alongside the skills under `.commandcode/skills/`, matching Command Code's documented custom-slash-command surface.
|
||||
|
||||
- [#1613](https://github.com/Fission-AI/OpenSpec/pull/1613) [`42d7f67`](https://github.com/Fission-AI/OpenSpec/commit/42d7f673bc5f13378451267c8a9d0c23f63a2d1a) Thanks [@Angelthebestone](https://github.com/Angelthebestone)! - ### New Features
|
||||
|
||||
- **Command Code support** — `openspec init` now supports Command Code as an adapterless skills-only tool. It installs the OpenSpec skills under `.commandcode/skills/` and invokes them as `/openspec-*` commands, matching Command Code's native skill surface.
|
||||
|
||||
- [#1604](https://github.com/Fission-AI/OpenSpec/pull/1604) [`83be9d1`](https://github.com/Fission-AI/OpenSpec/commit/83be9d113e8310789c281f7c8a00ed4fad191dd5) Thanks [@clay-good](https://github.com/clay-good)! - Add `openspec validate --archived`: an opt-in check that every change under `changes/archive/` has all of its `tasks.md` checkboxes ticked, exiting non-zero if any are unchecked. This surfaces changes that were archived with unfinished work — which the normal validate flow never catches, because it only looks at active changes — and is meant for a pre-commit or CI hook ([#205](https://github.com/Fission-AI/OpenSpec/issues/205)). It is a standalone scope: it does not alter any existing `validate` invocation and does not re-validate already-applied spec deltas.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1530](https://github.com/Fission-AI/OpenSpec/pull/1530) [`bf5099e`](https://github.com/Fission-AI/OpenSpec/commit/bf5099e39fdb5d7bde2adc84f49ea93afd7463e9) Thanks [@clay-good](https://github.com/clay-good)! - Apply workflow now tells agents to surface unexpected scope instead of hiding it. When a task needs work beyond what the spec describes, the `/opsx:apply` skill and command guidance direct the agent to pause and report the added scope rather than silently narrowing, deferring, or simplifying away specified behavior, and to mark a task complete only when its specified behavior is fully implemented. Fixes [#1529](https://github.com/Fission-AI/OpenSpec/issues/1529).
|
||||
|
||||
- [#1603](https://github.com/Fission-AI/OpenSpec/pull/1603) [`9ae75c8`](https://github.com/Fission-AI/OpenSpec/commit/9ae75c86efe5d326ffa7ca5a3fd64b1f1e7728c2) Thanks [@clay-good](https://github.com/clay-good)! - `openspec archive` no longer writes terminal escape codes to a redirected or captured stdout. Its confirmation prompts and the no-argument change picker drew their live UI with ANSI cursor-move sequences even when stdout was not a terminal — noise in a redirected log, and in some non-interactive hosts an unbounded render loop that could grow the captured output until the disk filled. When stdout (or stdin) is not a terminal, archive now reads the confirmations as plain text, and a no-argument run asks you to pass a change name up front instead of drawing a menu. Piped answers (`printf 'y\n' | openspec archive …`) and `--yes` behave as before, and interactive terminals are unchanged. Fixes [#1526](https://github.com/Fission-AI/OpenSpec/issues/1526).
|
||||
|
||||
- [#1528](https://github.com/Fission-AI/OpenSpec/pull/1528) [`9425897`](https://github.com/Fission-AI/OpenSpec/commit/942589741de35f1b8896b410d7ea70295bb137c0) Thanks [@Marzx13](https://github.com/Marzx13)! - Canonicalize rebuilt specs to end with exactly one final LF. Previously a spec whose `## Requirements` section was last was rebuilt with a trailing blank line (`\n\n`), which failed Markdown whitespace checks after sync or archive. Internal spacing and content after the Requirements section are unchanged.
|
||||
|
||||
- [#1640](https://github.com/Fission-AI/OpenSpec/pull/1640) [`610b78f`](https://github.com/Fission-AI/OpenSpec/commit/610b78f6554e8aabfa294df53962428ff85c8b76) Thanks [@clay-good](https://github.com/clay-good)! - Preserve the blank lines around a spec's `## Requirements` heading when syncing a delta. `openspec archive` rebuilt `openspec/specs/<capability>/spec.md` by joining its slices with a bare newline, so the blank lines that surround the heading were dropped and the resulting file failed Markdown whitespace checks. The rebuild now keeps that spacing intact. Fixes [#1625](https://github.com/Fission-AI/OpenSpec/issues/1625). Thanks [@jwang513](https://github.com/jwang513)! ([#1637](https://github.com/Fission-AI/OpenSpec/pull/1637))
|
||||
|
||||
- [#1640](https://github.com/Fission-AI/OpenSpec/pull/1640) [`610b78f`](https://github.com/Fission-AI/OpenSpec/commit/610b78f6554e8aabfa294df53962428ff85c8b76) Thanks [@clay-good](https://github.com/clay-good)! - `openspec validate --all` and `openspec list --json` no longer silently pass when run outside an OpenSpec project. From a directory with no root they used to resolve the current directory as an implicit root, exit 0, and report empty results — a false pass for CI and agents. Bulk validation (`--all`, `--changes`, `--specs`) and `list` now require an existing root (the `openspec/project.md` fallback for legacy projects is kept), while direct validation and other intentional implicit-root workflows are unchanged. Thanks [@clay-good](https://github.com/clay-good)! ([#1612](https://github.com/Fission-AI/OpenSpec/pull/1612))
|
||||
|
||||
- [#1640](https://github.com/Fission-AI/OpenSpec/pull/1640) [`610b78f`](https://github.com/Fission-AI/OpenSpec/commit/610b78f6554e8aabfa294df53962428ff85c8b76) Thanks [@clay-good](https://github.com/clay-good)! - Label the `update` workflow in the `openspec config` workflow picker. The checklist had friendly labels for 11 of the 12 workflows but was missing `update`, so that row — one of the six core workflows every user sees — fell back to its raw id with a placeholder description. The update-change template's stale "expanded-profile" wording is also reworded to "optional". Fixes [#1627](https://github.com/Fission-AI/OpenSpec/issues/1627). Thanks [@clay-good](https://github.com/clay-good)! ([#1632](https://github.com/Fission-AI/OpenSpec/pull/1632))
|
||||
|
||||
- [#1640](https://github.com/Fission-AI/OpenSpec/pull/1640) [`610b78f`](https://github.com/Fission-AI/OpenSpec/commit/610b78f6554e8aabfa294df53962428ff85c8b76) Thanks [@clay-good](https://github.com/clay-good)! - `openspec schema fork` now preserves the source schema's YAML formatting. Renaming a forked `schema.yaml` round-tripped through a parse/re-serialize step that dropped comments, could rewrite block-scalar style (a literal `|` folded to `>`), and reordered keys, so the fork no longer matched its source. The rename now edits the document in place via the YAML Document API, leaving comments, scalar style, and key order untouched. Thanks [@clay-good](https://github.com/clay-good)! ([#1607](https://github.com/Fission-AI/OpenSpec/pull/1607))
|
||||
|
||||
- [#1640](https://github.com/Fission-AI/OpenSpec/pull/1640) [`610b78f`](https://github.com/Fission-AI/OpenSpec/commit/610b78f6554e8aabfa294df53962428ff85c8b76) Thanks [@clay-good](https://github.com/clay-good)! - `openspec schemas` now resolves through the canonical OpenSpec root-selection precedence instead of always reading from the current directory. It accepts `--store <id>`, rejects `--store-path` like the other store-aware commands, and returns the shared machine-readable diagnostics on JSON failures, while preserving the existing human output and bare JSON array on success. Thanks [@Patodo](https://github.com/Patodo)! ([#1616](https://github.com/Fission-AI/OpenSpec/pull/1616))
|
||||
|
||||
- [#1640](https://github.com/Fission-AI/OpenSpec/pull/1640) [`610b78f`](https://github.com/Fission-AI/OpenSpec/commit/610b78f6554e8aabfa294df53962428ff85c8b76) Thanks [@clay-good](https://github.com/clay-good)! - `openspec validate` now warns on ambiguous task numbering in `spec-driven` changes: a task ID duplicated at full depth (including across resolved task files), or a task whose leading number disagrees with its enclosing `## N.` group. Numeric-looking text outside numbered groups is ignored, and custom schemas are unchanged until they opt in. The checks run across direct, bulk, and deprecated change validation. Closes [#1520](https://github.com/Fission-AI/OpenSpec/issues/1520). Thanks [@alectimison-maker](https://github.com/alectimison-maker)! ([#1523](https://github.com/Fission-AI/OpenSpec/pull/1523))
|
||||
|
||||
- [#1522](https://github.com/Fission-AI/OpenSpec/pull/1522) [`07dea6e`](https://github.com/Fission-AI/OpenSpec/commit/07dea6ed2faf71c8b9f4944d64246f2ff39eeffc) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Don't let a legacy Codex upgrade hijack the vendor-neutral `agents` target** — `openspec update` no longer overwrites an existing `.agents` skills tree (and its ownership marker) when Codex is detected only from leftover global `~/.codex/prompts`. Because Codex and the vendor-neutral `agents` target share `.agents/skills`, a project that used the `agents` target could have its generic skills silently rewritten with Codex-specific syntax and its target flipped to Codex on the next `update --force`. The legacy-upgrade path now respects the established owner of a shared skills directory, matching the one-writer rule `openspec init` already applies. When an upgrade is skipped this way, that tool's repo-local legacy files (e.g. `.codex/prompts/openspec-*.md`) are also preserved rather than cleaned up, since no replacement was written to take their place. A genuine first-time Codex upgrade (no `.agents` tree yet) is unaffected.
|
||||
|
||||
- [#1521](https://github.com/Fission-AI/OpenSpec/pull/1521) [`c751b3d`](https://github.com/Fission-AI/OpenSpec/commit/c751b3da52a7f06d6662a8673feff4685566cdd4) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Stop silently dropping unlabeled scenarios on archive** — `openspec validate` and `openspec archive` now recognize every level-4 (`####` followed by whitespace) child of a requirement as a scenario, matching how the spec is counted elsewhere. Before, the scenario-loss guard only recognized headers written exactly as `#### Scenario:`, so a `MODIFIED` requirement that dropped a differently-labeled child (for example `#### Edge case`) passed validation and was then permanently deleted by archive with no warning. Both paths now agree, so the loss is caught at authoring time. Scenario names are normalized when comparing (an optional `Scenario:` prefix and a CommonMark closing `#` run are ignored), so simply relabeling a scenario is not mistaken for dropping one.
|
||||
|
||||
- [#1610](https://github.com/Fission-AI/OpenSpec/pull/1610) [`17581c1`](https://github.com/Fission-AI/OpenSpec/commit/17581c11edf6b27ef18be7be1e4dcc06c81a3fff) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- `openspec init` now suggests an IDE restart only when an IDE-resident tool such as Cursor, GitHub Copilot, Continue, or Cline was configured. CLI tools like Claude Code, Codex, and Gemini CLI no longer show the hint, since their commands work as soon as the files exist.
|
||||
|
||||
- [#1609](https://github.com/Fission-AI/OpenSpec/pull/1609) [`804427b`](https://github.com/Fission-AI/OpenSpec/commit/804427b6ff3f3b35b542365ba8b32e183fce3287) Thanks [@clay-good](https://github.com/clay-good)! - Suppress the first-run telemetry disclosure notice when `--json` is used. On a
|
||||
first-ever run the notice was written to stdout and could break `--json`
|
||||
consumers; it is now deferred to the first later non-JSON run, keeping `--json`
|
||||
output valid while still guaranteeing the disclosure.
|
||||
|
||||
## 1.8.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1303](https://github.com/Fission-AI/OpenSpec/pull/1303) [`1aa0f2a`](https://github.com/Fission-AI/OpenSpec/commit/1aa0f2abfc19f2487f5b8566e6eb3bf15f41c20a) Thanks [@solanab](https://github.com/solanab)! - Add the vendor-neutral `agents` target: `openspec init --tools agents` installs the workflow skills to `.agents/skills/openspec-*/SKILL.md`, the shared location AGENTS.md-compatible assistants read. It is skills-only, so no slash commands are generated. Because `agents` is now a real target, `--tools all` includes it and creates `.agents/skills/` where it previously did not.
|
||||
|
||||
- [#1274](https://github.com/Fission-AI/OpenSpec/pull/1274) [`7a4a745`](https://github.com/Fission-AI/OpenSpec/commit/7a4a745d803b698c34947eda6d73b5a24aebb58c) Thanks [@NicoAvanzDev](https://github.com/NicoAvanzDev)! - Generate GitHub Copilot coding agent setup and custom agent files during `openspec init` and keep them synchronized during `openspec update`.
|
||||
|
||||
- [#1214](https://github.com/Fission-AI/OpenSpec/pull/1214) [`161f945`](https://github.com/Fission-AI/OpenSpec/commit/161f9454a372aab67c495d780928bba89c829f3e) Thanks [@showms](https://github.com/showms)! - Add MiniMax Code as a global skills-only tool target.
|
||||
|
||||
- [#1518](https://github.com/Fission-AI/OpenSpec/pull/1518) [`568e56c`](https://github.com/Fission-AI/OpenSpec/commit/568e56c67231dbe2447aca4f0e7995c05ada95a3) Thanks [@clay-good](https://github.com/clay-good)! - ### New Features
|
||||
|
||||
- **Atlassian Rovo Dev CLI** — `openspec init --tools rovodev` installs the OpenSpec workflow skills for Atlassian's Rovo Dev CLI. It is skills-only (no slash commands), written to `.rovodev`.
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- **Codex skills now live in the shared `.agents` directory** — `openspec init` and `openspec update` install Codex skills under `.agents/skills/` (the canonical location assistants read) and migrate an existing `.codex` skills directory in place. Files you customized are preserved, not overwritten.
|
||||
- **`openspec status` separates planning from implementation** — status now reports `isPlanningComplete` (every non-skipped planning artifact exists; skipped artifacts count as satisfied without being written) distinctly from overall progress, and its messages no longer imply a change is finished before it has been implemented. `isComplete` is kept as a compatibility alias, so existing scripts keep working.
|
||||
|
||||
- [#1517](https://github.com/Fission-AI/OpenSpec/pull/1517) [`73207a6`](https://github.com/Fission-AI/OpenSpec/commit/73207a6f2cd235729ac3fe3cb1e44152b8f63f12) Thanks [@clay-good](https://github.com/clay-good)! - Make GitHub Copilot cloud coding-agent files opt-in. Selecting the `github-copilot` tool no longer silently writes a GitHub Actions workflow into `.github/`; `openspec init` now asks first (default No) and remembers the choice in `openspec/config.yaml` (`githubCopilot.cloudAgent`). Use `--copilot-cloud` / `--no-copilot-cloud` to decide non-interactively.
|
||||
|
||||
- `openspec update` never prompts — it only refreshes cloud files for projects that opted in (or that already have generated cloud files, so existing setups keep working).
|
||||
- Opting out (`--no-copilot-cloud` or `cloudAgent: false`) removes OpenSpec-managed cloud files; a user-customized file is always preserved, never overwritten or deleted.
|
||||
- `init` and `update` now report whether cloud files were written, skipped, or left untouched — and if you already have your own `copilot-setup-steps.yml`, they say it was preserved and that you need to add the OpenSpec install step by hand.
|
||||
|
||||
- [#1484](https://github.com/Fission-AI/OpenSpec/pull/1484) [`521ee33`](https://github.com/Fission-AI/OpenSpec/commit/521ee33e6ece269241b45e08017ee60f13fdef08) Thanks [@clay-good](https://github.com/clay-good)! - Retire a capability when a change removes its last requirement. A change that declares `retire_capabilities: true` in its `.openspec.yaml` (alongside the `schema:` that file requires) may now be archived even when its REMOVED entries take a capability's last requirement: `openspec archive` deletes that capability's main spec instead of aborting with "Spec must have at least one requirement". Without the marker nothing changes — the archive aborts exactly as before, except the message now names the marker as the way out. Retirement happens only when the emptied spec could not have been written at all, every one is named in the archive output, a pasteable `git checkout` is included when the spec lived in the caller's checkout, and `--no-validate` never retires. Archive now also rejects a main spec with duplicate canonical requirement names instead of letting delta reconciliation collapse one of the duplicate blocks. One thing to know before retiring: a capability's spec is the base another change's MODIFIED block is checked against, so an in-flight change that modifies the capability you just retired will keep validating clean and then refuse to archive ("target spec does not exist; only ADDED requirements are allowed for new specs") — close or rework that change alongside the retirement.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1502](https://github.com/Fission-AI/OpenSpec/pull/1502) [`ece8660`](https://github.com/Fission-AI/OpenSpec/commit/ece8660d44bd19b86440376327752cda3d7b0717) Thanks [@clay-good](https://github.com/clay-good)! - `openspec validate` now treats the English `SHALL`/`MUST` convention as guidance in normal mode, so requirements written in other languages can validate. Strict mode continues to enforce the convention.
|
||||
|
||||
- [#1483](https://github.com/Fission-AI/OpenSpec/pull/1483) [`2b3d368`](https://github.com/Fission-AI/OpenSpec/commit/2b3d368539132be6311e55db58899abbf5306b81) Thanks [@clay-good](https://github.com/clay-good)! - Tell the caller which flag to pass when `openspec archive` cannot ask its confirmation questions. An AI agent (or any script) runs the CLI with stdin closed, so every prompt rejects with `@inquirer`'s `User force closed the prompt with 0 null` — the archive aborted with an error that named neither the question nor the flag, and agents burned a turn guessing ([#1479](https://github.com/Fission-AI/OpenSpec/issues/1479)). Each confirmation now reports what it needed and a pasteable rerun that carries the flags you already passed: `openspec archive <name> --skip-specs --yes` stays a `--skip-specs` run, so following the suggestion cannot merge specs you opted out of merging, and a change name that needs quoting gets double quotes, the one form bash, zsh, PowerShell and cmd.exe all read the same way (a name no shell reads literally even quoted — one containing `$`, a backtick, or the `%`/`!` that cmd.exe still expands inside quotes — is left as a `<change-name>` placeholder rather than a command that would target something else). `openspec archive` with no change name used to swallow the same failure, print `No change selected. Aborting.` and exit 0 — success for a run that archived nothing; it now exits 1 asking for a change name, matching how `openspec show` and `openspec validate` already behave without a terminal. The check is reactive — it inspects a prompt that already failed — so answers piped into the command, `--yes`, `--json`, and Ctrl-C all behave exactly as before, and a run that OpenSpec already considers non-interactive (`CI`, `OPEN_SPEC_INTERACTIVE=0`, `--no-interactive`) gets the guidance even when the runner allocated a pty. The onboarding walkthrough, the only generated guidance that tells an agent to run `openspec archive`, now shows `--yes`.
|
||||
|
||||
- [#1486](https://github.com/Fission-AI/OpenSpec/pull/1486) [`427abf4`](https://github.com/Fission-AI/OpenSpec/commit/427abf40ac45a9a44f78eb74c81f53f9f4197ccf) Thanks [@clay-good](https://github.com/clay-good)! - Task progress now counts indented sub-tasks. A `tasks.md` whose sub-tasks were unfinished reported `✓ Complete` in `openspec list` and `openspec view`, was missing those tasks from the `openspec instructions apply` list, and archived with no incomplete-task warning, because both checkbox parsers only matched checkboxes at column 0.
|
||||
|
||||
Progress counting and the apply task list now share one parser, so `list`, `view`, `archive` and `apply` agree about which lines of a tasks file are tasks. A checkbox with no text after it is left out of the apply list, which has nothing to act on, but still counts toward every progress number; a file of nothing but such checkboxes now asks to be rewritten rather than reporting itself done. The shared pattern matches every line the two it replaced matched, and more, so task counts can rise but never fall: no change starts reporting less work than before, and archive's incomplete-task warning can only become stricter. Checkboxes are still counted wherever they appear, including inside a code fence, an HTML comment or an indented block, so a `tasks.md` that shows a checklist as a format example can now count that example as work — remove it from the file, or pass `--yes` to archive.
|
||||
|
||||
- [#1500](https://github.com/Fission-AI/OpenSpec/pull/1500) [`26bd1d4`](https://github.com/Fission-AI/OpenSpec/commit/26bd1d4e5c6c6ba75bd7d6136424019b2bf89ced) Thanks [@clay-good](https://github.com/clay-good)! - Keep generated workflows on the selected store, handle optional workflow fallbacks safely, and validate synced specs before reporting success.
|
||||
|
||||
- [#1490](https://github.com/Fission-AI/OpenSpec/pull/1490) [`45cca5d`](https://github.com/Fission-AI/OpenSpec/commit/45cca5db6137ed209117cc70510eb3e057fb981b) Thanks [@clay-good](https://github.com/clay-good)! - Say before confirmation when archiving a change will delete a note written next to a requirement. A requirement absorbs anything below it that OpenSpec doesn't recognize as a new heading — a note indented by the one to three spaces Markdown allows, for example — so removing or modifying that requirement took the note with it, silently. `openspec archive` now names content the rebuilt spec would actually drop and where to move it to keep it. The merge itself is unchanged: nothing is relocated, because a `#` line inside a scenario looks identical to a note and moving one of those would rewrite the spec wrongly.
|
||||
|
||||
- [#1492](https://github.com/Fission-AI/OpenSpec/pull/1492) [`690a27e`](https://github.com/Fission-AI/OpenSpec/commit/690a27e649c4a3325daeb0f6667ebe0f82792179) Thanks [@mc856](https://github.com/mc856)! - `openspec init` and `openspec update` no longer delete the CoStrict and Junie command files they just generated. Legacy cleanup removes artifacts older OpenSpec versions left behind, and two of its patterns named paths the current adapters still write to. CoStrict's was a whole-directory removal of `.cospec/openspec/commands/`, the folder the adapter writes `opsx-<id>.md` into, so every run wiped the directory — including any file the user kept there — while the banner above it read `No user content to preserve`. Junie's `.junie/commands/opsx-*.md` listed its own current output. Cleanup runs before the config migration, so on a config that has no `profile` key yet the missing command files make delivery detection read the project as skills-only and persist that to the global config: the files are not regenerated, and the preference changes for every other project too.
|
||||
|
||||
CoStrict is now a file pattern, `.cospec/openspec/commands/openspec-*.md`, matching the three commands the pre-`opsx` CoStrict integration wrote there (`openspec-proposal.md`, `openspec-apply.md`, `openspec-archive.md`) and the same shape every other file-based tool already uses. Junie's entry is removed outright: Junie support arrived after the slash configurators that wrote `openspec-*` files were deleted, so no OpenSpec version ever created those files there. Genuinely legacy files are still detected and removed, and no other tool's patterns change — they never overlapped their adapter's current output.
|
||||
|
||||
- [#1501](https://github.com/Fission-AI/OpenSpec/pull/1501) [`0b20ae3`](https://github.com/Fission-AI/OpenSpec/commit/0b20ae3964283bdcb4e34ea7380770857f6a339c) Thanks [@clay-good](https://github.com/clay-good)! - Keep the propose workflow focused on planning, clarify material ambiguities before creating a change, and hand implementation off to the apply workflow.
|
||||
|
||||
- [#1503](https://github.com/Fission-AI/OpenSpec/pull/1503) [`8a3850d`](https://github.com/Fission-AI/OpenSpec/commit/8a3850da735e241c14ad94935463f879b33f21a9) Thanks [@clay-good](https://github.com/clay-good)! - When exploration turns into a new change, generated explore guidance now instructs agents to run `openspec new change` before writing requested artifacts. This preserves the required `.openspec.yaml` metadata instead of letting an agent create an incomplete change directory by hand. After the user accepts a capture, explore also creates the requested artifacts without requiring another workflow command.
|
||||
|
||||
- [#1513](https://github.com/Fission-AI/OpenSpec/pull/1513) [`622c509`](https://github.com/Fission-AI/OpenSpec/commit/622c509a1349c3ad9c52cd1a4ee007bd47549204) Thanks [@FasterPHP](https://github.com/FasterPHP)! - Honor `telemetry.enabled` in global config. `false` disables anonymous telemetry and `openspec update` version checks; unset keeps telemetry enabled, and env/CI opt-outs still take precedence.
|
||||
|
||||
- [#1499](https://github.com/Fission-AI/OpenSpec/pull/1499) [`9cd845f`](https://github.com/Fission-AI/OpenSpec/commit/9cd845fc459b71486d9f2424c2e1f38e2ca8766e) Thanks [@clay-good](https://github.com/clay-good)! - Keep generated files, specs, archive moves, and local state inside their intended security boundaries without breaking linked monorepo workflows.
|
||||
|
||||
- [#1482](https://github.com/Fission-AI/OpenSpec/pull/1482) [`84ebc57`](https://github.com/Fission-AI/OpenSpec/commit/84ebc57cb3f0e91b93484484092fdc2f9fcf39e6) Thanks [@clay-good](https://github.com/clay-good)! - `openspec validate <change>` now reports a MODIFIED requirement that omits a scenario the main spec still has — the same loss archive already refuses to apply — so the change fails at authoring time instead of at archive time. A change carrying a stale MODIFIED block will start failing validation; it was already unarchivable, and the message names the scenarios to copy back in.
|
||||
|
||||
## 1.7.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Add CodeArts Agent skills support: `openspec init --tools codeartsagent` installs the workflow skills.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Add Hermes Agent as a supported AI tool: `openspec init --tools hermes` installs the workflow skills (Hermes is skills-only and invokes them directly).
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Add ZCode as a supported AI tool: `openspec init --tools zcode` generates its skills and `/opsx:*` commands.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Codex is now skills-only: workflows install as `$openspec-*` skills and previously managed custom prompts are retired (existing ones are cleaned up on update).
|
||||
|
||||
- [#1062](https://github.com/Fission-AI/OpenSpec/pull/1062) [`eac2973`](https://github.com/Fission-AI/OpenSpec/commit/eac2973819037727b10214f70db2f54d82f2d891) Thanks [@showms](https://github.com/showms)! - Add current project context and per-operation guidance to apply and archive workflows. Projects can configure `operations.apply.guidance` and `operations.archive.guidance`; `openspec instructions apply` returns apply inputs, and the new read-only `openspec instructions archive` surface returns archive inputs for the selected root.
|
||||
|
||||
Archive, bulk archive, and sync skills now load current archive inputs and `specs` artifact rules at execution time, fail before writes or moves when required instruction lookups fail, and reuse specs-rule snapshots during inline sync.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Publish the workflow skills as static `skills/<name>/SKILL.md` files so `npx skills add Fission-AI/OpenSpec` works.
|
||||
|
||||
- [#1399](https://github.com/Fission-AI/OpenSpec/pull/1399) [`27b22ab`](https://github.com/Fission-AI/OpenSpec/commit/27b22ab4cbf530fa00e17f0f6b75a44d56777542) Thanks [@clay-good](https://github.com/clay-good)! - Add `skip_specs: true` change metadata for work with no spec-level behavior change (pure refactors, tooling, docs). `openspec validate` accepts a zero-delta change that declares the marker (honored only when the metadata parses under the shared change-metadata schema and names a schema that loads) and errors when the marker and delta specs are both present, the artifact graph no longer blocks `tasks` on spec files for such changes, `openspec status` renders the specs stage as explicitly skipped, and the propose/specs guidance points to the marker instead of contradicting the validator.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Resolve symlinked schema directories so schemas shared via symlink (e.g. from a dotfiles repo) are discovered.
|
||||
|
||||
- [#1470](https://github.com/Fission-AI/OpenSpec/pull/1470) [`6295515`](https://github.com/Fission-AI/OpenSpec/commit/6295515d4da4f7c76eaed00b7f1926771eae92de) Thanks [@clay-good](https://github.com/clay-good)! - `openspec update` now offers to upgrade the CLI when yours is behind the published one. Instruction files are generated by the installed CLI, so a stale install reported `✓ All 1 tool(s) up to date (v1.6.0)` while the workflows added in newer releases were never written:
|
||||
|
||||
```text
|
||||
A newer OpenSpec CLI is available (v1.6.0 → v1.7.0).
|
||||
Running from: /usr/local/lib/node_modules/@fission-ai/openspec
|
||||
? Upgrade to v1.7.0 now? (Y/n)
|
||||
```
|
||||
|
||||
Say yes and it upgrades, confirms the new version is the one that answers, then re-runs the update so the new workflows arrive in the same command. Say no and it prints the command matching how you installed OpenSpec, and updates with what you have. Nothing happens to your machine that you did not agree to: the offer appears only in an interactive terminal and only where `npm install -g` would help, and the check is skipped in CI or when `OPENSPEC_NO_UPDATE_CHECK`, `DO_NOT_TRACK=1`, or `OPENSPEC_TELEMETRY=0` is set.
|
||||
|
||||
See [CLI reference → `openspec update`](https://github.com/Fission-AI/OpenSpec/blob/main/docs/cli.md#openspec-update) for the per-install-method behavior and every opt-out.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1404](https://github.com/Fission-AI/OpenSpec/pull/1404) [`a84ae70`](https://github.com/Fission-AI/OpenSpec/commit/a84ae70e8c6ef6ffaab56599d6f91fa39873e63d) Thanks [@clay-good](https://github.com/clay-good)! - Generated skills for tools without a command adapter (Kimi Code, Mistral Vibe, Hermes, ForgeCode, CodeArts) no longer reference `/opsx:*` commands that were never generated: skill cross-references, the init getting-started hint, and the profile-migration message now use each tool's documented skill invocation (Kimi Code: `/skill:openspec-*`; others: `/openspec-*`), and Codex — skills-invocable with no slash surface — gets a syntax-neutral hint that names the skill. Selections that mix invocation syntaxes print one labeled hint per distinct form, so every advertised instruction is usable by the tool it names. When `delivery: commands` would generate nothing for a selected tool, init prints a configuration correction naming that tool, even when other tools did get commands or skills. The committed skills.sh distribution is regenerated with skill references (default `/openspec-*` form, as that channel installs skills only).
|
||||
|
||||
- [#1363](https://github.com/Fission-AI/OpenSpec/pull/1363) [`5199f41`](https://github.com/Fission-AI/OpenSpec/commit/5199f41a5d523b9212dd2854ec5e505d2f80e2e7) Thanks [@clay-good](https://github.com/clay-good)! - ### Features
|
||||
|
||||
- **One default store for every repo on your machine** — `openspec config set defaultStore <id>` sets a machine-level fallback root: any command run outside a planning root, with no `--store` flag and no project `store:` pointer, resolves to that store. It sits at the bottom of the precedence list, so `--store`, a local root, and a project pointer all still win. The root banner and JSON `root` block report the distinct provenance `source: "global_default"`, so users and tooling can tell a machine-wide default from a repo's own pointer. A stale id degrades to the underlying store error with a fix that names `openspec config unset defaultStore`.
|
||||
|
||||
- [#1435](https://github.com/Fission-AI/OpenSpec/pull/1435) [`6a5171e`](https://github.com/Fission-AI/OpenSpec/commit/6a5171e18630db4ed8e78c9edfaae4be532e2af6) Thanks [@clay-good](https://github.com/clay-good)! - `openspec new change` now accepts numeric-prefixed names like `100-add-feature` or `00001-add-auth`, useful for ordering or tiering changes. Change names now use the same kebab-case grammar as store ids and change metadata (a leading digit is allowed); `archive` already treated date-prefixed names as a supported convention. Uppercase, spaces, underscores, and leading/trailing or consecutive hyphens are still rejected, and every previously valid name stays valid.
|
||||
|
||||
- [#1425](https://github.com/Fission-AI/OpenSpec/pull/1425) [`040a869`](https://github.com/Fission-AI/OpenSpec/commit/040a86931f5398167137a483b2e8081aec13016e) Thanks [@clay-good](https://github.com/clay-good)! - Compare config key guards literally instead of through a helper.
|
||||
|
||||
`setNestedValue` and `deleteNestedValue` rejected prototype-reaching key segments through a helper that did a `Set` lookup. That is correct, but static analysis could not follow it, so CodeQL kept reporting prototype-pollution on the very assignments the guard protects. The segments are now compared literally in the same function, still checked across the whole path before anything is written. Behavior is unchanged for every input, verified against the previous implementation across 400,000 generated cases.
|
||||
|
||||
- [#1431](https://github.com/Fission-AI/OpenSpec/pull/1431) [`6a4f0d7`](https://github.com/Fission-AI/OpenSpec/commit/6a4f0d7f3384486132cb9c516b635c23cadc1fa2) Thanks [@clay-good](https://github.com/clay-good)! - A delta spec that introduces a brand-new capability can now open with a `## Purpose`, and `openspec archive` uses it as the Purpose of the main spec it creates instead of writing the `TBD - created by archiving change <name>. Update Purpose after archive.` placeholder over it. The `specs` artifact instruction, its example, the delta template and the `openspec-sync-specs` skill all tell authors and agents to write one, so the CLI and agent-driven sync paths produce the same main spec.
|
||||
|
||||
Archive keeps the placeholder when the delta has no usable `## Purpose`:
|
||||
|
||||
- no `## Purpose` header outside a code fence or HTML comment, or a body that is only a code fence or only a comment
|
||||
- a body that would leave a spec its own parser cannot read — a heading or requirement header that truncates a section, an unterminated fence, or any HTML comment
|
||||
- in the second case archive also says why, and still completes rather than aborting
|
||||
|
||||
A carried Purpose under 50 characters is kept but warned about, since `openspec validate --strict` reports it as too brief. The Purpose of an existing main spec is never touched; archive warns when it ignores a delta's Purpose there.
|
||||
|
||||
- [#1437](https://github.com/Fission-AI/OpenSpec/pull/1437) [`19d4171`](https://github.com/Fission-AI/OpenSpec/commit/19d41714c8b790488732687443713e406ef5aeef) Thanks [@clay-good](https://github.com/clay-good)! - `openspec archive` no longer aborts when a REMOVED delta's requirement is already gone from the main spec (the early-sync pattern the sync skill teaches): it warns, treats the removal as already applied, and reports applied-only totals. In `--json` mode those warnings are carried in a new optional `warnings` array on the archive result. When every operation for a spec was already synced, archive skips rewriting that file instead of churning normalization differences into it. A delta that both RENAMEs and REMOVEs the same requirement is now rejected explicitly, by both `validate` and `archive` — the two spellings are compared case- and whitespace-insensitively — and a REMOVED header that differs only in case or whitespace from an existing requirement still aborts (that is a typo, not an early sync). Also fixed: the archive delta gate matches section headers case-insensitively like the parser; symlinked `specs/<capability>/spec.md` files are discovered instead of silently dropped; `openspec show <change>` no longer prints a spurious "scenarios" flag warning; files generated for qwen and bob reference commands by their real hyphenated names (`/opsx-<id>`), and init's getting-started hint follows suit; apply/update/onboard guidance names the CLI fallback for profiles that don't install `/opsx:continue` or `/opsx:new`.
|
||||
|
||||
- [#1411](https://github.com/Fission-AI/OpenSpec/pull/1411) [`c439a4e`](https://github.com/Fission-AI/OpenSpec/commit/c439a4ee48ef02dcdae6ac8101b7d12924695e7e) Thanks [@clay-good](https://github.com/clay-good)! - Fix phantom requirements parsed from delta specs, which made `openspec archive` warn about problems `openspec validate` never reported.
|
||||
|
||||
A header inside a delta section that is not a `### Requirement:` header — a divider such as `### Documentation Requirements` — was read as a requirement with no scenario. `openspec archive` warned that it was missing a scenario, and `openspec show <change> --json` and `openspec change list` counted it as an extra delta. The change parser now ignores those headers, matching the delta reader, so the phantom is gone from the warnings and from the JSON. Main spec parsing is unchanged.
|
||||
|
||||
`openspec archive` also no longer repeats requirement-level issues from the delta specs in its non-blocking "Proposal warnings in proposal.md" block. Each defect was printed twice there, and a `## REMOVED Requirements` entry — names-only by design — was reported as missing a scenario on every correct removal. Delta spec validation still reports and blocks on genuine defects, and proposal-level warnings are unchanged.
|
||||
|
||||
- [#1394](https://github.com/Fission-AI/OpenSpec/pull/1394) [`b474f81`](https://github.com/Fission-AI/OpenSpec/commit/b474f81cb4bebbeff0e447fd78c34a613ebd02fa) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Archive no longer races the spec sync, or reports a sync that never landed** — the generated `openspec-archive-change` skill (and the matching `opsx:archive` command) handed the spec sync to a background task and then moved the change folder immediately. The archive could move the delta specs out from under the running sync: the change ended up archived, `openspec/specs/` was never updated, and the summary still reported `Specs: ✓ Synced`. The sync now runs inline, and the archive only proceeds once every capability with a delta spec has been checked against it — ADDED present, MODIFIED changes applied, REMOVED gone, RENAMED under the new name and not the old. If the sync fails or a capability doesn't match, the archive stops and reports what differs instead of claiming success; nothing has moved, so you can fix it and retry.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Apply profile changes with the installed CLI instead of shelling out to `npx`, which could run a different version.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Delta and main-spec parsers strip a UTF-8 BOM, so files saved by Windows editors or PowerShell redirects no longer fail with "No delta sections found".
|
||||
|
||||
- [#1398](https://github.com/Fission-AI/OpenSpec/pull/1398) [`97d441a`](https://github.com/Fission-AI/OpenSpec/commit/97d441a8ee2738d3008709e61acfc91925c7ae3a) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Bulk archive now stops when you pick "Cancel"** — the generated `openspec-bulk-archive-change` skill (and the matching `opsx:bulk-archive` command) offered a "Cancel" option at the confirmation prompt but never told the agent what to do with it, so the next step archived every selected change anyway. The prompt now routes each answer by intent: "Cancel" stops without archiving anything, the archive options proceed (the ready-only option archives just the changes the status table marks `Ready` or `Ready*`), and any other answer re-asks instead of archiving. The single-change archive skill already routes Cancel this way; this brings the bulk variant in line.
|
||||
|
||||
- [#1375](https://github.com/Fission-AI/OpenSpec/pull/1375) [`52a8bce`](https://github.com/Fission-AI/OpenSpec/commit/52a8bce1fd2bc98c51fa35cf0cfa05e799eb4404) Thanks [@clay-good](https://github.com/clay-good)! - `--change` now accepts any change name that exists on disk (e.g. date-prefixed names like `2026-07-04-voice-copilot-v1`), matching what `list`, `validate`, and `archive` already resolve. Lookup still rejects unsafe names (path separators, `..`, hidden entries); the kebab-case naming rule still applies when creating a change.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - `openspec new change` rejects names over 200 characters with a validation message instead of surfacing a raw ENAMETOOLONG filesystem error.
|
||||
|
||||
- [#1447](https://github.com/Fission-AI/OpenSpec/pull/1447) [`fb19699`](https://github.com/Fission-AI/OpenSpec/commit/fb196995dad017074415a638824eb546f3321cbc) Thanks [@hsusul](https://github.com/hsusul)! - Generated tool command files now carry valid YAML frontmatter for every supported tool. Command names ship as `OPSX: Explore`, and the unquoted `name: OPSX: Explore` that adapters emitted is not parseable YAML — strict parsers rejected the whole file, so the command failed to load. Several adapters also re-implemented their own escaping, and a few interpolated descriptions in raw.
|
||||
|
||||
Escaping now lives in one place (`escapeYamlValue` / `formatTagsArray`) and every adapter uses it. String frontmatter values are always double-quoted, which also keeps values like `true`, `null` and `123` from round-tripping as booleans, nulls and numbers. Non-string fields such as `allowed-tools` and `invokable` are unchanged. Expect the first `openspec update` after upgrading to rewrite the frontmatter lines of your generated command files.
|
||||
|
||||
Archive workflow guidance also gets two corrections: bulk archive now carries its per-delta include/exclude decisions into execution, so a delta whose implementation was not found is reported as `sync skipped` instead of being synced anyway, and both archive workflows verify the main specs before moving the change directory.
|
||||
|
||||
- [#1471](https://github.com/Fission-AI/OpenSpec/pull/1471) [`9a937cb`](https://github.com/Fission-AI/OpenSpec/commit/9a937cb9b36fb1040bdbde3bab3fa3903944ef10) Thanks [@clay-good](https://github.com/clay-good)! - Reference slash commands by the name each tool actually registers. Command bodies, generated `SKILL.md` cross-references, and the `init`/`update`/migration hints all advertised `/opsx:<id>`, but only 7 of the 28 tools with a command adapter register that name — the ones whose files sit in an `opsx/` directory. The other 21 write `.../opsx-<id>.md`, where the filename is the command, so tools such as Cursor, GitHub Copilot, Windsurf and Kilo Code were told to type a command their palette never had; a single generated Cursor file named itself `/opsx-apply` in frontmatter and then told the reader to run `/opsx:apply`. The command _name_ is now derived from the command file each adapter writes rather than a hand-maintained tool list, so a newly added adapter cannot drift, and the _wrapper_ around it is adapter metadata: Amazon Q loads its files into a prompt library invoked with `@`, so it now gets `@opsx-<id>` in command bodies, skills, and the onboarding hint instead of a slash command it never registers. Codex, which generates no command files at all, now gets `$openspec-<skill>` — the syntax its CLI actually accepts — everywhere it previously advertised `/opsx:*`, superseding the syntax-neutral hint described in the pending `adapterless-skill-references` note. Command filenames and paths are unchanged, and Claude Code output is byte-identical.
|
||||
|
||||
- [#1364](https://github.com/Fission-AI/OpenSpec/pull/1364) [`f58b445`](https://github.com/Fission-AI/OpenSpec/commit/f58b4456925b6331f3e5902a1c57905afe7edbf5) Thanks [@clay-good](https://github.com/clay-good)! - Fix `openspec completion install` detecting the wrong shell for fish (and other)
|
||||
users whose interactive shell differs from their login shell. Detection now
|
||||
consults the parent process before falling back to `$SHELL`, so running the
|
||||
command from fish installs fish completions instead of defaulting to bash.
|
||||
|
||||
- [#1377](https://github.com/Fission-AI/OpenSpec/pull/1377) [`285dfd7`](https://github.com/Fission-AI/OpenSpec/commit/285dfd7d764752b2a1e7e8cc843d613421e62652) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- Config `rules:` keys are no longer reported as `Unknown artifact ID` when they belong to a different schema. The global rules map is now validated against the union of artifact IDs across every available schema, so multi-schema projects stop seeing spurious warnings on every command ([#1322](https://github.com/Fission-AI/OpenSpec/issues/1322)).
|
||||
|
||||
- [#1401](https://github.com/Fission-AI/OpenSpec/pull/1401) [`b33b15d`](https://github.com/Fission-AI/OpenSpec/commit/b33b15d98ae929624c991632c7382ebc234d4ca7) Thanks [@clay-good](https://github.com/clay-good)! - Stop `design.md` from restating the proposal. In the default `spec-driven` schema, the design instruction asked for "Background, current state, constraints, stakeholders" and "What this design achieves and excludes" without saying that motivation and scope already live in `proposal.md`, so agents restated the proposal's Why and What Changes instead of adding the design's own value - approach, alternatives, and trade-offs. The instruction and the design template now state the boundary explicitly (the proposal covers why and what, design covers how) and tell the agent to reference those documents rather than repeat them ([#1382](https://github.com/Fission-AI/OpenSpec/issues/1382)).
|
||||
|
||||
- [#1167](https://github.com/Fission-AI/OpenSpec/pull/1167) [`1637856`](https://github.com/Fission-AI/OpenSpec/commit/1637856c423f2e84457652d1ab58885fe9744fb2) Thanks [@mehdishahdoost](https://github.com/mehdishahdoost)! - **Windsurf is now Devin Desktop.** Windsurf was rebranded on June 2, 2026 and its config directory moved: `.devin/` is the preferred read + write location, `.windsurf/` a legacy read-only fallback that the Devin Local agent does not read at all. OpenSpec follows the rename rather than carrying two ids for one product — the tool id is `devin`, writing `.devin/workflows/opsx-<id>.md` and `.devin/skills/openspec-*/SKILL.md`, and it is detected from either directory.
|
||||
|
||||
- `--tools windsurf` still resolves, so existing setup scripts keep working; it now configures `.devin/`.
|
||||
- If your OpenSpec files are still in `.windsurf/`, `openspec update` explains the rebrand and offers to move them. `--force` and non-interactive runs take the move; declining leaves every file exactly where it is. Only the files OpenSpec generates move — each skill's `SKILL.md` and commands named `opsx-*`. A hand-written Cascade workflow, a reference file you keep beside a `SKILL.md`, a command file you edited, and `.devin/rules/` all stay exactly where they are.
|
||||
- Devin skills and the getting-started hint reference `/openspec-*` skills rather than `/opsx-*` workflows, because only Devin Desktop reads workflows; the `/openspec-*` form works on both agents. Workflow bodies still use `/opsx-<id>`, the name Devin registers for a workflow file.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - `openspec doctor` now notes when a store checkout is behind its upstream ref.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Make the archive scenario-drift check multiplicity-aware: a MODIFIED block that keeps only one of two same-named scenarios no longer silently drops the other.
|
||||
|
||||
- [#1408](https://github.com/Fission-AI/OpenSpec/pull/1408) [`378d468`](https://github.com/Fission-AI/OpenSpec/commit/378d468ad348dc1e973ed30c5cfa458fb77c9de3) Thanks [@clay-good](https://github.com/clay-good)! - Explore now reads the project's context and rules from `openspec/config.yaml` (or `config.yml`) at the start of a session, so it reasons with the same tech stack and conventions the artifact-creating workflows already receive.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - `openspec feedback` shows the formatted text and a pre-filled submission URL on any gh failure (issues disabled, network, rate limit), not only when gh is missing or unauthenticated.
|
||||
|
||||
- [#1396](https://github.com/Fission-AI/OpenSpec/pull/1396) [`60f720c`](https://github.com/Fission-AI/OpenSpec/commit/60f720c43acd94de7645ac8629c614ede4682b6a) Thanks [@clay-good](https://github.com/clay-good)! - Fix `openspec feedback` failing when the repository does not define the `feedback` label. The command now retries without the label and notes that it was not applied, instead of exiting with an error and discarding the feedback.
|
||||
|
||||
- [#1151](https://github.com/Fission-AI/OpenSpec/pull/1151) [`18cbf5d`](https://github.com/Fission-AI/OpenSpec/commit/18cbf5d32ffe1bff4fff692e24568c605cf1e0fa) Thanks [@javigomez](https://github.com/javigomez)! - ### Fixed
|
||||
|
||||
- Ignore Markdown structure (requirement headers, delta sections, scenarios, REMOVED/RENAMED entries) that appears inside fenced code blocks when parsing delta specs. Previously a fenced `### Requirement:` example was parsed as a real (phantom) requirement, producing spurious `validate` errors and risking incorrect `archive` output. Fenced-code detection is now shared across the Markdown parsers so `validate` and `archive` behave consistently.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - The archive scenario-drift check now ignores `#### Scenario:` lines inside fenced code blocks, matching validate: a fenced example no longer false-aborts an archive, and a fenced name no longer masks a genuinely dropped scenario.
|
||||
|
||||
- [#1316](https://github.com/Fission-AI/OpenSpec/pull/1316) [`9b70481`](https://github.com/Fission-AI/OpenSpec/commit/9b70481df727ab9f7a00dd0118e4e09373a36fb9) Thanks [@mc856](https://github.com/mc856)! - ### Bug Fixes
|
||||
|
||||
- **`archive` no longer stacks a second date prefix** — archiving a change whose name already starts with a `YYYY-MM-DD-` prefix (a common authoring convention) keeps the name as-is instead of prepending today's date. Previously `openspec archive 2026-07-04-voice-copilot-v1 --yes` produced `2026-07-06-2026-07-04-voice-copilot-v1`, and when run on a later day the folder sorted under a day on which the change did not happen. Names without a full date prefix (including partial dates like `2026-07-feature`) are dated as before, and the naming is now idempotent.
|
||||
|
||||
- [#1374](https://github.com/Fission-AI/OpenSpec/pull/1374) [`da3907b`](https://github.com/Fission-AI/OpenSpec/commit/da3907b8a9170711c8b7f63e18352e8577cf7df5) Thanks [@clay-good](https://github.com/clay-good)! - fix(completion): make the PowerShell completion script parse and load again
|
||||
|
||||
The generated `OpenSpecCompletion.ps1` contained 18 empty `switch ($positionalIndex) { }` blocks — emitted for commands whose positionals are all `path`-typed (PowerShell completes paths natively, so those cases produce no clauses). A switch with no clauses is a PowerShell parse error ("Missing condition in switch statement clause"), and PowerShell parses the whole file before running it, so the script never loaded and completions never registered. The generator now skips the positional-index block entirely when no positional produces completions, so the script parses clean (18 → 0 errors) and tab completion works.
|
||||
|
||||
- [#1388](https://github.com/Fission-AI/OpenSpec/pull/1388) [`9b5d2cd`](https://github.com/Fission-AI/OpenSpec/commit/9b5d2cdd0c1aa4b1b49da4f95c6cec8d7d38b155) Thanks [@mc856](https://github.com/mc856)! - ### Bug Fixes
|
||||
|
||||
- **Archive workflow templates no longer teach agents to stack a second date prefix** — the `openspec-archive-change` and `openspec-bulk-archive-change` skill/command templates (and the onboarding walkthrough's archived-path example) now mirror the `openspec archive` rule: a change whose name already starts with a `YYYY-MM-DD-` prefix is archived under its own name, while other names get the current date prepended as before. Previously an agent following the workflow instructions on a change named `2026-07-04-voice-copilot-v1` produced `archive/2026-07-07-2026-07-04-voice-copilot-v1`, whatever the CLI did.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Gemini command files escape TOML-active characters (quotes, backslashes, control characters) in the description and prompt, so a template value containing them can no longer produce an invalid `.toml` file.
|
||||
|
||||
- [#1464](https://github.com/Fission-AI/OpenSpec/pull/1464) [`5bcf057`](https://github.com/Fission-AI/OpenSpec/commit/5bcf05766a70ec0163c3e700a3029b1c1da895d8) Thanks [@clay-good](https://github.com/clay-good)! - Workflow skills and commands no longer tell agents to use the Claude Code-only AskUserQuestion tool. The same templates are generated for every supported tool, and agents without that tool (OpenCode, Factory Droid, Codex, and others) errored or stalled on the instruction. The guidance is now runtime-neutral: agents are simply told to ask the user.
|
||||
|
||||
- [#1403](https://github.com/Fission-AI/OpenSpec/pull/1403) [`2d6c447`](https://github.com/Fission-AI/OpenSpec/commit/2d6c447100c51fb1e5f65c6f6a35ce02a3196a10) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Propose and fast-forward skills no longer name the Claude-only TodoWrite tool** — the generated `openspec-propose` and `openspec-ff-change` skills (and their `/opsx:propose` / `/opsx:ff` commands) told every agent to "Use the **TodoWrite tool**", which only exists in Claude Code. Codex, Cursor, Gemini, Copilot, and the other supported tools have no such tool, so agents either errored or stalled looking for it. The instruction is now runtime-neutral ("Use a todo list to track progress"), which works everywhere — including Claude Code.
|
||||
|
||||
- [#1415](https://github.com/Fission-AI/OpenSpec/pull/1415) [`e2f748c`](https://github.com/Fission-AI/OpenSpec/commit/e2f748c64f05efaeac720f83c71fb6f1b6f6e18d) Thanks [@clay-good](https://github.com/clay-good)! - Reject config key paths that reach the prototype chain, and update the bundled `yaml` dependency.
|
||||
|
||||
`openspec config set --allow-unknown __proto__.polluted <value>` reported success and assigned onto `Object.prototype` for the rest of the process. `--allow-unknown` was meant to relax the known-key check only, but it skipped every key check, so `__proto__`, `constructor`, and `prototype` segments reached the nested-write helper. Those segments are now rejected in `config set` whether or not `--allow-unknown` is passed, and `setNestedValue` / `deleteNestedValue` refuse them regardless of caller. Ordinary keys such as `featureFlags.myFlag` behave exactly as before.
|
||||
|
||||
The `yaml` runtime dependency moves from 2.8.2 to 2.9.0, picking up the fix for a stack overflow on deeply nested input (GHSA / advisory patched in 2.8.3).
|
||||
|
||||
- [#1376](https://github.com/Fission-AI/OpenSpec/pull/1376) [`7958924`](https://github.com/Fission-AI/OpenSpec/commit/7958924e95654af981437951e967983385da8001) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Archive after early sync** — `openspec archive` no longer fails with `ADDED failed … already exists` when a change's specs were already synced to the main specs before archiving (the early-sync pattern from the `sync` workflow). If an ADDED requirement already exists in the target spec with identical content, applying it is treated as a no-op; a same-named requirement with different content still aborts the archive as a genuine conflict ([#1332](https://github.com/Fission-AI/OpenSpec/issues/1332)).
|
||||
|
||||
- [#1386](https://github.com/Fission-AI/OpenSpec/pull/1386) [`b419e96`](https://github.com/Fission-AI/OpenSpec/commit/b419e965bbf413cc658bbac37325ebc147b1c869) Thanks [@mc856](https://github.com/mc856)! - ### Bug Fixes
|
||||
|
||||
- **Archive after early sync (RENAMED)** — `openspec archive` no longer fails with `RENAMED failed … source not found` when a change's renames were already synced to the main specs before archiving (the early-sync pattern from the `sync` workflow). If a RENAMED requirement's source header is gone but the target header exists in the spec, applying the rename is treated as a no-op; a rename whose source and target are both missing still aborts the archive as a genuine error, and reported counts reflect only renames actually applied.
|
||||
|
||||
- [#1462](https://github.com/Fission-AI/OpenSpec/pull/1462) [`ebf66c7`](https://github.com/Fission-AI/OpenSpec/commit/ebf66c7ee1df3f7465d7f480753f952483133a73) Thanks [@clay-good](https://github.com/clay-good)! - Respect reduced-motion preferences in `openspec init`: the welcome animation is skipped when the OS reduced-motion setting is on (macOS Reduce Motion, GNOME animations disabled), when `OPENSPEC_NO_ANIMATION` is set, or when the new `--no-animation` flag is passed. The static welcome screen is shown instead.
|
||||
|
||||
- [#1405](https://github.com/Fission-AI/OpenSpec/pull/1405) [`5dfef4b`](https://github.com/Fission-AI/OpenSpec/commit/5dfef4b00c233fbe78f40488bd4ff98f4204684c) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Custom schema instructions are no longer overridden by hard-coded spec-driven patterns** — the `openspec-continue-change` skill/command embedded one-line "common artifact patterns" for proposal.md, specs, design.md, and tasks.md, so agents followed those shortcuts instead of the schema's `instruction` field whenever a custom schema reused familiar artifact names. The templates now state that the `instruction` field is the authoritative guidance, and the `propose`, `continue`, and `ff` workflows direct the agent — both in the artifact-creation step and in the guidelines — to invoke a skill when the instruction delegates artifact creation to one, verifying the artifact exists afterward (fixes [#777](https://github.com/Fission-AI/OpenSpec/issues/777)).
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Follow the Kimi CLI rename to Kimi Code: new install paths with automatic migration of existing `.kimi` setups.
|
||||
|
||||
- [#1415](https://github.com/Fission-AI/OpenSpec/pull/1415) [`e2f748c`](https://github.com/Fission-AI/OpenSpec/commit/e2f748c64f05efaeac720f83c71fb6f1b6f6e18d) Thanks [@clay-good](https://github.com/clay-good)! - Parse spec headings in linear time when the title is padded with whitespace.
|
||||
|
||||
Building the reference index read the first Purpose line with a regex that backtracked quadratically on a heading full of spaces: 10,000 characters of padding took 60ms, and 100,000 would have taken roughly six seconds. The heading scan is now hand-rolled and linear. Behavior is unchanged — the replacement was checked against the old implementation across 303,000 generated inputs, including CommonMark closing sequences (`## Purpose ##`), seven-hash lines, and headings with no space after the hashes.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Use local dates for CLI date-only values (archive names, timestamps) instead of UTC, so late-evening archives no longer get tomorrow's date.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - `openspec update` warns when a custom profile is missing core workflows instead of silently generating a partial install.
|
||||
|
||||
- [#1428](https://github.com/Fission-AI/OpenSpec/pull/1428) [`81d5109`](https://github.com/Fission-AI/OpenSpec/commit/81d5109b86f16537deb99f84a772a83235dc9e09) Thanks [@taltas](https://github.com/taltas)! - Update current Roo Code product references to its community successor, Zoo Code.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Archive treats a MODIFIED delta whose content already matches the main spec as a no-op: a fully early-synced change now reports "Specs already in sync" instead of rewriting the file and claiming modifications.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Render multi-select prompts with `[x]`/`[ ]` checkbox markers instead of radio-button icons.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Discover nested spec paths like `specs/<area>/<capability>/spec.md` recursively and consistently across parse, apply, and archive.
|
||||
|
||||
- [#1410](https://github.com/Fission-AI/OpenSpec/pull/1410) [`b3b05e1`](https://github.com/Fission-AI/OpenSpec/commit/b3b05e1abeb312caefd57e60be799aeb466c1d0e) Thanks [@clay-good](https://github.com/clay-good)! - Only advertise onboarding commands that will actually exist. The `openspec init` welcome screen and the `openspec update` "Getting started" summary listed `/opsx:new` and `/opsx:continue`, which the default `core` profile never generates, so users were told to run commands that did not exist. Both surfaces now list the commands for the installed workflows. The `init` and `update` completion hints also name the skill (`/openspec-propose`) instead of a command for tools that receive no command files — Codex, and any tool under skills-only delivery.
|
||||
|
||||
- [#1412](https://github.com/Fission-AI/OpenSpec/pull/1412) [`1dc670d`](https://github.com/Fission-AI/OpenSpec/commit/1dc670deea741b8313b8a22fb975741f84677b3f) Thanks [@clay-good](https://github.com/clay-good)! - ### Fixed
|
||||
|
||||
- **`/opsx:propose` and `/opsx:ff` no longer finish a change with no spec written.** The workflows listed only `proposal`/`design`/`tasks` and treated the apply phase's `tasks` artifact as the stop condition — but `status` marks an artifact `done` as soon as a matching file exists, so writing `tasks.md` early satisfied the loop while `specs/<capability>/spec.md` was never created (a spec-less change in a spec-driven tool). The loop now derives the full required set — every apply dependency plus everything it transitively `requires` — from a single `status` call, creates each missing artifact, and only skips one when its own `instruction` field marks it conditional. ([#1260](https://github.com/Fission-AI/OpenSpec/issues/1260), [#788](https://github.com/Fission-AI/OpenSpec/issues/788))
|
||||
|
||||
### Changed
|
||||
|
||||
- **`openspec status --json` now reports each artifact's `requires` edges.** Every entry in the `artifacts` array carries a `requires` array of the ids it directly depends on, present for every status (including `done`) so agents can compute the transitive required set from `status` alone. Additive and backward-compatible — existing fields are unchanged.
|
||||
|
||||
- [#1191](https://github.com/Fission-AI/OpenSpec/pull/1191) [`7704702`](https://github.com/Fission-AI/OpenSpec/commit/7704702d61fa71e4f553c21a06bdf8e4ee803b4a) Thanks [@mc856](https://github.com/mc856)! - Generate Markdown commands for Qwen Code instead of deprecated TOML format. Qwen Code now recommends Markdown custom commands with YAML frontmatter; the old `.qwen/commands/opsx-*.toml` files are cleaned up as legacy artifacts on update.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - An already-synced RENAMED delta aborts when a case/whitespace variant of the source requirement still exists — the same typo guard REMOVED deltas have.
|
||||
|
||||
- [#1368](https://github.com/Fission-AI/OpenSpec/pull/1368) [`de78c31`](https://github.com/Fission-AI/OpenSpec/commit/de78c31ffd885a0558ae55d332f74d5485dc01c0) Thanks [@clay-good](https://github.com/clay-good)! - ### Fixes
|
||||
|
||||
- **Regenerated artifacts now pick up your manual edits** — the continue, propose, and fast-forward workflows (and the `openspec instructions` dependency block) now tell the agent to re-read dependency artifacts from disk before creating the next one, instead of trusting whatever version it saw earlier in the conversation. Previously, editing `spec.md` and deleting `design.md`/`tasks.md` to regenerate them could silently produce artifacts based on the stale, pre-edit content.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Proposal guidance now resolves blocking open questions with the user instead of deferring them to design.md.
|
||||
|
||||
- [#1392](https://github.com/Fission-AI/OpenSpec/pull/1392) [`a13abea`](https://github.com/Fission-AI/OpenSpec/commit/a13abeac47d419462b0193dbf9423dd466ffe6c7) Thanks [@clay-good](https://github.com/clay-good)! - ### Fixed
|
||||
|
||||
- Stop a delta spec written directly at a change's `specs/` root from being silently dropped. `validate` accepted `specs/spec.md` and counted its deltas, but the apply/archive merge only reads capability folders (`specs/<capability>/spec.md`), so the change could pass validation and be archived while its requirements never reached `openspec/specs/`. `validate` now uses the same discovery rules as the merge path and reports the misplaced file with a fix hint, and `archive` blocks instead of completing.
|
||||
|
||||
- [#1465](https://github.com/Fission-AI/OpenSpec/pull/1465) [`f917b8b`](https://github.com/Fission-AI/OpenSpec/commit/f917b8be5e1100189ef62320ba9322763053640e) Thanks [@clay-good](https://github.com/clay-good)! - Order artifacts by the schema's declaration order instead of alphabetically.
|
||||
|
||||
`specs` and `design` both require only `proposal`, so both become ready at once - and the tie used to be broken alphabetically, which put `design` first. `openspec status` listed design above specs and `nextSteps` recommended writing `design.md` before any spec existed, contradicting the spec-driven schema's own documented `proposal → specs → design → tasks` sequence.
|
||||
|
||||
Ties now follow the order the schema declares its artifacts, so `openspec status`, `status --json`, `nextSteps`, `blocked by:` lists, and an artifact's `unlocks` all agree. No dependency edges changed, so nothing newly blocks and `design.md` stays optional - only the order of equally-ready artifacts moved. Custom schemas get the same guarantee: dependency order still comes first, but wherever your schema leaves two artifacts equally ready, the order of its `artifacts:` list now decides which one the CLI recommends - so reorder that list if it was never deliberate.
|
||||
|
||||
- [#1446](https://github.com/Fission-AI/OpenSpec/pull/1446) [`5348da9`](https://github.com/Fission-AI/OpenSpec/commit/5348da930c4038ffd5b5a521702b71315dcd0019) Thanks [@showms](https://github.com/showms)! - ### Bug Fixes
|
||||
|
||||
- Preserve an existing project-local schema when `openspec schema init --force` rejects an unknown artifact ID. Forced replacement now begins only after artifact validation succeeds.
|
||||
|
||||
- [#1433](https://github.com/Fission-AI/OpenSpec/pull/1433) [`26f009d`](https://github.com/Fission-AI/OpenSpec/commit/26f009d940f311b99db7f310816bb166a99fb3ef) Thanks [@clay-good](https://github.com/clay-good)! - Change lookup no longer requires `proposal.md`. `openspec show`, `openspec change list/show/validate`, and shell completion now resolve a change by its directory, matching `openspec list`, `status`, `instructions`, and `validate`.
|
||||
|
||||
Previously a change created by `openspec new change` — which scaffolds only `.openspec.yaml` — was reported as `Unknown item` by `openspec show` and was missing from completions and `openspec change list` until a proposal was written, and a change from a schema with no proposal artifact was never resolvable. `openspec change list` now reports the same set as `openspec list`, keeps task counts for a change that has no proposal yet, and labels it `(no proposal.md yet)` rather than `(unable to read)`. Showing such a change explains that the proposal is not written yet and points at `openspec status --change <name>`.
|
||||
|
||||
- [#1468](https://github.com/Fission-AI/OpenSpec/pull/1468) [`fc886af`](https://github.com/Fission-AI/OpenSpec/commit/fc886af7f93068482bbf2c66fd1eb76b40c6a22f) Thanks [@clay-good](https://github.com/clay-good)! - The continue, update, verify, sync, and archive workflow skills now select a change the same way apply does: use the provided name, infer it from conversation context, auto-select when exactly one active change exists, and only prompt when the choice is genuinely ambiguous. Previously these workflows were told to always prompt ("Do NOT guess or auto-select"), so invoking them with a single active change stalled on a question with only one possible answer. The selection is always announced ("Using change: <name>") with how to override, and bulk archive still always prompts.
|
||||
|
||||
- [#1194](https://github.com/Fission-AI/OpenSpec/pull/1194) [`b7c85c7`](https://github.com/Fission-AI/OpenSpec/commit/b7c85c741ca56748a4ae095b573fe4550c5c977f) Thanks [@mc856](https://github.com/mc856)! - Fix skills-only delivery emitting `/opsx:*` command references. SKILL.md files generated by init, update, and workspace skill setup now reference the corresponding skills (e.g. `/openspec-apply-change`) when `delivery: 'skills'` is configured, instead of commands that were never generated.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Specs instructions include the spec content guidance from the concepts docs, so generated specs follow the requirement/scenario format.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - The static welcome screen (reduced motion, `--no-animation`, narrow terminals) now waits for the Enter it asks for instead of letting the keystroke submit the tool picker unseen.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Sync and archive workflows resolve main specs through the store-aware root instead of assuming `openspec/specs` in the repo.
|
||||
|
||||
- [#1402](https://github.com/Fission-AI/OpenSpec/pull/1402) [`0da5f98`](https://github.com/Fission-AI/OpenSpec/commit/0da5f98e147543a44379e32295e2e9798d775d83) Thanks [@clay-good](https://github.com/clay-good)! - Show the main spec format in the sync-specs skill so agents stop leaving delta operation headers (`## ADDED/MODIFIED Requirements`) in `openspec/specs/` — merged main specs with those headers parse as 0 requirements in `openspec view` ([#1120](https://github.com/Fission-AI/OpenSpec/issues/1120)).
|
||||
|
||||
- [#1476](https://github.com/Fission-AI/OpenSpec/pull/1476) [`8731290`](https://github.com/Fission-AI/OpenSpec/commit/87312900f532c6c13ea556d4badaff2efdfa9602) Thanks [@clay-good](https://github.com/clay-good)! - Telemetry no longer depends on `posthog-node`: the single usage event is sent with a plain fetch to the same endpoint. Installing OpenSpec no longer pulls the fast-publishing `posthog-node`/`@posthog/core`/`@posthog/types` tree, which broke downstream installs under supply-chain age policies like pnpm's `minimumReleaseAge` ([#1390](https://github.com/Fission-AI/OpenSpec/issues/1390)).
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - The stale-CLI check hardens its install detection: a directory merely named `volta` no longer changes the upgrade hint, the Windows npm-ownership check corroborates against the `openspec.cmd` shim npm actually writes, and a registry redirect from https to plain http is no longer followed.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - The stale-CLI check tears down a redirected registry connection when its time budget expires instead of leaving the socket open.
|
||||
|
||||
- [#1442](https://github.com/Fission-AI/OpenSpec/pull/1442) [`10fa39b`](https://github.com/Fission-AI/OpenSpec/commit/10fa39b1c3a3e88c02ae7d3053864c03a793ff47) Thanks [@hsusul](https://github.com/hsusul)! - `openspec update` now refreshes tools that are configured with command files but no skills (delivery `commands`). Previously it read the generating version only from skill files, so such a tool was reported as "up to date" forever and its command files were never regenerated after a CLI upgrade. Command files carry no version stamp, so OpenSpec compares their contents against what it would generate now — including removing a command file left behind by a workflow you have since deselected. CRLF line endings and a UTF-8 BOM are treated as checkout artifacts rather than drift, so a Windows clone does not report a spurious update.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - `openspec update` with `delivery: commands` prints the same configuration correction as init when it removes the skills of a tool that supports only skills, instead of deleting them silently.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - `openspec validate` reports an unreadable specs/ directory as the error it is instead of misdiagnosing it as "no deltas found".
|
||||
|
||||
- [#1455](https://github.com/Fission-AI/OpenSpec/pull/1455) [`6b3623a`](https://github.com/Fission-AI/OpenSpec/commit/6b3623a39e96f49995d38d642738b31f68e92039) Thanks [@c4patino](https://github.com/c4patino)! - `openspec view` now resolves the configured OpenSpec root instead of always reading the current directory, and accepts `--store <id>` like its sibling commands. Projects whose `openspec/config.yaml` points at an external store saw an empty dashboard — 0 specs, 0 requirements — while `openspec list` read the same store correctly.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - Preserve keyboard input on Windows after the welcome screen instead of dropping the first keystrokes.
|
||||
|
||||
- [#1475](https://github.com/Fission-AI/OpenSpec/pull/1475) [`17af60c`](https://github.com/Fission-AI/OpenSpec/commit/17af60c66e4c049e3986fdbafcdc16b202cda59f) Thanks [@clay-good](https://github.com/clay-good)! - zsh completion install honors `$ZSH` and `$ZSH_CUSTOM`, so Oh My Zsh setups at custom locations get the completion where their shell actually loads it.
|
||||
|
||||
## 1.6.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1090](https://github.com/Fission-AI/OpenSpec/pull/1090) [`3f0ca3f`](https://github.com/Fission-AI/OpenSpec/commit/3f0ca3f6ce6f2ec41260c5cbe7954b7e46adcf43) Thanks [@jjxyxsjr](https://github.com/jjxyxsjr)! - ### New Features
|
||||
|
||||
- **TRAE command adapter** — Added command adapter for Trae IDE, enabling generation of `.trae/commands/opsx-<id>.md` files for custom slash commands
|
||||
|
||||
- [#1340](https://github.com/Fission-AI/OpenSpec/pull/1340) [`1552731`](https://github.com/Fission-AI/OpenSpec/commit/15527310f9be13cc9a4035ea01b93ba85873d956) Thanks [@TabishB](https://github.com/TabishB)! - ### New Features
|
||||
|
||||
- **Oh My Pi support** — Generate native OPSX commands and skills for Oh My Pi projects, including tool detection and the expected `.omp` directory layout.
|
||||
- **Update planning artifacts in place** — Use `/opsx:update` to revise an existing change's planning artifacts, reconcile related artifacts, and keep implementation work delegated to `/opsx:apply`.
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- **Fresh store registration** — Register and use newly created stores before their empty changes, specs, or archive directories have been committed.
|
||||
- **Safer requirement archiving** — Stop stale `MODIFIED` requirements from silently deleting scenarios that were added by an earlier archive.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1300](https://github.com/Fission-AI/OpenSpec/pull/1300) [`a5bfeda`](https://github.com/Fission-AI/OpenSpec/commit/a5bfedafc8b3d914fe01d05eb36ad9ad3fbe35a2) Thanks [@clay-good](https://github.com/clay-good)! - ### Features
|
||||
|
||||
- **Auto-approve the OpenSpec CLI in generated skills and commands** — every generated `SKILL.md` (all tools) and every Claude Code `/opsx:*` slash command now carries `allowed-tools: Bash(openspec:*)` in its frontmatter, so agents that honor the Agent Skills standard run `openspec` commands without prompting for approval on each call; tools that don't recognize the field ignore it. Scope is limited to the `openspec` CLI; because `allowed-tools` pre-approves rather than restricts, every other tool a skill or command uses stays available under your normal permission settings.
|
||||
|
||||
- [#1311](https://github.com/Fission-AI/OpenSpec/pull/1311) [`5956a8e`](https://github.com/Fission-AI/OpenSpec/commit/5956a8e872f41a8f690922b5c9b6927970252b2a) Thanks [@danilopopeye](https://github.com/danilopopeye)! - ### Bug Fixes
|
||||
|
||||
- **`archive` exits non-zero when blocked in human mode** — `openspec archive <change> -y` (and any non-`--json` invocation) no longer returns exit code 0 when validation fails and nothing is archived. The three blocking paths in human mode — delta-spec validation failure, spec rebuild failure, and rebuilt-spec validation failure — now set `process.exitCode = 1`, matching the existing `--json` behavior. Previously the command printed "Validation failed" (or "Aborted. No files were changed.") and exited 0, letting scripts and CI believe the archive succeeded. Aligns `archive` with the same exit-code guarantee already approved for `apply` instructions (#1250).
|
||||
|
||||
- [#1280](https://github.com/Fission-AI/OpenSpec/pull/1280) [`a325305`](https://github.com/Fission-AI/OpenSpec/commit/a3253051ea1934fd0d76620addb855dfce801742) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **`validate` resolves changes like `status`** — `openspec validate <change>` (and `--all`/`--changes` and the interactive selector) now resolves a change by directory existence, matching `status`/`instructions`, instead of requiring `proposal.md`. A scaffolded or still-authoring change is validated rather than reported as `Unknown item`, and a resolved-but-invalid change now exits non-zero. Delta discovery also recurses the nested `specs/<area>/<capability>/spec.md` layout. (#1182)
|
||||
- **Task progress reads nested/glob `tasks.md`** — `openspec view`, `list`, and the `archive` incomplete-task gate now resolve task progress through the tracked-tasks artifact's `generates` glob (the same file-resolution `status` uses), so a change whose tasks live in nested `tasks.md` files is classified correctly and can no longer archive while unfinished. (#1202)
|
||||
- **SHALL/MUST body-keyword hint applies to main specs** — A main-spec requirement whose normative keyword sits only in the `### Requirement:` header now receives the same targeted "move it to the body line" remediation as a change delta, emitted exactly once. (#1156)
|
||||
|
||||
- [#1281](https://github.com/Fission-AI/OpenSpec/pull/1281) [`9a0dfb5`](https://github.com/Fission-AI/OpenSpec/commit/9a0dfb5cd136b423c9f13c0b29ec3ea69761b4e6) Thanks [@clay-good](https://github.com/clay-good)! - ### Bug Fixes
|
||||
|
||||
- **Requirement reading fidelity** — The requirement reader used by `validate <change>`, `validate <spec>`, and `archive` is now unified into one fence-, metadata-, and multi-line-aware extraction, closing the known divergences between the change-delta path and the main-spec path (the remaining ones are documented in the change's design doc):
|
||||
|
||||
- A `SHALL`/`MUST` keyword that wraps onto a later body line is detected instead of dropped (#361).
|
||||
- Metadata lines (`**ID**:`, `**Priority**:`) before the description are skipped on the spec path, matching the change path (#418). A requirement written entirely as metadata (e.g. `**Constraint**: The system MUST ...`) keeps that line as its text instead of being emptied.
|
||||
- A fenced code block before the prose line no longer becomes the requirement text (#312).
|
||||
- A `#### Scenario:` inside a fenced example no longer counts as a real scenario in `validate <change>`, matching `validate <spec>`.
|
||||
- `SHALL`/`MUST` detection uses one whole-word predicate across all readers, and a requirement with no body text falls back to its header title on both paths.
|
||||
|
||||
Displayed requirement text (e.g. in JSON output and delta descriptions) now reflects the full requirement body rather than only its first line. Archived spec content is unchanged — the archive rebuild reads raw `### Requirement:` blocks, not the parsed text.
|
||||
|
||||
- **Surface non-canonical delta headers** — `validate <change>` now emits an INFO note when an `## ADDED`/`## MODIFIED Requirements` section contains a level-3 header that is not a canonical `### Requirement:` header (one the delta reader silently skips, such as a stray `### Documentation Requirements` divider). The note never changes the `valid` result, including under `--strict` (#498).
|
||||
|
||||
## 1.5.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1267](https://github.com/Fission-AI/OpenSpec/pull/1267) [`96f6cac`](https://github.com/Fission-AI/OpenSpec/commit/96f6cacb206c65bee30066f6a1f4e9b855a0d783) Thanks [@TabishB](https://github.com/TabishB)! - ### New Features
|
||||
|
||||
- **Stores (very early beta)** — Introduces stores as a simpler way to organize specs and changes, replacing the workspace and initiative model. This feature is in very early beta — expect rough edges and breaking changes in upcoming releases.
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- **Config parsing** — Configuration values wrapped in JSON containers are now parsed correctly.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1240](https://github.com/Fission-AI/OpenSpec/pull/1240) [`cbf386b`](https://github.com/Fission-AI/OpenSpec/commit/cbf386bd6888f103f8ff7d59b3eab98ce5b57998) Thanks [@zied-jlassi](https://github.com/zied-jlassi)! - fix(adapters): escape carriage returns in generated YAML frontmatter
|
||||
|
||||
`escapeYamlValue` flagged `\r` as a character requiring quoting but never escaped it, leaving a literal carriage return inside the double-quoted scalar where YAML line folding/normalization could silently corrupt the value (realistic with CRLF-authored command descriptions). Carriage returns are now escaped as `\r`. The helper — previously duplicated verbatim across five adapters (bob, claude, cursor, pi, windsurf) — is extracted into a shared `command-generation/yaml.ts` module so the behavior stays consistent and is fixed in one place.
|
||||
|
||||
## 1.4.1
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1165](https://github.com/Fission-AI/OpenSpec/pull/1165) [`0a01146`](https://github.com/Fission-AI/OpenSpec/commit/0a01146c181a3af8dbf645547bcbe20c0d48d615) Thanks [@TabishB](https://github.com/TabishB)! - Move beta workspace view state to `.openspec-workspace/view.yaml`, stop top-level `openspec update` from routing into workspace updates, and ignore foreign root `workspace.yaml` files so Dagster projects keep updating normally.
|
||||
|
||||
## 1.4.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
- [#1003](https://github.com/Fission-AI/OpenSpec/pull/1003) [`342ed43`](https://github.com/Fission-AI/OpenSpec/commit/342ed43e694abba65a3ea275f94ba3b77df85da3) Thanks [@Miss-you](https://github.com/Miss-you)! - ### New Features
|
||||
|
||||
- **Kimi CLI support** — OpenSpec can now initialize Kimi CLI as a supported skills-only tool using `.kimi/skills/`
|
||||
|
||||
### Other
|
||||
|
||||
- Added Kimi-specific docs and init coverage aligned with skill-based `/skill:openspec-*` usage
|
||||
|
||||
- [#1154](https://github.com/Fission-AI/OpenSpec/pull/1154) [`aa16080`](https://github.com/Fission-AI/OpenSpec/commit/aa16080d16b70f7b26cebd465334b2e16c0e7a43) Thanks [@TabishB](https://github.com/TabishB)! - ### New Features
|
||||
|
||||
- **Mistral Vibe support** — OpenSpec can now initialize Mistral Vibe as a supported skills-only tool using `.vibe/skills/`
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- **Case-insensitive requirement headers** — Requirement headers are now parsed regardless of capitalization, so specs no longer fail to parse over header casing
|
||||
- **Zsh completions on oh-my-zsh** — Fixed shell completion setup so tab completion installs correctly under oh-my-zsh's `compinit`
|
||||
|
||||
### Other
|
||||
|
||||
- **Clearer validation hints** — When a requirement has SHALL/MUST only in its header, `openspec validate` now points you to move the keyword onto the requirement body line instead of showing the generic error
|
||||
|
||||
- [#1030](https://github.com/Fission-AI/OpenSpec/pull/1030) [`485c97e`](https://github.com/Fission-AI/OpenSpec/commit/485c97e97d766e35dd16c02370baee2044abc4f4) Thanks [@TabishB](https://github.com/TabishB)! - ### New Features
|
||||
|
||||
- Include the sync workflow in the default core profile so new installs generate `/opsx:sync` skills and commands by default.
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#1111](https://github.com/Fission-AI/OpenSpec/pull/1111) [`7fdb177`](https://github.com/Fission-AI/OpenSpec/commit/7fdb1771585b1688597d73dde5a8bc906084d0de) Thanks [@TabishB](https://github.com/TabishB)! - ### Fixed
|
||||
|
||||
- Preserve workspace planning detection when Windows short paths or symlink aliases resolve to a canonical workspace root.
|
||||
|
||||
## 1.3.1
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- [#995](https://github.com/Fission-AI/OpenSpec/pull/995) [`d1f3861`](https://github.com/Fission-AI/OpenSpec/commit/d1f3861d9ec694cc924b042b5da01963dcf93137) Thanks [@TabishB](https://github.com/TabishB)! - ### Bug Fixes
|
||||
|
||||
- **Canonical artifact paths** — Workflow artifact paths are now resolved via the native `realpath`, so symlinks and case-insensitive filesystems no longer cause path mismatches during apply and archive.
|
||||
- **Glob apply instructions** — Apply instructions with glob artifact outputs now resolve correctly, and literal artifact outputs are enforced to be file paths.
|
||||
- **Hidden main spec requirements** — Requirements nested inside fenced code blocks or otherwise hidden in main specs are now detected during validation.
|
||||
- **Clean `--json` output** — Spinner progress text no longer leaks into stderr when `--json` is passed, so AI agents that combine stdout and stderr can parse the JSON reliably.
|
||||
- **Silent telemetry in firewalled environments** — PostHog network errors are now swallowed with a 1s timeout and retries/remote config disabled, so OpenSpec no longer surfaces `PostHogFetchNetworkError` in locked-down networks. Telemetry opt-out is documented earlier in the README, installation guide, and CLI reference.
|
||||
|
||||
## 1.3.0
|
||||
|
||||
### Minor Changes
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
# Contributing
|
||||
|
||||
Thanks for helping improve OpenSpec.
|
||||
|
||||
## 1. Open a discussion or an issue first
|
||||
|
||||
Every change starts here, including small ones.
|
||||
|
||||
- [Start a discussion](https://github.com/Fission-AI/OpenSpec/discussions) if it affects OpenSpec's core design.
|
||||
- [Open an issue](https://github.com/Fission-AI/OpenSpec/issues) for bugs and everything else.
|
||||
|
||||
This is so we can agree on the approach before you spend time building. PRs without a linked issue or a prior discussion may be closed.
|
||||
|
||||
## 2. Decide whether it needs a change proposal
|
||||
|
||||
A bug fix, a typo, or a small improvement goes straight to a PR.
|
||||
|
||||
A new feature, a significant refactor, or anything that changes OpenSpec's architecture needs an OpenSpec change proposal first, so we can align on intent and goals before implementation begins. Open it as a PR containing only `openspec/changes/<name>/` and wait for it to be approved before you write the code.
|
||||
|
||||
When writing a proposal, keep the OpenSpec philosophy in mind: we serve a wide variety of users across different coding agents, models, and use cases. Changes should work well for everyone.
|
||||
|
||||
If you are not sure which side of the line your change falls on, ask in the discussion or issue from step 1.
|
||||
|
||||
## 3. Make your change
|
||||
|
||||
You need Node 20.19+ and pnpm.
|
||||
|
||||
```bash
|
||||
pnpm install
|
||||
pnpm build # tests run against the build output
|
||||
pnpm test
|
||||
pnpm exec tsc --noEmit
|
||||
pnpm lint
|
||||
```
|
||||
|
||||
Those four commands are what CI runs, so a green local run means a green CI run.
|
||||
|
||||
Run `pnpm changeset` if your change affects users, and commit the file it generates.
|
||||
|
||||
## 4. Open the PR
|
||||
|
||||
- Branch off `main` in your fork.
|
||||
- Title it as a conventional commit: `type(scope): subject`, for example `fix(archive): keep authored Purpose`.
|
||||
- Link what you opened in step 1: `Closes #123` for an issue, or a link to the discussion when there is no issue.
|
||||
- If a coding agent wrote the code, say which agent and model, and confirm you tested it. AI-generated code is welcome when it has been verified.
|
||||
|
||||
Maintainers are listed in [MAINTAINERS.md](MAINTAINERS.md).
|
||||
@@ -7,13 +7,6 @@ People who maintain and guide OpenSpec.
|
||||
| Name | GitHub | Role |
|
||||
|------|--------|------|
|
||||
| Tabish Bidiwale | [@TabishB](https://github.com/TabishB) | Lead maintainer |
|
||||
| Clay Good | [@clay-good](https://github.com/clay-good) | Maintainer |
|
||||
|
||||
## Automation Maintainers
|
||||
|
||||
| Name | GitHub | Role |
|
||||
|------|--------|------|
|
||||
| Alfred | [@alfred-openspec](https://github.com/alfred-openspec) | Automation maintainer |
|
||||
|
||||
## Advisors
|
||||
|
||||
|
||||
@@ -42,19 +42,15 @@ Our philosophy:
|
||||
Follow <a href="https://x.com/0xTab">@0xTab on X</a> for updates · Join the <a href="https://discord.gg/YctCnvvshC">OpenSpec Discord</a> for help and questions.
|
||||
</p>
|
||||
|
||||
### Teams
|
||||
|
||||
Using OpenSpec in a team? [Email here](mailto:teams@openspec.dev) for access to our Slack channel.
|
||||
|
||||
<!-- TODO: Add GIF demo of /opsx:propose → /opsx:archive workflow -->
|
||||
|
||||
## See it in action
|
||||
|
||||
```text
|
||||
You: /opsx:explore
|
||||
AI: What would you like to explore?
|
||||
You: I want dark mode but I'm not sure how to do it cleanly.
|
||||
AI: Let me look at your styling setup...
|
||||
Cleanest path here: CSS variables + a small theme context,
|
||||
with system-preference detection. No new dependencies. Scope it?
|
||||
You: Yes, let's do it.
|
||||
|
||||
You: /opsx:propose add-dark-mode
|
||||
AI: Created openspec/changes/add-dark-mode/
|
||||
✓ proposal.md — why we're doing this, what's changing
|
||||
@@ -76,29 +72,6 @@ AI: Archived to openspec/changes/archive/2025-01-23-add-dark-mode/
|
||||
Specs updated. Ready for the next feature.
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary><strong>What do the specs actually look like?</strong></summary>
|
||||
|
||||
Plain Markdown — requirements with concrete scenarios, no special syntax to learn. Here's what goes in the `specs/` folder created above:
|
||||
|
||||
```markdown
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Theme selection
|
||||
The app SHALL let users switch between light and dark themes,
|
||||
defaulting to the system preference.
|
||||
|
||||
#### Scenario: User toggles dark mode
|
||||
- **WHEN** the user clicks the theme toggle
|
||||
- **THEN** the app switches to dark mode and persists the choice
|
||||
```
|
||||
|
||||
Your AI writes these; you review the plan before any code is written.
|
||||
|
||||
OpenSpec is built with OpenSpec — browse this repo's live [specs](openspec/specs) and in-flight [changes](openspec/changes) for real examples at scale.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>OpenSpec Dashboard</strong></summary>
|
||||
|
||||
@@ -108,21 +81,9 @@ OpenSpec is built with OpenSpec — browse this repo's live [specs](openspec/spe
|
||||
|
||||
</details>
|
||||
|
||||
## Why teams adopt OpenSpec
|
||||
|
||||
Solo, OpenSpec keeps you and your AI honest on a single repo. On a team, the hard part moves: a feature spans the API server, the web app, and a shared library; requirements are owned by one team and consumed by others; planning starts before any code exists.
|
||||
|
||||
**[Stores](docs/stores-beta/user-guide.md)** are the answer — planning in a repo of its own. The same `openspec/` shape you already know (specs and changes), shared by `git push` like anything else. One source of truth your whole team and every coding agent can read, across every repo.
|
||||
|
||||
- **Cross-repo features** — one change, one plan, even when the code lands in three repos.
|
||||
- **Shared requirements** — a platform team owns the specs; product teams reference them read-only, right where their coding agent can read them. No drifting wiki.
|
||||
- **Plan before code** — capture the plan in the store now; the code repos catch up later.
|
||||
|
||||
> Stores are in **beta**. Start with the [Stores User Guide](docs/stores-beta/user-guide.md).
|
||||
|
||||
## Quick Start
|
||||
|
||||
**Requires Node.js 20.19.0 or higher.** Homebrew installs it as a dependency.
|
||||
**Requires Node.js 20.19.0 or higher.**
|
||||
|
||||
Install OpenSpec globally:
|
||||
|
||||
@@ -130,12 +91,6 @@ Install OpenSpec globally:
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
```
|
||||
|
||||
Or install the official [Homebrew formula](https://formulae.brew.sh/formula/openspec) on macOS or Linux:
|
||||
|
||||
```bash
|
||||
brew install openspec
|
||||
```
|
||||
|
||||
Then navigate to your project directory and initialize:
|
||||
|
||||
```bash
|
||||
@@ -143,50 +98,25 @@ cd your-project
|
||||
openspec init
|
||||
```
|
||||
|
||||
> **Want your AI to do it?** Paste the [setup prompt](docs-lab/start/installation.md#install-with-your-ai-assistant) into your coding assistant — it installs the CLI, runs `openspec init`, and verifies the result.
|
||||
Now tell your AI: `/opsx:propose <what-you-want-to-build>`
|
||||
|
||||
Now talk to your AI:
|
||||
|
||||
- **Not sure what to build yet?** Start with `/opsx:explore`, a no-stakes thinking partner that reads your code, weighs options, and shapes a plan before any code gets written. ([Explore guide](docs/explore.md))
|
||||
- **Already know what you want?** Go straight to `/opsx:propose <what-you-want-to-build>`.
|
||||
|
||||
Both are in the default profile. If you want the expanded workflow (`/opsx:new`, `/opsx:continue`, `/opsx:ff`, `/opsx:verify`, `/opsx:bulk-archive`, `/opsx:onboard`), select it with `openspec config profile` and apply with `openspec update`.
|
||||
|
||||
`/opsx:propose` is the canonical name; your tool may spell it `/opsx-propose` (Cursor, GitHub Copilot), `@opsx-propose` (Amazon Q) or `$openspec-propose` (Codex). `openspec init` prints the right form for the tools you picked — see [How To Invoke](docs/supported-tools.md#how-to-invoke).
|
||||
If you want the expanded workflow (`/opsx:new`, `/opsx:continue`, `/opsx:ff`, `/opsx:verify`, `/opsx:sync`, `/opsx:bulk-archive`, `/opsx:onboard`), select it with `openspec config profile` and apply with `openspec update`.
|
||||
|
||||
> [!NOTE]
|
||||
> Not sure if your tool is supported? [View the full list](docs/supported-tools.md) – we support 30+ tools and growing.
|
||||
> Not sure if your tool is supported? [View the full list](docs/supported-tools.md) – we support 25+ tools and growing.
|
||||
>
|
||||
> Also works with Homebrew, pnpm, yarn, bun, and Nix. [See installation options](docs-lab/start/installation.md).
|
||||
> Also works with pnpm, yarn, bun, and nix. [See installation options](docs/installation.md).
|
||||
|
||||
## Docs
|
||||
|
||||
**Start here:** the **[Documentation Home](docs/README.md)** maps everything. New to OpenSpec? Read [Getting Started](docs/getting-started.md), then [How Commands Work](docs/how-commands-work.md) (where you actually type `/opsx:propose`).
|
||||
|
||||
→ **[Getting Started](docs/getting-started.md)**: first steps<br>
|
||||
→ **[Explore First](docs/explore.md)**: think it through with `/opsx:explore` before you commit<br>
|
||||
→ **[How Commands Work](docs/how-commands-work.md)**: where slash commands run vs the CLI<br>
|
||||
→ **[Core Concepts at a Glance](docs/overview.md)**: the whole mental model, one page<br>
|
||||
→ **[Examples & Recipes](docs/examples.md)**: real changes, start to finish<br>
|
||||
→ **[Workflows](docs/workflows.md)**: combos and patterns<br>
|
||||
→ **[Existing Projects](docs/existing-projects.md)**: adopt OpenSpec on a brownfield codebase<br>
|
||||
→ **[Editing a Change](docs/editing-changes.md)**: update artifacts, go back, reconcile manual edits<br>
|
||||
→ **[Commands](docs/commands.md)**: slash commands & skills<br>
|
||||
→ **[CLI](docs/cli.md)**: terminal reference<br>
|
||||
→ **[Stores](docs/stores-beta/user-guide.md)**: plan in a separate repo, shared across your team (beta)<br>
|
||||
→ **[Supported Tools](docs/supported-tools.md)**: tool integrations & install paths<br>
|
||||
→ **[Concepts](docs/concepts.md)**: how it all fits<br>
|
||||
→ **[Multi-Language](docs/multi-language.md)**: multi-language support<br>
|
||||
→ **[Customization](docs/customization.md)**: make it yours<br>
|
||||
→ **[Community Showcase](docs/community.md)**: projects and resources built with and for OpenSpec<br>
|
||||
→ **[FAQ](docs/faq.md)** · **[Troubleshooting](docs/troubleshooting.md)** · **[Glossary](docs/glossary.md)**: quick help
|
||||
|
||||
|
||||
## Community schemas
|
||||
|
||||
Third-party schema bundles distributed via standalone repositories — these provide opinionated workflows that integrate OpenSpec with other tools, similar to how [github/spec-kit's community extension catalog](https://github.com/github/spec-kit/tree/main/extensions) handles tool integrations.
|
||||
|
||||
→ **[Browse the catalog](docs/customization.md#community-schemas)** in the customization docs.
|
||||
→ **[Customization](docs/customization.md)**: make it yours
|
||||
|
||||
|
||||
## Why OpenSpec?
|
||||
@@ -196,7 +126,7 @@ AI coding assistants are powerful but unpredictable when requirements live only
|
||||
- **Agree before you build** — human and AI align on specs before code gets written
|
||||
- **Stay organized** — each change gets its own folder with proposal, specs, design, and tasks
|
||||
- **Work fluidly** — update any artifact anytime, no rigid phase gates
|
||||
- **Use your tools** — works with 30+ AI assistants via slash commands
|
||||
- **Use your tools** — works with 20+ AI assistants via slash commands
|
||||
|
||||
### How we compare
|
||||
|
||||
@@ -214,12 +144,6 @@ AI coding assistants are powerful but unpredictable when requirements live only
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
```
|
||||
|
||||
If you installed OpenSpec with Homebrew:
|
||||
|
||||
```bash
|
||||
brew upgrade openspec
|
||||
```
|
||||
|
||||
**Refresh agent instructions**
|
||||
|
||||
Run this inside each project to regenerate AI guidance and ensure the latest slash commands are active:
|
||||
@@ -230,15 +154,27 @@ openspec update
|
||||
|
||||
## Usage Notes
|
||||
|
||||
**Model selection**: OpenSpec works best with high-reasoning models. We recommend Codex 5.5 and Opus 4.7 for both planning and implementation.
|
||||
**Model selection**: OpenSpec works best with high-reasoning models. We recommend Opus 4.5 and GPT 5.2 for both planning and implementation.
|
||||
|
||||
**Context hygiene**: OpenSpec benefits from a clean context window. Clear your context before starting implementation and maintain good context hygiene throughout your session.
|
||||
|
||||
## Contributing
|
||||
|
||||
Open a discussion (for core design changes) or an issue before you open a PR, and link the issue or discussion from the PR. New features, significant refactors, and architectural changes need an OpenSpec change proposal first.
|
||||
**Small fixes** — Bug fixes, typo corrections, and minor improvements can be submitted directly as PRs.
|
||||
|
||||
→ **[CONTRIBUTING.md](CONTRIBUTING.md)**: the full process, from first issue to merged PR
|
||||
**Larger changes** — For new features, significant refactors, or architectural changes, please submit an OpenSpec change proposal first so we can align on intent and goals before implementation begins.
|
||||
|
||||
When writing proposals, keep the OpenSpec philosophy in mind: we serve a wide variety of users across different coding agents, models, and use cases. Changes should work well for everyone.
|
||||
|
||||
**AI-generated code is welcome** — as long as it's been tested and verified. PRs containing AI-generated code should mention the coding agent and model used (e.g., "Generated with Claude Code using claude-opus-4-5-20251101").
|
||||
|
||||
### Development
|
||||
|
||||
- Install dependencies: `pnpm install`
|
||||
- Build: `pnpm run build`
|
||||
- Test: `pnpm test`
|
||||
- Develop CLI locally: `pnpm run dev` or `pnpm run dev:cli`
|
||||
- Conventional commits (one-line): `type(scope): subject`
|
||||
|
||||
## Other
|
||||
|
||||
@@ -249,9 +185,7 @@ OpenSpec collects anonymous usage stats.
|
||||
|
||||
We collect only command names and version to understand usage patterns. No arguments, paths, content, or PII. Automatically disabled in CI.
|
||||
|
||||
**Opt-out (any one is enough):**
|
||||
- `openspec config set telemetry.enabled false` (global config; unset means on)
|
||||
- `export OPENSPEC_TELEMETRY=0` or `export DO_NOT_TRACK=1` (env overrides config)
|
||||
**Opt-out:** `export OPENSPEC_TELEMETRY=0` or `export DO_NOT_TRACK=1`
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
-62
@@ -1,62 +0,0 @@
|
||||
# Security Policy
|
||||
|
||||
## Reporting a vulnerability
|
||||
|
||||
Report privately through [GitHub Security Advisories](https://github.com/Fission-AI/OpenSpec/security/advisories/new). Please don't open a public issue for a suspected vulnerability.
|
||||
|
||||
Include what you can: affected version, reproduction steps, and the impact you believe it has. We aim to acknowledge within 3 business days and to ship a fix or a decision within 30 days. Valid reports are credited in the advisory unless you'd rather stay anonymous.
|
||||
|
||||
## Supported versions
|
||||
|
||||
Fixes ship in the latest published version on npm. Older versions are not patched — upgrade to pick up a fix.
|
||||
|
||||
## Threat model
|
||||
|
||||
OpenSpec is a local command-line tool. It has no server, no network listener, and no privileged daemon. It reads and writes markdown under the directory you run it in, using paths you supply, with your own user permissions. It can offer to upgrade itself during `openspec update`, and only with your say-so. It sends anonymous usage telemetry, which you can disable with `OPENSPEC_TELEMETRY=0`.
|
||||
|
||||
That shapes what is and isn't a vulnerability here:
|
||||
|
||||
| In scope | Out of scope |
|
||||
| --- | --- |
|
||||
| Code execution triggered by parsing a spec, config, or template file | Reading or writing a file path you passed to the CLI yourself |
|
||||
| Escaping the directory OpenSpec was pointed at, via untrusted input | Static-analysis findings on file-path joins with no untrusted input |
|
||||
| Leaking credentials or file contents through telemetry or logs | Vulnerabilities in devDependencies that don't ship in the published package |
|
||||
| Prototype pollution or injection reachable from a config or spec file | Denial of service against your own machine using your own input |
|
||||
|
||||
If you think something sits on the boundary, report it and we'll work it out together.
|
||||
|
||||
## Published package contents
|
||||
|
||||
The `openspec` npm package publishes `dist/`, `bin/`, and `schemas/`. Build and test tooling (vite, rollup, vitest, eslint, and their transitive dependencies) is not published. Scanners that read `pnpm-lock.yaml` without separating dependency scope will report advisories for packages that never reach an installed copy of OpenSpec.
|
||||
|
||||
You do not have to take that on trust — install the package and look:
|
||||
|
||||
```sh
|
||||
npm install @fission-ai/openspec
|
||||
ls node_modules | grep -E '^(vite|rollup|vitest|eslint|js-yaml|minimatch)$' # no matches
|
||||
```
|
||||
|
||||
`pnpm audit --prod` in this repository reports the same scope, and CI runs it on every pull request.
|
||||
|
||||
## What the CLI does on your machine
|
||||
|
||||
| Surface | Behavior |
|
||||
| --- | --- |
|
||||
| Install scripts | The package ships no `preinstall`, `install`, or `postinstall` script, so installing it from the npm registry runs no code from OpenSpec. (`prepare` is still declared; npm runs it only for git and local-directory installs, where it builds from source.) Shell completions are opt-in via `openspec completion install`; the CLI prints a one-line tip about them on its first run. |
|
||||
| Running other programs | Every call that goes through a shell uses a fixed literal (`which gh`, `gh auth status`). Anything carrying your input — issue text, editor paths, workset commands, the path passed to `openspec update` — uses an argument array, never string interpolation into a shell. On Windows, `.cmd` shims are launched through `cross-spawn`, which escapes arguments rather than concatenating them. |
|
||||
| Installing software | `openspec update` can run `npm install -g @fission-ai/openspec@latest` and then re-run `openspec update` with the upgraded CLI. It does this only after you answer yes to a prompt, only for the OpenSpec package itself, only when npm owns the install, and never in CI or a non-interactive shell. A global install lives outside your project, so it runs with your permissions there and executes whatever lifecycle scripts the published package ships. It then reads the installed binary's version back rather than assuming the upgrade took. Decline and it prints the command for you to run yourself. |
|
||||
| Telemetry | Command name, OpenSpec version, and a locally generated random UUID. No file paths, no file contents, no environment, no hostname, and IP capture is explicitly disabled. Opt out with `OPENSPEC_TELEMETRY=0` or `DO_NOT_TRACK=1`; it is off in CI automatically. |
|
||||
| Network | Telemetry when enabled, and one npm registry request during `openspec update` to check whether a newer CLI has been published. That request sends no data about you beyond what any HTTP request reveals, runs once per `openspec update` with nothing cached, and is skipped when `CI` is set to anything but an explicit off-value, under `NODE_ENV=test`, or when `OPENSPEC_NO_UPDATE_CHECK`, `DO_NOT_TRACK=1`, or `OPENSPEC_TELEMETRY=0` is set. Reading, writing, and validating specs is entirely local. |
|
||||
|
||||
## Automated checks
|
||||
|
||||
| Tool | Covers |
|
||||
| --- | --- |
|
||||
| [CodeQL](https://github.com/Fission-AI/OpenSpec/security/code-scanning) | Static analysis on every push and pull request to `main` |
|
||||
| [Dependabot](https://github.com/Fission-AI/OpenSpec/security/dependabot) | Dependency advisories plus weekly update pull requests for the CLI, the docs site, and CI actions |
|
||||
| Dependency review | Blocks a pull request that introduces a high-severity dependency |
|
||||
| Secret scanning | Enabled on the repository, including push protection |
|
||||
| `pnpm audit` | Published dependencies are audited on every pull request, on pushes to `main`, and weekly. Advisory on pull requests so an unrelated change is not blocked; failing elsewhere, so a new advisory surfaces even when no dependency changed. Build tooling is always advisory. |
|
||||
| Pinned actions | Every GitHub Action runs from a commit SHA, so a moved tag cannot change what CI executes |
|
||||
|
||||
Alerts are triaged against the threat model above, so a finding in build-only tooling is fixed on the normal update cadence rather than treated as an incident.
|
||||
+1
-3
@@ -1,5 +1,3 @@
|
||||
#!/usr/bin/env node
|
||||
|
||||
import { runCli } from '../dist/cli/index.js';
|
||||
|
||||
runCli();
|
||||
import '../dist/cli/index.js';
|
||||
@@ -1,94 +0,0 @@
|
||||
Ok these are my notes when reviewing the different sections/file in docs-lab.
|
||||
I've written down my thoughts when looking at these sections so we can think about how to update these
|
||||
docs with the feedback in mind.
|
||||
|
||||
|
||||
## Start > Overview
|
||||
|
||||
Ok the following subtitle here is horrible:
|
||||
|
||||
> OpenSpec gives you and your coding agent a shared, reviewable plan before code is written.
|
||||
|
||||
This is not a strong value prop in the day and age of plan mode, but other than that i don't think it sells openspec hard enough
|
||||
|
||||
OpenSpec is not really about a shared plan for a single session it's about a keeping things on track and aligned for larger features.
|
||||
|
||||
what we focus on:
|
||||
- making it work for teams
|
||||
- git native / things checked into vcs
|
||||
- intented behaviour matches the implemented behaviour
|
||||
- we help you capture intendede behaviour and match it to the implemented behaviour.
|
||||
- it's about correctness, coherence,
|
||||
|
||||
Control theory inspiration:
|
||||
|
||||
Instructors break down how a system measures its current state, compares it to a desired goal, and adjusts its actions to reduce the difference.
|
||||
|
||||
|
||||
|
||||
## Guides > Explore and idea
|
||||
|
||||
I think in this section we should mention:
|
||||
|
||||
This is about exploring the problem space, figuring out what problems you care about and diving deeper into them.
|
||||
|
||||
It was designed with a very different philiosphy in mind of giving you the freedom to explore the problem space and jump around to different ideas and sections.
|
||||
|
||||
It serves a similar purpose to other newer entrees in the fields like superpowers or matt pocock's skills.
|
||||
|
||||
We often do see people combining explore with
|
||||
|
||||
Often this is a matter of UX and personal preference. There is no single best skill or method to getting to
|
||||
aligment with your agent.
|
||||
|
||||
Some people prefer a conversing with a thoughtful design partner, others might prefer being asked questions till they have a good understanding of a problem.
|
||||
|
||||
Feel free to customize the explore skills to your needs.
|
||||
|
||||
Unrelated to docs:
|
||||
|
||||
How do we solve the problem for PM's?
|
||||
How do we give them a good home? - what is their job to be done?
|
||||
How we efficiently help them achieve that?
|
||||
|
||||
- they're basically turning it into tickets?
|
||||
|
||||
|
||||
What do we want to get across the line this week?
|
||||
|
||||
- The spec drift agent?
|
||||
- The dashboard?
|
||||
|
||||
- figure out how we use agent session and traces better
|
||||
|
||||
|
||||
## From docs-lab drafting (2026-08-19, project-config page)
|
||||
|
||||
Product issue, not docs: the installed skills in this repo are stale against the current
|
||||
templates. `.claude/skills/openspec-archive-change/SKILL.md` has no `openspec instructions`
|
||||
call at all, while `src/core/templates/workflows/archive-change.ts:40` instructs one; the
|
||||
installed apply skill also doesn't mention the `context`/`operationGuidance` fields in the
|
||||
JSON it reads. So config injection reaches the CLI output, but a stale skill never tells
|
||||
the agent to consume it. Running `openspec update` should refresh them.
|
||||
|
||||
|
||||
## From docs-lab drafting (2026-08-19, schemas page)
|
||||
|
||||
Product issues found while verifying the schema system (all file refs current as of today):
|
||||
|
||||
- `schema init` next-steps output prints a command that doesn't exist in that form:
|
||||
"Use with: openspec new --schema <name>" (schema.ts:999); real syntax is
|
||||
`openspec new change <name> --schema <name>`.
|
||||
- `openspec new change` spinner prints the hardcoded default schema, not the resolved one
|
||||
(new-change.ts:118): "Creating change 'x' with schema 'spec-driven'..." then "Schema: lite".
|
||||
- `schema fork` re-serializes schema.yaml (literal `instruction: |` becomes folded `>`,
|
||||
comments dropped), so diffing a fork against upstream is noisy (schema.ts:706-712).
|
||||
- All `openspec schema` subcommands plus `openspec schemas`/`templates` use process.cwd()
|
||||
and take no --store; they silently see nothing when run from a subdirectory, unlike
|
||||
root-resolved commands (schema.ts:383/485/634/768).
|
||||
- `suggestSchemas` fuzzy "did you mean" helper exists but is wired to nothing
|
||||
(project-config.ts:420).
|
||||
|
||||
Docs follow-up: the community schema catalog lives only in legacy docs/customization.md
|
||||
(#community-schemas); customize/schemas.md links to it on GitHub. When the old docs tree
|
||||
retires, the catalog needs a docs-lab home.
|
||||
@@ -1,294 +0,0 @@
|
||||
# docs-lab: parallel rebuild of the OpenSpec docs
|
||||
|
||||
**Status: prose is landing page by page; the rest are skeletons** (real headings plus a
|
||||
one-line `>` job statement the site lifts into the page description). The live site
|
||||
builds from this tree: `website/docs.sync.config.mjs` maps these files to published
|
||||
pages, and the old `docs/` tree is no longer used by the site.
|
||||
|
||||
This README owns the structure: which pages exist and which page teaches what. The
|
||||
reverse view, from a job or message to the page that owns it, is
|
||||
[message-map.md](message-map.md). How to
|
||||
write them (style, voice, formatting) is the `write-openspec-docs` skill's
|
||||
[writing.md](../.agents/skills/write-openspec-docs/writing.md).
|
||||
|
||||
## The bar for every page
|
||||
|
||||
Every page in docs-lab is written by hand, from scratch. The old `docs/` tree is source
|
||||
material for facts, never text to carry over.
|
||||
|
||||
What we're after is that the reader gets the idea: every page reads well and makes sense
|
||||
to anyone, whatever their level of skill, and above all it is simple. The worst thing we
|
||||
can ship is documentation that is cognitively expensive to understand, and that cost
|
||||
comes from complicated words, metaphors that don't make sense, random terminology that
|
||||
isn't explained, and formatting that gets in the way of reading. Every sentence has a
|
||||
purpose and is easy to read and comprehend. If a sentence doesn't pass that test, rewrite
|
||||
it or cut it.
|
||||
|
||||
## Structure rules
|
||||
|
||||
**Folders are the areas.** Every page lives in its area's folder (`start/`,
|
||||
`guides/`, `customize/`, `multi-repo/`, `reference/`, `help/`); the root holds only this
|
||||
README, `message-map.md`, and `sources.md`. Most folders publish as one
|
||||
sidebar group; `guides/` publishes as the Guides group, holding three collapsible
|
||||
subgroups (Understanding OpenSpec, Using OpenSpec, Adopting OpenSpec), all expanded
|
||||
by default (held back from the site until the pages are drafted: the whole section is
|
||||
commented out in `website/docs.sync.config.mjs`, and links to a guide fall back to its
|
||||
source on GitHub until it's re-listed). Reference holds three nested
|
||||
folders (`reference/architecture/`, `reference/schemas/`, and
|
||||
`reference/configuration/`), each publishing as a collapsible group with `index.md` as
|
||||
its landing page; the spec-driven schema publishes as a single page
|
||||
(`reference/schemas/spec-driven/index.md`) inside the Schemas group. Labels and URLs come from
|
||||
`website/docs.sync.config.mjs`, so moving a file never moves a URL.
|
||||
|
||||
**Teach once.** The loop (propose, review, apply, archive) has one teacher; every other
|
||||
page links, never re-teaches:
|
||||
|
||||
- `start/quickstart.md` teaches it as UX: how a human moves a change through the
|
||||
lifecycle, including what archive does on disk.
|
||||
- `start/overview.md` shows it as pitch: copy only, no explanation.
|
||||
- `guides/concepts.md` stays out of it: the page explains the artifacts (specs, changes,
|
||||
the delta) and links to the quickstart for the loop. Disk paths appear inline with the
|
||||
concept that owns them, never as a layout section.
|
||||
- `start/installation.md` owns install; `start/setup.md` owns init and what it writes.
|
||||
The quickstart opens with one prerequisite line linking both and starts at explore.
|
||||
|
||||
**Guides vs reference.** `reference/skills.md` holds each skill's contract: arguments,
|
||||
what it creates, and what it responds with. Guide pages
|
||||
(the Using and Adopting subgroups) own the human judgment for a task, including when
|
||||
to reach for each skill, may span several skills, and never restate skill mechanics.
|
||||
`reference/architecture/` is the one exception to Reference's look-it-up bar: it's
|
||||
explanation content, housed here as a pragmatic home while it's three pages. If it
|
||||
grows (say, by absorbing contributor internals), consider giving it its own folder
|
||||
and tab.
|
||||
|
||||
**Reference is lookup, and named for it.** `reference/schemas/` and
|
||||
`reference/configuration/` are contracts: keys, values, types, defaults, and
|
||||
locations, on tables and fences. Anything explanatory (what a schema is, what
|
||||
to put in config.yaml) lives in Customize or Guides and is linked, never
|
||||
restated. Naming follows three rules. A reference folder's landing
|
||||
page is titled "Overview"; the folder label already names the group, and
|
||||
repeating it double-nests the sidebar. A page documenting one file carries
|
||||
concept and filename in the title, concept first, where the concept names the
|
||||
file's use, never just its scope ("Project configuration (config.yaml)", "CLI
|
||||
settings (config.json)"): the left edge is what the eye disambiguates in the
|
||||
sidebar, and the filename keeps the title matching what readers search for and
|
||||
see on disk. A file whose name is the term readers use keeps the filename
|
||||
alone as the title (`schema.yaml`), and a page owning one product term takes
|
||||
that term as the title (`spec-driven`), and
|
||||
a page covering several files takes the concept alone (Stores), naming its
|
||||
files in the job line.
|
||||
|
||||
**FAQ is one-liners.** Every FAQ entry is a short answer, a few lines at most, or a
|
||||
router link to the page that owns the topic. How-to content never lives in the FAQ:
|
||||
when an answer outgrows a one-liner, it moves to a guide or reference page and the FAQ
|
||||
entry becomes a pointer.
|
||||
|
||||
## Page index: every page's job
|
||||
|
||||
Each goal below is the page's `>` blockquote verbatim, so the promise here is the promise
|
||||
readers see. A page delivers exactly its goal: content that outgrows it means splitting
|
||||
the page or rewriting the goal in both places, never letting them drift.
|
||||
|
||||
### Start: from "what is this?" to your first archived change
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [Overview](start/overview.md) | _TODO: emptied 2026-08-21 for a from-scratch rewrite and pulled from the site (`/docs` redirects to Installation meanwhile); the old goal line was dropped as too weak a pitch. Brief in Notes.md._ |
|
||||
| [Installation](start/installation.md) | Install the `openspec` CLI on your machine, update it, and uninstall it. |
|
||||
| [Set up your project](start/setup.md) | Add OpenSpec to a project: run init, see what it wrote, and adjust it. |
|
||||
| [Quickstart](start/quickstart.md) | Your first change in a new or existing project, from idea to archived. |
|
||||
|
||||
### Guides: understand the system, use it well, bring it to your codebase and team
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [Understanding › Concepts](guides/concepts.md) | What the two artifacts are, and how a change describes a diff against current specs. |
|
||||
| [Using › Explore an idea](guides/explore.md) | Think it through with the agent before you commit to a proposal. |
|
||||
| [Using › Review the plan](guides/review-the-plan.md) | The two-minute pass that catches wrong turns before they're code. |
|
||||
| [Using › Apply a change](guides/apply.md) | Run the plan: pacing, context windows, and picking up where you left off. |
|
||||
| [Using › Change course](guides/change-course.md) | Revise a change in flight, or decide it's cleaner to start fresh. |
|
||||
| [Adopting › Existing codebases](guides/existing-codebases.md) | Bring OpenSpec to a codebase with a lot of code and no specs: where to start, what to backfill, and how specs grow from there. |
|
||||
| [Adopting › Teams](guides/teams.md) | Run OpenSpec as a team: what to commit, how a change rides its PR, and when to archive. |
|
||||
|
||||
### Customize: make the workflows fit your project
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [Overview](customize/overview.md) | Your options for customizing OpenSpec. |
|
||||
| [Profiles](customize/profiles.md) | Choose which workflows are installed, and whether they install as skills, commands, or both. |
|
||||
| [Project configuration](customize/project-config.md) | Make the workflows plan changes the way you want with a few lines in config.yaml. |
|
||||
| [Schemas](customize/schemas.md) | Change what OpenSpec produces: the artifacts, their order, and their templates. |
|
||||
|
||||
### Multi-repo (beta): plan across repository boundaries
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [Stores (beta)](multi-repo/stores.md) | Plan changes that span repositories: one store, many repos. |
|
||||
| [Worksets (beta)](multi-repo/worksets.md) | Open the store and the repos that use it in one editor window, so your agent sees both. |
|
||||
|
||||
### Reference: look it up, exact and complete
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [Skills](reference/skills.md) | Every OpenSpec skill: arguments, what it creates, and what it responds with. |
|
||||
| [CLI](reference/cli.md) | The `openspec` terminal commands. |
|
||||
| [Schemas](reference/schemas/index.md) | Every available workflow schema and the artifacts it defines. |
|
||||
| [Schemas › schema.yaml](reference/schemas/schema-yaml.md) | Every field of a schema definition, for reading or writing one. |
|
||||
| [Schemas › spec-driven](reference/schemas/spec-driven/index.md) | The default workflow's artifacts: their order, their formats, and the change folder they produce. |
|
||||
| [Configuration](reference/configuration/index.md) | Every file and setting that changes how OpenSpec behaves, and where each lives. |
|
||||
| [Configuration › Project configuration (config.yaml)](reference/configuration/config-yaml.md) | Every field of openspec/config.yaml: the schema, context, and rules this project plans with. |
|
||||
| [Configuration › Change metadata (.openspec.yaml)](reference/configuration/change-metadata.md) | The supported fields and validation rules for the metadata stored with each change. |
|
||||
| [Configuration › CLI settings (config.json)](reference/configuration/config-json.md) | Every field of config.json: how the openspec CLI behaves on your machine. |
|
||||
| [Configuration › Environment variables](reference/configuration/environment-variables.md) | Every environment variable OpenSpec reads. |
|
||||
| [Configuration › Stores](reference/configuration/stores.md) | The files behind multi-repo stores: registry.yaml and store.yaml, and which root a command uses. |
|
||||
| [Supported tools](reference/supported-tools.md) | Which AI coding tools OpenSpec supports, and each one's command syntax. |
|
||||
| [Glossary](reference/glossary.md) | Every OpenSpec term, one line each. |
|
||||
| [Architecture](reference/architecture/index.md) (held back from the site until drafted) | How OPSX is built: internals for the curious. |
|
||||
| [Architecture › Workflow runs](reference/architecture/workflow-runs.md) | How a workflow run executes, from invocation to written artifacts. |
|
||||
| [Architecture › Design decisions](reference/architecture/design-decisions.md) | Why OPSX works the way it does. |
|
||||
|
||||
### Help: get unstuck (held back from the site until drafted, see Open TODOs)
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [FAQ](help/faq.md) | Short answers to the questions that don't need a page. |
|
||||
| [Troubleshooting](help/troubleshooting.md) | When OpenSpec doesn't do what you expected: symptoms and their fixes. |
|
||||
|
||||
### Legacy: land the old workflow safely (held back from the site until drafted, see Open TODOs)
|
||||
|
||||
| Page | Goal |
|
||||
|---|---|
|
||||
| [Migrating from the legacy workflow](help/legacy/migration.md) | Moving from the legacy `/openspec:*` commands to OPSX. |
|
||||
|
||||
## Old docs
|
||||
|
||||
The `docs/` tree is legacy, and the plan is to remove it once docs-lab covers what it
|
||||
owns. It has become a bit of an AI slop mess, so nothing from it is carried over as text
|
||||
(see The bar for every page). Until it's removed it stays untouched: fixes land in
|
||||
docs-lab, never in `docs/`.
|
||||
|
||||
[`sources.md`](sources.md) maps every current `docs/` page to its destination here: the
|
||||
source material while drafting, the redirect list at cutover. Cutover steps are in that
|
||||
file's [Cutover](sources.md#cutover) section.
|
||||
|
||||
## Open TODOs
|
||||
|
||||
- Not started: the Architecture pages (`reference/architecture/index.md`,
|
||||
`workflow-runs.md`, `design-decisions.md`). All three are headings only, so we hid the
|
||||
group from the site on 2026-08-21 (folder entry commented out in
|
||||
`website/docs.sync.config.mjs`). The files stay on disk with a WIP comment. Published
|
||||
pages that link to them (`reference/glossary.md` to the Overview,
|
||||
`customize/project-config.md` to Workflow runs) fall back to the GitHub source until
|
||||
the group is re-listed.
|
||||
- Not started: the Help and Legacy pages (`help/faq.md`, `help/troubleshooting.md`,
|
||||
`help/legacy/migration.md`). FAQ has one answer and the other two are headings only, so
|
||||
we hid both sections from the site on 2026-08-21 (commented out in
|
||||
`website/docs.sync.config.mjs`, same mechanism as Guides). The files stay on disk with
|
||||
a WIP comment. Published pages that link to them (`start/setup.md` to FAQ,
|
||||
`reference/glossary.md` to Migration) fall back to the GitHub source until the
|
||||
sections are re-listed.
|
||||
- Not started: `start/overview.md` is empty on purpose. We cleared the skeleton
|
||||
(headings, narrative beats, diagram gallery) on 2026-08-21 to rewrite the landing page
|
||||
from scratch. The old pitch ("a shared, reviewable plan before code is written")
|
||||
undersells OpenSpec now that plan mode is everywhere; the rewrite should sell keeping
|
||||
larger features on track and aligned (teams, git-native, intended vs implemented
|
||||
behavior, control-loop framing). Brief in `Notes.md` ("Start > Overview"); the diagram
|
||||
candidates went with the gallery and live in git history. Until the rewrite lands the
|
||||
page is off the site: its entry is commented out in `website/docs.sync.config.mjs` and
|
||||
`/docs` redirects to Installation (`website/public/_redirects` plus a fallback in the
|
||||
docs page route). Restoring it is one uncomment plus removing the two redirects. The
|
||||
Teach-once rule still applies: the loop appears here as pitch only.
|
||||
- Product feedback, not a docs task: spec-driven's design `instruction` lists six
|
||||
sections (including Migration Plan and Open Questions) but
|
||||
`schemas/spec-driven/templates/design.md` carries only four headers. The docs show
|
||||
both verbatim; the mismatch belongs upstream. Noted 2026-08-14 while consolidating
|
||||
the spec-driven page.
|
||||
- Product feedback, not a docs task: `openspec store setup --remote` writes the URL
|
||||
into `store.yaml` but never configures a git `origin`, so "setup --remote, then
|
||||
`git push -u origin main`" fails as written; the Stores page shows `git remote add`
|
||||
instead. The pasteable missing-store fix in `openspec doctor` is powered by
|
||||
`references:` remotes, not `store.yaml`. Noted 2026-08-21 while porting the Stores
|
||||
page.
|
||||
- Style guide follow-up (`.agents/skills/write-openspec-docs/writing.md`), from the
|
||||
Stores page's review rounds, 2026-08-21: never use a term the page hasn't shown
|
||||
(say "the `store:` line", not "the pointer"; define by showing the artifact first);
|
||||
when behavior depends on the reader's starting state, enumerate the states and walk
|
||||
each to its outcome; sentence subjects are you, OpenSpec, or your agent, never an
|
||||
implementation unit ("the resolver picks") or a class of things ("store-only
|
||||
projects make..."); when a defined term is reused a section later, re-gloss it in
|
||||
one parenthetical at the point of use.
|
||||
- Fence convention follow-up, 2026-08-21: the Stores page puts commands in `bash`
|
||||
fences with a one-line `#` comment and OpenSpec output in a separate `yaml` fence.
|
||||
`customize/schemas.md` still uses `console` fences with `$` prompts (lines 78, 114,
|
||||
137, 145; prompts at 24 and 115); the style guide should name the convention and
|
||||
that page should adopt it.
|
||||
- Monorepo: message-map row 37 is still a Gap. "Packages treated as separate repos"
|
||||
may land on the Stores page later; not part of the current page.
|
||||
|
||||
- `reference/cli.md` is fully drafted: the command table plus one section per real
|
||||
command, facts captured from working-tree runs (2026-08-11). The `delivery` key that
|
||||
start/setup.md's "Skills, commands, or both" section sets appears there only as
|
||||
command output; its field-level home, `reference/configuration/config-json.md`, is
|
||||
drafted (2026-08-14).
|
||||
- Telemetry is undocumented. `OPENSPEC_TELEMETRY=0` appears nowhere in the tree; the
|
||||
Deno install command grants `--allow-net=edge.openspec.dev` with no explanation (the
|
||||
telemetry gloss was deliberately pulled pending a real home). The home now exists:
|
||||
write `reference/configuration/environment-variables.md` (the env var, what's
|
||||
collected, the opt-out, the CI auto-disable), then have the Deno section link to it
|
||||
to explain the flag. Noted 2026-08-07; home settled 2026-08-10.
|
||||
- Product feedback, not a docs task: init doesn't say when the global profile changed what
|
||||
it wrote. A machine with `profile: custom` silently installs a different workflow set
|
||||
than a stock machine, and nothing in the init output names the profile that shaped it.
|
||||
Noted 2026-08-05 while verifying installation.md; track upstream, don't paper over in prose.
|
||||
- Product feedback, not a docs task: drop the sync-specs skill from the default set; its
|
||||
job reads as reference content, not a workflow, and it pads the skill list every reader
|
||||
scans. Noted 2026-08-08 while writing start/setup.md's workflow tree.
|
||||
- Product feedback, not a docs task: make the shared `.agents/` folder the default install
|
||||
target for every tool, with tool-specific folders (`.claude/`, ...) the exception. The
|
||||
docs already prefer `.agents/` in examples; the product should match. Noted 2026-08-08.
|
||||
- `help/troubleshooting.md`'s skeleton has no section for install-time failures
|
||||
(`command not found`, wrong Node version, PATH). Old `docs/troubleshooting.md` covered
|
||||
them; `start/installation.md` carries caveats inline but there is no symptom-to-fix
|
||||
home. Add a section or an installation.md anchor. Noted 2026-08-10 during the old-docs
|
||||
message audit.
|
||||
- Missing guide: the iterative flow. new/continue/fast-forward have no owner for the
|
||||
judgment: what the flow is, when to pick it over propose, and ff vs continue. Old
|
||||
`docs/workflows.md` covered it (Two Modes, When to Use What); `sources.md` routes that
|
||||
page's mechanics to `guides/apply.md` and contracts to `reference/skills.md`, so the
|
||||
choice itself landed nowhere. Likely a Guides › Using page slotted between Explore and
|
||||
Review the plan, with a pointer to `customize/profiles.md` (the skills are optional
|
||||
workflows outside the core set). Salvage only the ff-vs-continue rule of thumb; the rest of
|
||||
workflows.md is unverified. Noted 2026-08-11. Related: message-map row 29 words
|
||||
apply.md's pacing question as drafting-time pacing, the same creation-stage choice;
|
||||
fix that row's wording or owner when this guide lands. Noted 2026-08-14.
|
||||
- Missing guide: working with git. OpenSpec never touches git, so every git decision
|
||||
lands on the reader with no page to answer it: do you branch before or after propose,
|
||||
does a task get its own commit, what goes in the PR, where does the archive commit
|
||||
land. `guides/teams.md` owns the archive-vs-PR ordering; the rest is unowned. Likely a
|
||||
`guides/` file in the Adoption group. Noted 2026-08-08.
|
||||
- `customize/skills.md` is parked: the skeleton stays on disk but is out of the page
|
||||
index, the sidebar, and the sync config. Editing installed skill prompts has no good
|
||||
answer yet (`openspec update` overwrites edits); the message map keeps the question as
|
||||
a Gap. Revive when the product has a real story for surviving updates. Parked 2026-08-14.
|
||||
- `guides/examples.md` is parked: the skeleton stays on disk but is out of the page
|
||||
index, the sidebar, and the sync config. Contrived examples teach the wrong lesson for
|
||||
this product; revive the page when real archived changes from actual usage can fill it.
|
||||
The content plan (weak-vs-reviewed pairs, archived-changes gallery) is in the file's
|
||||
comment. Parked 2026-08-11.
|
||||
- Product feedback, not a docs task: "expanded" survives in product strings and the
|
||||
update workflow is unlabeled in the picker. The only stored profile values are core
|
||||
and custom, but `src/core/templates/workflows/update-change.ts` says "expanded-profile
|
||||
workflow", and `WORKFLOW_PROMPT_META` (`src/commands/config.ts`) has no `update` entry,
|
||||
so the `openspec config` workflow picker renders a core workflow as raw `update` /
|
||||
"Workflow: update". Docs standardized on core/custom with "expand the set" as a verb
|
||||
(2026-08-12). Noted 2026-08-12 during the glossary product sweep.
|
||||
- Product feedback, not a docs task: converge on skills only, soon. A workflow's skill and
|
||||
command are the same instructions, Claude Code has already merged commands into skills
|
||||
upstream, and setup spends a whole subsection explaining why two forms exist. Every page
|
||||
gets simpler when commands go. Noted 2026-08-08 while writing start/setup.md.
|
||||
- Website QOL backlog, site build not prose: i18n; AI search layered on the stock keyword
|
||||
search (an ask-the-docs answer box, not just matching); proper light/dark themes that
|
||||
carry the Survey palette (DESIGN.md tokens) into both modes instead of a stock dark
|
||||
theme. Candidates to bundle in the same pass: `llms.txt` plus a per-page "copy as
|
||||
Markdown" button so agents can ingest pages, copy buttons on code blocks, and
|
||||
"edit this page on GitHub" links. Noted 2026-08-11.
|
||||
@@ -1,32 +0,0 @@
|
||||
# Overview
|
||||
|
||||
> Your options for customizing OpenSpec.
|
||||
|
||||
OpenSpec supports multiple customization options. This page shows what each one changes and when to use it.
|
||||
|
||||
## What you can customize
|
||||
|
||||
| Option | What it changes | Use it when |
|
||||
|---|---|---|
|
||||
| [Profiles](profiles.md) | Which workflows are installed, and whether as skills, commands, or both | You want additional workflows and working patterns, or to remove workflows you don't need |
|
||||
| [Project configuration](project-config.md) | The instructions injected into every workflow run: context, rules, and operation guidance (`config.yaml`) | You want changes planned your way, like tasks always including Playwright tests |
|
||||
| [Schemas](schemas.md) | What OpenSpec produces: the artifacts, their order, and their templates | Changes should produce different planning files, sections, or formats |
|
||||
|
||||
## Not sure which to use?
|
||||
|
||||
Config and schemas are two levels of customization. Pick by how hands-on you want to get:
|
||||
|
||||
- **Start with [project configuration](project-config.md)**: it's lighter, and for most projects it's enough. You keep the standard artifacts and add your own context and rules on top.
|
||||
- **Fork a [schema](schemas.md) when adding isn't enough**: config only adds on top of the core workflow. It can add a rule like "tasks always include tests," but it can't drop the design doc or rename a file. That's schema territory. Forking gives you your own copy to edit.
|
||||
|
||||
*"Fork" here means the `openspec schema fork` command, not forking a git repo. [Schemas](schemas.md) has the details.*
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
a["The workflows should know my stack and conventions"] --> config
|
||||
b["One artifact needs an extra rule, like tasks always including tests"] --> config
|
||||
c["Different artifacts, file names, or document structure"] --> schema
|
||||
d["The built-in instructions say things my team does differently"] --> schema
|
||||
config["Project configuration<br/>(config.yaml)"]
|
||||
schema["Fork a schema<br/>(openspec schema fork)"]
|
||||
```
|
||||
@@ -1,88 +0,0 @@
|
||||
# Profiles
|
||||
|
||||
> Choose which workflows are installed, and whether they install as skills, commands, or both.
|
||||
|
||||
A profile is your preference for which OpenSpec workflows (the [skills and commands](../start/setup.md#the-workflow-files-skills-and-commands) in your AI tool) are installed across your machine. The default profile is `core`. Include or exclude workflows and your selection is saved as the `custom` profile.
|
||||
|
||||
## The core set
|
||||
|
||||
The `core` profile installs six workflows, covering the whole loop from idea to archive:
|
||||
|
||||
| Workflow | What it's for |
|
||||
|---|---|
|
||||
| [`explore`](../reference/skills.md#openspec-explore) | Think through an idea before it becomes a change proposal |
|
||||
| [`propose`](../reference/skills.md#openspec-propose) | Create a change proposal and generate all its planning artifacts in one step |
|
||||
| [`apply`](../reference/skills.md#openspec-apply-change) | Implement a change proposal's tasks |
|
||||
| [`update`](../reference/skills.md#openspec-update-change) | Revise a change proposal's existing planning artifacts |
|
||||
| [`sync`](../reference/skills.md#openspec-sync-specs) | Merge a change proposal's spec updates into `specs/` without archiving it |
|
||||
| [`archive`](../reference/skills.md#openspec-archive-change) | Move a finished change proposal to the archive |
|
||||
|
||||
Each links to its full contract: arguments, what it creates, and what it responds with.
|
||||
|
||||
## Expanding the set: optional workflows
|
||||
|
||||
Six more workflows are available beyond the core set. Three of them (`new`, `continue`, `ff`) create a change proposal artifact by artifact, instead of all at once like `propose`.
|
||||
|
||||
| Workflow | What it's for |
|
||||
|---|---|
|
||||
| [`new`](../reference/skills.md#openspec-new-change) | Start a change proposal as an empty scaffold |
|
||||
| [`continue`](../reference/skills.md#openspec-continue-change) | Create the next planning artifact in a change proposal, one at a time |
|
||||
| [`ff`](../reference/skills.md#openspec-ff-change) | Create a change proposal and every planning artifact implementation needs, in one pass |
|
||||
| [`verify`](../reference/skills.md#openspec-verify-change) | Check that the implementation matches the change proposal's artifacts |
|
||||
| [`bulk-archive`](../reference/skills.md#openspec-bulk-archive-change) | Archive several change proposals at once |
|
||||
| [`onboard`](../reference/skills.md#openspec-onboard) | Learn the workflow by doing one real change proposal end to end |
|
||||
|
||||
To change the set, run the interactive picker:
|
||||
|
||||
```bash
|
||||
openspec config profile
|
||||
```
|
||||
|
||||
The picker asks what to configure ([delivery](#delivery-skills-commands-or-both), workflows, or both), then lists all twelve workflows as checkboxes, with the installed ones checked. Any selection that isn't exactly the core six is saved as the `custom` profile, so you can also uncheck core workflows you don't use.
|
||||
|
||||
## Delivery: skills, commands, or both
|
||||
|
||||
Delivery is a profile setting that lets you choose to have only skills or only commands installed. The default is `both`. [Set up your project](../start/setup.md#the-workflow-files-skills-and-commands) explains the two forms and why both exist. The field's exact contract is in [CLI settings (config.json)](../reference/configuration/config-json.md#delivery).
|
||||
|
||||
Two ways to change it:
|
||||
|
||||
**Interactively**: run `openspec config profile` and choose "Delivery only". Here's switching to skills only:
|
||||
|
||||
```
|
||||
Current profile settings
|
||||
Delivery: both
|
||||
|
||||
? What do you want to configure? Delivery only
|
||||
? Delivery mode (how workflows are installed): Skills only
|
||||
|
||||
Config changes:
|
||||
delivery: both -> skills
|
||||
? Apply changes to this project now? (Y/n) y
|
||||
```
|
||||
|
||||
**Directly**: one command, no prompts:
|
||||
|
||||
```bash
|
||||
openspec config set delivery skills # or: both, commands
|
||||
```
|
||||
|
||||
Delivery never changes the profile name. `core` and `custom` describe the workflow set only, and switching back to `core` keeps your delivery setting.
|
||||
|
||||
## Switching profiles
|
||||
|
||||
Switching is two steps: change the profile on your machine, then update each project to apply it.
|
||||
|
||||
1. Change the profile:
|
||||
|
||||
```bash
|
||||
openspec config profile # interactive
|
||||
openspec config profile core # reset to the core six (keeps delivery)
|
||||
```
|
||||
|
||||
2. Run the update in each project you work in:
|
||||
|
||||
```bash
|
||||
openspec update
|
||||
```
|
||||
|
||||
When your current directory is an existing OpenSpec project, the interactive flow offers to run step 2 there for you.
|
||||
@@ -1,121 +0,0 @@
|
||||
# Project configuration
|
||||
|
||||
> Make the workflows plan changes the way you want with a few lines in config.yaml.
|
||||
|
||||
`openspec/config.yaml` tells the workflows how you want changes planned.
|
||||
|
||||
For example, the following configuration updates the creation rules for the [tasks.md](../reference/schemas/spec-driven/index.md) artifact:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
tasks:
|
||||
- End every task with a commit
|
||||
```
|
||||
|
||||
When the agent runs, it pulls from these rules and ensures every task ends with a commit step.
|
||||
|
||||
Keep rules short. Everything here lands in the agent's context, and verbose rules can make the output worse.
|
||||
|
||||
## How it works
|
||||
|
||||
config.yaml holds instructions the agent receives when it creates artifacts or works through the workflow.
|
||||
|
||||
Here's what happens on every run:
|
||||
|
||||
1. You run a workflow (e.g. `/openspec-propose`).
|
||||
2. The agent calls the [`openspec instructions`](../reference/cli.md) command.
|
||||
3. The command reads your context and rules from config.yaml.
|
||||
4. OpenSpec's built-in instructions and your customizations are combined into a single prompt for the agent.
|
||||
5. The agent follows that prompt to write the artifact.
|
||||
|
||||
For example, with a `context` field and the rule from the top of this page, here's what [`openspec instructions`](../reference/cli.md) returns for tasks.md (trimmed and annotated):
|
||||
|
||||
```xml
|
||||
<artifact id="tasks" change="add-dark-mode" schema="spec-driven">
|
||||
|
||||
<!-- From your config.yaml: context -->
|
||||
<project_context>
|
||||
Designs and tasks must cover Windows, macOS, and Linux
|
||||
Write all artifacts in Spanish
|
||||
</project_context>
|
||||
|
||||
<!-- From your config.yaml: rules for tasks -->
|
||||
<rules>
|
||||
- End every task with a commit
|
||||
</rules>
|
||||
|
||||
<!-- From OpenSpec: the built-in guidance -->
|
||||
<instruction>
|
||||
...how to write a good tasks.md...
|
||||
</instruction>
|
||||
|
||||
<template>
|
||||
...the tasks.md structure to fill in...
|
||||
</template>
|
||||
|
||||
</artifact>
|
||||
```
|
||||
|
||||
Your config arrives first, then OpenSpec's built-in instruction and template. Rules add to the built-ins and never replace them. Edits to config.yaml reach the agent on the next run.
|
||||
|
||||
## The fields
|
||||
|
||||
Three fields shape what the agent receives. Each field's exact contract (types, limits, validation) is in [Project configuration (config.yaml)](../reference/configuration/config-yaml.md).
|
||||
|
||||
| Field | What it does | Injected into |
|
||||
|---|---|---|
|
||||
| `context` | Instructions the agent always receives | Everything: every artifact, `apply`, `archive` |
|
||||
| `rules` | Extra instructions for one artifact | Only that artifact's creation |
|
||||
| `operations` | Guidance for how a workflow step is carried out | Only `apply` and `archive` |
|
||||
|
||||
config.yaml's other fields (`schema`, `store`, `references`) select which schema and which OpenSpec root a project uses. The contract page covers them.
|
||||
|
||||
The last column is exact, so a field reaches only the steps listed there. In particular, `verify` never receives `rules`. It checks the implementation against the artifacts as written.
|
||||
|
||||
### context
|
||||
|
||||
`context` is background the agent receives when it creates an artifact, applies tasks, or archives a change.
|
||||
|
||||
```yaml
|
||||
context: |
|
||||
We ship cross-platform. Designs and tasks must cover Windows, macOS, and Linux
|
||||
Write all artifacts in Spanish
|
||||
```
|
||||
|
||||
Use `context` for facts and constraints that should shape workflow output. Keep durable project documentation in the project's documentation files, and leave out anything the agent can learn by reading the code.
|
||||
|
||||
**Another language**: because context reaches every artifact, you can add `Write all artifacts in Spanish.` to instruct the agent to write proposal, spec, design, and tasks artifacts in Spanish.
|
||||
|
||||
### rules
|
||||
|
||||
`rules` attach to one artifact, keyed by artifact id. Each line is added to that artifact's built-in guidance:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
proposal:
|
||||
- Keep proposals under 500 words
|
||||
tasks:
|
||||
- Every UI task includes a Playwright test
|
||||
```
|
||||
|
||||
Proposals now stay short and tasks.md always plans browser tests. Every other artifact is untouched.
|
||||
|
||||
### operations
|
||||
|
||||
`operations` guides how the agent carries out `apply` and `archive`, rather than what artifacts say:
|
||||
|
||||
```yaml
|
||||
operations:
|
||||
apply:
|
||||
guidance:
|
||||
- Run the linter before marking a task complete
|
||||
archive:
|
||||
guidance:
|
||||
- Summarize what shipped before archiving
|
||||
```
|
||||
|
||||
During apply, the agent lints as it completes tasks. During archive, it closes with a summary.
|
||||
|
||||
## When config.yaml isn't enough
|
||||
|
||||
Config adds instructions on top of the standard workflow, but it can't change which artifacts exist or how they're structured. When you want that level of control, or rules aren't steering behavior consistently, [fork a schema](schemas.md).
|
||||
@@ -1,170 +0,0 @@
|
||||
# Schemas
|
||||
|
||||
> Change what OpenSpec produces: the artifacts, their order, and their templates.
|
||||
|
||||
A schema defines what a change proposal produces: which artifacts, in what order, from which templates. For example, [spec-driven](../reference/schemas/spec-driven/index.md), the default bundled schema, produces these four in roughly this order, each building on what came before:
|
||||
|
||||
```
|
||||
proposal → specs → design → tasks
|
||||
```
|
||||
|
||||
Fork a schema when you want these to be different documents, whether that means fewer of them, different names, or a different structure.
|
||||
|
||||
## Where schemas live
|
||||
|
||||
OpenSpec looks for a schema in three places, in order, and uses the first one it finds:
|
||||
|
||||
1. **Your project**: `openspec/schemas/`, committed with the repo so your whole team gets it.
|
||||
2. **Your machine**: `~/.local/share/openspec/schemas` on macOS and Linux (or under `$XDG_DATA_HOME` if you set it), or `%LOCALAPPDATA%\openspec\schemas` on Windows. Schemas here are available in every project you work in.
|
||||
3. **The package**: the built-ins, like `spec-driven`, ship inside openspec itself.
|
||||
|
||||
The same name can exist in more than one place, and the more specific location wins. `openspec schema which` shows which copy is in use:
|
||||
|
||||
```
|
||||
$ openspec schema which spec-driven
|
||||
Schema: spec-driven
|
||||
Source: project
|
||||
Path: /your-project/openspec/schemas/spec-driven
|
||||
|
||||
Shadows:
|
||||
package: .../openspec/schemas/spec-driven
|
||||
```
|
||||
|
||||
## What's in a schema
|
||||
|
||||
A schema is defined by a folder of plain files: one schema.yaml that declares the artifacts, and a template for each of them. Here's the built-in `spec-driven`:
|
||||
|
||||
```
|
||||
spec-driven/
|
||||
├── schema.yaml
|
||||
└── templates/
|
||||
├── proposal.md
|
||||
├── spec.md
|
||||
├── design.md
|
||||
└── tasks.md
|
||||
```
|
||||
|
||||
- **schema.yaml**: declares each artifact, the file it generates, the template it starts from, what it requires first, and the instruction the agent receives when creating it. Every field's contract is in [schema.yaml](../reference/schemas/schema-yaml.md).
|
||||
- **templates/**: one markdown skeleton per artifact, which the agent fills in.
|
||||
|
||||
Here's the tasks artifact's entry in schema.yaml, trimmed:
|
||||
|
||||
```yaml
|
||||
artifacts:
|
||||
- id: tasks
|
||||
generates: tasks.md
|
||||
description: Implementation checklist with trackable tasks
|
||||
template: tasks.md
|
||||
instruction: |
|
||||
...what the agent is told when creating tasks.md...
|
||||
requires:
|
||||
- specs
|
||||
- design
|
||||
```
|
||||
|
||||
The built-in schemas ship inside the openspec package, so you never edit them in place. You get your own copy by forking.
|
||||
|
||||
## Creating your own custom schema
|
||||
|
||||
There are two ways to get your own schema:
|
||||
|
||||
1. **Fork an existing schema** and edit your copy. Start here when an existing schema is close to what you want, because everything in it already works.
|
||||
2. **Start from scratch** when none of them fit, scaffolding an empty schema with `openspec schema init`.
|
||||
|
||||
### Fork an existing schema
|
||||
|
||||
1. Fork the schema you want to start from, running from your project root:
|
||||
|
||||
```console
|
||||
$ openspec schema fork spec-driven
|
||||
|
||||
Note: Schema commands are experimental and may change.
|
||||
✔ Forked 'spec-driven' to 'spec-driven-custom'
|
||||
|
||||
Source: .../openspec/schemas/spec-driven (package)
|
||||
Destination: /your-project/openspec/schemas/spec-driven-custom
|
||||
```
|
||||
|
||||
Pass a second argument to pick the name (`openspec schema fork spec-driven team-flow`). Names are kebab-case.
|
||||
|
||||
2. Edit the copy: schema.yaml and the templates. [Editing your fork](#editing-your-fork) covers what to change.
|
||||
|
||||
3. Validate it:
|
||||
|
||||
```bash
|
||||
openspec schema validate spec-driven-custom
|
||||
```
|
||||
|
||||
This is the one command that catches a broken schema (missing templates, bad YAML, dependency cycles) before you're in the middle of a change.
|
||||
|
||||
4. Point your project at it in openspec/config.yaml. This step is yours to do because fork leaves config.yaml untouched:
|
||||
|
||||
```yaml
|
||||
schema: spec-driven-custom
|
||||
```
|
||||
|
||||
5. New change proposals now follow your schema. Changes created earlier keep the schema they started with.
|
||||
|
||||
To replace the default everywhere without touching config.yaml, fork to the same name: `openspec schema fork spec-driven spec-driven`. Your project's copy then shadows the built-in, as [Where schemas live](#where-schemas-live) explains.
|
||||
|
||||
### Start from scratch
|
||||
|
||||
`openspec schema init` scaffolds a new schema instead of copying one:
|
||||
|
||||
```console
|
||||
$ openspec schema init lite --description "Lite flow" --artifacts proposal,tasks
|
||||
|
||||
✔ Created schema 'lite'
|
||||
Schema created at: /your-project/openspec/schemas/lite
|
||||
Artifacts: proposal, tasks
|
||||
```
|
||||
|
||||
The scaffold is bare. Artifacts come from the built-in four ids only, and the generated templates carry no instructions, so the agent gets less guidance until you write your own. From there the fork steps apply unchanged: validate it, then point config.yaml at it.
|
||||
|
||||
## Editing your fork
|
||||
|
||||
A fork has two kinds of files to edit:
|
||||
|
||||
- **templates/** change the skeleton of each document. Add a section to the tasks template and every new tasks.md starts with it. Keep the `#` title on the first line: the artifact inherits it, so every generated file opens as a titled document.
|
||||
- **schema.yaml** changes the workflow itself: which artifacts exist, what each one requires first, and the instruction the agent gets when creating it.
|
||||
|
||||
For example, to drop the design document for a leaner flow:
|
||||
|
||||
1. Delete the `design` entry from schema.yaml.
|
||||
2. Remove `design` from the `requires` list of `tasks`.
|
||||
3. Validate:
|
||||
|
||||
```console
|
||||
$ openspec schema validate spec-driven-custom
|
||||
|
||||
✓ Schema 'spec-driven-custom' is valid
|
||||
```
|
||||
|
||||
Skip step 2 and validate catches it:
|
||||
|
||||
```console
|
||||
✗ Schema 'spec-driven-custom' has errors:
|
||||
error: Invalid dependency reference in artifact 'tasks': 'design' does not exist
|
||||
```
|
||||
|
||||
Validate after every hand-edit. A broken schema otherwise surfaces in the middle of a change, when a workflow asks for a file that isn't there. Like config.yaml, schema edits reach the agent on the next run.
|
||||
|
||||
## A fork is a snapshot
|
||||
|
||||
`openspec update` refreshes the installed skills and commands, and it never touches `openspec/schemas/`. Your fork keeps working exactly as you left it, which also means it stops receiving improvements when the built-in schema evolves. To pick those up later, fork the built-in again under a new name and port the differences across.
|
||||
|
||||
## Sharing schemas
|
||||
|
||||
Sharing a schema means copying its folder.
|
||||
|
||||
- **With your team**: commit `openspec/schemas/` and everyone on the repo uses it.
|
||||
- **Across your projects**: put the folder in the user-level directory from [Where schemas live](#where-schemas-live).
|
||||
- **From the community**: the [community catalog](https://github.com/Fission-AI/OpenSpec/blob/main/docs/customization.md#community-schemas) lists shared schemas. Copy one into `openspec/schemas/<name>` and it works like your own.
|
||||
|
||||
We're working on a schema registry, public and private, so schemas can be installed by name instead of copied by hand.
|
||||
|
||||
### Use OpenSpec with Superpowers
|
||||
|
||||
The community-maintained [`superpowers-bridge`](https://github.com/JiangWay/openspec-schemas/tree/main/superpowers-bridge) schema connects OpenSpec artifacts to [Superpowers](https://github.com/obra/superpowers) execution skills. Follow the bridge's installation and compatibility notes before copying it into your project.
|
||||
|
||||
The bridge is released outside OpenSpec. OpenSpec does not test or version its Superpowers integration.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Customizing skills
|
||||
|
||||
> Edit the installed skill prompts directly: what you can change, and what update overwrites.
|
||||
|
||||
<!-- PARKED 2026-08-14 (README TODO): out of the page index, sidebar, and sync config.
|
||||
No good answer yet for edits surviving `openspec update`; the message map keeps
|
||||
"How should a user edit the installed skill prompts?" as a Gap. Skeleton below is
|
||||
the shape to revive. The honest page for the update-clobber caveat. -->
|
||||
|
||||
## What you can change
|
||||
|
||||
## What openspec update overwrites
|
||||
|
||||
## Supported alternatives
|
||||
@@ -1,11 +0,0 @@
|
||||
# Apply a change
|
||||
|
||||
> Run the plan: pacing, context windows, and picking up where you left off.
|
||||
|
||||
<!-- Skeleton: headings only. Promoted out of examples.md in review round 2. -->
|
||||
|
||||
## Task by task or all at once
|
||||
|
||||
## Managing the context window
|
||||
|
||||
## Continue and fast-forward
|
||||
@@ -1,11 +0,0 @@
|
||||
# Change course
|
||||
|
||||
> Revise a change in flight, or decide it's cleaner to start fresh.
|
||||
|
||||
<!-- Skeleton: headings only. -->
|
||||
|
||||
## Update or start fresh?
|
||||
|
||||
## Revising artifacts with openspec-update-change
|
||||
|
||||
## Advanced: revising mid-implementation
|
||||
@@ -1,9 +0,0 @@
|
||||
# Concepts
|
||||
|
||||
> What the two artifacts are, and how a change describes a diff against current specs.
|
||||
|
||||
<!-- Skeleton: headings only. Narrowed in review round 3 (dedup pass). The quickstart's archive file-steps absorbed the loop mechanics this page once planned to own, so the loop section is gone: the quickstart is the loop's only teacher, and core-vs-optional moved to customize/profiles.md. The fixed-vs-shapeable section was cut entirely (customize/overview.md dropped that framing in review, 2026-08-14: it opens straight on the options and never says what can't be changed). What remains is the one explanation this page owns: the artifacts. Specs absorbs "What a spec is"; Changes owns the delta concept: one worked delta block (ADDED/MODIFIED/REMOVED, from docs/concepts.md's core) showing a change as a diff against current specs; the file-format rules live in reference/schemas/spec-driven/index.md (Delta specs section). Disk paths appear inline with the concept that owns them (specs/ under Specs, changes/ under Changes), never as a layout section. Close with link lines: quickstart for the loop, customize/overview for the customization options. When to archive relative to a branch or PR stays in guides/teams.md. -->
|
||||
|
||||
## Specs: the system as built
|
||||
|
||||
## Changes: a folder of deltas
|
||||
@@ -1,16 +0,0 @@
|
||||
# Examples
|
||||
|
||||
> See what a good change looks like: real drafts, what review caught, and the fixes.
|
||||
|
||||
<!-- Skeleton: headings only. PARKED 2026-08-11: out of the README index and sync config. Contrived examples teach the wrong lesson for this product; the page waits for real archived changes from actual usage. Plan when revived: weak-vs-reviewed pairs (4) plus an archived-changes gallery. Earlier decisions still hold: slimmed in review round 2, purely example pairs; apply technique lives in guides/apply.md. -->
|
||||
|
||||
|
||||
## Adding a feature to an undocumented codebase
|
||||
|
||||
## Changing an API without breaking clients
|
||||
|
||||
## A behavior-preserving refactor
|
||||
|
||||
## A database migration with rollback
|
||||
|
||||
## Real archived changes
|
||||
@@ -1,13 +0,0 @@
|
||||
# Existing codebases
|
||||
|
||||
> Bring OpenSpec to a codebase with a lot of code and no specs: where to start, what to backfill, and how specs grow from there.
|
||||
|
||||
<!-- Skeleton: headings only. Rescoped 2026-08-11: the page is the adoption guide for legacy codebases (a lot of code, no specs), not just the backfill task; "Specs for existing code" is now one section. The opening section owns "you don't need specs first": the quickstart runs on an existing repo as-is, and specs accumulate through changes. Source: docs/existing-projects.md. When prose lands, reshape to the Guides skeleton (one-line what, quickstart link, 80% path, Advanced). -->
|
||||
|
||||
## Start with a change
|
||||
|
||||
## Specs for existing code
|
||||
|
||||
## Working from a PRD
|
||||
|
||||
## Organizing specs as they grow
|
||||
@@ -1,17 +0,0 @@
|
||||
# Explore an idea
|
||||
|
||||
> Think it through with the agent before you commit to a proposal.
|
||||
|
||||
<!-- Skeleton: headings only. -->
|
||||
|
||||
## When to explore first
|
||||
|
||||
## A real explore session
|
||||
|
||||
## From exploration to proposal
|
||||
|
||||
## Advanced
|
||||
|
||||
### Exploring mid-change
|
||||
|
||||
### Challenging a draft plan
|
||||
@@ -1,36 +0,0 @@
|
||||
# Review the plan
|
||||
|
||||
> The two-minute pass that catches wrong turns before they're code.
|
||||
|
||||
<!-- Partial draft: the plan-review sections are still headings only. -->
|
||||
|
||||
## The two-minute pass
|
||||
|
||||
## What good requirements look like
|
||||
|
||||
## What good scenarios look like
|
||||
|
||||
## Pushing back
|
||||
|
||||
## Advanced: verify after apply
|
||||
|
||||
Before archiving, check that the code does what the scenarios describe. The optional
|
||||
[verify skill](../reference/skills.md#openspec-verify-change) can help find gaps.
|
||||
|
||||
### Keep a record when checks are hard to track
|
||||
|
||||
Use the change's `tasks.md` or an existing test report. For each check, record:
|
||||
|
||||
- **Scenario**: the requirement and scenario it checks, with a link to that version of the spec.
|
||||
- **Check**: the test or manual check and what should happen.
|
||||
- **Result**: pass, fail, not run, or unknown. Link to the original run or dated observation.
|
||||
- **Tested version**: the code revision or build tested, and where it ran.
|
||||
|
||||
### Review the results
|
||||
|
||||
- **Open the source.** Confirm the result in the linked run or report. A checked task or an agent's summary alone does not prove the test passed.
|
||||
- **Look for gaps.** Check that every scenario has a result. A passing test on one device or environment does not cover another. Keep missing and failed checks visible.
|
||||
- **Check for changes.** Rerun checks affected by changes to the requirements, code, or environment. Unrelated documentation edits may leave earlier results valid.
|
||||
|
||||
**Archiving does not enforce these checks.** If passing results are required for
|
||||
release, enforce that in your CI or release process.
|
||||
@@ -1,17 +0,0 @@
|
||||
# Teams
|
||||
|
||||
> Run OpenSpec as a team: what to commit, how a change rides its PR, and when to archive.
|
||||
|
||||
<!-- Skeleton: headings only. Retitled from "Teams & parallel changes" 2026-08-11: the page's job is running OpenSpec in a team; parallel changes stays as the touching-one-spec section, and the general parallel-changes answer (solo included) remains an unowned gap in message-map.md. Expanded in review: this page owns the git/PR conventions (the quickstart's archive step shows the mechanism; this page owns timing). Source for all three new sections: docs/team-workflow.md. "A change is a branch and a PR": one branch carries the change folder and the code, so the PR shows the plan and the diff together. "Review in pull requests": reviewer order proposal → spec delta → code; approach disagreements land on the proposal, not across 300 lines of diff. "When to archive": after the PR merges (recommended, specs/ only advances with shipped work) vs inside the PR (simpler, noisier diff); pick one and be consistent. Proposal-first PRs (plan reviewed before implementation starts) go under Advanced. -->
|
||||
|
||||
## Checking openspec/ into git
|
||||
|
||||
## A change is a branch and a PR
|
||||
|
||||
## Review in pull requests
|
||||
|
||||
## When to archive
|
||||
|
||||
## Parallel changes touching one spec
|
||||
|
||||
## Advanced: conventions for larger teams
|
||||
@@ -1,24 +0,0 @@
|
||||
# FAQ
|
||||
|
||||
> Short answers to the questions that don't need a page.
|
||||
|
||||
<!-- WIP, on the todo list: this page is not written yet and is held back from the
|
||||
site (its section is commented out in website/docs.sync.config.mjs, 2026-08-21). The
|
||||
file stays so the structure and inbound links survive; re-list it in the sync config
|
||||
once the prose lands. -->
|
||||
|
||||
<!-- Every entry is a one-liner: a short answer or a router link to the page that owns the topic; how-to content never lives here (README's "FAQ is one-liners" rule). Update/uninstall moved to installation.md; the skills-missing fix and Getting help live in troubleshooting.md; the git question is a one-line yes routing to guides/teams.md, which owns the team conventions. Unfilled headings are skeletons. -->
|
||||
|
||||
## Should openspec/ be checked into git?
|
||||
|
||||
## What runs in the terminal, and what in chat?
|
||||
|
||||
## Does OpenSpec work with my tool?
|
||||
|
||||
If it has a row in the [support matrix](../reference/supported-tools.md), yes.
|
||||
Pick its id at init. If it isn't listed but reads the shared `.agents/skills/`
|
||||
folder, pick **Other / Universal** (`--tools agents`), covered by the support
|
||||
matrix's Other / Universal section. If neither, request it in the
|
||||
[OpenSpec repo](https://github.com/Fission-AI/OpenSpec/issues).
|
||||
|
||||
## Where did the old /openspec:* commands go?
|
||||
@@ -1,26 +0,0 @@
|
||||
# Migrating from the legacy workflow
|
||||
|
||||
> Moving from the legacy `/openspec:*` commands to OPSX.
|
||||
|
||||
<!-- WIP, on the todo list: this page is not written yet and is held back from the
|
||||
site (its section is commented out in website/docs.sync.config.mjs, 2026-08-21). The
|
||||
file stays so the structure and inbound links survive; re-list it in the sync config
|
||||
once the prose lands. -->
|
||||
|
||||
<!-- Skeleton: headings only. -->
|
||||
|
||||
## What changed and why
|
||||
|
||||
## Command mapping
|
||||
|
||||
## Migrating a project
|
||||
|
||||
### Back up custom content before cleanup
|
||||
|
||||
Files listed under **Files to remove** are deleted entirely. Back up any custom content before accepting cleanup.
|
||||
|
||||
- **`openspec/AGENTS.md`**: detected by existence alone; cleanup does not inspect its contents.
|
||||
- **Root-level `AGENTS.md`, `CLAUDE.md`, and other config files**: cleanup removes OpenSpec marker blocks and preserves content outside those blocks.
|
||||
- **Legacy command directories**: cleanup preserves files it does not recognize as generated commands.
|
||||
|
||||
## Behavior differences
|
||||
@@ -1,20 +0,0 @@
|
||||
# Troubleshooting
|
||||
|
||||
> When OpenSpec doesn't do what you expected: symptoms and their fixes.
|
||||
|
||||
<!-- WIP, on the todo list: this page is not written yet and is held back from the
|
||||
site (its section is commented out in website/docs.sync.config.mjs, 2026-08-21). The
|
||||
file stays so the structure and inbound links survive; re-list it in the sync config
|
||||
once the prose lands. -->
|
||||
|
||||
<!-- Skeleton: headings only. Canonical home for symptom-to-fix, including the skills-missing checklist. -->
|
||||
|
||||
## Skills don't appear in chat
|
||||
|
||||
## The agent ignores the workflow
|
||||
|
||||
## Validation failures
|
||||
|
||||
## Sync and archive issues
|
||||
|
||||
## Getting help
|
||||
@@ -1,65 +0,0 @@
|
||||
# Message map: the questions the docs must answer, and where
|
||||
|
||||
The [README](README.md) index runs page to job. This file runs the other way: one flat
|
||||
list of the questions we need the docs to answer, each pointing at the group and page
|
||||
that owns the answer. Status says whether that answer exists yet: **Answered** (the
|
||||
owning page's prose has landed), **Skeleton** (owner assigned, page is headings only),
|
||||
**Gap** (no owner), **Off-site** (answered outside these docs by decision). Flip a row
|
||||
to Answered when its page's prose lands. Rows follow the sidebar order of the owning
|
||||
page; gaps sit where their proposed home would fall, and off-site rows go last. Keep
|
||||
rows coarse (question to page, never sentence to section) so this stays cheap to
|
||||
maintain.
|
||||
|
||||
| Question | Answered by | Status |
|
||||
|---|---|---|
|
||||
| How do we pitch the core idea (keeping larger features on track and aligned, not just a plan before code)? | [Start › Overview](start/overview.md) (emptied 2026-08-21 for a from-scratch rewrite and pulled from the site until then; brief in Notes.md) | Skeleton |
|
||||
| How does someone decide OpenSpec is worth their time? | [Start › Overview](start/overview.md) (emptied 2026-08-21, see row above) | Skeleton |
|
||||
| How should a user install the CLI, update it, uninstall it? | [Start › Installation](start/installation.md) | Answered |
|
||||
| How can a user hand install and setup to their AI assistant? | [Start › Installation](start/installation.md), the install.md prompt | Answered |
|
||||
| How should a user add OpenSpec to their repo? | [Start › Set up your project](start/setup.md) | Answered |
|
||||
| How do the workflows get into a user's tool, and why skills and commands both? | [Start › Set up your project](start/setup.md) | Answered |
|
||||
| How do we teach the loop: propose, review, apply, archive? | [Start › Quickstart](start/quickstart.md) | Answered |
|
||||
| How should a user run their first change end to end? | [Start › Quickstart](start/quickstart.md) | Answered |
|
||||
| How does a user know which prompts go in the AI chat and which commands in the terminal? | [Start › Quickstart](start/quickstart.md) inline with each step, then [Help › FAQ](help/faq.md) | Answered |
|
||||
| How do we explain what specs and changes are? | [Guides › Understanding › Concepts](guides/concepts.md) | Skeleton |
|
||||
| How should a user think through an idea before proposing? | [Guides › Using › Explore an idea](guides/explore.md) | Skeleton |
|
||||
| How should a user review a plan? | [Guides › Using › Review the plan](guides/review-the-plan.md) | Skeleton |
|
||||
| How does a user check the implementation matches the plan before archiving? | [Guides › Using › Review the plan](guides/review-the-plan.md), the verify pass | Skeleton |
|
||||
| How should a user run a plan across sessions and context limits? | [Guides › Using › Apply a change](guides/apply.md) | Skeleton |
|
||||
| How should a user pace the plan: draft everything at once, or artifact by artifact? | [Guides › Using › Apply a change](guides/apply.md), continue and fast-forward | Skeleton |
|
||||
| How do we explain the standard flow (propose drafts every artifact in one step) vs the iterative flow (new creates the change, continue drafts the next artifact, fast-forward catches up)? | [Start › Quickstart](start/quickstart.md) teaches only the standard flow; [Guides › Using › Apply a change](guides/apply.md) owns pacing once a change exists; [Reference › Skills](reference/skills.md) holds the new/continue/ff contracts; [Customize › Profiles](customize/profiles.md) covers installing them; a [README](README.md) TODO proposes a Using guide | Gap |
|
||||
| How should a user change direction mid-change, or bail out? | [Guides › Using › Change course](guides/change-course.md) | Skeleton |
|
||||
| How should a team run OpenSpec together? | [Guides › Adopting › Teams](guides/teams.md) | Skeleton |
|
||||
| How should a user work on several changes at once? | [Guides › Adopting › Teams](guides/teams.md) owns the touching-one-spec collision case; the general answer (solo included, not just teams) has no owner yet | Gap |
|
||||
| How should a user handle git across the loop: branching, commits, PRs? | Only archive-vs-PR ordering is owned, by [Guides › Adopting › Teams](guides/teams.md); README TODO proposes a guide | Gap |
|
||||
| What does a good change look like? | `guides/examples.md` is parked until real archived changes can fill it (README TODO); no published owner | Gap |
|
||||
| How should a user adopt OpenSpec on code that already exists? | [Guides › Adopting › Existing codebases](guides/existing-codebases.md) | Skeleton |
|
||||
| How should a user run OpenSpec in a monorepo? | Legacy `docs/existing-projects.md` owned it (one `openspec/` at the repo root, domains map to packages); likely home is [Guides › Adopting › Existing codebases](guides/existing-codebases.md), with [Multi-repo › Stores](multi-repo/stores.md) taking packages treated as separate repos | Gap |
|
||||
| How do we explain what's customizable in OpenSpec? | [Customize › Overview](customize/overview.md) | Answered |
|
||||
| How does a user pick the right customization level, and when should they escalate from config to schemas? | [Customize › Overview](customize/overview.md), the "Not sure which to use?" section | Answered |
|
||||
| How should a user choose which workflows are installed? | [Customize › Profiles](customize/profiles.md) | Answered |
|
||||
| How does a user switch to skills only or commands only? | [Customize › Profiles](customize/profiles.md), Delivery section; [Start › Set up your project](start/setup.md) owns why both forms exist | Answered |
|
||||
| How does a user make the workflows plan changes their way: context, rules, and guidance? | [Customize › Project configuration](customize/project-config.md) | Answered |
|
||||
| How does a user get artifacts written in a language other than English? | [Customize › Project configuration](customize/project-config.md), the context section's "Another language" note | Answered |
|
||||
| How should a user change what OpenSpec produces? | [Customize › Schemas](customize/schemas.md), with the fork walkthrough in "Creating your own custom schema" | Answered |
|
||||
| How should a user edit the installed skill prompts? | No owner: `customize/skills.md` is parked (README TODO) until there's a good answer to `openspec update` overwriting edits | Gap |
|
||||
| How should a user run OpenSpec across multiple repos? | [Multi-repo › Stores](multi-repo/stores.md); [Start › Set up your project](start/setup.md) routes there from "Pick where OpenSpec lives" | Answered |
|
||||
| How should a user plan a change that spans repos? | [Multi-repo › Stores](multi-repo/stores.md) | Answered |
|
||||
| What does each skill do, and when should a user reach for it? | [Reference › Skills](reference/skills.md) | Answered |
|
||||
| Where does a user look up a terminal command? | [Reference › CLI](reference/cli.md) | Answered |
|
||||
| How does a user learn what telemetry is collected, and opt out? | [Reference › Configuration › Environment variables](reference/configuration/environment-variables.md) owns the facts (was a README-TODO gap); [Help › FAQ](help/faq.md) routes searchers there | Skeleton |
|
||||
| Where does a user look up an artifact's format, or a schema definition's fields? | [Reference › Schemas](reference/schemas/index.md) | Answered |
|
||||
| Where does a user look up a setting or a file that changes OpenSpec's behavior? | [Reference › Configuration](reference/configuration/index.md) | Answered |
|
||||
| Which openspec/ tree does a command operate on? | [Reference › Configuration › Stores](reference/configuration/stores.md) owns the whole resolution ladder, including the everyday case (nearest openspec/ wins); readers reach it from the Stores row of the [Configuration overview](reference/configuration/index.md) map | Skeleton |
|
||||
| How should a user run a change with no spec impact, or retire a capability outright? | [Reference › Configuration › Change metadata](reference/configuration/change-metadata.md) owns the `skip_specs` and `retire_capabilities` contracts; [Reference › Schemas › spec-driven](reference/schemas/spec-driven/index.md), Delta specs section, owns their effect on deltas and archive; neither half has a guide owner | Gap |
|
||||
| What is an initiative, and how does a change join one? | No owner: the `initiative` field's contract sits on [Reference › Configuration › Change metadata](reference/configuration/change-metadata.md), but no page teaches initiatives (multi-repo has only Stores) | Gap |
|
||||
| What is a workset, and how does a user open one in their editor? | [Multi-repo › Worksets](multi-repo/worksets.md); the `openers` field's contract stays on [Reference › Configuration › CLI settings](reference/configuration/config-json.md) | Answered |
|
||||
| Which AI tools work, and what's each one's syntax? | [Reference › Supported tools](reference/supported-tools.md) | Answered |
|
||||
| My tool isn't listed, can I still use OpenSpec? | [Help › FAQ](help/faq.md) routes: the shared `.agents` target or an issue; [Reference › Supported tools](reference/supported-tools.md), Per-tool notes, holds the shared target's contract | Answered |
|
||||
| Where does a user look up a term? | [Reference › Glossary](reference/glossary.md) | Answered |
|
||||
| How is OPSX built? | [Reference › Architecture](reference/architecture/index.md) | Skeleton |
|
||||
| How do we explain that the workflow is fluid, actions not phases? | [Start › Overview](start/overview.md) will carry the pitch once rewritten (the "shared map, not a plan up front" framing was in the cleared skeleton); [sources.md](sources.md) routes opsx.md's explanation to [Guides › Understanding › Concepts](guides/concepts.md), but that page narrowed to artifacts only in review round 3; likely home is Guides › Understanding, widening [Concepts](guides/concepts.md) or adding a sibling page, with [Reference › Architecture › Design decisions](reference/architecture/design-decisions.md) keeping the why | Gap |
|
||||
| What should a user do when OpenSpec doesn't do what they expected? | [Help › Troubleshooting](help/troubleshooting.md), then [Help › FAQ](help/faq.md) | Skeleton |
|
||||
| Where does a user go for help or to report a bug? | [Help › Troubleshooting](help/troubleshooting.md), Getting help | Skeleton |
|
||||
| How should a user move off the legacy `/openspec:*` commands? | [Help › Migration](help/legacy/migration.md) | Skeleton |
|
||||
| How does a script or CI drive the CLI programmatically? | Off-site by decision: repo-side contributor docs, per [sources.md](sources.md) | Off-site |
|
||||
@@ -1,358 +0,0 @@
|
||||
# Stores (beta)
|
||||
|
||||
> Plan changes that span repositories: one store, many repos.
|
||||
|
||||
OpenSpec normally lives inside one repo: an `openspec/` folder next to the code it plans. A store moves that folder into a repository of its own, and several code repos can share it.
|
||||
|
||||
After a one-time setup on each machine, commands like `status`, `new change`, and `archive` can work in the store from any directory.
|
||||
|
||||
```
|
||||
team-plans (a store: OpenSpec in its own repo)
|
||||
├── .openspec-store/store.yaml the store's name
|
||||
└── openspec/
|
||||
├── specs/
|
||||
└── changes/
|
||||
▲
|
||||
│ set up once on each machine,
|
||||
│ shared by pushing and cloning like any repo
|
||||
┌─────────────┼─────────────┐
|
||||
│ │ │
|
||||
web-app api-server mobile-app
|
||||
(code repo) (code repo) (code repo)
|
||||
```
|
||||
|
||||
You share a store with git, the same way you share code: commit, push, pull, and review it yourself. Specs and changes get branches and pull requests the same way code does.
|
||||
|
||||
## When you need one
|
||||
|
||||
Two common reasons to use a store:
|
||||
|
||||
- **Frontend and backend in separate repos**: one feature touches both, and the plan needs a single home instead of two halves.
|
||||
|
||||
```
|
||||
shop-plans (store)
|
||||
└── openspec/changes/add-discounts/ one plan for the feature
|
||||
▲
|
||||
┌─────────┴─────────┐
|
||||
│ │
|
||||
storefront api
|
||||
(frontend repo) (backend repo)
|
||||
```
|
||||
|
||||
- **One product, several client repos**: Android, iOS, and web ship from their own repos but share one expected behavior. A spec describes behavior, not implementation, so one spec serves all three.
|
||||
|
||||
```
|
||||
product-specs (store)
|
||||
└── openspec/specs/checkout/spec.md the expected behavior
|
||||
▲
|
||||
┌─────────────┼─────────────┐
|
||||
│ │ │
|
||||
android-app ios-app web-app
|
||||
(code repo) (code repo) (code repo)
|
||||
```
|
||||
|
||||
You can have more than one store, though we recommend keeping the count low.
|
||||
|
||||
## Set up a store
|
||||
|
||||
One person creates the store, then everyone else joins it.
|
||||
|
||||
1. **Create the store** (one person, once per team). Run `openspec store setup` and answer the prompts:
|
||||
|
||||
```bash
|
||||
# run from anywhere; it asks what to create and where
|
||||
openspec store setup
|
||||
```
|
||||
|
||||
It asks three questions:
|
||||
|
||||
- **Store name**: `team-plans`
|
||||
- **Where should this store live?**: pre-filled with `~/openspec/<name>`, press Enter to accept it or type another path
|
||||
- **Create this store?**: shows what it's about to make, answer `Yes`
|
||||
|
||||
Then it reports what it created:
|
||||
|
||||
```yaml
|
||||
Store ready: team-plans
|
||||
Location: ~/openspec/team-plans
|
||||
OpenSpec root: ready
|
||||
Registry: registered
|
||||
|
||||
Next: run normal OpenSpec commands against this store, for example:
|
||||
openspec new change <change-id> --store team-plans
|
||||
Share this store by committing and pushing it like any Git repo.
|
||||
```
|
||||
|
||||
2. **Push it to your git host.** Create an empty `team-plans` repo on your host first. Setup doesn't add a git remote, so connect the store to that repo, then push:
|
||||
|
||||
```bash
|
||||
# connect the store to the empty repo on your git host
|
||||
cd ~/openspec/team-plans
|
||||
git remote add origin git@github.com:acme/team-plans.git
|
||||
|
||||
# publish it
|
||||
git push -u origin main
|
||||
```
|
||||
|
||||
3. **Join the store** (every teammate, once per machine):
|
||||
|
||||
```bash
|
||||
# get the store onto your machine
|
||||
git clone git@github.com:acme/team-plans.git ~/openspec/team-plans
|
||||
|
||||
# tell OpenSpec where it lives
|
||||
openspec store register ~/openspec/team-plans
|
||||
```
|
||||
|
||||
```yaml
|
||||
Store registered: team-plans
|
||||
Location: /Users/you/openspec/team-plans
|
||||
OpenSpec root: ready
|
||||
Registry: registered
|
||||
```
|
||||
|
||||
Registering tells your machine where this store lives. The store's name is already committed inside it, in `.openspec-store/store.yaml`. Setup registered the creator's copy, so only cloned copies need this step.
|
||||
|
||||
4. **Confirm it worked**, from any directory:
|
||||
|
||||
```bash
|
||||
# any OpenSpec command reaches the store by name
|
||||
openspec status --store team-plans
|
||||
```
|
||||
|
||||
```yaml
|
||||
Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
|
||||
No active changes. Create one with: openspec new change <name> --store team-plans
|
||||
```
|
||||
|
||||
## Types of setups
|
||||
|
||||
OpenSpec has three setups. The rest of this page uses these names:
|
||||
|
||||
- **repo-local**: OpenSpec inside your repo, no store. The default.
|
||||
- **store-only**: your repo keeps no specs or changes of its own. Everything lives in the store.
|
||||
- **store-optional**: your project has its own `openspec/` folder and also reaches a store when you ask.
|
||||
|
||||
### The default: OpenSpec inside your repo (`repo-local`)
|
||||
|
||||
`openspec init` puts an `openspec/` folder next to your code, and that repo's specs and changes live there. No store is involved. This is the setup [Set up your project](../start/setup.md) teaches, and most projects never need another.
|
||||
|
||||
```
|
||||
web-app (code repo)
|
||||
└── openspec/
|
||||
├── specs/
|
||||
└── changes/
|
||||
```
|
||||
|
||||
### OpenSpec outside your repo, in a store (`store-only`)
|
||||
|
||||
The repo keeps no specs or changes of its own. Everything it plans lives in the store, and one line in the repo's config connects the two.
|
||||
|
||||
Common when one team builds all the repos and plans in one place. The [examples above](#when-you-need-one) all have this shape.
|
||||
|
||||
```
|
||||
team-plans (store)
|
||||
└── openspec/
|
||||
├── specs/ the repo's specs live here
|
||||
└── changes/ its changes too
|
||||
▲
|
||||
│ store: team-plans (the connecting line)
|
||||
web-app (code repo)
|
||||
└── openspec/
|
||||
└── config.yaml nothing else
|
||||
```
|
||||
|
||||
### OpenSpec in your repo and in a store (`store-optional`)
|
||||
|
||||
The repo stays repo-local for its own work, while the store holds the shared specs and changes. Inside the repo, OpenSpec uses your project's `openspec/` folder, and reaches the store only when you pass `--store`.
|
||||
|
||||
Common when a repo used OpenSpec before the store existed, or when a mostly independent repo only occasionally touches shared work.
|
||||
|
||||
```
|
||||
team-plans (store)
|
||||
└── openspec/ the shared specs and changes
|
||||
▲
|
||||
│ only when you pass --store team-plans
|
||||
web-app (code repo)
|
||||
└── openspec/ this repo's own
|
||||
├── config.yaml
|
||||
├── specs/
|
||||
└── changes/
|
||||
```
|
||||
|
||||
A repo can start repo-local and move its specs and changes into the store later. [Move a repo's specs and changes into the store](#move-a-repos-specs-and-changes-into-the-store) shows how.
|
||||
|
||||
## Where artifacts get created when using stores
|
||||
|
||||
When you use a store, OpenSpec also has to decide where the artifacts get created. It depends on your setup:
|
||||
|
||||
- **store-only** (your project only writes to the store): every artifact is created in the store. The `store:` line below records that.
|
||||
- **store-optional** (your project has its own `openspec/` folder and also uses a store): artifacts are created in your project, unless you name the store in your request or pass `--store` for that change. Your agent then carries the flag through the rest of the workflow.
|
||||
|
||||
OpenSpec writes artifacts to one of two places: your project's `openspec/` folder, or the store's. It picks in this order, and the first option that applies wins:
|
||||
|
||||
1. **`--store <id>` on a command.** Always wins, from any directory.
|
||||
2. **Your project's `openspec/` folder.** If your project has its own `specs/` or `changes/` folders, OpenSpec uses them.
|
||||
3. **The `store:` line in your project.** How a store-only project records its store.
|
||||
4. **`defaultStore` on your machine.** The fallback when none of the above applies.
|
||||
|
||||
When OpenSpec selects a store, it prints `Using OpenSpec root: ...` before the command output.
|
||||
|
||||
### The `store:` line (store-only projects)
|
||||
|
||||
Add one line to your project's `openspec/config.yaml`:
|
||||
|
||||
```yaml
|
||||
# web-app/openspec/config.yaml
|
||||
store: team-plans
|
||||
```
|
||||
|
||||
Everything you or your agent run inside your project now uses the store, with no flag to type:
|
||||
|
||||
```bash
|
||||
# inside web-app, connected
|
||||
openspec status
|
||||
```
|
||||
|
||||
```yaml
|
||||
Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
|
||||
No active changes. Create one with: openspec new change <name> --store team-plans
|
||||
```
|
||||
|
||||
- **Without the line**: run a plain command in a store-only project and OpenSpec stops with an error listing your registered stores.
|
||||
- **Commit it**: teammates who clone your project get the line too. They still need the store registered on their machine ([step 3 of Set up a store](#set-up-a-store)), or OpenSpec errors and tells them to register it.
|
||||
- **Next to real folders**: if your project also has `specs/` or `changes/` folders, OpenSpec uses those and ignores the line, with a warning.
|
||||
|
||||
### Install integrations in a store-only repo
|
||||
|
||||
Run init from the code repo's root to install AI tool integration files without moving planning back into that repo:
|
||||
|
||||
```bash
|
||||
# inside web-app, at the repository root
|
||||
openspec init --tools claude
|
||||
```
|
||||
|
||||
- **Integration files**: written in the code repo.
|
||||
- **`openspec/config.yaml`**: preserved byte-for-byte, including the `store:` line.
|
||||
- **`openspec/specs/` and `openspec/changes/`**: not created in the code repo.
|
||||
|
||||
OpenSpec refuses this command from a subdirectory of the code repo. Run it from the repository root.
|
||||
|
||||
OpenSpec also refuses `--language` here because the language belongs in the external store's config. Run init in the store root or edit that config directly.
|
||||
|
||||
### `defaultStore` on your machine
|
||||
|
||||
Set it once if every project you work in uses the same store. OpenSpec falls back to it when it finds no flag, no local `openspec/` folder, and no `store:` line:
|
||||
|
||||
```bash
|
||||
# use team-plans whenever nothing else names a store
|
||||
openspec config set defaultStore team-plans
|
||||
|
||||
# undo it
|
||||
openspec config unset defaultStore
|
||||
```
|
||||
|
||||
**Commands that stay local.** `init`, `update`, `templates`, `schemas`, and the `openspec schema` subcommands act on the current directory only and take no `--store`.
|
||||
|
||||
## Move a repo's specs and changes into the store
|
||||
|
||||
To take a repo from repo-local to store-only:
|
||||
|
||||
1. Move everything in the repo's `openspec/specs/` and `openspec/changes/` into the same folders in the store.
|
||||
2. Delete the now-empty folders, so the repo's `openspec/` folder holds only `config.yaml`.
|
||||
3. Add the `store:` line to that `config.yaml`.
|
||||
|
||||
`openspec status` inside the repo now starts with `Using OpenSpec root: team-plans`.
|
||||
|
||||
## Work in the store
|
||||
|
||||
The workflows don't change, for you or for your agent. Propose, apply, and archive run the way they always do. The only difference is where the artifacts get created, and [the section above](#where-artifacts-get-created-when-using-stores) covers that.
|
||||
|
||||
Create a change from inside a store-only repo and it lands in the store:
|
||||
|
||||
```bash
|
||||
# inside web-app; the store: line routes this to team-plans
|
||||
openspec new change add-login
|
||||
```
|
||||
|
||||
```yaml
|
||||
Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
|
||||
Created change 'add-login' at /Users/you/openspec/team-plans/openspec/changes/add-login/
|
||||
Schema: spec-driven
|
||||
Next: openspec status --change add-login --store team-plans
|
||||
```
|
||||
|
||||
- **Where it went**: into the store repo, not next to your code.
|
||||
- **Sharing it**: the change exists only in your checkout until you commit and push the store repo. Teammates see it when they pull. The same goes for every artifact the workflows write.
|
||||
- **Paths in the docs**: wherever the docs show an `openspec/` path, in a store setup that folder is the store's.
|
||||
|
||||
When artifacts get created somewhere you didn't expect, `openspec doctor` checks your setup without changing anything and prints a fix for each finding:
|
||||
|
||||
```bash
|
||||
# check the current root and its stores
|
||||
openspec doctor
|
||||
```
|
||||
|
||||
```yaml
|
||||
Doctor
|
||||
|
||||
Root
|
||||
Location: /Users/you/openspec/team-plans
|
||||
OpenSpec root: ok
|
||||
Store: team-plans (metadata ok)
|
||||
|
||||
References
|
||||
(none declared)
|
||||
```
|
||||
|
||||
`openspec context` lists the root and stores your current directory works with, when you want the same picture without the checks.
|
||||
|
||||
To open the store and a repo in one editor window, so your agent can read both, see [Worksets (beta)](worksets.md).
|
||||
|
||||
## Read specs from another store
|
||||
|
||||
Your repo can keep its own `openspec/` folder and still let your agent read another store's specs. Declare that store under `references:` in the repo's `openspec/config.yaml`:
|
||||
|
||||
```yaml
|
||||
# api-server/openspec/config.yaml
|
||||
references:
|
||||
- team-plans
|
||||
```
|
||||
|
||||
References are read-only. Your work stays in your repo, and the reference only changes what your agent is told.
|
||||
|
||||
When a workflow creates an artifact, its instructions gain an index of the referenced store's specs, each with a one-line summary and the exact command to fetch it:
|
||||
|
||||
```xml
|
||||
<referenced_stores>
|
||||
<!-- Read-only upstream context. Fetch what you need; cite what you use. -->
|
||||
Store team-plans (/Users/you/openspec/team-plans):
|
||||
- payments: Rules for charging and refunding customers.
|
||||
Fetch: openspec show <spec-id> --type spec --store team-plans
|
||||
</referenced_stores>
|
||||
```
|
||||
|
||||
A reference can also carry the store's clone URL, for machines that don't have that store yet:
|
||||
|
||||
```yaml
|
||||
references:
|
||||
- team-plans
|
||||
- { id: design-system, remote: "git@github.com:acme/design-system.git" }
|
||||
```
|
||||
|
||||
With the URL declared, `openspec doctor` turns a missing store into a pasteable fix:
|
||||
|
||||
```yaml
|
||||
# output wrapped to fit
|
||||
References
|
||||
- team-plans: ok (/Users/you/openspec/team-plans)
|
||||
- design-system: Referenced store 'design-system' is not registered on this machine.
|
||||
Fix: git clone -- git@github.com:acme/design-system.git '/Users/you/openspec/design-system' &&
|
||||
openspec store register '/Users/you/openspec/design-system' --id design-system
|
||||
```
|
||||
|
||||
## Beta limits
|
||||
|
||||
- **The shape may change**: command names, flags, and file formats can change between releases. Re-read this page after upgrading.
|
||||
- **No sync, by design**: OpenSpec never clones, pulls, or pushes. A stale checkout shows stale specs until you pull, and references are read from whatever is on disk.
|
||||
- **One checkout per store name**: registering a second folder under a name that's already registered fails, with a hint to run `openspec store unregister` first.
|
||||
@@ -1,62 +0,0 @@
|
||||
# Worksets (beta)
|
||||
|
||||
> Open the store and the repos that use it in one editor window, so your agent sees both.
|
||||
|
||||
With a store, the context your agent needs is split across folders. The specs and changes live in the store, and the code lives in each repo. An agent started in one repo can read and grep that repo and nothing else, so it works from half the picture.
|
||||
|
||||
Worksets are the utility OpenSpec provides for this. A workset is a saved, named list of folders you open together. This page assumes the store is already set up and registered on your machine. [Stores (beta)](stores.md) covers that.
|
||||
|
||||
## How it works
|
||||
|
||||
- **What it is**: a named list of folders, saved on your machine only. Nothing is written into the member folders, and nothing is committed.
|
||||
- **What opening does**: OpenSpec generates a `.code-workspace` file from the list and launches your editor on it. Every member folder sits in one window.
|
||||
- **What you get**: your editor's search, and any agent you run inside that window, can read every member folder. The agent can grep the store's specs and the repo's code in one session.
|
||||
- **What it doesn't change**: which `openspec/` folder a command uses. That still follows [Where artifacts get created](stores.md#where-artifacts-get-created-when-using-stores).
|
||||
|
||||
## Set it up
|
||||
|
||||
1. **Save the workset** (once per machine). List the repo and the store as members, and the tool to open them with:
|
||||
|
||||
```bash
|
||||
# save a named list of folders you open together
|
||||
openspec workset create platform \
|
||||
--member ~/src/web-app \
|
||||
--member ~/openspec/team-plans \
|
||||
--tool code
|
||||
```
|
||||
|
||||
```yaml
|
||||
Saved workset 'platform' (2 members) to your machine.
|
||||
Open it any time with: openspec workset open platform
|
||||
```
|
||||
|
||||
2. **Open it** whenever you start work:
|
||||
|
||||
```bash
|
||||
# open every member in one VS Code window
|
||||
openspec workset open platform
|
||||
```
|
||||
|
||||
`openspec workset list` shows what you saved, and `openspec workset remove <name>` deletes a workset without touching the member folders:
|
||||
|
||||
```yaml
|
||||
platform (opens in VS Code)
|
||||
web-app /Users/you/src/web-app
|
||||
team-plans /Users/you/openspec/team-plans
|
||||
```
|
||||
|
||||
## Use it: one change, two folders
|
||||
|
||||
Say the `add-login` change lives in the `team-plans` store, and the code for it lives in `web-app`. Open the `platform` workset and ask your agent to implement the change. In that one session it can:
|
||||
|
||||
- read `team-plans/openspec/changes/add-login/` and the specs next to it
|
||||
- edit the code in `web-app/`
|
||||
- run `openspec` commands from inside `web-app`
|
||||
|
||||
Without the workset, the agent only sees whichever folder it was started in.
|
||||
|
||||
## Tools out of the box
|
||||
|
||||
- **VS Code** (`--tool code`) and **Cursor** (`--tool cursor`): built in. Each opens one window with every member folder.
|
||||
- **Claude Code and Codex in the terminal**: temporarily disabled as workset openers while that flow is reworked. `--tool claude` or `--tool codex` stops with an error that says so and points you to VS Code or Cursor.
|
||||
- **Other editors**: add them under the `openers` key in [CLI settings (config.json)](../reference/configuration/config-json.md).
|
||||
@@ -1,11 +0,0 @@
|
||||
# Design decisions
|
||||
|
||||
> Why OPSX works the way it does.
|
||||
|
||||
<!-- WIP, on the todo list: this page is not written yet and is held back from the
|
||||
site (its entry is commented out in website/docs.sync.config.mjs, 2026-08-21). The file
|
||||
stays so the structure and inbound links survive; re-list it in the sync config once the
|
||||
prose lands. -->
|
||||
|
||||
<!-- Skeleton: heading only. Split from reference/architecture.md on 2026-08-10.
|
||||
message-map.md routes "the workflow is fluid, actions not phases" here. -->
|
||||
@@ -1,19 +0,0 @@
|
||||
# Overview
|
||||
|
||||
> How OPSX is built: internals for the curious.
|
||||
|
||||
<!-- WIP, on the todo list: this page is not written yet and is held back from the
|
||||
site (its entry is commented out in website/docs.sync.config.mjs, 2026-08-21). The file
|
||||
stays so the structure and inbound links survive; re-list it in the sync config once the
|
||||
prose lands. -->
|
||||
|
||||
<!-- Skeleton: headings only. Moved out of Legacy in review round 2 (it documents
|
||||
the current system); split from a single architecture.md page into this folder
|
||||
on 2026-08-10. -->
|
||||
|
||||
The pages in this section:
|
||||
|
||||
- [Workflow runs](workflow-runs.md): how a workflow run executes, from invocation to written artifacts.
|
||||
- [Design decisions](design-decisions.md): why OPSX works the way it does.
|
||||
|
||||
## How the pieces fit
|
||||
@@ -1,10 +0,0 @@
|
||||
# Workflow runs
|
||||
|
||||
> How a workflow run executes, from invocation to written artifacts.
|
||||
|
||||
<!-- WIP, on the todo list: this page is not written yet and is held back from the
|
||||
site (its entry is commented out in website/docs.sync.config.mjs, 2026-08-21). The file
|
||||
stays so the structure and inbound links survive; re-list it in the sync config once the
|
||||
prose lands. -->
|
||||
|
||||
<!-- Skeleton: heading only. Split from reference/architecture.md on 2026-08-10. -->
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,65 +0,0 @@
|
||||
# Change metadata (.openspec.yaml)
|
||||
|
||||
> The supported fields and validation rules for the metadata stored with each change.
|
||||
|
||||
## Location
|
||||
|
||||
Each change keeps its metadata at `openspec/changes/<change-name>/.openspec.yaml`, next to its artifacts. Creating a change writes the file with `schema` and `created` filled in.
|
||||
|
||||
## Fields
|
||||
|
||||
| Key | Type | Required | Effect |
|
||||
| --- | --- | --- | --- |
|
||||
| `schema` | string | Yes | The workflow schema this change follows |
|
||||
| `created` | string, YYYY-MM-DD | No | Records the date the change was created |
|
||||
| `goal` | string | No | Records what the change sets out to do |
|
||||
| `affected_areas` | list of strings | No | Records the areas the change expects to touch |
|
||||
| `initiative` | map: `store` and `id` | No | Records the initiative this change belongs to |
|
||||
| `skip_specs` | boolean | No | Declares the change makes no spec deltas, so zero deltas validate |
|
||||
| `retire_capabilities` | boolean | No | Authorizes archive to delete a capability this change empties |
|
||||
|
||||
### schema
|
||||
|
||||
The workflow schema this change follows. It is set when the change is created and wins over the project config, so a change keeps its schema even if `openspec/config.yaml` changes afterwards. Run [`openspec schemas`](../cli.md#openspec-schemas) to list the available schema names.
|
||||
|
||||
### initiative
|
||||
|
||||
The initiative this change belongs to, as a store id and an initiative id, both kebab-case:
|
||||
|
||||
```yaml
|
||||
initiative:
|
||||
store: platform-specs
|
||||
id: unify-billing
|
||||
```
|
||||
|
||||
Keys other than `store` and `id` are rejected. No command reads the link today.
|
||||
|
||||
### skip_specs
|
||||
|
||||
Declares the change intentionally makes no spec deltas: a pure refactor, tooling, or docs change. With it set, validation accepts zero deltas, and artifacts that would generate spec files count as complete. Setting it while spec files exist under specs/ is a validation error.
|
||||
|
||||
### retire_capabilities
|
||||
|
||||
Authorizes archive to retire a capability. When this change's REMOVED deltas take away the last requirement a capability has, archive deletes that capability's main spec instead of stopping. The flag exists because the deletion is only recoverable from git, so it stays the author's call.
|
||||
|
||||
## Example
|
||||
|
||||
A filled-in .openspec.yaml:
|
||||
|
||||
```yaml
|
||||
schema: spec-driven
|
||||
created: 2026-08-14
|
||||
goal: Add magic-link login to the API
|
||||
affected_areas:
|
||||
- auth
|
||||
- api
|
||||
```
|
||||
|
||||
## Validation
|
||||
|
||||
The file is validated whenever a command writes or reads it. A write that fails validation throws and writes nothing. Reading an existing file fails on invalid YAML, a field that breaks its contract, or a schema name that is not available. A missing file is not an error, and the change is treated as having no metadata.
|
||||
|
||||
Unlike [config.yaml](config-yaml.md), bad values are never dropped with a warning. A metadata error stops the command.
|
||||
|
||||
- **Unknown top-level keys**: OpenSpec ignores them. `status`, `instructions`, `validate`, and `archive` report that they have no effect. JSON output carries the warning in its structured result.
|
||||
- **Strict validation**: `openspec validate --strict` treats an unknown-key warning as a failure.
|
||||
@@ -1,97 +0,0 @@
|
||||
# CLI settings (config.json)
|
||||
|
||||
> Every field of config.json: how the openspec CLI behaves on your machine.
|
||||
|
||||
## Location
|
||||
|
||||
The CLI keeps its machine-level settings at `~/.config/openspec/config.json` on macOS and Linux, and `%APPDATA%\openspec\config.json` on Windows. `$XDG_CONFIG_HOME` wins on every platform when set. The `openspec config` command reads and edits it.
|
||||
|
||||
## Fields
|
||||
|
||||
| Key | Type | Required | Effect |
|
||||
| --- | --- | --- | --- |
|
||||
| `profile` | string: `core` or `custom` | No | Picks the workflow set `openspec init` installs |
|
||||
| `delivery` | string: `both`, `skills`, or `commands` | No | Whether init installs skills, slash commands, or both |
|
||||
| `workflows` | list of strings | No | The workflow list a `custom` profile installs |
|
||||
| `featureFlags` | map: flag → boolean | No | Boolean feature toggles |
|
||||
| `defaultStore` | string | No | Machine-level fallback store for root resolution |
|
||||
| `openers` | map: tool id → settings | No | The tools worksets open in, and how each is launched |
|
||||
| `telemetry` | map | No | Telemetry opt-out, anonymous id, and notice-seen state |
|
||||
|
||||
### profile
|
||||
|
||||
Which workflow set `openspec init` installs. Defaults to `core`: propose, explore, apply, update, sync, and archive. Setting `custom` installs exactly the `workflows` list instead.
|
||||
|
||||
### delivery
|
||||
|
||||
Whether init installs workflows as skills, as slash commands, or both. Defaults to `both`.
|
||||
|
||||
### workflows
|
||||
|
||||
The workflows a `custom` profile installs; ignored when the profile is `core`. Valid ids: `propose`, `explore`, `new`, `continue`, `apply`, `update`, `ff`, `sync`, `archive`, `bulk-archive`, `verify`, `onboard`.
|
||||
|
||||
### featureFlags
|
||||
|
||||
Boolean toggles keyed by flag name, set with `openspec config set featureFlags.<flag> true`. No flag is read by the CLI today.
|
||||
|
||||
### defaultStore
|
||||
|
||||
The machine-level fallback store id for root resolution, consulted only when no `--store` flag, local `openspec/`, or project `store:` pointer resolves. The full ladder is [Root resolution](../../multi-repo/stores.md#where-artifacts-get-created-when-using-stores).
|
||||
|
||||
### openers
|
||||
|
||||
The tools a workset can open in, keyed by tool id. Edit `openers` in the global `config.json` with `openspec config edit` in your terminal.
|
||||
|
||||
| Field | Contract |
|
||||
| --- | --- |
|
||||
| `style` | `workspace-file` or `attach-dirs`. Required for a new tool; optional for a built-in. |
|
||||
| `label` | Non-empty string shown in the tool picker. Defaults to the id for a new tool. |
|
||||
| `command` | Non-empty executable name or path. Defaults to the id for a new tool. Put arguments in `args`, not in this string. |
|
||||
| `args` | Array of strings passed before the workspace file or attach flags. Defaults to `[]` for a new tool. |
|
||||
| `attach_flag` | Non-empty string paired with each member path for `attach-dirs`. Defaults to `--add-dir` for a new tool. Ignored for `workspace-file`. |
|
||||
|
||||
**Built-in overrides:** `code`, `cursor`, `claude`, and `codex` retain any fields you omit. Setting `args` replaces the entire argument list; `[]` clears it.
|
||||
|
||||
**Launch styles:** `workspace-file` passes the generated `.code-workspace` path to the executable. `attach-dirs` passes one flag/path pair per member, including the primary member.
|
||||
|
||||
**Availability:** `attach-dirs` openers, including Claude Code and Codex, are disabled by default. You cannot select or save them with `--tool`, and OpenSpec refuses to open a workset that already names one. Configuration overrides do not enable the `attach-dirs` launch style.
|
||||
|
||||
**Validation:** unknown fields, invalid types, and a new tool without `style` fail when a workset command reads the opener table.
|
||||
|
||||
This example adds VS Code Insiders and passes `--new-window` whenever the built-in VS Code opener launches:
|
||||
|
||||
```json
|
||||
{
|
||||
"openers": {
|
||||
"code-insiders": {
|
||||
"style": "workspace-file",
|
||||
"label": "VS Code Insiders"
|
||||
},
|
||||
"code": {
|
||||
"args": ["--new-window"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The corresponding `code-insiders` or `code` executable must be installed and available on `PATH`.
|
||||
|
||||
### telemetry
|
||||
|
||||
The CLI stores your anonymous id and whether the first-run notice was shown. Set `telemetry.enabled` to `false` to disable telemetry. You can also opt out with `OPENSPEC_TELEMETRY=0` or `DO_NOT_TRACK=1` in your environment.
|
||||
|
||||
## Example
|
||||
|
||||
A filled-in config.json:
|
||||
|
||||
```json
|
||||
{
|
||||
"profile": "core",
|
||||
"delivery": "both",
|
||||
"featureFlags": {},
|
||||
"telemetry": {
|
||||
"anonymousId": "5f8a2c1e-4b6d-4f9a-9c3d-7e1b2a8d4c6f",
|
||||
"noticeSeen": true
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -1,101 +0,0 @@
|
||||
# Project configuration (config.yaml)
|
||||
|
||||
> Every field of openspec/config.yaml: the schema, context, and rules this project plans with.
|
||||
|
||||
## Location
|
||||
|
||||
Each OpenSpec project keeps its config file at `openspec/config.yaml`, in the project root.
|
||||
|
||||
## Fields
|
||||
|
||||
| Key | Type | Required | Effect |
|
||||
| --- | --- | --- | --- |
|
||||
| `schema` | string | Yes | The workflow schema this project's changes follow |
|
||||
| `context` | string | No | Injected into every artifact, apply, and archive |
|
||||
| `rules` | map: artifact ID → list of strings | No | Extra rules added to one artifact's built-in guidance |
|
||||
| `operations` | map: operation → guidance list | No | Advisory guidance for apply and archive work |
|
||||
| `store` | string | No | Fallback OpenSpec root when this openspec/ is config-only |
|
||||
| `references` | list | No | Stores whose specs are indexed into instructions |
|
||||
|
||||
Invalid fields never fail a command. Each field is validated on its own, and a bad value is dropped with a warning.
|
||||
|
||||
What to write in these fields is covered in [Project configuration](../../customize/project-config.md).
|
||||
|
||||
### schema
|
||||
|
||||
The workflow schema every change in this project follows. Valid values are `spec-driven` or a schema name the project defines. Run [`openspec schemas`](../cli.md#openspec-schemas) to list the available schema names.
|
||||
|
||||
### context
|
||||
|
||||
Free text injected into every artifact's instructions and supplied to apply and archive. The limit is 50KB, and a larger value is ignored with a warning.
|
||||
|
||||
### rules
|
||||
|
||||
Extra rules for one artifact, added to the schema's built-in guidance:
|
||||
|
||||
```yaml
|
||||
rules:
|
||||
proposal:
|
||||
- Keep proposals under 500 words
|
||||
```
|
||||
|
||||
Artifact IDs are not restricted to the built-in names, so artifacts from custom schemas work as keys.
|
||||
|
||||
### operations
|
||||
|
||||
Advisory guidance for how apply and archive work is conducted, separate from artifact rules:
|
||||
|
||||
```yaml
|
||||
operations:
|
||||
apply:
|
||||
guidance:
|
||||
- Keep test summaries concise
|
||||
```
|
||||
|
||||
Only `apply` and `archive` are read.
|
||||
|
||||
### store
|
||||
|
||||
A store id used as the OpenSpec root, consulted only when this openspec/ directory is config-only (no specs/ or changes/). It is a fallback, never an override. The full ladder is [Root resolution](../../multi-repo/stores.md#where-artifacts-get-created-when-using-stores).
|
||||
|
||||
### references
|
||||
|
||||
Store ids whose specs this project's work draws on. An index of each store's specs (id, summary, fetch command) is added to instructions output. Spec content is never inlined, and root resolution is never affected. An entry is a store id or a map with `id` and an optional `remote` clone source:
|
||||
|
||||
```yaml
|
||||
references:
|
||||
- platform-specs
|
||||
- id: billing-specs
|
||||
remote: git@github.com:acme/billing-specs.git
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
A filled-in config.yaml:
|
||||
|
||||
```yaml
|
||||
schema: spec-driven
|
||||
|
||||
context: |
|
||||
Designs and tasks must cover Windows, macOS, and Linux
|
||||
Write all artifacts in Spanish
|
||||
|
||||
rules:
|
||||
proposal:
|
||||
- Keep proposals under 500 words
|
||||
- Always state what is out of scope
|
||||
tasks:
|
||||
- Break tasks into chunks of max 2 hours
|
||||
|
||||
operations:
|
||||
apply:
|
||||
guidance:
|
||||
- Keep test summaries concise
|
||||
archive:
|
||||
guidance:
|
||||
- Summarize the archive outcome before finishing
|
||||
```
|
||||
|
||||
## Legacy names
|
||||
|
||||
`openspec/config.yml` is read as an alias when `config.yaml` does not exist. When both files exist, `config.yaml` wins and `config.yml` is ignored. `openspec init` creates `config.yaml`.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Environment variables
|
||||
|
||||
> Every environment variable OpenSpec reads.
|
||||
|
||||
<!-- Skeleton: headings only. This page is the telemetry opt-out's home
|
||||
(README TODO): OPENSPEC_TELEMETRY=0, DO_NOT_TRACK=1, auto-disabled in CI, plus
|
||||
what's collected. start/installation.md's Deno section links here to explain
|
||||
its network-permission flag. XDG vars move the config/data directories. -->
|
||||
|
||||
## OPENSPEC_TELEMETRY
|
||||
|
||||
## DO_NOT_TRACK
|
||||
|
||||
## XDG_CONFIG_HOME and XDG_DATA_HOME
|
||||
@@ -1,11 +0,0 @@
|
||||
# Overview
|
||||
|
||||
> Every file and setting that changes how OpenSpec behaves, and where each lives.
|
||||
|
||||
| File | Lives at | Controls |
|
||||
| --- | --- | --- |
|
||||
| [Project configuration (config.yaml)](config-yaml.md) | `openspec/config.yaml` | The schema, context, and rules this project plans with |
|
||||
| [Change metadata (.openspec.yaml)](change-metadata.md) | `openspec/changes/<name>/.openspec.yaml` | The workflow schema, goal, scope, and spec exceptions for one change |
|
||||
| [CLI settings (config.json)](config-json.md) | `~/.config/openspec/config.json` (Windows varies) | How the openspec CLI behaves on your machine |
|
||||
| Environment variables | Your shell or CI environment | Telemetry opt-out, and where the config and data directories live |
|
||||
| Stores | `~/.local/share/openspec/stores/` (Windows varies) | The registry and metadata behind multi-repo stores |
|
||||
@@ -1,22 +0,0 @@
|
||||
# Stores
|
||||
|
||||
> The files behind multi-repo stores: registry.yaml and store.yaml, and which root a command uses.
|
||||
|
||||
<!-- Skeleton: headings only. Beta, like the multi-repo group. Machine-maintained
|
||||
rather than hand-edited; documented so readers can inspect and repair them. The
|
||||
concept and workflow live in multi-repo/stores.md. Root resolution is the
|
||||
contract from src/core/root-selection.ts: --store flag, else nearest ancestor
|
||||
openspec/, else a config-only openspec/'s store: pointer, else the global
|
||||
defaultStore, else error. This page owns the whole ladder including the
|
||||
everyday case (nearest openspec/ wins); the section's Overview only links
|
||||
here. Locations (store/foundation.ts): registry.yaml at <dataDir>/stores/
|
||||
(~/.local/share/openspec/stores/); store.yaml at .openspec-store/store.yaml
|
||||
inside each checkout. The glossary's "OpenSpec root" row links here. -->
|
||||
|
||||
## registry.yaml
|
||||
|
||||
## store.yaml
|
||||
|
||||
## Locations
|
||||
|
||||
## Root resolution
|
||||
@@ -1,40 +0,0 @@
|
||||
# Glossary
|
||||
|
||||
> Every OpenSpec term, one line each.
|
||||
|
||||
OpenSpec reuses words that mean something else in git, CI, and agent tooling. Each row gives the OpenSpec meaning. The last column links to more detail where available.
|
||||
|
||||
| Term | Definition | More |
|
||||
|---|---|---|
|
||||
| **Apply** | Implement the tasks in a change proposal. Skill: `openspec-apply-change`. | [Apply a change](skills.md#openspec-apply-change) |
|
||||
| **Archive** | Complete a change proposal: merge its deltas into the main specs and move its folder to `openspec/changes/archive/`. | [Quickstart](../start/quickstart.md) |
|
||||
| **Artifact** | A planning document inside a change proposal: `proposal.md`, delta specs, `design.md`, `tasks.md`. Not a build output. | [Artifacts](schemas/spec-driven/index.md#artifacts) |
|
||||
| **Capability** | One behavior area of your system. Each has one spec at `openspec/specs/<capability>/spec.md`. | [Capabilities](schemas/spec-driven/index.md#proposalmd) |
|
||||
| **Change proposal** | One unit of work: a folder under `openspec/changes/<name>/` holding its planning artifacts. Often shortened to "change". Not a git commit. | [Propose](../start/quickstart.md#step-2-propose) |
|
||||
| **Command** | A typed entry point for a workflow. Spelling varies per tool (`/opsx:propose`, `/opsx-propose`). The docs name workflows by skill instead. | [Supported tools](supported-tools.md) |
|
||||
| **Continue** | Create the next planning artifact for an existing change proposal. Skill: `openspec-continue-change`. | [Skills](skills.md) |
|
||||
| **Delivery** | How workflows are installed: as skills, commands, or both. | [Set up your project](../start/setup.md) |
|
||||
| **Delta spec** | A spec inside a change proposal listing only what changes, under `ADDED`, `MODIFIED`, `REMOVED`, and `RENAMED` headers. | [Delta specs](schemas/spec-driven/index.md#delta-specs-specmd) |
|
||||
| **Explore** | Think an idea through with the agent before proposing. Writes no code. Skill: `openspec-explore`. | [Explore an idea](skills.md#openspec-explore) |
|
||||
| **Fast-forward** | Create a change proposal with every planning artifact in one pass, ready to implement. Skill: `openspec-ff-change`. Not a git fast-forward. | [Skills](skills.md) |
|
||||
| **Legacy workflow** | The pre-OPSX `/openspec:*` commands. | |
|
||||
| **Loop** | The cycle a change proposal moves through: explore, propose, review, apply, archive. | [Quickstart](../start/quickstart.md) |
|
||||
| **Main specs** | The `openspec/specs/` tree: the current, agreed behavior of your system. Archiving merges deltas into it. A capability with no spec yet gets one from its `ADDED` requirements. | [Archive](../start/quickstart.md#step-5-archive) |
|
||||
| **OpenSpec root** | The `openspec/` tree a command resolves to and operates on: your repo's, or a store's. | [Stores](../multi-repo/stores.md#where-artifacts-get-created-when-using-stores) |
|
||||
| **OPSX** | The current OpenSpec workflow system, and the command prefix it installs (`/opsx:`). | |
|
||||
| **Profile** | Which workflows init installs: `core` or `custom`. | [Profiles](../customize/profiles.md) |
|
||||
| **Propose** | Create a change proposal and generate all its planning artifacts in one step. Skill: `openspec-propose`. | [Quickstart](../start/quickstart.md) |
|
||||
| **Registry** | The machine-level list of registered stores, in `registry.yaml`. Not a package registry. | [CLI](cli.md#openspec-store) |
|
||||
| **Requirement** | One behavior the system must have, written with SHALL: `### Requirement:` in a spec. | [Delta specs](schemas/spec-driven/index.md#delta-specs-specmd) |
|
||||
| **Scenario** | A testable example under a requirement, in WHEN/THEN form. | [Delta specs](schemas/spec-driven/index.md#delta-specs-specmd) |
|
||||
| **Schema** | The definition of which artifacts a change proposal produces, and in what order. Not JSON Schema. | [Schemas](schemas/index.md) |
|
||||
| **Skill** | A workflow's instructions, installed where your AI tool reads them (`.agents/skills/`, ...). | [Skills](skills.md) |
|
||||
| **Spec** | A file describing how one capability behaves today, at `openspec/specs/<capability>/spec.md`. | [Archive](../start/quickstart.md#step-5-archive) |
|
||||
| **spec-driven** | The default schema: proposal, then delta specs, then design, then tasks. | [spec-driven](schemas/spec-driven/index.md) |
|
||||
| **Store** | A standalone OpenSpec repo registered on your machine, for planning that spans repositories. Not a data store. | [Stores (beta)](../multi-repo/stores.md) |
|
||||
| **Sync** | Merge implemented deltas into the main specs without archiving. Skill: `openspec-sync-specs`. | [Skills](skills.md) |
|
||||
| **Template** | The starting content a schema gives each artifact. | [Schemas](../customize/schemas.md) |
|
||||
| **Update** | As a skill (`openspec-update-change`): revise a change proposal's planning artifacts. As a CLI command (`openspec update`): refresh OpenSpec's installed files. | [Update a change](skills.md#openspec-update-change), [CLI](cli.md) |
|
||||
| **Verify** | Check the implementation matches a change proposal's artifacts before archiving. Skill: `openspec-verify-change`. | [Skills](skills.md) |
|
||||
| **Workflow** | A named OpenSpec action (propose, apply, archive, ...), installed into your AI tool as a skill or command. | [Set up your project](../start/setup.md) |
|
||||
| **Workset** | A personal, local group of folders opened together in one tool. Not a store, and nothing is shared. | [Worksets (beta)](../multi-repo/worksets.md) |
|
||||
@@ -1,20 +0,0 @@
|
||||
# Overview
|
||||
|
||||
> Every available workflow schema and the artifacts it defines.
|
||||
|
||||
<!-- This group states the formats. How schemas shape artifacts and how to
|
||||
change or write one is customize/schemas.md's job. -->
|
||||
|
||||
A schema defines which artifacts a change proposal produces, and in what order. On disk it's a folder with a schema.yaml in it. Every field of that file is on the [schema.yaml](schema-yaml.md) page.
|
||||
|
||||
## Available schemas
|
||||
|
||||
One schema ships with the CLI:
|
||||
|
||||
| Schema | Artifacts |
|
||||
|---|---|
|
||||
| [spec-driven](spec-driven/index.md) (default) | `proposal`, `specs`, `design`, `tasks` |
|
||||
|
||||
A project can add its own schemas, and a machine can override globally. Where those folders live and which copy wins is in schema.yaml's [Location](schema-yaml.md#location) section.
|
||||
|
||||
In your terminal, [`openspec schemas`](../cli.md#openspec-schemas) prints every schema your project can see.
|
||||
@@ -1,228 +0,0 @@
|
||||
# schema.yaml
|
||||
|
||||
> Every field of a schema definition, for reading or writing one.
|
||||
|
||||
`schema.yaml` lists the planning files a workflow creates. It also defines their order and the handoff to implementation.
|
||||
|
||||
## Location
|
||||
|
||||
A project schema lives under `openspec/schemas/<name>/`:
|
||||
|
||||
```text
|
||||
openspec/schemas/review-first/
|
||||
├── schema.yaml
|
||||
└── templates/
|
||||
├── proposal.md
|
||||
└── tasks.md
|
||||
```
|
||||
|
||||
OpenSpec checks three places for that directory. The first match wins.
|
||||
|
||||
| Copy | Directory |
|
||||
|---|---|
|
||||
| **1. Project** | `<project>/openspec/schemas/<name>/` |
|
||||
| **2. User, macOS and Linux** | `~/.local/share/openspec/schemas/<name>/` |
|
||||
| **2. User, Windows** | `%LOCALAPPDATA%\openspec\schemas\<name>\` |
|
||||
| **3. Package** | The schemas installed with the CLI |
|
||||
|
||||
If `XDG_DATA_HOME` is set, the user directory moves to `$XDG_DATA_HOME/openspec/schemas/<name>/` on every platform.
|
||||
|
||||
The directory name is the lookup key used by `--schema`, `config.yaml`, and [`.openspec.yaml`](../configuration/change-metadata.md#schema). If the `name` field differs from the directory name, OpenSpec still uses the directory name for lookup.
|
||||
|
||||
[`openspec schema which <name>`](../cli.md#openspec-schema-which) prints the active directory and any lower-priority copies it hides.
|
||||
|
||||
## Top-level fields
|
||||
|
||||
| Field | Contract |
|
||||
|---|---|
|
||||
| `name` | **Required.** A non-empty string stored as the schema name. Lookup still uses the directory name. |
|
||||
| `version` | **Required.** A positive integer stored as the schema revision. The value doesn't change OpenSpec's behavior. |
|
||||
| `description` | An optional string printed by `openspec schemas`. With no value, the schema has no description. |
|
||||
| `artifacts` | **Required.** A non-empty list of [artifact entries](#artifact-fields). |
|
||||
| `apply` | Optional [apply settings](#apply-fields). With no block, OpenSpec uses the [apply defaults](#apply-defaults). |
|
||||
|
||||
## Artifact fields
|
||||
|
||||
Each entry under `artifacts` defines one planning file or set of files.
|
||||
|
||||
| Field | Contract |
|
||||
|---|---|
|
||||
| `id` | **Required.** A unique, non-empty string used in dependencies, project rules, commands, and apply settings. |
|
||||
| `generates` | **Required.** A relative path or glob telling the agent where to write the artifact inside the change folder. |
|
||||
| `description` | **Required.** A string that labels the artifact in instructions sent to the agent. |
|
||||
| `template` | **Required.** A relative path to the artifact's format in the schema's `templates/` folder. |
|
||||
| `instruction` | Optional guidance telling the agent what content to produce. |
|
||||
| `requires` | A list of artifact IDs that must be complete first. Default: `[]`. |
|
||||
|
||||
### `generates`
|
||||
|
||||
The path starts from the change folder. For a change named `add-auth`:
|
||||
|
||||
```yaml
|
||||
generates: proposal.md
|
||||
```
|
||||
|
||||
The artifact goes here:
|
||||
|
||||
```text
|
||||
openspec/changes/add-auth/proposal.md
|
||||
```
|
||||
|
||||
A glob can match several files:
|
||||
|
||||
```yaml
|
||||
generates: specs/**/*.md
|
||||
```
|
||||
|
||||
This matches Markdown files below `openspec/changes/add-auth/specs/`.
|
||||
|
||||
OpenSpec recognizes these glob forms in `generates`:
|
||||
|
||||
- **Wildcards and character classes**: values containing `*`, `?`, or `[`, such as `specs/**/*.md` and `review-[ab].md`.
|
||||
- **Brace expansions**: alternatives such as `review-{api,ui}.md` and ranges such as `file-{1..3}.md`.
|
||||
- **Extglobs**: patterns such as `@(proposal|design).md`, `+(proposal|design).md`, and `!(proposal|design).md`.
|
||||
|
||||
**Literal filenames**: a leading `!` alone does not make a glob. Use `generates: '!review.md'` to name that file. Plain parentheses such as `(proposal|design).md` and single-element braces such as `review-{api}.md` also remain literal.
|
||||
|
||||
OpenSpec rejects absolute paths and paths containing a `..` segment.
|
||||
|
||||
#### Completion
|
||||
|
||||
OpenSpec checks whether the output exists. It doesn't read the file to decide whether the artifact is complete.
|
||||
|
||||
| `generates` value | Complete when |
|
||||
|---|---|
|
||||
| `proposal.md` | That file exists. |
|
||||
| `specs/**/*.md` | The glob matches at least one file. |
|
||||
|
||||
### `template`
|
||||
|
||||
The path starts from the schema's `templates/` folder. In the `review-first` schema:
|
||||
|
||||
```yaml
|
||||
template: proposal.md
|
||||
```
|
||||
|
||||
OpenSpec reads this file:
|
||||
|
||||
```text
|
||||
openspec/schemas/review-first/templates/proposal.md
|
||||
```
|
||||
|
||||
OpenSpec gives the template's contents to the agent as the output format. It doesn't copy the template into the change folder.
|
||||
|
||||
OpenSpec rejects absolute paths and paths containing a `..` segment.
|
||||
|
||||
### `requires`
|
||||
|
||||
- **Dependencies**: every ID in `requires` must name another artifact in the same schema.
|
||||
- **Ready state**: an artifact becomes ready after all its dependencies are complete.
|
||||
- **Invalid graphs**: missing IDs, duplicate IDs, and dependency cycles fail validation.
|
||||
- **Ties**: when several artifacts are ready, their order in `artifacts` decides which one OpenSpec returns first.
|
||||
|
||||
## Apply fields
|
||||
|
||||
`apply` defines what must exist before implementation starts.
|
||||
|
||||
| Field | Contract |
|
||||
|---|---|
|
||||
| `requires` | **Required.** A non-empty list of artifacts that must exist before apply instructions become ready. |
|
||||
| `tracks` | An optional relative path or glob for Markdown task files in the change folder. Default: `null`. |
|
||||
| `instruction` | Optional guidance sent to the agent when apply is ready. OpenSpec uses built-in guidance by default. |
|
||||
|
||||
Artifact `requires` controls planning order. `apply.requires` controls when apply instructions become ready.
|
||||
|
||||
### `tracks`
|
||||
|
||||
The path starts from the change folder. For a change named `add-auth`, `tracks: tasks.md` reads:
|
||||
|
||||
```text
|
||||
openspec/changes/add-auth/tasks.md
|
||||
```
|
||||
|
||||
A glob such as `tracks: "**/tasks.md"` reads every matching file, such as `backend/tasks.md` and `frontend/tasks.md`. OpenSpec combines their tasks and progress. Use the same value for an artifact's `generates` field so status and list track the same files.
|
||||
|
||||
Apply stays blocked if no file matches or the matched files contain no checkbox with task text. OpenSpec counts these checkbox forms:
|
||||
|
||||
```markdown
|
||||
- [ ] Pending task
|
||||
- [x] Completed task
|
||||
* [X] Completed task
|
||||
+ [ ] Pending task
|
||||
1. [ ] Pending task
|
||||
2) [x] Completed task
|
||||
```
|
||||
|
||||
Any Markdown list marker works: `-`, `*`, `+`, or a number of up to nine digits followed by `.` or `)`. Leading spaces are allowed. The [tasks.md section of the spec-driven page](spec-driven/index.md#tasksmd) defines the stricter format produced by the default schema.
|
||||
|
||||
The tracked files drive the apply state:
|
||||
|
||||
- **`blocked`**: no file matches, or no readable file has a checkbox with task text.
|
||||
- **`ready`**: at least one task is pending, or a matched file could not be read while another provides tasks.
|
||||
- **`all_done`**: every tracked task is checked and every matched file was read.
|
||||
|
||||
If a matched file cannot be read, apply keeps the tasks and progress from readable files but does not mark the change `all_done`. [Apply JSON output](../cli.md#openspec-instructions) identifies each unavailable file and the reason.
|
||||
|
||||
OpenSpec rejects absolute paths and paths containing a `..` segment.
|
||||
|
||||
### Apply defaults
|
||||
|
||||
| Behavior | Default |
|
||||
|---|---|
|
||||
| Required artifacts | Every artifact in the schema |
|
||||
| Progress tracking | No tracked file |
|
||||
| Agent guidance | Built-in apply guidance |
|
||||
|
||||
## Complete example
|
||||
|
||||
```yaml
|
||||
name: review-first
|
||||
version: 1
|
||||
description: Proposal and implementation checklist
|
||||
|
||||
artifacts:
|
||||
- id: proposal
|
||||
generates: proposal.md
|
||||
description: Why the change is needed and what it affects
|
||||
template: proposal.md
|
||||
instruction: |
|
||||
Explain the problem, the proposed change, and its impact.
|
||||
requires: []
|
||||
|
||||
- id: tasks
|
||||
generates: tasks.md
|
||||
description: Trackable implementation checklist
|
||||
template: tasks.md
|
||||
instruction: |
|
||||
Break the approved proposal into ordered implementation tasks.
|
||||
requires:
|
||||
- proposal
|
||||
|
||||
apply:
|
||||
requires:
|
||||
- tasks
|
||||
tracks: tasks.md
|
||||
instruction: |
|
||||
Work through the pending tasks and mark each one complete.
|
||||
```
|
||||
|
||||
## Validation
|
||||
|
||||
[`openspec schema validate <name>`](../cli.md#openspec-schema-validate) checks:
|
||||
|
||||
- Field types and required fields
|
||||
- Relative paths
|
||||
- Artifact IDs, dependencies, and cycles
|
||||
- `apply.requires` IDs: each must be an artifact in the schema
|
||||
- Template files
|
||||
|
||||
A schema with an unknown `apply.requires` ID doesn't load, so every command that uses it reports the error.
|
||||
|
||||
Validation warns, without failing, when `apply.tracks` isn't exactly equal to some artifact's `generates` value. OpenSpec finds the tracked artifact by comparing those two strings, so anything else leaves it unable to tell which artifact's progress the file belongs to. That includes a typo like `task.md`, and also `tracks: tasks/main.md` against `generates: tasks/*.md`, where the glob does produce the file but the strings still differ. Apply keeps reading the file either way, but `openspec list` and `openspec status` count `tasks.md` instead.
|
||||
|
||||
Validation doesn't catch these mistakes:
|
||||
|
||||
| Mistake | What happens |
|
||||
|---|---|
|
||||
| A field is misspelled, such as `instrution` | OpenSpec ignores it. Validation doesn't report the typo. |
|
||||
| `name` differs from the schema directory | Validation passes. OpenSpec still uses the directory name for lookup. |
|
||||
@@ -1,480 +0,0 @@
|
||||
# spec-driven
|
||||
|
||||
> The default workflow's artifacts: their order, their formats, and the change folder they produce.
|
||||
|
||||
`spec-driven` is OpenSpec's built-in default schema. [schema.yaml](../schema-yaml.md) defines the fields it sets.
|
||||
|
||||
## Artifacts
|
||||
|
||||
The workflow drafts four artifacts:
|
||||
|
||||
| Artifact | File | Purpose |
|
||||
|---|---|---|
|
||||
| [`proposal`](#proposalmd) | `proposal.md` | Why the change is needed |
|
||||
| [`specs`](#delta-specs-specmd) | `specs/<capability-path>/spec.md`, one per capability | What behavior changes |
|
||||
| [`design`](#designmd) | `design.md` | How to build it |
|
||||
| [`tasks`](#tasksmd) | `tasks.md` | The implementation checklist |
|
||||
|
||||
## Drafting order
|
||||
|
||||
```text
|
||||
┌─ specs ──┐
|
||||
proposal ────┤ ├── tasks ── apply
|
||||
└─ design ─┘
|
||||
```
|
||||
|
||||
Proposal comes first. Specs and design follow in either order, and tasks needs both. Implementation ([apply](#apply)) starts once `tasks.md` is in place.
|
||||
|
||||
Two artifacts can be skipped:
|
||||
|
||||
- **`design`**: when none of [its conditions](#designmd) apply, the agent leaves it out and drafts `tasks` anyway.
|
||||
- **`specs`**: set [`skip_specs: true`](../../configuration/change-metadata.md#skip_specs) in the change's `.openspec.yaml`.
|
||||
|
||||
## Example change folder
|
||||
|
||||
A change named `add-user-auth`, with every artifact drafted:
|
||||
|
||||
```text
|
||||
openspec/changes/add-user-auth/
|
||||
├── .openspec.yaml change metadata, written when the change is created
|
||||
├── proposal.md
|
||||
├── specs/
|
||||
│ └── user-auth/
|
||||
│ └── spec.md one delta spec per capability
|
||||
├── design.md
|
||||
└── tasks.md
|
||||
```
|
||||
|
||||
## proposal.md
|
||||
|
||||
Establishes why the change is needed.
|
||||
|
||||
### Structure
|
||||
|
||||
The template the agent receives as the output format ([templates/proposal.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/proposal.md)):
|
||||
|
||||
```md
|
||||
# Proposal
|
||||
|
||||
## Why
|
||||
|
||||
<!-- Explain the motivation for this change. What problem does this solve? Why now? -->
|
||||
|
||||
## What Changes
|
||||
|
||||
<!-- Describe what will change. Be specific about new capabilities, modifications, or removals. -->
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
<!-- Capabilities being introduced. Name each capability for a cohesive system
|
||||
behavior that can own related requirements as the system evolves. Do not name
|
||||
implementation tasks or proposal sections. Avoid broad catch-all names. Use
|
||||
kebab-case for path segments you introduce (e.g., user-auth or identity/user-auth)
|
||||
that follow the project's existing spec organization. Each creates
|
||||
specs/<capability-path>/spec.md. -->
|
||||
- `<capability-path>`: <brief description of what this capability covers>
|
||||
|
||||
### Modified Capabilities
|
||||
<!-- Existing capabilities whose REQUIREMENTS are changing (not just implementation).
|
||||
Only list here if spec-level behavior changes. Each needs a delta spec file.
|
||||
Use the exact existing path under openspec/specs/. Leave empty if no requirement
|
||||
changes. A change with no capabilities at all (pure refactor, tooling, docs)
|
||||
must set `skip_specs: true` in its .openspec.yaml - openspec validate rejects
|
||||
a zero-delta change without that marker. Do not invent a requirement just to
|
||||
satisfy validation. -->
|
||||
- `<existing-capability-path>`: <what requirement is changing>
|
||||
|
||||
## Impact
|
||||
|
||||
<!-- Affected code, APIs, dependencies, systems -->
|
||||
```
|
||||
|
||||
### Instructions
|
||||
|
||||
The instruction sent to the agent when it drafts this artifact (from [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
|
||||
|
||||
```md
|
||||
Create the proposal document that establishes WHY this change is needed.
|
||||
|
||||
Sections:
|
||||
- **Why**: 1-2 sentences on the problem or opportunity. What problem does this solve? Why now?
|
||||
- **What Changes**: Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**.
|
||||
- **Capabilities**: Identify which specs will be created or modified:
|
||||
- **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<capability-path>/spec.md`. Name each capability for a durable system behavior (for example, `user-auth`), not the work in this change (for example, `add-login-endpoint`). Choose a cohesive boundary that can own related requirements as the system evolves; avoid broad catch-all capabilities. Use kebab-case for path segments you introduce (e.g., `user-auth` or `identity/user-auth`) and follow the project's existing spec organization.
|
||||
- **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Use the exact existing path under `openspec/specs/`. Leave empty if no requirement changes.
|
||||
- **Impact**: Affected code, APIs, dependencies, or systems.
|
||||
|
||||
IMPORTANT: The Capabilities section is critical. It creates the contract between
|
||||
proposal and specs phases. Research existing specs before filling this in:
|
||||
run `openspec list --specs` for the project's capability inventory, then
|
||||
`openspec show "<spec-id>" --type spec --json --no-scenarios` for any that
|
||||
look related - that returns a capability's purpose and requirement texts
|
||||
without pulling whole spec files into context. Append `--store "<id>"` to
|
||||
both commands only for a registered standalone store, and keep `--type
|
||||
spec`: a change and a spec sharing a name is otherwise an ambiguous-item
|
||||
error. `openspec list` without `--specs` lists in-flight changes, not
|
||||
specs - it never shows what the project already covers. Reuse an existing
|
||||
capability's exact path instead of introducing a near-duplicate name.
|
||||
The filtered read is only an overview. Before deciding what is already
|
||||
covered or what should change, read each relevant spec in full, including
|
||||
scenarios, with `openspec show "<spec-id>" --type spec` (same `--store` rule).
|
||||
Each capability listed here will need a corresponding spec file.
|
||||
|
||||
Every change must either declare at least one capability (new or
|
||||
modified) or explicitly opt out of specs: `openspec validate` rejects a
|
||||
change with zero deltas unless the change's `.openspec.yaml` sets
|
||||
`skip_specs: true`. Use `skip_specs: true` only when no spec-level
|
||||
behavior changes (pure refactor, tooling, docs) - specs describe
|
||||
behavior, so if behavior does not change, no spec should change either.
|
||||
Do not invent a requirement just to satisfy validation.
|
||||
|
||||
Keep it concise (1-2 pages). Focus on the "why" not the "how" -
|
||||
implementation details belong in design.md.
|
||||
|
||||
This is the foundation - specs, design, and tasks all build on this.
|
||||
```
|
||||
|
||||
## Delta specs (spec.md)
|
||||
|
||||
Defines what behavior changes, with one delta spec per capability the proposal lists.
|
||||
|
||||
Each delta spec is the `spec.md` inside its capability folder. `openspec validate` and `openspec archive` reject delta sections written in any other file under `specs/`, such as `specs/user-auth.md`, because archive never merges them.
|
||||
|
||||
### Structure
|
||||
|
||||
The template the agent receives as the output format ([templates/spec.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/spec.md)):
|
||||
|
||||
```md
|
||||
# Spec Delta
|
||||
|
||||
## Purpose
|
||||
<!-- New capabilities only: one or two sentences (50+ characters) on what this capability is for. Delete this section for an existing capability. -->
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: <!-- requirement name -->
|
||||
<!-- requirement text -->
|
||||
|
||||
#### Scenario: <!-- scenario name -->
|
||||
- **WHEN** <!-- condition -->
|
||||
- **THEN** <!-- expected outcome -->
|
||||
```
|
||||
|
||||
### Instructions
|
||||
|
||||
The instruction sent to the agent when it drafts this artifact (from [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
|
||||
|
||||
````md
|
||||
Create specification files that define WHAT the system should do.
|
||||
|
||||
A spec is a behavior contract, not an implementation plan.
|
||||
|
||||
Good spec content:
|
||||
- Observable behavior users or downstream systems rely on
|
||||
- Inputs, outputs, and error conditions
|
||||
- External constraints (security, privacy, reliability, compatibility)
|
||||
- Scenarios that can be tested or explicitly validated
|
||||
|
||||
Avoid in specs:
|
||||
- Internal class/function names
|
||||
- Library or framework choices
|
||||
- Step-by-step implementation details
|
||||
- Detailed execution plans (those belong in design.md or tasks.md)
|
||||
|
||||
Quick test: if the implementation can change without changing externally
|
||||
visible behavior, it likely does not belong in the spec.
|
||||
|
||||
Create one spec file per capability listed in the proposal's Capabilities section.
|
||||
`<capability-path>` is the spec directory relative to `specs/` (for example,
|
||||
`user-auth` or `identity/user-auth`). Preserve the full path:
|
||||
- New capabilities: use the exact path from the proposal at `specs/<capability-path>/spec.md`. Any path segment newly introduced in the proposal must be kebab-case. Follow the project's existing organization; do not add a new domain level when the project uses a flat layout.
|
||||
- Modified capabilities: use the exact existing path from `openspec/specs/<capability-path>/` when creating the delta at `specs/<capability-path>/spec.md`. Run `openspec list --specs` to confirm that path before writing the delta, appending `--store "<id>"` only for a registered standalone store - a mistyped or invented path targets a capability that does not exist rather than the one you meant. Do not move or rename the capability.
|
||||
|
||||
There must be at least one spec file unless the change's `.openspec.yaml`
|
||||
sets `skip_specs: true` (no spec-level behavior change) - `openspec validate`
|
||||
rejects a zero-delta change without that marker. If the proposal lists no
|
||||
capabilities and `skip_specs` is not set, revisit the proposal first.
|
||||
|
||||
Delta operations (use ## headers):
|
||||
- **ADDED Requirements**: New capabilities
|
||||
- **MODIFIED Requirements**: Changed behavior - MUST include full updated content
|
||||
- **REMOVED Requirements**: Deprecated features - MUST include **Reason** and **Migration**
|
||||
- **RENAMED Requirements**: Name changes only - use FROM:/TO: format
|
||||
|
||||
Format requirements:
|
||||
- Each requirement: `### Requirement: <name>` followed by description
|
||||
- Use SHALL/MUST for normative requirements (avoid should/may)
|
||||
- Each scenario: `#### Scenario: <name>` with WHEN/THEN format
|
||||
- **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
|
||||
- Every requirement MUST have at least one scenario.
|
||||
- Keep each requirement's description (the text between `### Requirement:` and its first scenario) to 500 characters or fewer. `openspec validate` flags longer descriptions once they reach the main spec. This is an informational hint, not an error. When writing a new requirement, state one behavior per requirement: move examples and edge cases into scenarios, and split a requirement that covers several behaviors into separate `### Requirement:` blocks, each with its own scenarios. Under MODIFIED, keep the existing requirement block whole; never split, trim or rewrite existing text just to meet the length.
|
||||
|
||||
New capabilities only: the delta spec's first section is `## Purpose` -
|
||||
one or two sentences (50+ characters, or `openspec validate --strict`
|
||||
reports it as too brief) describing what the capability is for. Archive
|
||||
copies it into the main spec it creates; without it the new main spec is
|
||||
left with a `TBD ... Update Purpose after archive` placeholder to fill in
|
||||
by hand. Do NOT add `## Purpose` to a delta for an existing capability -
|
||||
that spec already has one and the delta's is ignored. To change an
|
||||
existing capability's Purpose - including a leftover `TBD` placeholder -
|
||||
edit `<planningHome.root>/openspec/specs/<capability-path>/spec.md`
|
||||
directly. `planningHome.root` comes from the `openspec instructions ...
|
||||
--json` response. Always use it rather than a repo-relative path: it
|
||||
resolves to the store whenever the change lives in one - whether that
|
||||
came from `--store`, a project `store:` pointer, or a global default
|
||||
store - and to the current repository otherwise. Do not try to work out
|
||||
which case applies; the field already has.
|
||||
|
||||
MODIFIED requirements workflow:
|
||||
1. Locate the existing requirement in `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (the same store-aware root as above)
|
||||
2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios)
|
||||
3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior
|
||||
4. Ensure header text matches exactly (whitespace-insensitive)
|
||||
|
||||
Common pitfall: Using MODIFIED with partial content loses detail at archive time.
|
||||
If adding new concerns without changing existing behavior, use ADDED instead.
|
||||
|
||||
Example (a new capability, so its first section is `## Purpose`):
|
||||
```
|
||||
# Spec Delta
|
||||
|
||||
## Purpose
|
||||
|
||||
Lets users take their data out of the product in a portable format.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: User can export data
|
||||
The system SHALL allow users to export their data in CSV format.
|
||||
|
||||
#### Scenario: Successful export
|
||||
- **WHEN** user clicks "Export" button
|
||||
- **THEN** system downloads a CSV file with all user data
|
||||
|
||||
## REMOVED Requirements
|
||||
|
||||
### Requirement: Legacy export
|
||||
**Reason**: Replaced by new export system
|
||||
**Migration**: Use new export endpoint at /api/v2/export
|
||||
```
|
||||
|
||||
Specs should be testable - each scenario is a potential test case.
|
||||
````
|
||||
|
||||
## design.md
|
||||
|
||||
Explains how to implement the change. Drafted only when the change needs one.
|
||||
|
||||
### Structure
|
||||
|
||||
The template the agent receives as the output format ([templates/design.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/design.md)):
|
||||
|
||||
```md
|
||||
# Design
|
||||
|
||||
## Context
|
||||
|
||||
<!-- Current state and constraints that shape the approach. See proposal.md for motivation - don't restate it -->
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
<!-- What this design aims to achieve -->
|
||||
|
||||
**Non-Goals:**
|
||||
<!-- What is explicitly out of scope -->
|
||||
|
||||
## Decisions
|
||||
|
||||
<!-- Key design decisions with rationale and alternatives considered -->
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
<!-- Known risks and trade-offs -->
|
||||
```
|
||||
|
||||
### Instructions
|
||||
|
||||
The instruction sent to the agent when it drafts this artifact (from [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
|
||||
|
||||
```md
|
||||
Create the design document that explains HOW to implement the change.
|
||||
|
||||
When to include design.md (create only if any apply):
|
||||
- Cross-cutting change (multiple services/modules) or new architectural pattern
|
||||
- New external dependency or significant data model changes
|
||||
- Security, performance, or migration complexity
|
||||
- Ambiguity that benefits from technical decisions before coding
|
||||
|
||||
Sections:
|
||||
- **Context**: Only the current state and constraints needed to explain the approach. Reference the proposal for motivation instead of restating it (e.g., "See proposal.md - Why").
|
||||
- **Goals / Non-Goals**: What this design achieves and explicitly excludes. Don't restate the proposal's scope - add only design-level boundaries.
|
||||
- **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision.
|
||||
- **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation
|
||||
- **Migration Plan**: Steps to deploy, rollback strategy (if applicable)
|
||||
- **Open Questions**: Unknowns that can safely be answered later without
|
||||
changing the specs, the approach, or the task breakdown. Omit if none.
|
||||
|
||||
Open questions are for genuinely deferrable unknowns, not decisions you
|
||||
skipped. If a question would change the specs, the chosen approach, or
|
||||
the task breakdown, resolve it now - ask the user instead of guessing.
|
||||
|
||||
Focus on architecture and approach, not line-by-line implementation.
|
||||
The proposal covers why and what; design covers how. Reference the
|
||||
proposal for motivation and, once written, the specs for requirements -
|
||||
if a section would only restate them, point to them instead.
|
||||
|
||||
Good design docs explain the "why" behind technical decisions.
|
||||
```
|
||||
|
||||
## tasks.md
|
||||
|
||||
Breaks the implementation into checkable tasks. [apply](#apply) tracks progress here.
|
||||
|
||||
### Structure
|
||||
|
||||
The template the agent receives as the output format ([templates/tasks.md](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/templates/tasks.md)):
|
||||
|
||||
```md
|
||||
# Tasks
|
||||
|
||||
## 1. <!-- Task Group Name -->
|
||||
|
||||
- [ ] 1.1 <!-- Task description -->
|
||||
- [ ] 1.2 <!-- Task description -->
|
||||
|
||||
## 2. <!-- Task Group Name -->
|
||||
|
||||
- [ ] 2.1 <!-- Task description -->
|
||||
- [ ] 2.2 <!-- Task description -->
|
||||
```
|
||||
|
||||
### Instructions
|
||||
|
||||
The instruction sent to the agent when it drafts this artifact (from [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
|
||||
|
||||
````md
|
||||
Create the task list that breaks down the implementation work.
|
||||
|
||||
Before writing tasks, check design.md for Open Questions. If any of them
|
||||
would change what gets built, resolve them with the user first - do not
|
||||
bake an unstated assumption into the task list.
|
||||
|
||||
**IMPORTANT: Follow the template below exactly.** The apply phase parses
|
||||
checkbox format to track progress. A box holding only `x` counts as done,
|
||||
upper or lower case and with any spacing, so `- [ x]` is done too. Every
|
||||
other marker, including `- [~]`, `- [-]` and an empty `- []`, reads as
|
||||
unfinished. A line with no checkbox is not tracked at all.
|
||||
|
||||
Guidelines:
|
||||
- Group related tasks under ## numbered headings
|
||||
- Each task MUST be a checkbox: `- [ ] X.Y Task description`
|
||||
- Tasks should be small enough to complete in one session
|
||||
- Order tasks by dependency (what must be done first?)
|
||||
- Each task MUST state how to verify completion (a test, command,
|
||||
observable behavior, or delivered artifact). Put the verification in
|
||||
that task's checkbox description. Use a separate verification task only
|
||||
when it checks broader integration or system behavior that spans
|
||||
multiple implementation tasks.
|
||||
- Each task group MUST land the tests and documentation its own work
|
||||
calls for. Do NOT collect testing or documentation into a final group -
|
||||
when a late group first exercises work from an early one, the failures
|
||||
cascade back through every group in between and force rework. A group
|
||||
whose work calls for neither, such as scaffolding or dependency setup,
|
||||
carries neither. A final group is for integration checks only, not for
|
||||
the tests and docs an earlier group owed.
|
||||
|
||||
Example:
|
||||
```
|
||||
# Tasks
|
||||
|
||||
## 1. Setup
|
||||
|
||||
- [ ] 1.1 Create new module structure and verify expected files are present
|
||||
- [ ] 1.2 Add dependencies to package.json and verify package installation succeeds
|
||||
|
||||
## 2. Core Implementation
|
||||
|
||||
- [ ] 2.1 Implement data export function and verify the export test passes
|
||||
- [ ] 2.2 Add CSV formatting utilities and verify unit tests cover quoting and delimiters
|
||||
- [ ] 2.3 Document the export API in docs/export.md and verify the documented command runs as written
|
||||
```
|
||||
|
||||
Reference specs for what needs to be built, design for how to build it.
|
||||
````
|
||||
|
||||
## Apply
|
||||
|
||||
The handoff from planning to implementation. Apply is the phase that works through `tasks.md`, not an artifact.
|
||||
|
||||
- **Starts**: once `tasks.md` exists and lists at least one task.
|
||||
- **Tracks**: the checkboxes in `tasks.md`. Checking them off is the progress record.
|
||||
- **Ends**: every checkbox checked. OpenSpec then suggests archiving the change.
|
||||
|
||||
### Settings
|
||||
|
||||
The apply settings (from [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
|
||||
|
||||
```yaml
|
||||
apply:
|
||||
requires: [tasks]
|
||||
tracks: tasks.md
|
||||
# instruction: shown below
|
||||
```
|
||||
|
||||
### Instructions
|
||||
|
||||
The instruction sent to the agent when implementation starts (from [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml)):
|
||||
|
||||
```md
|
||||
Read context files, work through pending tasks, mark complete as you go.
|
||||
Pause if you hit blockers or need clarification.
|
||||
```
|
||||
|
||||
## schema.yaml
|
||||
|
||||
The complete [schema.yaml](https://github.com/Fission-AI/OpenSpec/blob/main/schemas/spec-driven/schema.yaml), with instruction bodies elided. Each is shown in full in its section above.
|
||||
|
||||
```yaml
|
||||
name: spec-driven
|
||||
version: 1
|
||||
description: Default OpenSpec workflow - proposal → specs → design → tasks
|
||||
artifacts:
|
||||
- id: proposal
|
||||
generates: proposal.md
|
||||
description: Initial proposal document outlining the change
|
||||
template: proposal.md
|
||||
# instruction: shown in full under proposal.md above
|
||||
requires: []
|
||||
|
||||
- id: specs
|
||||
generates: "specs/**/*.md"
|
||||
description: Detailed specifications for the change
|
||||
template: spec.md
|
||||
# instruction: shown in full under Delta specs above
|
||||
requires:
|
||||
- proposal
|
||||
|
||||
- id: design
|
||||
generates: design.md
|
||||
description: Technical design document with implementation details
|
||||
template: design.md
|
||||
# instruction: shown in full under design.md above
|
||||
requires:
|
||||
- proposal
|
||||
|
||||
- id: tasks
|
||||
generates: tasks.md
|
||||
description: Implementation checklist with trackable tasks
|
||||
template: tasks.md
|
||||
# instruction: shown in full under tasks.md above
|
||||
requires:
|
||||
- specs
|
||||
- design
|
||||
|
||||
apply:
|
||||
requires: [tasks]
|
||||
tracks: tasks.md
|
||||
# instruction: shown in full under Apply above
|
||||
```
|
||||
@@ -1,185 +0,0 @@
|
||||
# Skills
|
||||
|
||||
> Every OpenSpec skill: arguments, what it creates, and what it responds with.
|
||||
|
||||
<!-- Drafted 2026-08-11 via one subagent per entry, each verifying every claim against
|
||||
its workflow template in src/core/templates/workflows/; assembled and uniformity-passed
|
||||
by the main session. Terminology: "change proposal", never bare "change" (user call,
|
||||
2026-08-11). Shape (user-reviewed): intro bullets define Core/Optional, then ONE index
|
||||
table (Skill / Job / Type) and a flat run of H2 entries matching
|
||||
cli.md's shape - no group sections. Recipe per entry: one-line job sentence, then a
|
||||
two-column key-value table (header row "Contract | Description", uniform across
|
||||
entries) holding the pure input/output contract,
|
||||
one row per fact: Arguments (what you pass; each cell self-contains its
|
||||
optional/ambiguous behavior) / Creates (exact paths written; always states the code
|
||||
boundary) / Response (what the agent reports back and where it stops). No judgment
|
||||
rows: no when-to-use beyond the job sentence, no Not-for routing, no guide links
|
||||
(guides link here, not the reverse). The ff job says "create a change proposal"
|
||||
because its template unconditionally scaffolds a new one (redirects if the name
|
||||
exists), contradicting the old "remaining artifacts" framing. Paths shown are the
|
||||
default single-repo layout, stated without a caveat: reference pages state defaults,
|
||||
and the store-moves-the-planning-home fact is multi-repo/stores.md's to teach (the
|
||||
per-tool command spelling story likewise stays with setup.md and supported-tools.md;
|
||||
user cut the NOTE carrying both, 2026-08-11). H2 entries double as the site's
|
||||
right-rail TOC and the anchors guides deep-link. No frontmatter in source: sync-docs.mjs lifts H1 to title and the > line to
|
||||
description (README pins the > line verbatim in its page index). Deliberately
|
||||
excluded, each with an owner elsewhere: per-tool command spellings and syntax
|
||||
(reference/supported-tools.md), example transcripts (quickstart and guides), tips and
|
||||
when-to-use judgment (guides own it), troubleshooting (help/troubleshooting.md),
|
||||
legacy /openspec:* commands (help/legacy/migration.md). Source: old docs/commands.md
|
||||
maps here per sources.md; its unsupported claims (apply "runs tests", bulk-archive
|
||||
name arguments, fixed tasks.md filename) were checked against templates and dropped.
|
||||
Skill names from WORKFLOW_TO_SKILL_DIR (src/core/profile-sync-drift.ts) and the
|
||||
templates in src/core/templates/workflows/; core set src/core/profiles.ts:14. "Optional"
|
||||
is the docs' set label (was "Expanded"; renamed 2026-08-12: the product's only stored
|
||||
profile values are core and custom, so "expanded" reads as a third profile). -->
|
||||
|
||||
The skills come in two sets:
|
||||
|
||||
- **Core**: installed by default, the main planning loop.
|
||||
- **Optional**: installed only when you add them, via [Profiles](../customize/profiles.md).
|
||||
|
||||
Every skill expects a project that already uses OpenSpec. Before its first step that writes anything, a skill checks for a resolved root. What happens when there is none depends on how the skill was reached:
|
||||
|
||||
- **Auto-selected**: your agent picked the skill on its own, without you naming OpenSpec. It drops OpenSpec and answers your request normally, the way it would with OpenSpec not installed.
|
||||
- **Explicit OpenSpec request**: you named OpenSpec, named the skill, or ran its command. It stops before writing and asks how to proceed: run `openspec init` here, target a store with `--store <id>`, or continue without OpenSpec. It waits for your answer.
|
||||
|
||||
Commands are always the second case. A project whose `openspec/config.yaml` names a store this machine cannot resolve (not registered, or a malformed `store:` line) is not treated as uninitialized: the skill stops and shows the store error with its fix. No skill creates an `openspec/` directory on its own in either case. The entries below describe what each skill does once a root is in place.
|
||||
|
||||
| Skill | Job | Type |
|
||||
|---|---|---|
|
||||
| [openspec-explore](#openspec-explore) | Think through an idea before it becomes a change proposal | Core |
|
||||
| [openspec-propose](#openspec-propose) | Create a change proposal with all its planning artifacts in one step | Core |
|
||||
| [openspec-apply-change](#openspec-apply-change) | Implement a change proposal's tasks | Core |
|
||||
| [openspec-update-change](#openspec-update-change) | Revise a change proposal's plan | Core |
|
||||
| [openspec-sync-specs](#openspec-sync-specs) | Merge a change proposal's spec updates into `specs/` | Core |
|
||||
| [openspec-archive-change](#openspec-archive-change) | Move a finished change proposal to the archive | Core |
|
||||
| [openspec-new-change](#openspec-new-change) | Start a change proposal as an empty scaffold | Optional |
|
||||
| [openspec-continue-change](#openspec-continue-change) | Create the next planning artifact, one at a time | Optional |
|
||||
| [openspec-ff-change](#openspec-ff-change) | Create a change proposal with every artifact implementation needs, in one pass | Optional |
|
||||
| [openspec-verify-change](#openspec-verify-change) | Check the implementation matches the plan | Optional |
|
||||
| [openspec-bulk-archive-change](#openspec-bulk-archive-change) | Archive several change proposals at once | Optional |
|
||||
| [openspec-onboard](#openspec-onboard) | Learn the workflow by doing one real change proposal end to end | Optional |
|
||||
|
||||
Each entry below names the skill that owns the next step. When your profile leaves that skill out, the installed files never name it: the handoff becomes the equivalent `openspec` command, or a plain request to you, and a line that exists only to point at a missing skill is not written at all. So the skills you have always hand off to skills you have. Which set you get is [Profiles](../customize/profiles.md).
|
||||
|
||||
## openspec-explore
|
||||
|
||||
Think through an idea before it becomes a change proposal.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A topic: an idea, a problem, a comparison, or the name of an existing change proposal to explore in context. With nothing given it enters explore mode. |
|
||||
| **Creates** | Nothing by default. It reads and investigates only. On request it captures insights: a new change proposal under `openspec/changes/<name>/`, or updates to an existing one's proposal, design, specs, or tasks. Never code. |
|
||||
| **Response** | An open conversation with no required output. When thinking crystallizes it summarizes the problem, approach, open questions, and next steps, and offers to capture them. You decide. Implementation never starts here. |
|
||||
|
||||
## openspec-propose
|
||||
|
||||
Create a change proposal and generate all its planning artifacts in one step.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A kebab-case name (`add-dark-mode`) or a plain description. Asks if you give neither. |
|
||||
| **Creates** | `openspec/changes/<name>/` with every artifact the schema defines, in dependency order (spec-driven: proposal, spec deltas, design, tasks). Never code. |
|
||||
| **Response** | The created artifacts, ready for review, and the next step. Stops there; implementation waits for `openspec-apply-change`. |
|
||||
|
||||
## openspec-apply-change
|
||||
|
||||
Implement a change proposal's tasks, working through the list until done or blocked.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A change proposal name (`add-auth`), optional. If the target is ambiguous it lists the active change proposals and asks you to pick. |
|
||||
| **Creates** | Code: the minimal changes each task calls for, in your project files. In the change proposal it checks off each finished task (`- [ ]` to `- [x]`) in the tracked file identified by `sourcePath` and one-based `line`. A schema may track tasks across multiple files. |
|
||||
| **Response** | Progress per task, then an overall count (N/M tasks complete). All done: suggests `openspec-archive-change`. Blocked by missing artifacts: points to `openspec-continue-change`, or to `openspec status` and `openspec instructions` when that skill is not installed (the core profile leaves it out). Unclear tasks or errors: pauses and asks. |
|
||||
|
||||
## openspec-update-change
|
||||
|
||||
Revise a change proposal's existing planning artifacts and keep them coherent with each
|
||||
other.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A change proposal name, optional, plus the revision you want. With no revision stated it runs a coherence review: artifacts checked against each other for contradictions, gaps, and duplication. |
|
||||
| **Creates** | Edits artifact files that already exist. One exception: for an artifact written as a glob, such as `specs/**/*.md`, that already has at least one file, it can add a missing companion file once you confirm the path. An artifact with no files yet is `openspec-continue-change`'s job. Without that skill (the core profile leaves it out), it points to `openspec status` and `openspec instructions` instead. Never code. |
|
||||
| **Response** | Shows each proposed revision and writes it only after you confirm, one artifact at a time. Ends with what was revised and the next step; implementation waits for `openspec-apply-change`. |
|
||||
|
||||
## openspec-sync-specs
|
||||
|
||||
Merge a change proposal's spec updates into `specs/` without archiving it.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A change proposal name, optional. You can also name a subset of its delta specs, and only those sync. |
|
||||
| **Creates** | Edits or creates `openspec/specs/<capability-path>/spec.md` for each delta spec, merging added, modified, removed, and renamed requirements into the main spec. Never code. |
|
||||
| **Response** | A per-capability summary of requirements added, modified, removed, or renamed, after the updated specs validate. The change proposal stays active; archiving waits for `openspec-archive-change`. |
|
||||
|
||||
## openspec-archive-change
|
||||
|
||||
Move a finished change proposal to the archive.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A change proposal name, optional. |
|
||||
| **Creates** | Moves the change proposal folder to `openspec/changes/archive/YYYY-MM-DD-<name>/` (no date added if the name already starts with one). With your approval it first syncs outstanding delta specs. When `openspec-sync-specs` is installed, it runs that workflow. Otherwise, it merges the delta specs into the main specs itself. Never code. |
|
||||
| **Response** | Warns and asks before archiving with incomplete artifacts or tasks, and asks whether to sync when delta specs exist. Ends with a summary: name, schema, archive location, spec sync status, and any warnings. |
|
||||
|
||||
## openspec-new-change
|
||||
|
||||
Start a change proposal as an empty scaffold.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A kebab-case name (`add-user-auth`) or a plain description, plus a schema name only for a non-default workflow. Asks what you want to build if you give neither. |
|
||||
| **Creates** | `openspec/changes/<name>/` as an empty scaffold: no artifacts yet, never code. |
|
||||
| **Response** | The scaffold's name and location, the workflow's artifact sequence, status (0/N complete), and the first artifact's template. Drafting artifacts waits for `openspec-continue-change`. |
|
||||
|
||||
## openspec-continue-change
|
||||
|
||||
Create the next planning artifact in a change proposal, one at a time.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A change proposal name, optional. If still ambiguous it asks you to pick from the most recently modified. |
|
||||
| **Creates** | The single next ready artifact in the schema's sequence, written into the change proposal folder. One artifact per run, never code. |
|
||||
| **Response** | The created artifact, progress (N of M complete), and which artifacts that unlocked. When planning is complete it says so; implementation moves to `openspec-apply-change`. |
|
||||
|
||||
## openspec-ff-change
|
||||
|
||||
Create a change proposal and every planning artifact implementation needs, in one pass.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A kebab-case name or a plain description. Asks if you give neither. If the named change proposal already exists it suggests continuing it instead. |
|
||||
| **Creates** | `openspec/changes/<name>/` and every planning artifact implementation requires, in dependency order (spec-driven: proposal, specs, design, tasks), leaving out only artifacts marked skipped or conditional. Never code. |
|
||||
| **Response** | The change proposal's name and location, each artifact created, and any conditional artifact skipped and why. Stops there; implementation waits for `openspec-apply-change`. |
|
||||
|
||||
## openspec-verify-change
|
||||
|
||||
Check that the implementation matches the change proposal's artifacts.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | A change proposal name, optional. When ambiguous it asks, listing change proposals that have a tasks artifact. |
|
||||
| **Creates** | Nothing. It reads the change proposal's artifacts and the codebase. Verification is report-only. |
|
||||
| **Response** | A report: a scorecard for Completeness, Correctness, and Coherence, then CRITICAL, WARNING, and SUGGESTION issues with recommendations, and a final archive-readiness assessment. It changes nothing and does not archive. |
|
||||
|
||||
## openspec-bulk-archive-change
|
||||
|
||||
Archive several change proposals at once.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | None. It lists the active change proposals and asks you to select any number, with an option for all. If none are active it says so and stops. |
|
||||
| **Creates** | `openspec/changes/archive/YYYY-MM-DD-<name>/` per archived change proposal (already-dated names keep their prefix). Each one's spec deltas sync first via `openspec-sync-specs`. Never code. |
|
||||
| **Response** | A status table per change proposal and one confirmation for the whole batch, then a summary of archived, skipped, and failed, plus spec sync results. When two change proposals touch the same spec it checks the codebase and syncs implemented deltas oldest first. |
|
||||
|
||||
## openspec-onboard
|
||||
|
||||
Learn the workflow by doing one real change proposal end to end.
|
||||
|
||||
| Contract | Description |
|
||||
|---|---|
|
||||
| **Arguments** | None. It scans your codebase for small starter tasks and asks you to pick one or describe your own. |
|
||||
| **Creates** | A real change proposal for the chosen task, one artifact at a time, then real code once you confirm implementation. Archives the change proposal at the end. |
|
||||
| **Response** | A narrated walkthrough of the full cycle with pauses for your input: explore, create, build each artifact, implement, archive. Ends with a recap and a pointer to `openspec-propose`. Takes about 15 to 20 minutes. |
|
||||
@@ -1,190 +0,0 @@
|
||||
# Supported tools
|
||||
|
||||
> Which AI coding tools OpenSpec supports, and each one's command syntax.
|
||||
|
||||
Every tool in the matrix runs the same OpenSpec workflows. A skill and its command are
|
||||
the same workflow instructions. The only difference is what you type. Which form init
|
||||
installs is the delivery setting, covered in
|
||||
[Set up your project](../start/setup.md#the-workflow-files-skills-and-commands).
|
||||
|
||||
## Support matrix
|
||||
|
||||
Invocations are shown for the apply workflow. Every workflow follows the same shape.
|
||||
The id goes to `openspec init --tools <id>` to skip the picker ([CLI](cli.md)).
|
||||
|
||||
| Tool | `--tools` id | Skills | Skill invocation | Commands | Command invocation |
|
||||
|---|---|---|---|---|---|
|
||||
| Amazon Q Developer | `amazon-q` | `.amazonq/skills/` | `/openspec-apply-change` | `.amazonq/prompts/` | `@opsx-apply` |
|
||||
| Amp | `amp` | `.agents/skills/` | `/openspec-apply-change` | none | none |
|
||||
| Antigravity | `antigravity` | `.agents/skills/` | `/openspec-apply-change` | `.agents/workflows/` | `/opsx-apply` |
|
||||
| AtomCode | `atomcode` | `.atomcode/skills/` | `/openspec-apply-change` | `.atomcode/commands/` | `/opsx-apply` |
|
||||
| Auggie (Augment CLI) | `auggie` | `.augment/skills/` | `/openspec-apply-change` | `.augment/commands/` | `/opsx-apply` |
|
||||
| IBM Bob | `bob` | `.bob/skills/` | `/openspec-apply-change` | `.bob/commands/` | `/opsx-apply` |
|
||||
| Claude Code | `claude` | `.claude/skills/` | `/openspec-apply-change` | `.claude/commands/opsx/` | `/opsx:apply` |
|
||||
| Cline | `cline` | `.cline/skills/` | `/openspec-apply-change` | `.clinerules/workflows/` | `/opsx-apply` |
|
||||
| CodeArts | `codeartsagent` | `.codeartsdoer/skills/` | `/openspec-apply-change` | none | none |
|
||||
| CodeBuddy Code (CLI) | `codebuddy` | `.codebuddy/skills/` | `/openspec-apply-change` | `.codebuddy/commands/opsx/` | `/opsx:apply` |
|
||||
| Code Studio | `codestudio` | `.codestudio/skills/` | `/openspec-apply-change` | `.codestudio/prompts/` | `/opsx-apply` |
|
||||
| Codex | `codex` | `.agents/skills/` | `$openspec-apply-change` | none | none |
|
||||
| Continue | `continue` | `.continue/skills/` | `/openspec-apply-change` | `.continue/prompts/` | `/opsx-apply` |
|
||||
| CoStrict | `costrict` | `.cospec/skills/` | `/openspec-apply-change` | `.cospec/openspec/commands/` | `/opsx-apply` |
|
||||
| Crush | `crush` | `.crush/skills/` | `/openspec-apply-change` | `.crush/commands/opsx/` | `/opsx:apply` |
|
||||
| Cursor | `cursor` | `.cursor/skills/` | `/openspec-apply-change` | `.cursor/commands/` | `/opsx-apply` |
|
||||
| DeepSeek Harness | `dsh` | `.dsh/skills/` | `/openspec-apply-change` | none | none |
|
||||
| Devin Desktop (formerly Windsurf) | `devin` | `.devin/skills/` | `/openspec-apply-change` | `.devin/workflows/` | `/opsx-apply` |
|
||||
| EasyCode | `easycode` | `.easycode/skills/` | `/openspec-apply-change` | `.easycode/commands/opsx/` | `/opsx:apply` |
|
||||
| Factory Droid | `factory` | `.factory/skills/` | `/openspec-apply-change` | `.factory/commands/` | `/opsx-apply` |
|
||||
| ForgeCode | `forgecode` | `.forge/skills/` | `/openspec-apply-change` | none | none |
|
||||
| Gemini CLI | `gemini` | `.gemini/skills/` | `/openspec-apply-change` | `.gemini/commands/opsx/` | `/opsx:apply` |
|
||||
| GigaCode | `gigacode` | `.gigacode/skills/` | `/openspec-apply-change` | `.gigacode/commands/` | `/opsx-apply` |
|
||||
| GitHub Copilot | `github-copilot` | `.github/skills/` | `/openspec-apply-change` | `.github/prompts/` | `/opsx-apply` |
|
||||
| Grok Build | `grok` | `.grok/skills/` | `/openspec-apply-change` | none | none |
|
||||
| GSD | `gsd` | `.agents/skills/` | ask for `openspec-apply-change` | none | none |
|
||||
| Hermes Agent | `hermes` | `.hermes/skills/` | `/openspec-apply-change` | none | none |
|
||||
| iFlow | `iflow` | `.iflow/skills/` | `/openspec-apply-change` | `.iflow/commands/` | `/opsx-apply` |
|
||||
| Junie | `junie` | `.junie/skills/` | `/openspec-apply-change` | `.junie/commands/` | `/opsx-apply` |
|
||||
| Kilo Code | `kilocode` | `.kilocode/skills/` | `/openspec-apply-change` | `.kilo/command/` | `/opsx-apply` |
|
||||
| Kimi Code | `kimi` | `.kimi-code/skills/` | `/skill:openspec-apply-change` | none | none |
|
||||
| Kiro | `kiro` | `.kiro/skills/` | `/openspec-apply-change` | `.kiro/prompts/` | `/opsx-apply` |
|
||||
| Lingma | `lingma` | `.lingma/skills/` | `/openspec-apply-change` | `.lingma/commands/opsx/` | `/opsx:apply` |
|
||||
| MiniMax Code | `minimax-code` | `~/.minimax/skills/` (global) | `/openspec-apply-change` | none | none |
|
||||
| Mistral Vibe | `vibe` | `.vibe/skills/` | `/openspec-apply-change` | none | none |
|
||||
| Oh My Pi | `oh-my-pi` | `.omp/skills/` | `/openspec-apply-change` | `.omp/commands/` | `/opsx-apply` |
|
||||
| OpenCode | `opencode` | `.opencode/skills/` | `/openspec-apply-change` | `.opencode/commands/` | `/opsx-apply` |
|
||||
| Pi | `pi` | `.pi/skills/` | `/openspec-apply-change` | `.pi/prompts/` | `/opsx-apply` |
|
||||
| Qoder | `qoder` | `.qoder/skills/` | `/openspec-apply-change` | `.qoder/commands/opsx/` | `/opsx:apply` |
|
||||
| Qwen Code | `qwen` | `.qwen/skills/` | `/openspec-apply-change` | `.qwen/commands/` | `/opsx-apply` |
|
||||
| Trae | `trae` | `.trae/skills/` | `/openspec-apply-change` | `.trae/commands/` | `/opsx-apply` |
|
||||
| [Veai](https://veai.ru/docs/veai/download) | `veai` | `.veai/skills/` | `/openspec-apply-change` | none | none |
|
||||
| Warp | `warp` | `.warp/skills/` | `/openspec-apply-change` | none | none |
|
||||
| ZCode | `zcode` | `.zcode/skills/` | `/openspec-apply-change` | `.zcode/commands/opsx/` | `/opsx:apply` |
|
||||
| Zoo Code | `roocode` | `.roo/skills/` | `/openspec-apply-change` | `.roo/commands/` | `/opsx-apply` |
|
||||
| Other / Universal | `agents` | `.agents/skills/` | `/openspec-apply-change` | none | none |
|
||||
|
||||
- **Skill invocation**: whether a tool registers skills as typed entries is the tool's
|
||||
own behavior. The column shows the spelling OpenSpec uses in generated files and in
|
||||
the hint init prints. Check your tool's docs if typing it does nothing.
|
||||
- **Command file formats**: most tools take `.md` command files. EasyCode and Gemini
|
||||
CLI take `.toml`, Continue `.prompt`, and Code Studio, Kiro, and GitHub Copilot
|
||||
`.prompt.md`. The spelling you type is the same either way.
|
||||
|
||||
## Per-tool notes
|
||||
|
||||
A tool not listed here behaves exactly as its row reads.
|
||||
|
||||
### Amp
|
||||
|
||||
- **Project skills**: Amp reads OpenSpec skills from `.agents/skills/`.
|
||||
- **No command files**: Amp runs skills directly, so init skips command generation.
|
||||
- **Shared folder**: Amp shares `.agents/skills/` with Antigravity, Codex, Zed Agent,
|
||||
and the `agents` target. OpenSpec writes the skill tree once.
|
||||
|
||||
### Antigravity
|
||||
|
||||
- **Current folder**: Antigravity v1.20.5 and later read workspace skills and
|
||||
workflows from `.agents/`.
|
||||
- **Legacy folder**: after OpenSpec writes replacements, it removes equivalent
|
||||
generated files from `.agent/`. Custom files and changed generated files stay in
|
||||
`.agent/` for you to review.
|
||||
- **Shared skills**: Antigravity shares `.agents/skills/` with Amp, Codex, Zed Agent,
|
||||
and the `agents` target. OpenSpec writes that skill tree once while still writing
|
||||
Antigravity commands to `.agents/workflows/`.
|
||||
|
||||
### Cline
|
||||
|
||||
Cline reads commands from `.clinerules/workflows/`, not from its `.cline/` folder.
|
||||
Skills stay in `.cline/skills/`.
|
||||
|
||||
### Codex
|
||||
|
||||
- **CLI and IDE extension**: mention `$openspec-propose` with your idea, or run
|
||||
`/skills` to select the skill. Codex does not recognize `/openspec-propose`
|
||||
([upstream issue](https://github.com/openai/codex/issues/11817)).
|
||||
- **Desktop app**: open Skills in the sidebar and select `openspec-propose`.
|
||||
[OpenAI's skills documentation](https://learn.chatgpt.com/docs/build-skills)
|
||||
describes both interfaces.
|
||||
- **No command files**: Codex runs skills directly, so init skips commands even when
|
||||
delivery includes them and prints `Commands skipped for: codex (uses skills)`.
|
||||
- **Shared folder**: Codex skills land in `.agents/skills/`, the same tree Amp,
|
||||
Antigravity, Zed Agent, and the `agents` target use. Selecting more than one keeps a
|
||||
single compatible tree, and its handoffs spell both `$openspec-*` and `/openspec-*`
|
||||
when Codex owns it.
|
||||
- **Legacy path**: skills installed under `.codex/skills/` by older versions are
|
||||
migrated on the next `openspec update`.
|
||||
|
||||
### DeepSeek Harness
|
||||
|
||||
- **Project root**: DSH uses the nearest `.git` ancestor, or the current directory
|
||||
outside Git. Run `openspec init --tools dsh` there. For a nested OpenSpec project,
|
||||
add the absolute path to its `.dsh/skills/` directory to DSH's `customSkillDirs`.
|
||||
Git-root skills still win if names overlap
|
||||
([upstream discovery rules](https://github.com/deepseek-ai/deepseek-harness/tree/master/packages/skill/skill-filesystem)).
|
||||
- **Priority**: `.dsh/skills/` takes precedence over same-named skills in
|
||||
`.agents/skills/`.
|
||||
- **Delivery**: use `skills` or `both`. With `commands`, no DSH workflows are
|
||||
installed. Change delivery with `openspec config profile`, then rerun
|
||||
`openspec init --tools dsh`.
|
||||
|
||||
### Devin Desktop (formerly Windsurf)
|
||||
|
||||
- **Two agents**: command files in `.devin/workflows/` work only in Devin Desktop.
|
||||
Devin Local runs skills only, so generated skills reference `/openspec-<skill>`,
|
||||
which works in both.
|
||||
- **Rename**: `--tools windsurf` still resolves to `devin`. A project holding
|
||||
OpenSpec files in the legacy `.windsurf/` folder is offered the move on the next
|
||||
`openspec update`.
|
||||
|
||||
### GitHub Copilot
|
||||
|
||||
- **IDE extensions (command delivery)**: VS Code, JetBrains, and Visual Studio load
|
||||
`.github/prompts/opsx-<id>.prompt.md` as `/opsx-<id>`. If a command disappears
|
||||
while its file still exists, restart the IDE.
|
||||
- **Copilot CLI (skill delivery)**: the CLI ignores `.github/prompts/` and loads
|
||||
`.github/skills/openspec-*/SKILL.md` instead. Invoke a skill as
|
||||
`/openspec-<skill>`. If a skill disappears while its file still exists, run
|
||||
`/skills reload`, then `/skills info openspec-propose` to confirm discovery.
|
||||
|
||||
### GSD
|
||||
|
||||
- **Project skills**: GSD reads OpenSpec workflows from
|
||||
[`.agents/skills/`](https://github.com/open-gsd/gsd-pi/blob/main/docs/user-docs/skills.md).
|
||||
- **Invocation**: ask GSD to use the `openspec-<workflow>` skill. GSD can also select
|
||||
a matching skill through its skill discovery setting.
|
||||
- **No subagent files**: [`.gsd/agents/`](https://github.com/open-gsd/gsd-pi/blob/main/docs/user-docs/subagents.md)
|
||||
contains GSD subagent definitions. OpenSpec does not write workflow skills there.
|
||||
|
||||
### Hermes Agent
|
||||
|
||||
Hermes loads skills only from `~/.hermes/skills/` by default. Add the project's
|
||||
`.hermes/skills/` folder to `skills.external_dirs` in `~/.hermes/config.yaml`;
|
||||
init prints this reminder after install.
|
||||
|
||||
### MiniMax Code
|
||||
|
||||
- **Global only**: skills go to `~/.minimax/skills/`. Nothing is written inside
|
||||
the repo.
|
||||
- **Safe across projects**: a commands-only delivery leaves the global skills in
|
||||
place, so one project's setting cannot remove skills another project uses.
|
||||
|
||||
### Warp
|
||||
|
||||
- **Skills always**: skills go to `.warp/skills/` even when delivery is `commands`,
|
||||
because Warp has no command files and invokes skills directly.
|
||||
- **What OpenSpec claims**: only `.warp/skills/`. Warp settings and `WARP.md` are
|
||||
not created or edited.
|
||||
|
||||
### Other / Universal (shared `.agents` skills)
|
||||
|
||||
- **When it fits**: any tool that reads the shared `.agents/skills/` folder,
|
||||
including tools with no row in the matrix. It is the entry to pick when your
|
||||
assistant is not listed. The init picker's search box finds it by `universal`,
|
||||
`other`, `generic`, `custom`, `proprietary`, `unlisted`, `unsupported`,
|
||||
`vendor-neutral`, or `agents.md`.
|
||||
- **Alongside other targets**: Amp, Antigravity, Codex, Zed Agent, and this target share
|
||||
one physical skill tree. OpenSpec records one writer in `.openspec-target` and
|
||||
writes the tree once per run. Each tool's separate command files are still
|
||||
generated.
|
||||
- **What OpenSpec claims**: only the `openspec-*` folders and the
|
||||
`.openspec-target` marker. Anything else under `.agents/` is left alone.
|
||||
- **`AGENTS.md`**: not created or edited. The target is the `.agents/` folder, not
|
||||
the file.
|
||||
@@ -1,45 +0,0 @@
|
||||
# Where every current page goes
|
||||
|
||||
The old-to-new mapping: the source material for each `docs-lab/` page while drafting,
|
||||
and the redirect list at cutover. The target structure is the page index in
|
||||
[README.md](README.md).
|
||||
|
||||
| Current (`docs/`) | Destination |
|
||||
|---|---|
|
||||
| README.md (index) | `start/overview.md`, rewritten as pitch and routing |
|
||||
| getting-started.md | `start/quickstart.md` |
|
||||
| installation.md | split: `start/installation.md` (machine-level: matrix, update, uninstall) · `start/setup.md` (project-level: init, what init writes, skills-vs-commands delivery, stores router) |
|
||||
| how-commands-work.md | `start/quickstart.md` (inline labels) · `help/faq.md` · `help/troubleshooting.md` |
|
||||
| existing-projects.md | `guides/existing-codebases.md` ("Existing codebases"); walkthrough half to `start/quickstart.md` |
|
||||
| overview.md | `guides/concepts.md` |
|
||||
| concepts.md | `guides/concepts.md` (core) · delta format to `reference/schemas/spec-driven/index.md` (Delta specs section) · embedded glossary table deleted |
|
||||
| explore.md | `guides/explore.md` |
|
||||
| workflows.md | `guides/apply.md` (execution patterns, continue/ff) · `reference/skills.md` |
|
||||
| opsx.md | split four ways: config to `customize/project-config.md` · commands to `reference/skills.md` · philosophy to `guides/concepts.md` · architecture to `reference/architecture/` |
|
||||
| reviewing-changes.md + writing-specs.md | `guides/review-the-plan.md` (merged) |
|
||||
| editing-changes.md | `guides/change-course.md` |
|
||||
| team-workflow.md | `guides/teams.md` |
|
||||
| examples.md | parked: `guides/examples.md` skeleton kept off the index and sync config until real archived changes exist (see README TODOs) |
|
||||
| customization.md | `customize/project-config.md` + `customize/schemas.md` + `customize/overview.md` (decision ladder) · schema.yaml fields to `reference/schemas/schema-yaml.md` |
|
||||
| multi-language.md | `customize/project-config.md` §context, the "Another language" note |
|
||||
| stores-beta/user-guide.md | `multi-repo/stores.md` · worksets section to `multi-repo/worksets.md` |
|
||||
| commands.md | `reference/skills.md` (legacy `/openspec:*` section removed) |
|
||||
| cli.md | `reference/cli.md` (minus install, which moves to `start/installation.md`) |
|
||||
| supported-tools.md | `reference/supported-tools.md` |
|
||||
| glossary.md | `reference/glossary.md` |
|
||||
| faq.md | `help/faq.md` (unpublished-model claim deleted; update/uninstall to `start/installation.md`) |
|
||||
| troubleshooting.md | `help/troubleshooting.md`, canonical home for all 5 copies, plus Getting help |
|
||||
| migration-guide.md | `help/legacy/migration.md` (demoted) |
|
||||
| agent-contract.md | **off-site**, to repo-side contributor docs |
|
||||
|
||||
New pages with no single current source: `customize/overview.md`, `customize/profiles.md`
|
||||
(today: scattered two-line fragments across 12 pages), and the
|
||||
`reference/schemas/` and `reference/configuration/` sections (which replaced the
|
||||
planned `reference/file-formats.md`).
|
||||
|
||||
## Cutover
|
||||
|
||||
Point `website/docs.sync.config.mjs` here, add old-to-new redirects in
|
||||
`website/public/_redirects`, and verify `llms.txt` / `llms-full.txt` /
|
||||
per-page markdown routes. `docs/` stays in place, untouched. The site just
|
||||
stops reading it.
|
||||
@@ -1,168 +0,0 @@
|
||||
# Installation
|
||||
|
||||
> Install the `openspec` CLI on your machine, update it, and uninstall it.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
OpenSpec runs on Node.js 20.19.0 or newer. Homebrew installs Node.js as a
|
||||
dependency, and the Nix package includes the runtime. Check your installed version
|
||||
before using another install method.
|
||||
|
||||
In your terminal:
|
||||
|
||||
```bash
|
||||
node --version
|
||||
```
|
||||
|
||||
If that prints `v20.19.0` or higher, you're set. If not, install a newer Node from
|
||||
[nodejs.org](https://nodejs.org) or through your version manager (nvm, fnm, asdf,
|
||||
volta). You can skip this check when you install with Homebrew or Nix.
|
||||
|
||||
The workflow itself runs inside an AI coding tool: Claude Code, Cursor, or any other tool on the [supported list](../reference/supported-tools.md).
|
||||
|
||||
## Install with your AI assistant
|
||||
|
||||
Paste this into your AI chat:
|
||||
|
||||
```text
|
||||
Fetch https://raw.githubusercontent.com/Fission-AI/OpenSpec/main/install.md and follow it.
|
||||
```
|
||||
|
||||
Or, in your terminal, pipe it into a CLI agent (Claude Code shown):
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/Fission-AI/OpenSpec/main/install.md | claude
|
||||
```
|
||||
|
||||
That fetches [install.md at the repo root](https://github.com/Fission-AI/OpenSpec/blob/main/install.md), a prompt written for any agent that can run shell commands (a few IDE integrations can't). Expect your assistant to:
|
||||
|
||||
1. Check your Node version, and stop if it's older than 20.19.0.
|
||||
2. Skip the install if the CLI is already on your machine. Otherwise, show you the install command and wait for your confirmation before running it.
|
||||
3. Verify `openspec` is on your PATH.
|
||||
4. Name the folder it thinks you mean, suggest the AI tool you're already talking to, and ask which others you use, then run `openspec init` there (the [project setup](setup.md) step).
|
||||
5. Report what init created and the exact spelling to invoke OpenSpec in your tool.
|
||||
|
||||
It stops before anything privileged and never edits your shell startup files. The [manual methods below](#install-methods) are the source of truth, and the prompt runs them for you.
|
||||
|
||||
This install method is new and can have varying results depending on model used. Only use if you're comfortable correcting AI mistakes. Otherwise we recommend following the standard method below.
|
||||
|
||||
## Install methods
|
||||
|
||||
Install the CLI globally; [setting up your project](setup.md) comes after.
|
||||
|
||||
In your terminal:
|
||||
|
||||
```npm
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
```
|
||||
|
||||
### Homebrew
|
||||
|
||||
Homebrew installs OpenSpec and its Node.js dependency on macOS or Linux. In your terminal:
|
||||
|
||||
```bash
|
||||
brew install openspec
|
||||
```
|
||||
|
||||
The formula is published in [homebrew-core](https://formulae.brew.sh/formula/openspec), so you don't need to add a tap.
|
||||
|
||||
### Yarn
|
||||
|
||||
`yarn global add` is Yarn Classic (1.x) only. Modern Yarn removed global installs, so use npm, pnpm, or bun instead. A global CLI doesn't have to share your project's package manager.
|
||||
|
||||
### Bun
|
||||
|
||||
Bun installs OpenSpec but doesn't run it, so you still need Node on your machine (the [prerequisite](#prerequisites) above). Without it, every command fails with `env: node: No such file or directory`. Bun treats [every Node CLI](https://bun.com/docs/pm/bunx#shebangs) this way.
|
||||
|
||||
### Deno
|
||||
|
||||
Deno installs the CLI from npm and needs explicit permission flags. In your terminal:
|
||||
|
||||
```bash
|
||||
deno install --global \
|
||||
--allow-read --allow-write --allow-env --allow-sys=cpus,homedir --allow-net=edge.openspec.dev \
|
||||
npm:@fission-ai/openspec@latest
|
||||
```
|
||||
|
||||
Some commands launch another program: [`openspec config edit`](../reference/cli.md) opens your editor. Deno interrupts those with a permission prompt on every run. To stop it asking, add a scoped `--allow-run=<program>` to the install command.
|
||||
|
||||
> [!NOTE]
|
||||
> If Deno can't resolve `@latest`, pin a version range instead: `npm:@fission-ai/openspec@^1.7.0`.
|
||||
|
||||
### Nix
|
||||
|
||||
The OpenSpec repo ships a Nix flake. Install it into your profile. In your terminal:
|
||||
|
||||
```bash
|
||||
nix profile install github:Fission-AI/OpenSpec
|
||||
```
|
||||
|
||||
Or run a one-off command first, without installing:
|
||||
|
||||
```bash
|
||||
nix run github:Fission-AI/OpenSpec -- --version
|
||||
```
|
||||
|
||||
That leaves nothing on your PATH, so there's no install to check afterward.
|
||||
|
||||
To put OpenSpec in a project dev shell instead, add the flake as an input and use its default package; [flake.nix](https://github.com/Fission-AI/OpenSpec/blob/main/flake.nix) lists the outputs.
|
||||
|
||||
The Nix package ships the Bash, Fish, and Zsh completion scripts at the standard
|
||||
locations (`share/bash-completion/completions`, `share/fish/vendor_completions.d`,
|
||||
`share/zsh/site-functions`), so they load with the package and there is no need to run
|
||||
`openspec completion install`.
|
||||
|
||||
### Check it worked
|
||||
|
||||
Whichever method you used, in your terminal:
|
||||
|
||||
```bash
|
||||
openspec --version
|
||||
```
|
||||
|
||||
If that prints a version number, the CLI is on your PATH. It installs once per machine.
|
||||
|
||||
Next, [set up your project](setup.md). If your assistant already ran init, that page shows what it wrote and how to adjust it.
|
||||
|
||||
## Updating
|
||||
|
||||
In your terminal, in each project where you ran init:
|
||||
|
||||
```bash
|
||||
openspec update
|
||||
```
|
||||
|
||||
When a newer CLI is out, [`openspec update`](../reference/cli.md#openspec-update) says so and can install it for you; that upgrade is once per machine. Every run refreshes the project's generated skills and commands, which never update on their own. A current project prints `✓ All 2 tool(s) up to date (v1.7.0)`.
|
||||
|
||||
|
||||
> [!WARNING]
|
||||
> On Homebrew, run `brew upgrade openspec`. On Deno, re-run the [Deno install](#deno) with `-f`; it won't overwrite the installed command without it. On Nix, use `nix profile upgrade openspec`.
|
||||
|
||||
> [!NOTE]
|
||||
> A global npm install belongs to one Node installation. Switch Node versions with nvm and the `openspec` command doesn't come along, so install it again under the new version.
|
||||
|
||||
## Uninstalling
|
||||
|
||||
To uninstall OpenSpec, run through the steps below; none of them touch your source code. You can also point your agent at this section and let it handle the removal.
|
||||
|
||||
**1. Remove [shell completions](../reference/cli.md#openspec-completion)**, if you set them up, while the CLI can still do it. In your terminal:
|
||||
|
||||
```bash
|
||||
openspec completion uninstall
|
||||
```
|
||||
|
||||
**2. Remove the package.** In your terminal:
|
||||
|
||||
```npm
|
||||
npm uninstall -g @fission-ai/openspec
|
||||
```
|
||||
|
||||
On Homebrew: `brew uninstall openspec`. On Deno: `deno uninstall --global openspec`. On Nix: `nix profile remove openspec`. Your shell should no longer find `openspec`.
|
||||
|
||||
**3. Delete what's left, or keep it.**
|
||||
|
||||
- Generated agent files: `openspec-*` skills and `opsx` commands under directories like `.claude/` or `.agents/`, per project. [Supported tools](../reference/supported-tools.md) lists each tool's paths; MiniMax Code keeps skills in `~/.minimax/skills`.
|
||||
- Leftovers from older versions: marker blocks in `CLAUDE.md` or `AGENTS.md` (delete the block, keep the file) and `opsx-*.md` prompts in `~/.codex/prompts`.
|
||||
- The `openspec/` folder: pause first. `specs/` and `changes/archive/` are your record of the system, plain Markdown that reads fine without OpenSpec.
|
||||
- Per-machine state: settings and the telemetry id in `~/.config/openspec/`; schema overrides and store registrations in `~/.local/share/openspec/` (Windows: `%APPDATA%\openspec`, `%LOCALAPPDATA%\openspec`). Registrations are pointers; the store repos they point to are untouched.
|
||||
@@ -1,14 +0,0 @@
|
||||
# Overview
|
||||
|
||||
TODO: this page is being rewritten from scratch.
|
||||
|
||||
<!-- Emptied 2026-08-21. The previous skeleton (section headings, narrative beats, and
|
||||
the diagram-options gallery) was cleared so the page starts clean. The old goal line
|
||||
("OpenSpec gives you and your coding agent a shared, reviewable plan before code is
|
||||
written") was dropped as too weak a pitch: the rewrite should sell keeping larger
|
||||
features on track and aligned (teams, git-native artifacts, intended behavior matching
|
||||
implemented behavior, the control-loop framing). The brief is in docs-lab/Notes.md
|
||||
under "Start > Overview". The diagram candidates (docs-lab/diagrams/) were deleted
|
||||
with the gallery; recover them from git history if the rewrite wants a starting point.
|
||||
README rules that still bind the rewrite: the loop appears here as pitch only, copy and
|
||||
no explanation; the quickstart is its one teacher. -->
|
||||
@@ -1,187 +0,0 @@
|
||||
# Quickstart
|
||||
|
||||
> Your first change, from idea to archived, in a new or existing project.
|
||||
|
||||
Before you start, you need the CLI on your machine ([Installation](installation.md)) and OpenSpec initialized in your project ([Set up your project](setup.md)).
|
||||
|
||||
## Start from an empty project
|
||||
|
||||
You can start without a chosen stack or a complete architecture. Initialize OpenSpec in your project folder, then ask your agent to explore the options with you. In your AI chat:
|
||||
|
||||
```text
|
||||
Help me explore a task tracker from scratch. I have not picked a stack. Compare the options and help me choose the first behavior to build.
|
||||
```
|
||||
|
||||
Decide what the first change needs and leave later architecture choices open. Ask your agent to propose that one change, then follow the steps below. You can revisit the architecture as the project grows.
|
||||
|
||||
## The loop at a glance
|
||||
|
||||
Every change moves through the same five steps: you think the idea through with your agent, it drafts a plan, you correct the plan before any code exists, the agent builds from it, and archiving updates your specs with what shipped.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
explore["1 · Explore<br/>think it through together"] --> propose["2 · Propose<br/>agent drafts the plan"]
|
||||
propose --> review["3 · Review<br/>you correct the plan"]
|
||||
review --> apply["4 · Apply<br/>agent builds, task by task"]
|
||||
apply --> archive["5 · Archive<br/>specs absorb the change"]
|
||||
archive -. "next change" .-> explore
|
||||
```
|
||||
|
||||
Every prompt below goes in your AI chat, the same place you ask for code. The examples use plain language so they work across tools. You can also invoke a skill directly; the syntax varies by tool ([supported tools](../reference/supported-tools.md)).
|
||||
|
||||
## Step 1: Explore
|
||||
|
||||
Think the idea through with your agent before you ask for a plan. In your AI chat:
|
||||
|
||||
```text
|
||||
Help me explore how rate limiting should work in this app.
|
||||
```
|
||||
|
||||
Explore is a thinking mode. The agent investigates your codebase, asks the questions that matter, sketches options, and challenges assumptions. It never writes code. It writes nothing else unless you ask it to capture what you decided, or say yes when it offers. The output is a sharper idea.
|
||||
|
||||
Stay here as long as the problem needs. When the shape feels right, hand it off:
|
||||
|
||||
```text
|
||||
Propose the change we just discussed.
|
||||
```
|
||||
|
||||
That line starts propose for you, carrying everything you settled. Skip the first prompt in step 2.
|
||||
|
||||
## Step 2: Propose
|
||||
|
||||
Propose turns the idea into a reviewable plan. Coming from explore, it's already running. Starting cold, when the change is clear in your head, ask directly. In your AI chat:
|
||||
|
||||
```text
|
||||
Propose a change to add rate limiting.
|
||||
```
|
||||
|
||||
The agent asks what it needs to, then writes a change folder:
|
||||
|
||||
```
|
||||
openspec/changes/add-rate-limiting/
|
||||
├── proposal.md why, and what changes
|
||||
├── specs/ what "done" means, as testable requirements
|
||||
├── design.md technical decisions (only when the change needs one)
|
||||
└── tasks.md the implementation checklist
|
||||
```
|
||||
|
||||
No code yet. Propose stops at the plan.
|
||||
|
||||
## Step 3: Review and correct the plan
|
||||
|
||||
Fix the plan while it's still words and nothing is built yet. Read in this order:
|
||||
|
||||
- **`proposal.md`**: is this the right problem, at the right size?
|
||||
- **`specs/`**: the highest-value read. Would you accept these requirements as done?
|
||||
- **`tasks.md`**: do the tasks cover the specs, and nothing more?
|
||||
|
||||
To fix something, either works:
|
||||
|
||||
- Edit the file yourself. The artifacts are plain markdown, and the files are the plan.
|
||||
- Tell your agent what's wrong ("the spec is missing the unauthenticated case"). It revises the artifacts.
|
||||
|
||||
## Step 4: Apply
|
||||
|
||||
Apply turns the plan into code. Start a fresh chat session, since implementation goes better on a clean context window. In your AI chat:
|
||||
|
||||
```text
|
||||
Apply the add-rate-limiting change.
|
||||
```
|
||||
|
||||
The agent reads the change folder, then works through `tasks.md`, checking off each task as it lands.
|
||||
|
||||
- **Interrupted, or out of context?** Open a new session and ask it to apply again. It resumes at the first unchecked task.
|
||||
- **Plan turned out wrong?** Fix the artifacts (either way from step 3), then continue applying.
|
||||
- **Progress** lives in the `tasks.md` checkboxes. There is no hidden state.
|
||||
|
||||
## Step 5: Archive
|
||||
|
||||
Archiving does two things: it updates your main specs with the change's requirements, and it moves the change folder into the archive folder (in `/openspec/changes/archive/*`).
|
||||
|
||||
When every box in `tasks.md` is checked, in your AI chat:
|
||||
|
||||
```text
|
||||
Archive the add-rate-limiting change.
|
||||
```
|
||||
|
||||
Step through what archiving does:
|
||||
|
||||
```file-steps
|
||||
## The finished change
|
||||
> Implementation is done. The delta spec (what this change adds) still sits inside the change folder; specs/ doesn't know about rate limiting yet.
|
||||
openspec/
|
||||
├── specs/ (no rate-limiting spec yet)
|
||||
└── changes/
|
||||
└── add-rate-limiting/
|
||||
├── proposal.md
|
||||
├── tasks.md every box checked
|
||||
└── specs/
|
||||
└── rate-limiting/
|
||||
└── spec.md the delta: ADDED requirements
|
||||
|
||||
## Requirements land in specs/
|
||||
> Each requirement in the delta lands in the main spec: added ones append, modified ones replace their old version. A new capability gets a new spec file.
|
||||
openspec/
|
||||
├── specs/
|
||||
+ │ └── rate-limiting/
|
||||
+ │ └── spec.md gains "Requirement: Rate limiting"
|
||||
└── changes/
|
||||
└── add-rate-limiting/
|
||||
└── specs/
|
||||
└── rate-limiting/
|
||||
└── spec.md the delta, source of the merge
|
||||
|
||||
## The folder moves to archive/
|
||||
> The whole change folder, delta included, moves into the archive under a date prefix. Nothing is deleted.
|
||||
openspec/
|
||||
├── specs/
|
||||
│ └── rate-limiting/
|
||||
│ └── spec.md
|
||||
└── changes/
|
||||
- └── add-rate-limiting/
|
||||
+ └── archive/
|
||||
+ └── 2026-08-08-add-rate-limiting/
|
||||
+ ├── proposal.md
|
||||
+ ├── tasks.md
|
||||
+ └── specs/rate-limiting/spec.md
|
||||
|
||||
## Specs describe the system as built
|
||||
> changes/ is clear for the next change. specs/ is the source of truth for what the system does; archive/ is the history of how it got there.
|
||||
openspec/
|
||||
├── specs/
|
||||
│ └── rate-limiting/
|
||||
│ └── spec.md the spec as built
|
||||
└── changes/
|
||||
└── archive/
|
||||
└── 2026-08-08-add-rate-limiting/
|
||||
```
|
||||
|
||||
Git is a separate concern. Commit the change folder with the code, and nothing else about your workflow changes.
|
||||
|
||||
### Keep or prune archived changes
|
||||
|
||||
`openspec/changes/archive/` keeps the proposal, design, tasks, and delta for each finished change. In the archive flow above, the delta has already updated `openspec/specs/`.
|
||||
|
||||
- **Keep the whole change folder** when you want a self-contained record in the current checkout.
|
||||
- **Remove an archived change's `specs/` folder** when Git is your spec history. Commit the archive first, then delete `openspec/changes/archive/<change>/specs/`. The proposal, design, and tasks remain in the checkout. `openspec validate --archived` still works because it checks task completion, not applied deltas.
|
||||
- **Remove the whole change folder** only when you no longer need its proposal, design, or task history in the checkout. The current specs do not change, but `openspec validate --archived` and searches of the checkout no longer include that change.
|
||||
|
||||
> [!WARNING]
|
||||
> Keep the archive commit in your repository history if you want Git to retain the deleted files. Squashing the archive and cleanup commits together removes that intermediate snapshot.
|
||||
|
||||
OpenSpec does not prune archived changes automatically or provide a retention setting.
|
||||
|
||||
## Going further
|
||||
|
||||
- [Delta specs](../reference/schemas/spec-driven/index.md#delta-specs-specmd): how to write the behavior changes in a delta spec.
|
||||
- [Profiles](../customize/profiles.md): optional workflows beyond the core set (verify before archive, incremental planning).
|
||||
|
||||
## Advanced guides
|
||||
|
||||
<!-- Planned pages, not yet written or in the README page map. Listed here so the quickstart routes to them once they exist. -->
|
||||
|
||||
Not written yet; guides we plan to add:
|
||||
|
||||
- **Prototype first**: spike the code before any spec, then backfill the proposal from what the prototype taught you.
|
||||
- **Building iteratively**: a sequence of small changes instead of one big proposal.
|
||||
- **Revising an implemented change**: the plan needs to move again after apply, but the change hasn't merged or archived yet.
|
||||
@@ -1,153 +0,0 @@
|
||||
# Set up your project
|
||||
|
||||
> Add OpenSpec to a project: run init, see what it wrote, and adjust it.
|
||||
|
||||
## Pick where OpenSpec lives
|
||||
|
||||
- **In your repo (the default)**: specs and changes sit next to the code they describe and are versioned with it. The rest of this page follows this path.
|
||||
- **In a store**: a separate planning repo shared by the repos that use it, for multi-repo setups or keeping planning out of the repo entirely. [Stores (beta)](../multi-repo/stores.md) covers when that's worth it and how to set one up.
|
||||
|
||||
## Initialize your project
|
||||
|
||||
With the CLI installed ([Installation](installation.md)), run init at the root of your project. In your terminal:
|
||||
|
||||
```bash
|
||||
cd <your-project>
|
||||
openspec init
|
||||
```
|
||||
|
||||
Init asks which AI tools you use, writes the workflow files for the ones you pick, and reports what you got:
|
||||
|
||||
```
|
||||
OpenSpec Setup Complete
|
||||
|
||||
Created: Claude Code
|
||||
6 skills and 6 commands in .claude/
|
||||
Config: openspec/config.yaml (schema: spec-driven)
|
||||
```
|
||||
|
||||
Restart your IDE for the new commands to take effect.
|
||||
|
||||
Re-running init is safe:
|
||||
|
||||
- Tools you already set up print `Refreshed` instead of `Created`.
|
||||
- Running init again with a new tool selected adds that tool.
|
||||
- The `--tools` flag skips the picker ([CLI reference](../reference/cli.md)).
|
||||
|
||||
### Migrate an existing `project.md`
|
||||
|
||||
Init does not copy legacy `openspec/project.md` into `config.yaml`. It keeps the file and prints an AI-assisted migration request.
|
||||
|
||||
In your AI chat:
|
||||
|
||||
```
|
||||
Review openspec/project.md and migrate its useful content to openspec/config.yaml.
|
||||
Keep context concise: include only project-wide facts needed during artifact creation, apply, and archive.
|
||||
Move artifact-specific guidance into rules for the matching artifacts.
|
||||
Move guidance for apply or archive into the matching operations entry.
|
||||
Leave out generic, outdated, or verbose material. Do not delete project.md.
|
||||
```
|
||||
|
||||
Review `config.yaml`, then delete `project.md` when ready.
|
||||
|
||||
## What init installs
|
||||
|
||||
Running init creates two things in your project:
|
||||
|
||||
- An `openspec/` folder at the repo root
|
||||
- Workflow files (skills and commands) added to your AI tool's folder (`.agents/`, `.claude/`, etc.)
|
||||
|
||||
Commit all of it like the rest of your source. Init changes nothing else in your repo (if it finds leftovers from an older OpenSpec version, it asks before cleaning them up).
|
||||
|
||||
### The `openspec/` folder
|
||||
|
||||
Every OpenSpec artifact lives here, at the root of your project. Here's what that looks like:
|
||||
|
||||
```
|
||||
openspec/
|
||||
├── config.yaml project settings and context for the AI
|
||||
├── specs/ your specs (empty for now)
|
||||
└── changes/ in-motion changes (empty for now)
|
||||
└── archive/ completed changes move here
|
||||
```
|
||||
|
||||
[Project config](../customize/project-config.md) covers `config.yaml`.
|
||||
|
||||
### The workflow files (skills and commands)
|
||||
|
||||
These are the OpenSpec workflows, the actions you'll use as you work. Here they are as installed skills, in the shared `.agents/` folder most tools use:
|
||||
|
||||
```
|
||||
.agents/skills/
|
||||
├── openspec-explore/ think through an idea first
|
||||
├── openspec-propose/ propose a change
|
||||
├── openspec-apply-change/ implement a change's tasks
|
||||
├── openspec-update-change/ revise a change's plan
|
||||
├── openspec-sync-specs/ sync a change's spec updates into specs/
|
||||
├── openspec-archive-change/ move a finished change to the archive
|
||||
├── openspec-verify-change/ check the implementation matches the plan (not included by default)
|
||||
└── openspec-bulk-archive-change/ archive several changes at once (not included by default)
|
||||
```
|
||||
|
||||
This is the default set plus two optional workflows. [Profiles](../customize/profiles.md) lists all twelve.
|
||||
|
||||
By default each workflow installs in two forms:
|
||||
|
||||
- **Skill** (`openspec-apply-change`): instructions your agent picks up on its own when you ask for the work.
|
||||
- **Command** (`/opsx:apply` in Claude Code): a typed entry point for the same workflow, under a shorter name.
|
||||
|
||||
The two are functionally identical. A workflow's skill and its command carry the same instructions.
|
||||
|
||||
Why two: commands came first, and every tool spells them its own way. Skills are the newer standard shared across tools, but not every tool can invoke a skill directly, so commands stay as those tools' entry point.
|
||||
|
||||
Some tools install in skill form only. Where the tool runs skills directly, init skips commands and says so (`Commands skipped for: codex (uses skills)`).
|
||||
|
||||
We prefer skills and expect to retire commands eventually.
|
||||
|
||||
#### Change what gets installed
|
||||
|
||||
The interactive picker changes the delivery form and the workflow set ([Profiles](../customize/profiles.md)). In your terminal:
|
||||
|
||||
```bash
|
||||
openspec config profile
|
||||
```
|
||||
|
||||
Here's switching to skills only:
|
||||
|
||||
```
|
||||
Current profile settings
|
||||
Delivery: both
|
||||
|
||||
? What do you want to configure? Delivery only
|
||||
? Delivery mode (how workflows are installed): Skills only
|
||||
|
||||
Config changes:
|
||||
delivery: both -> skills
|
||||
? Apply changes to this project now? (Y/n) y
|
||||
```
|
||||
|
||||
Answering yes applies it to the current project on the spot. Other projects pick it up on their next `openspec update`. The setting is global, per machine.
|
||||
|
||||
#### Claude Code doesn't show the workflows
|
||||
|
||||
Claude Code loads OpenSpec workflows from one or both of these project paths, based on your delivery setting:
|
||||
|
||||
- **Skills**: `.claude/skills/openspec-*/SKILL.md`
|
||||
- **Commands**: `.claude/commands/opsx/<id>.md`
|
||||
|
||||
If the files are missing, refresh the project. In your terminal:
|
||||
|
||||
```bash
|
||||
openspec update
|
||||
```
|
||||
|
||||
If the command files exist but `/opsx:` shows no OpenSpec commands, update Claude Code and restart it. If commands still don't load, enable skills too. In your terminal:
|
||||
|
||||
```bash
|
||||
openspec config set delivery both
|
||||
openspec update
|
||||
```
|
||||
|
||||
Restart Claude Code, then run `/openspec-propose` in its chat. If only some workflows are missing, [change your profile](../customize/profiles.md#expanding-the-set-optional-workflows).
|
||||
|
||||
Setup is done. The [Quickstart](quickstart.md) takes your first change from here.
|
||||
-115
@@ -1,115 +0,0 @@
|
||||
# OpenSpec Documentation
|
||||
|
||||
Welcome. This is the home for everything OpenSpec.
|
||||
|
||||
OpenSpec helps you and your AI coding assistant **agree on what to build before any code is written.** You describe the change, the AI drafts a short spec and a task list, you both look at the same plan, and then the work happens. No more discovering halfway through that the AI built the wrong thing.
|
||||
|
||||
If you read nothing else, read these two pages:
|
||||
|
||||
1. [Getting Started](getting-started.md): install, initialize, and ship your first change.
|
||||
2. [How Commands Work](how-commands-work.md): where you actually type `/opsx:propose` (hint: in your AI chat, not the terminal). This trips up almost everyone once.
|
||||
|
||||
That second one matters more than it looks. OpenSpec has two halves: a command line tool you run in your terminal, and slash commands you give to your AI assistant. Knowing which is which saves you the most common moment of confusion.
|
||||
|
||||
> **The best habit to build first: when you're not sure what to build, start with `/opsx:explore`.** It's a no-stakes thinking partner that reads your code, weighs options, and sharpens a fuzzy idea into a concrete plan before any code gets written. The [Explore First](explore.md) guide makes the case.
|
||||
|
||||
## Pick your path
|
||||
|
||||
**I'm brand new.** Start with [Getting Started](getting-started.md), then skim the [Core Concepts at a Glance](overview.md). When something feels mysterious, the [FAQ](faq.md) and [Glossary](glossary.md) are nearby.
|
||||
|
||||
**I have a problem but not a plan.** This is the common case, and it has a dedicated answer: [Explore First](explore.md). Use `/opsx:explore` to think it through with the AI before committing to anything.
|
||||
|
||||
**I have a big existing codebase.** You don't document all of it. [Using OpenSpec in an Existing Project](existing-projects.md) shows how to start on real, brownfield code without boiling the ocean.
|
||||
|
||||
**I just want to get it working.** [Install](installation.md), run `openspec init`, then read [How Commands Work](how-commands-work.md) so your first slash command lands in the right place. Or hand the setup to your assistant with the [AI-assisted install prompt](installation.md#install-with-your-ai-assistant).
|
||||
|
||||
**I learn by example.** The [Examples & Recipes](examples.md) page walks through real changes start to finish: a small feature, a bug fix, a refactor, an exploration.
|
||||
|
||||
**The AI just drafted a plan — now what?** Read it. [Reviewing a Change](reviewing-changes.md) shows the two-minute pass that catches a wrong turn while it's still cheap, and [Writing Good Specs](writing-specs.md) covers what a plan worth approving is made of.
|
||||
|
||||
**I work on a team.** [OpenSpec on a Team](team-workflow.md) shows how a change maps onto a branch and a pull request, and how teammates review a plan before the code.
|
||||
|
||||
**I'm coming from the old workflow.** The [Migration Guide](migration-guide.md) explains what changed and why, and promises your existing work is safe.
|
||||
|
||||
**I want to bend it to my team's process.** [Customization](customization.md) covers project config, custom schemas, and shared context.
|
||||
|
||||
**Something's broken.** [Troubleshooting](troubleshooting.md) collects the failures people actually hit, with fixes.
|
||||
|
||||
## The whole map
|
||||
|
||||
### Start here
|
||||
|
||||
| Doc | What it gives you |
|
||||
|-----|-------------------|
|
||||
| [Getting Started](getting-started.md) | Install, initialize, and run your first change end to end |
|
||||
| [Explore First](explore.md) | Use `/opsx:explore` to think through an idea before you commit |
|
||||
| [How Commands Work](how-commands-work.md) | Where slash commands run, what "interactive mode" means, terminal vs chat |
|
||||
| [Core Concepts at a Glance](overview.md) | The whole mental model on one page: specs, changes, deltas, archive |
|
||||
| [Installation](installation.md) | npm, pnpm, yarn, bun, Nix, a prompt that hands setup to your AI assistant, and how to verify it worked |
|
||||
|
||||
### Use it day to day
|
||||
|
||||
| Doc | What it gives you |
|
||||
|-----|-------------------|
|
||||
| [Workflows](workflows.md) | Common patterns and when to reach for each command |
|
||||
| [Examples & Recipes](examples.md) | Full walkthroughs of real changes, copy-pasteable |
|
||||
| [Writing Good Specs](writing-specs.md) | What a strong requirement and scenario look like, and how to right-size a change |
|
||||
| [Reviewing a Change](reviewing-changes.md) | The two-minute pass on a drafted plan before any code is written |
|
||||
| [OpenSpec on a Team](team-workflow.md) | How changes fit branches, pull requests, and review |
|
||||
| [Using OpenSpec in an Existing Project](existing-projects.md) | Adopting OpenSpec on a large brownfield codebase |
|
||||
| [Editing & Iterating on a Change](editing-changes.md) | Update artifacts, go back, reconcile manual edits |
|
||||
| [Commands](commands.md) | Reference for every `/opsx:*` slash command |
|
||||
| [CLI](cli.md) | Reference for every `openspec` terminal command |
|
||||
|
||||
### Understand it deeply
|
||||
|
||||
| Doc | What it gives you |
|
||||
|-----|-------------------|
|
||||
| [Concepts](concepts.md) | The long-form explanation of specs, changes, artifacts, schemas, and archive |
|
||||
| [OPSX Workflow](opsx.md) | Why the workflow is fluid instead of phase-locked, plus an architecture deep dive |
|
||||
| [Glossary](glossary.md) | Every term defined in one place |
|
||||
|
||||
### Make it yours
|
||||
|
||||
| Doc | What it gives you |
|
||||
|-----|-------------------|
|
||||
| [Customization](customization.md) | Project config, custom schemas, shared context |
|
||||
| [Multi-Language](multi-language.md) | Generate artifacts in languages other than English |
|
||||
| [Supported Tools](supported-tools.md) | The 30+ AI tools OpenSpec integrates with, and where files land |
|
||||
| [Community Showcase](community.md) | Projects and resources built with and for OpenSpec |
|
||||
|
||||
### When you need help
|
||||
|
||||
| Doc | What it gives you |
|
||||
|-----|-------------------|
|
||||
| [FAQ](faq.md) | Quick answers to the questions people ask most |
|
||||
| [Troubleshooting](troubleshooting.md) | Concrete fixes for concrete failures |
|
||||
| [Migration Guide](migration-guide.md) | Moving from the legacy workflow to OPSX |
|
||||
|
||||
### Coordinate across repos (beta)
|
||||
|
||||
| Doc | What it gives you |
|
||||
|-----|-------------------|
|
||||
| [Stores: User Guide](stores-beta/user-guide.md) | Plan in its own repo when your work spans repos or teams |
|
||||
| [Agent Contract](agent-contract.md) | The machine-readable CLI surfaces agents drive |
|
||||
|
||||
## The thirty-second version
|
||||
|
||||
```text
|
||||
1. Install npm install -g @fission-ai/openspec@latest
|
||||
2. Initialize cd your-project && openspec init
|
||||
3. Explore (in your AI chat) /opsx:explore ← optional, but a great habit
|
||||
4. Propose (in your AI chat) /opsx:propose add-dark-mode
|
||||
5. Build (in your AI chat) /opsx:apply
|
||||
6. Archive (in your AI chat) /opsx:archive
|
||||
```
|
||||
|
||||
Steps 1 and 2 happen in your terminal. The rest happen in your AI assistant's chat. That split is the one thing worth memorizing, and [How Commands Work](how-commands-work.md) explains exactly why. Step 3 is optional, but starting with `/opsx:explore` when you're unsure is the habit most worth forming.
|
||||
|
||||
## Where else to get help
|
||||
|
||||
- **Discord:** [discord.gg/YctCnvvshC](https://discord.gg/YctCnvvshC) for questions, ideas, and help.
|
||||
- **GitHub Issues:** [github.com/Fission-AI/OpenSpec/issues](https://github.com/Fission-AI/OpenSpec/issues) for bugs and feature requests.
|
||||
- **`openspec feedback "your message"`** sends feedback straight from your terminal (it opens a GitHub issue).
|
||||
|
||||
Found something in these docs that's wrong, stale, or confusing? That's a bug. Open an issue or a PR. Documentation improvements are some of the most valuable contributions you can make.
|
||||
@@ -1,146 +0,0 @@
|
||||
# OpenSpec Agent Contract
|
||||
|
||||
Machine-readable surfaces of the `openspec` CLI, verified against `src/` (capstone audit, 2026-06-11). Every shape below is documented from the emitting code.
|
||||
|
||||
## 1. General conventions
|
||||
|
||||
- **One JSON document per invocation.** In `--json` mode, stdout carries exactly one JSON document (2-space pretty-printed). Human prose, spinners, and the store banner go to stderr.
|
||||
- **Store banner.** In human mode, a store-selected root prints `Using OpenSpec root: <id> (<path>)` to stderr. Never printed in JSON mode.
|
||||
- **Key casing is surface-dependent** (see Known inconsistencies): store/doctor/context payloads use `snake_case`; workflow payloads (`status`, `instructions`, `new change`, `validate`, `list`) use `camelCase`, except the embedded `root` object, which always uses `store_id`.
|
||||
- **Optional keys are omitted, not null**, in most payloads (e.g. `root.store_id`, `member.path`). Exceptions that use explicit `null` are called out per shape (store doctor `git.*`, failure payloads).
|
||||
|
||||
## 2. The diagnostic envelope
|
||||
|
||||
One envelope shape is shared by every machine-readable diagnostic (`StoreDiagnostic`):
|
||||
|
||||
```json
|
||||
{
|
||||
"severity": "error" | "warning" | "info",
|
||||
"code": "snake_case_string",
|
||||
"message": "human sentence",
|
||||
"target": "dotted.surface (optional)",
|
||||
"fix": "one actionable sentence/command (optional)"
|
||||
}
|
||||
```
|
||||
|
||||
Diagnostics appear in two positions: **status arrays** (`status: StoreDiagnostic[]` at top level or per entry) for health findings, and **thrown errors** converted to a single-element `status` array on command failure.
|
||||
|
||||
## 3. Root selection and `RootOutput`
|
||||
|
||||
All root-resolving commands (`list`, `show`, `validate`, `status`, `instructions`, `instructions apply`, `instructions archive`, `new change`, `archive`, `doctor`, `context`, `schemas`) resolve one OpenSpec root with one precedence:
|
||||
|
||||
1. `--store <id>` → the registered store's root (`source: "store"`).
|
||||
2. Otherwise, nearest ancestor with `openspec/`: planning shape → `source: "nearest"` (a `store:` pointer is ignored with a stderr warning); config-only dir with a valid `store:` pointer → that store, `source: "declared"`.
|
||||
3. No nearest root + global `defaultStore` set (`openspec config set defaultStore <id>`) → that store, `source: "global_default"`; a stale id fails with the underlying store error and a `fix` naming `openspec config unset defaultStore`.
|
||||
4. No nearest root, no default + registered stores exist → error `no_root_with_registered_stores`.
|
||||
5. No root, no default, no stores: commands may treat the cwd as `source: "implicit"`; `doctor`, `context`, `list`, and bulk `validate` instead fail with `no_openspec_root`. `list` preserves the implicit fallback for legacy projects with `openspec/project.md`.
|
||||
|
||||
Successful JSON payloads normally embed the root; successful `schemas --json`
|
||||
deliberately remains the compatibility bare array documented in §4.13:
|
||||
|
||||
```json
|
||||
"root": { "path": "/abs/path", "source": "store" | "declared" | "global_default" | "nearest" | "implicit", "store_id": "id (only when store-selected)" }
|
||||
```
|
||||
|
||||
**Root-failure contract**: in JSON mode a resolution failure prints `{ ...commandNullShape, "status": [diagnostic] }` on stdout and exits 1.
|
||||
|
||||
## 4. Command JSON shapes
|
||||
|
||||
### 4.1 `list --json`
|
||||
`{ "changes": [ { "name", "completedTasks", "totalTasks", "lastModified", "status": "no-tasks"|"complete"|"in-progress", "nested"?: ["<area>/<name>", ...] } ], "warnings"?: [ { "code", "name", "nested", "message" } ], "root": RootOutput }` — note the per-change `status` is a string enum here. `--specs`: `{ "specs": [ { "id", "requirementCount" } ], "root" }`.
|
||||
|
||||
`warnings` (omitted when empty) reports directories under `changes/` that are not changes. Today the only code is `nested_change_directory`: a namespace folder wrapping change directories, which OpenSpec cannot address because a change is always a directory directly under `changes/`. The same entry carries `nested` on the listed change, whose `status` is then meaningless. Do not treat such an entry as a change; report the message and leave the directories alone.
|
||||
|
||||
### 4.2 `show <item> --json`
|
||||
Change: `{ "id", "title", "deltaCount", "deltas": [...], "root" }`. Spec: `{ "id", "title", "overview", "requirementCount", "requirements": [...], "metadata": { "version", "format", "sourcePath"? }, "root" }`. A requirement, in a spec or in a change delta's `requirement`/`requirements`, is `{ "name", "text", "scenarios": [ { "name", "rawText" } ] }`. A requirement `name` is its header without `Requirement:` and without a closing `#` run, the exact name archive matches MODIFIED/REMOVED/RENAMED entries against. A scenario `name` is its level-4 header without `Scenario:` and without a closing `#` run, the name the MODIFIED scenario-loss check compares.
|
||||
|
||||
### 4.3 `validate --json`
|
||||
`{ "items": [ { "id", "type": "change"|"spec", "valid", "issues": [ { "level", "path", "message", "line"?, "column"? } ], "durationMs" } ], "summary": { "totals": {items,passed,failed}, "byType": {...} }, "version": "1.0", "root" }`. Exit 1 when any item fails.
|
||||
|
||||
### 4.4 `status --json`
|
||||
`{ "changeName", "schemaName", "planningHome"?: { "kind", "root", "changesDir", "defaultSchema" }, "changeRoot", "artifactPaths": { "<id>": {outputPath, resolvedOutputPath, existingOutputPaths} }, "nextSteps": ["..."], "actionContext": { "mode": "repo-local", "sourceOfTruth": "repo", "planningArtifacts", "linkedContext", "allowedEditRoots", "requiresAffectedAreaSelection", "constraints" }, "isPlanningComplete", "isComplete", "applyRequires", "artifacts": [ {id, outputPath, status: "done"|"skipped"|"ready"|"blocked", requires, missingDeps?} ], "root" }`. For a store-selected root, `allowedEditRoots` is `[<declaring project>, <store>]` when the nearest project on the current path is a config-only root whose `store:` pointer names that store, and `[<store>]` otherwise (including a global `defaultStore`), with a constraint telling the agent to ask which repository to edit. OpenSpec does not route a store's tasks to repos, so the declaring project is the current one, not every repo the change touches. `isPlanningComplete` means every non-skipped planning artifact exists; skipped artifacts count as satisfied without being created. It does not mean implementation tasks are complete. `isComplete` is retained as a compatibility alias with the same value. Each artifact's `requires` is its direct dependency ids (present for every status, so the transitive required set is computable even when the artifact is `done`); `missingDeps` appears only when `blocked`. The `artifacts` array is in dependency order, with the schema's `artifacts:` declaration order breaking ties between artifacts that become ready at the same time (never alphabetical), so the first `ready` entry is the artifact to write next; `missingDeps` uses that same order. `"skipped"` marks an artifact whose `generates` path is under `specs/` in a change whose `.openspec.yaml` declares `skip_specs: true`; it satisfies dependencies but must not be created. No active changes: `{ "changes": [], "message", "root" }`, exit 0.
|
||||
|
||||
`--all` (batch, mutually exclusive with `--change` — combining them is an error with the `{ "changes": [], "root": null, "status": [d] }` null-shape): `{ "changes": [ <per-change status object, no per-change root>, ... ], "root" }`, sorted by change name. A change that fails to load contributes `{ "changeName", "status": [d] }` in place; the sweep continues, preserves the complete envelope, and exits 1 in both text and JSON modes. An invalid `--schema` fails the whole invocation with the null-shape, even when no changes exist.
|
||||
|
||||
### 4.5 `instructions <artifact> --json`
|
||||
`{ "changeName", "artifactId", "schemaName", "changeDir", "planningHome"?, "outputPath", "resolvedOutputPath", "existingOutputPaths", "description", "instruction"?, "context"?, "rules"?, "references"?: ReferenceIndexEntry[], "skipped"?, "warning"?, "template", "dependencies": [{id,done,path,description,skipped?}], "unlocks", "root" }`. `unlocks` lists the artifacts this one makes ready, in the schema's declaration order (the same order `status` recommends them). `"skipped": true` (with `"warning"`) appears when the change declares `skip_specs: true` and this artifact is skipped — do not create its files. A dependency entry with `skipped: true` is satisfied without files — do not try to read its paths.
|
||||
|
||||
`ReferenceIndexEntry`: `{ "store_id", "root"?, "specs"?: [{id,summary}], "fetch"?, "status": [] }` — resolved entries carry root/specs/fetch; unresolved carry store_id + warning status. Index capped at 50KB (`reference_index_truncated`).
|
||||
|
||||
### 4.6 `instructions apply --json`
|
||||
`{ "changeName", "changeDir", "schemaName", "contextFiles": { "<artifactId>": ["/abs", ...] }, "progress": {total,complete,remaining}, "tasks": [{id,description,done}], "state": "blocked"|"all_done"|"ready", "missingArtifacts"?, "missingPrerequisites"?, "warnings"?, "instruction", "references"?, "context"?, "operationGuidance"?, "root" }`. `missingArtifacts` is what apply blocks on (the schema's `apply.requires`); `missingPrerequisites` is everything still to build before apply can run, in build order - the transitive closure of those requires, so it can be the longer list. `warnings` lists non-blocking problems with the change itself - today, a change that is ready to implement with no delta specs and no `skip_specs: true`, the state `openspec validate` rejects. Both optional root fields (`context`, `operationGuidance`) are read from the selected root on every invocation. `context` is a required prompt-level input whose relevant project facts, conventions, and constraints must be applied; `operationGuidance` is advisory input whose entries are followed only when applicable and compatible with the built-in workflow. Both remain separate from state, tasks, progress, context files, and the built-in instruction.
|
||||
|
||||
### 4.7 `instructions archive --json`
|
||||
`{ "changeName", "context"?, "operationGuidance"?, "root" }`. Requires a valid `--change` in the resolved repo/store root and uses the same required-context/advisory-guidance semantics as apply. This is a read-only runtime-input surface: it does not return the static archive workflow, inspect or merge delta specs, write main specs, or move the change.
|
||||
|
||||
### 4.8 `new change <name> --json`
|
||||
Success: `{ "change": { "id", "path", "metadataPath", "schema" }, "root" }`. Failure: `{ "change": null, "status": [d] }`, exit 1.
|
||||
|
||||
### 4.9 `archive <name> --json`
|
||||
Success: `{ "archive": { "change", "archivedAs": "YYYY-MM-DD-name", "path", "specsUpdated", "totals"?, "warnings"? }, "root" }`. Failure: `{ "archive": null, "root"?, "status": [d] }`, exit 1. `specsUpdated` is true only when at least one spec file was written or retired (a capability whose last requirement the change removed has its spec deleted, which requires `retire_capabilities: true` in the change's `.openspec.yaml`; every retirement is named in `warnings`, with a pasteable Git recovery command only when the spec lived in the caller's checkout); an already-synced change archives with all-zero totals and the skips listed in `warnings`. JSON mode is strictly non-interactive: every prompt point becomes an `archive_*` code.
|
||||
|
||||
### 4.10 `doctor --json`
|
||||
`{ "root": { "path", "source", "store_id"?, "healthy", "status": [] }, "store": { "id", "metadata": {present,valid,remote?}, "origin_url"?, "drift"?: {ahead,behind}, "status": [] } | null, "references": [...], "status": [] }`. `drift` (present only for a git-backed store checkout that has an upstream tracking ref) is ahead/behind counts against the last-fetched upstream, not the live remote. Health findings of any severity exit 0. Failure payload: `{ "root": null, "store": null, "references": [], "status": [d] }`, exit 1.
|
||||
|
||||
### 4.11 `context --json`
|
||||
`{ "root": { "path", "source", "store_id"?, "role": "openspec_root" }, "members": [ { "role": "referenced_store", "id", "path"?, "remote"?, "fetch"?, "status": [] } ], "status": [] }`. AVAILABLE = path present AND status empty. `--code-workspace <path>` writes `{folders:[{name,path}]}` (available referenced stores only, `ref:` prefixes); in JSON mode the write runs before printing so stdout holds exactly one document even on write failure. Failure: `{ "root": null, "members": [], "status": [d] }`, exit 1.
|
||||
|
||||
### 4.12 `store ... --json`
|
||||
setup/register: `{ "store": {id, root, metadata_path?}, "registry": {path, registered, already_registered}, "git": {is_repository, initialized, committed}, "created_files": [], "status": [] }`. unregister/remove: `{ "store", "registry": {path, removed}, "files": {deleted, deleted_path, left_on_disk}, "status": [] }`. list: `{ "stores": [{id, root}], "status": [] }`. doctor: `{ "stores": [ { id, root, metadata_path?, openspec_root: {...healthy, status}, metadata: {present, valid, id?, remote}, git: {is_repository, has_commits, has_uncommitted_changes, has_remote, origin_url}, status } ], "status": [] }` (`null` = unknown/not probed). Health findings exit 0; failures exit 1 with the matching null-shape. Prompt cancellation exits 130.
|
||||
|
||||
### 4.13 `schemas --json` / `templates --json`
|
||||
`schemas`: success remains a bare array `[ {name, description, artifacts, source} ]`; it resolves the canonical root-selection precedence and accepts `--store <id>`. Root-selection failure: `{ "schemas": [], "root": null, "status": [d] }`, exit 1. `templates`: keyed object `{ "<artifactId>": {path, source} }`, still cwd-based with no root/status keys.
|
||||
|
||||
## 5. Exit-code contract
|
||||
|
||||
| Situation | Exit | Stdout |
|
||||
|---|---|---|
|
||||
| Success, incl. health findings (doctor/context/store doctor) | 0 | the payload |
|
||||
| Command failure in `--json` mode | 1 | one JSON document with `status: [d]` and the command's null-shape |
|
||||
| `validate` with failing items | 1 | full report |
|
||||
| Prompt cancellation (`store` group, human mode) | 130 | stderr only |
|
||||
|
||||
## 6. Diagnostic code catalog
|
||||
|
||||
### Resolution
|
||||
`no_openspec_root`, `no_root_with_registered_stores`, `no_registered_stores`, `unknown_store`, `store_identity_mismatch`, `unhealthy_store_root`, `store_path_not_supported`, `invalid_store_pointer`, `initiative_option_removed`, `areas_option_removed`; pass-through: `invalid_store_id`, `invalid_store_registry`, `invalid_store_metadata`.
|
||||
|
||||
### OpenSpec-root health (error, no fix)
|
||||
`openspec_store_root_missing`, `openspec_store_root_not_directory`, `openspec_root_missing`, `openspec_root_not_directory`, `openspec_config_missing`, `openspec_config_not_file`, `openspec_specs_not_directory`, `openspec_changes_not_directory`, `openspec_archive_not_directory`. During the stores beta, `openspec/specs/`, `openspec/changes/`, and `openspec/changes/archive/` may be absent in a healthy root; they are only health errors when present but not directories.
|
||||
|
||||
### Store registry/identity/state
|
||||
`invalid_store_id`, `invalid_store_registry`, `invalid_store_metadata`, `store_registry_busy`, `store_not_found`, `no_store_registry`, `store_registry_changed`, `store_metadata_missing`, `store_metadata_id_mismatch`, `store_metadata_invalid`, `store_id_conflict`, `store_path_conflict`, `store_already_registered` (info).
|
||||
|
||||
### Store setup/register/remove
|
||||
`store_setup_id_required`, `store_setup_path_required`, `store_setup_path_not_directory`, `store_setup_inside_git_repo`, `store_setup_non_empty_directory`, `store_setup_cancelled`, `store_path_required`, `store_path_missing`, `store_path_not_directory`, `store_root_pointer_declared`, `store_register_root_unhealthy`, `store_register_identity_confirmation_required`, `store_register_cancelled`, `store_remote_empty`, `store_remote_requires_hand_edit`, `store_remove_confirmation_required`, `store_remove_cancelled`, `store_remove_path_not_directory`, `store_remove_metadata_missing`, `store_remove_contains_registered_store`, `store_root_missing` (warning in remove, error in doctor), `store_root_not_directory`.
|
||||
|
||||
### Store git
|
||||
`store_git_init_failed`, `store_git_identity_missing`, `store_git_commit_failed`, `store_git_no_commits` (warning), `store_clone_fragile_directories` (warning), `store_remote_divergence` (info, doctor), `store_checkout_drift` (info, doctor).
|
||||
|
||||
### References (warning)
|
||||
`reference_invalid_id`, `reference_registry_unreadable`, `reference_unresolved`, `reference_root_unhealthy`, `reference_index_truncated`.
|
||||
|
||||
### Relationships (warning; doctor; context keeps only the registry one)
|
||||
`relationship_registry_unreadable`, `root_pointer_ignored`, `root_pointer_invalid`, `pointer_declarations_inert`.
|
||||
|
||||
### Archive (JSON mode)
|
||||
`archive_change_name_required`, `archive_change_not_found`, `archive_change_symlink`, `archive_validation_failed`, `archive_confirmation_required`, `archive_tasks_incomplete`, `archive_spec_update_failed`, `archive_spec_validation_failed`, `archive_target_exists`, `archive_error`.
|
||||
|
||||
### Context writes
|
||||
`context_file_exists`, `context_output_dir_missing`.
|
||||
|
||||
### Fallbacks
|
||||
`doctor_failed`, `context_failed`, `store_error`, `change_error`, `archive_error`.
|
||||
|
||||
## Known inconsistencies
|
||||
|
||||
Recorded by the capstone audit; published-key renames are product decisions deferred past this release:
|
||||
|
||||
1. ~~In `--json` mode, several failure paths printed stderr only with no JSON document.~~ Fixed in the capstone gauntlet round: `show`/`validate` unknown and ambiguous items emit `{status:[{code: unknown_item | ambiguous_item, ...}]}`; thrown errors in `status`/`instructions`/`list`/`show`/`validate` route through the JSON-aware failure helper (the command's null-shape + `status`); `store <unknown subcommand> --json` emits `{status:[{code: unknown_store_subcommand}]}`; `list` carries its `{changes|specs: [], root: null}` null-shape on resolution failures.
|
||||
2. `store_root_missing` is emitted with two severities (warning in remove, error in store doctor) — context-dependent, documented above.
|
||||
3. snake_case (store family) vs camelCase (workflow family) key casing; `root.store_id` is snake_case everywhere.
|
||||
4. Four parallel envelope type declarations exist in src; archive diagnostics never carry `target`.
|
||||
5. `list --json` reuses the `status` key as a string enum per change.
|
||||
6. Only `validate` output carries a `version` field.
|
||||
7. `templates` ignores root selection (cwd-based, no `--store`).
|
||||
8. Deprecated noun forms (`change`/`spec` subcommands) emit unenveloped payloads without `root`/`status`.
|
||||
+31
-437
@@ -7,14 +7,10 @@ The OpenSpec CLI (`openspec`) provides terminal commands for project setup, vali
|
||||
| Category | Commands | Purpose |
|
||||
|----------|----------|---------|
|
||||
| **Setup** | `init`, `update` | Initialize and update OpenSpec in your project |
|
||||
| **Stores (standalone OpenSpec repos)** | `store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor` | Manage stores — standalone OpenSpec repos you've registered |
|
||||
| **Health** | `doctor` | Report relationship health for the resolved root |
|
||||
| **Working context** | `context` | Assemble the working set (root + referenced stores) |
|
||||
| **Personal worksets** | `workset create`, `workset list`, `workset open`, `workset remove` | Keep and open personal, local working views in your tool |
|
||||
| **Browsing** | `list`, `view`, `show` | Explore changes and specs |
|
||||
| **Validation** | `validate` | Check changes and specs for issues |
|
||||
| **Lifecycle** | `archive` | Finalize completed changes |
|
||||
| **Workflow** | `new change`, `status`, `instructions`, `templates`, `schemas` | Artifact-driven workflow support |
|
||||
| **Workflow** | `status`, `instructions`, `templates`, `schemas` | Artifact-driven workflow support |
|
||||
| **Schemas** | `schema init`, `schema fork`, `schema validate`, `schema which` | Create and manage custom workflows |
|
||||
| **Config** | `config` | View and modify settings |
|
||||
| **Utility** | `feedback`, `completion` | Feedback and shell integration |
|
||||
@@ -33,7 +29,6 @@ These commands are interactive and designed for terminal use:
|
||||
|---------|---------|
|
||||
| `openspec init` | Initialize project (interactive prompts) |
|
||||
| `openspec view` | Interactive dashboard |
|
||||
| `openspec workset open <name>` | Open a saved workset (editor window or terminal agent session) |
|
||||
| `openspec config edit` | Open config in editor |
|
||||
| `openspec feedback` | Submit feedback via GitHub |
|
||||
| `openspec completion install` | Install shell completions |
|
||||
@@ -50,17 +45,7 @@ These commands support `--json` output for programmatic use by AI agents and scr
|
||||
| `openspec status` | See artifact progress | `--json` for structured status |
|
||||
| `openspec instructions` | Get next steps | `--json` for agent instructions |
|
||||
| `openspec templates` | Find template paths | `--json` for path resolution |
|
||||
| `openspec schemas` | List available schemas | `--json` for schema discovery; `--store <id>` to select a registered root |
|
||||
| `openspec store setup <id>` | Create and register a local store | `--json` with explicit inputs for structured setup output |
|
||||
| `openspec store register <path>` | Register an existing store | `--json` for structured registration output |
|
||||
| `openspec store unregister <id>` | Forget a local store registration | `--json` for structured cleanup output |
|
||||
| `openspec store remove <id>` | Delete a registered local store folder | `--yes --json` for non-interactive deletion |
|
||||
| `openspec store list` | Browse registered stores | `--json` for structured registrations |
|
||||
| `openspec store doctor` | Check local store setup | `--json` for structured diagnostics |
|
||||
| `openspec new change <id>` | Create repo-local change scaffolding | `--json`, plus `--store <id>` to use a registered store as the OpenSpec root |
|
||||
| `openspec workset create [name]` | Compose a personal working view | `--member <path> --json` for non-interactive composition |
|
||||
| `openspec workset list` | Browse saved worksets | `--json` for structured views |
|
||||
| `openspec workset remove <name>` | Delete a saved view | `--yes --json` for non-interactive removal |
|
||||
| `openspec schemas` | List available schemas | `--json` for schema discovery |
|
||||
|
||||
---
|
||||
|
||||
@@ -82,16 +67,12 @@ These options work with all commands:
|
||||
|
||||
Initialize OpenSpec in your project. Creates the folder structure and configures AI tool integrations.
|
||||
|
||||
Default behavior uses global config defaults: profile `core`, delivery `both`, workflows `propose, explore, apply, update, sync, archive`.
|
||||
Default behavior uses global config defaults: profile `core`, delivery `both`, workflows `propose, explore, apply, archive`.
|
||||
|
||||
```
|
||||
openspec init [path] [options]
|
||||
```
|
||||
|
||||
Use `--language <language>` to add a language instruction to a new project's
|
||||
`openspec/config.yaml`. For an existing project, edit the config's `context`
|
||||
field so OpenSpec never overwrites project-specific guidance.
|
||||
|
||||
**Arguments:**
|
||||
|
||||
| Argument | Required | Description |
|
||||
@@ -103,20 +84,12 @@ field so OpenSpec never overwrites project-specific guidance.
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `--tools <list>` | Configure AI tools non-interactively. Use `all`, `none`, or comma-separated list |
|
||||
| `--language <language>` | Write artifacts in this language when creating a new config |
|
||||
| `--force` | Auto-cleanup legacy files without prompting |
|
||||
| `--profile <profile>` | Override global profile for this init run (`core` or `custom`) |
|
||||
| `--no-animation` | Show a static welcome screen instead of the animated one |
|
||||
| `--copilot-cloud` | Set up GitHub Copilot [cloud coding-agent files](supported-tools.md#github-copilot-cloud-coding-agent) without prompting |
|
||||
| `--no-copilot-cloud` | Skip GitHub Copilot cloud coding-agent files without prompting |
|
||||
|
||||
`--profile custom` uses whatever workflows are currently selected in global config (`openspec config profile`).
|
||||
|
||||
The welcome animation is also skipped when the `OPENSPEC_NO_ANIMATION` environment variable is set (any value, including empty), when `NO_COLOR` is set to a non-empty value, or when the OS reduced-motion preference is enabled (macOS Reduce Motion, GNOME animations disabled).
|
||||
|
||||
**Supported tool IDs (`--tools`)** — `windsurf` is also accepted, as an alias for `devin`: `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `command-code`, `codeartsagent`, `codex`, `devin`, `forgecode`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `hermes`, `iflow`, `junie`, `kilocode`, `kimi`, `kiro`, `lingma`, `minimax-code`, `vibe`, `oh-my-pi`, `opencode`, `pi`, `codeassistant`, `qoder`, `qwen`, `rovodev`, `roocode`, `trae`, `zed`, `zcode`, `agents`
|
||||
|
||||
> This list mirrors `AI_TOOLS` in `src/core/config.ts`. See [Supported Tools](supported-tools.md) for each tool's skill and command paths.
|
||||
**Supported tool IDs (`--tools`):** `amazon-q`, `antigravity`, `auggie`, `claude`, `cline`, `codex`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `iflow`, `kilocode`, `kiro`, `opencode`, `pi`, `qoder`, `qwen`, `roocode`, `trae`, `windsurf`
|
||||
|
||||
**Examples:**
|
||||
|
||||
@@ -130,9 +103,6 @@ openspec init ./my-project
|
||||
# Non-interactive: configure for Claude and Cursor
|
||||
openspec init --tools claude,cursor
|
||||
|
||||
# Non-interactive: configure global MiniMax Code skills
|
||||
openspec init --tools minimax-code
|
||||
|
||||
# Configure for all supported tools
|
||||
openspec init --tools all
|
||||
|
||||
@@ -154,7 +124,6 @@ openspec/
|
||||
.claude/skills/ # Claude Code skills (if claude selected)
|
||||
.cursor/skills/ # Cursor skills (if cursor selected)
|
||||
.cursor/commands/ # Cursor OPSX commands (if delivery includes commands)
|
||||
.agents/skills/ # Shared skills for AGENTS.md-compatible tools (if agents selected)
|
||||
... (other tool configs)
|
||||
```
|
||||
|
||||
@@ -184,246 +153,10 @@ openspec update [path] [options]
|
||||
|
||||
```bash
|
||||
# Update instruction files after npm upgrade
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
npm update @fission-ai/openspec
|
||||
openspec update
|
||||
```
|
||||
|
||||
Upgrade the package first. Instruction files are generated by the installed CLI, so running `openspec update` against a stale install reports everything up to date without adding the workflows newer releases ship.
|
||||
|
||||
To make that visible, `openspec update` asks the npm registry whether a newer CLI has been published. When yours is behind, it offers to upgrade:
|
||||
|
||||
```text
|
||||
A newer OpenSpec CLI is available (v1.6.0 → v1.7.0).
|
||||
Running from: /usr/local/lib/node_modules/@fission-ai/openspec
|
||||
? Upgrade to v1.7.0 now? (Y/n)
|
||||
```
|
||||
|
||||
Answer yes and it runs `npm install -g @fission-ai/openspec@latest`, then re-runs the update with the new CLI so the new workflows land in the same command. It confirms the upgrade by asking the installed binary its version rather than trusting npm's exit code, so if another install earlier on your `PATH` is still answering, it tells you instead of claiming success. Answer no and it prints the command and updates with the CLI you have. Ctrl-C stops the command.
|
||||
|
||||
The offer appears only in an interactive terminal, and only when npm owns the install — the one case `npm install -g` actually fixes. Everything else gets the command that matches how it was installed instead:
|
||||
|
||||
| How OpenSpec is installed | What you get |
|
||||
|---------------------------|--------------|
|
||||
| Global npm install | The prompt, and the upgrade run for you — in an interactive terminal; piped output gets the printed command instead |
|
||||
| Global pnpm, bun, yarn, or volta install | That manager's own command: `pnpm add -g …@latest`, `bun add -g …@latest`, `yarn global add …@latest`, or `volta install …@latest` |
|
||||
| A dependency of the project | A note to update the dependency, since its package manager owns the lockfile |
|
||||
| An `npx` / `dlx` cache | `npx @fission-ai/openspec@latest update` — that command is the update, so there is no second step |
|
||||
| A git clone | Nothing — your version is whatever the branch says |
|
||||
|
||||
Whenever anything is printed, it names the directory the running CLI was loaded from — the thing to check when you did upgrade but a stale shim still owns your `PATH`.
|
||||
|
||||
It asks the registry in `npm_config_registry` when npm exports it, and `https://registry.npmjs.org` otherwise. No `.npmrc` is read: letting file contents choose where an outbound request goes is a flow worth avoiding, and a project's `.npmrc` travels with the repository. On a private mirror, export `npm_config_registry` — or set `OPENSPEC_NO_UPDATE_CHECK` to skip the check entirely. The check is skipped when `CI` is set to anything but an explicit off-value (`false`, `0`, `no`, `off`, or empty), under `NODE_ENV=test`, and whenever `OPENSPEC_NO_UPDATE_CHECK` (any value), `DO_NOT_TRACK=1`, or `OPENSPEC_TELEMETRY=0` is set. It runs before the update and can delay it by at most 1.5 seconds — it gives up after that even when the network drops packets silently, and stays quiet when the registry is unreachable.
|
||||
|
||||
**How "up to date" is decided:** skill files record the version that generated
|
||||
them, so OpenSpec compares that against the installed CLI. Command files carry no
|
||||
version stamp, so for a tool that has commands but no skills (delivery
|
||||
`commands`), OpenSpec compares the file contents against what it would generate
|
||||
now — edits to those files count as drift and are overwritten. With delivery
|
||||
`skills` or `both`, only the recorded version is checked, so a hand-edited file
|
||||
whose version still matches is left alone; use `--force` to rewrite it. Either
|
||||
way, generated files are OpenSpec's to own — keep your own instructions
|
||||
elsewhere.
|
||||
|
||||
---
|
||||
|
||||
## Stores (standalone OpenSpec repos)
|
||||
|
||||
> **Beta.** Stores and the features built on them (references, working context, worksets) are new; command names, flags, file formats, and JSON output may change shape between releases. For the problem-first walkthrough, see the [stores guide](stores-beta/user-guide.md).
|
||||
|
||||
A store is a standalone OpenSpec repo you've registered on this machine — for example a planning repo or a contracts repo. Registering a store lets normal commands (`list`, `show`, `status`, `validate`, `new change`, `archive`, ...) act in it from anywhere by passing `--store <id>`.
|
||||
|
||||
### `openspec store setup`
|
||||
|
||||
Create and register a local store. With no arguments in a terminal,
|
||||
OpenSpec guides the user through setup. Agents and scripts should pass explicit
|
||||
inputs and use `--json`.
|
||||
|
||||
```bash
|
||||
openspec store setup [id] [options]
|
||||
```
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `--path <path>` | Folder where the store should live (for example `~/openspec/<id>`) |
|
||||
| `--remote <url>` | Record the canonical remote in the new store's `store.yaml` |
|
||||
| `--init-git` | Initialize a Git repository with an initial commit (default) |
|
||||
| `--no-init-git` | Skip every Git action: no init, no initial commit |
|
||||
| `--json` | Output JSON |
|
||||
|
||||
Non-interactive runs (`--json`, scripts, agents) must pass both the store id and `--path`. In an interactive terminal, setup prompts for the location with an editable suggestion in a visible, user-owned place (for example `~/openspec/<id>`); it never defaults to OpenSpec's managed data directory.
|
||||
|
||||
Examples:
|
||||
|
||||
```bash
|
||||
openspec store setup
|
||||
openspec store setup team-context
|
||||
openspec store setup team-context --path ~/openspec/team-context --no-init-git
|
||||
openspec store setup team-context --path ~/openspec/team-context --no-init-git --json
|
||||
```
|
||||
|
||||
### `openspec store register`
|
||||
|
||||
Register an existing local store folder. During the stores beta, a root may be
|
||||
registered before any changes exist, specs have been applied, or changes have
|
||||
been archived; in that case `openspec/changes/`, `openspec/specs/`, and
|
||||
`openspec/changes/archive/` may be absent until normal commands create them.
|
||||
A config-only repo that declares `store: <id>` remains a pointer to another
|
||||
store and is not registered as a store root unless that pointer is removed.
|
||||
|
||||
```bash
|
||||
openspec store register [path] [options]
|
||||
```
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `--id <id>` | Store id; defaults to store metadata or folder name |
|
||||
| `--yes` | Confirm creating store identity metadata for a healthy OpenSpec root |
|
||||
| `--json` | Output JSON |
|
||||
|
||||
### `openspec store unregister`
|
||||
|
||||
Forget a local store registration without deleting files.
|
||||
|
||||
```bash
|
||||
openspec store unregister <id> [--json]
|
||||
```
|
||||
|
||||
Use this when a store was moved, cloned somewhere else, or should no longer be
|
||||
shown by OpenSpec on this machine.
|
||||
|
||||
### `openspec store remove`
|
||||
|
||||
Forget a local store registration and delete its local folder.
|
||||
|
||||
```bash
|
||||
openspec store remove <id> [--yes] [--json]
|
||||
```
|
||||
|
||||
`remove` shows the exact folder before deleting in an interactive terminal.
|
||||
Agents, scripts, and JSON callers must pass `--yes` to confirm deletion.
|
||||
OpenSpec refuses to delete a folder that does not contain matching
|
||||
store metadata.
|
||||
|
||||
### `openspec store list`
|
||||
|
||||
List locally registered stores.
|
||||
|
||||
```bash
|
||||
openspec store list [--json]
|
||||
openspec store ls [--json]
|
||||
```
|
||||
|
||||
### `openspec store doctor`
|
||||
|
||||
Check local store registration, metadata, and Git presence.
|
||||
|
||||
```bash
|
||||
openspec store doctor [id] [--json]
|
||||
```
|
||||
|
||||
Doctor is diagnostic-only; it reports missing roots, metadata mismatches, and invalid local registry state without modifying the store.
|
||||
|
||||
### Referencing stores from a project
|
||||
|
||||
A project repo can declare which stores its work draws on in `openspec/config.yaml`:
|
||||
|
||||
```yaml
|
||||
schema: spec-driven
|
||||
references:
|
||||
- team-context
|
||||
```
|
||||
|
||||
From then on, `openspec instructions` output in that repo (both the per-artifact and `apply` surfaces, JSON and human modes) carries an index of each referenced store's specs — spec ids, a one-line summary from each spec's Purpose section, and the fetch command (`openspec show <spec-id> --type spec --store <id>`). The index is built live from the registered checkout on every run; spec content is never copied into the output.
|
||||
|
||||
References are read-only context. They never change where commands act: work stays in the repo's own root, and writing to a referenced store remains an explicit `--store` action. A reference that cannot be resolved (for example, a store not registered on this machine) degrades to a warning in the index with the exact fix, and instructions still generate. `openspec doctor` reports reference health in one place.
|
||||
|
||||
### Recording where a store is cloned from
|
||||
|
||||
A store can record its canonical clone source in its committed identity file, so onboarding never dead-ends at "register the store":
|
||||
|
||||
```bash
|
||||
openspec store setup team-context --path ~/openspec/team-context \
|
||||
--remote git@github.com:acme/team-context.git
|
||||
```
|
||||
|
||||
The remote lands in `.openspec-store/store.yaml` inside the initial commit, so every clone is born knowing it. For an existing store, edit `store.yaml` by hand and commit. `store doctor` shows the recorded remote (and the checkout's observed Git origin); setup/register sharing guidance names it; and register records the checkout's origin in the machine-local registry.
|
||||
|
||||
A reference declaration can carry the clone source too, so a teammate who doesn't have the store yet gets a complete, pasteable fix (`git clone <remote> <path> && openspec store register <path> --id <id>`):
|
||||
|
||||
```yaml
|
||||
references:
|
||||
- { id: team-context, remote: "git@github.com:acme/team-context.git" }
|
||||
```
|
||||
|
||||
Recording a remote is not sync: OpenSpec never clones, pulls, or pushes on its own.
|
||||
|
||||
### Declaring a default store
|
||||
|
||||
A repo whose planning is fully externalized — no local `openspec/specs/` or `openspec/changes/` — can declare its store once instead of passing `--store` on every command:
|
||||
|
||||
```yaml
|
||||
# openspec/config.yaml (the only file under openspec/)
|
||||
store: team-context
|
||||
```
|
||||
|
||||
Normal commands then resolve to the declared store automatically; the root banner and JSON `root` block report `source: "declared"` with the store id, and printed hints still carry `--store <id>`. The declaration is a fallback, never an override: explicit `--store` always wins, and a directory with real planning folders ignores the pointer (with a warning). To convert a pointer repo into a local OpenSpec root, remove the `store:` line and run `openspec init` — init refuses to scaffold while the declaration is present.
|
||||
|
||||
A machine-level variant covers every repo at once: `openspec config set defaultStore <id>` (see Configuration). It is consulted only after `--store`, a local root, and a project pointer have all failed to resolve; the root banner and JSON `root` block then report `source: "global_default"`.
|
||||
|
||||
## Doctor (relationship health)
|
||||
|
||||
One read-only question, one place: is the OpenSpec root healthy, and are the stores it references available on this machine?
|
||||
|
||||
```bash
|
||||
openspec doctor [--store <id>] [--json]
|
||||
```
|
||||
|
||||
The report separates root health, store metadata health (including a note when the recorded remote and the checkout's origin diverge, and a note when the store checkout has drifted behind its last-fetched upstream tracking ref), and reference health (the same diagnostics instructions show, with clone fixes for unresolved references). Health findings of any severity exit 0 — agents read the `status` arrays; only command failures (no root, unknown store) exit 1. Doctor never clones, syncs, or repairs. To get the assembled set itself rather than its health, use `openspec context`.
|
||||
|
||||
## Working context (the assembled set)
|
||||
|
||||
Everything this work relates to through OpenSpec declarations, in one working set: the OpenSpec root and the stores it references.
|
||||
|
||||
```bash
|
||||
openspec context [--store <id>] [--json] [--code-workspace <path> [--force]]
|
||||
```
|
||||
|
||||
The JSON brief is agent-consumable (each available referenced store carries its fetch recipe; unresolved members carry the same fixes instructions and doctor show). `--code-workspace` additionally writes a VS Code workspace file containing the root plus the available referenced stores (`ref:<id>` folders) — the one write this command performs, refused without `--force` if the file exists. Unavailable members are reported, never guessed at.
|
||||
|
||||
"Working context" is the assembled set; the `context:` field in `openspec/config.yaml` is project background injected into instructions — two different things. `openspec doctor` answers whether the set is healthy; `openspec context` answers what the set is.
|
||||
|
||||
## Personal worksets
|
||||
|
||||
> **Beta.** Worksets are part of the new beta surface; commands, flags, and file formats may change shape between releases. For the walkthrough, see the [stores guide](stores-beta/user-guide.md#worksets-reopen-the-folders-you-work-on-together).
|
||||
|
||||
A workset is a personal, named view of the folders you work on together — a planning root plus whatever else you choose — kept on your machine and reopened by name in your tool. It is purely local: never committed, never shared, never derived from declarations, and removing one never touches a member folder.
|
||||
|
||||
```bash
|
||||
openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
|
||||
openspec workset list [--json]
|
||||
openspec workset open <name> [--tool <id>]
|
||||
openspec workset remove <name> [--yes] [--json]
|
||||
```
|
||||
|
||||
`create` runs a short guided flow (or takes `--member` flags non-interactively; the first member is the primary — sessions start there). `open` launches the chosen tool: editors (VS Code, Cursor) open a window with every member and return; CLI agents (Claude Code, codex) take over this terminal as a session with every member attached and no prompt pre-filled, ending when you exit. A member folder missing at open time is skipped with a note; the rest opens. The saved tool preference is overridable per open with `--tool`.
|
||||
|
||||
Supporting a new tool is configuration, not code. Every tool is one of two launch styles — `workspace-file` (launched with the generated `.code-workspace`) or `attach-dirs` (one attach flag per member) — and the `openers` key in the global `config.json` (open it with `openspec config edit`) adds tools or adjusts built-ins per field:
|
||||
|
||||
```json
|
||||
{
|
||||
"openers": {
|
||||
"zed": { "style": "workspace-file" },
|
||||
"claude": { "attach_flag": "--dir" }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
All workset state lives under the global data dir's `worksets/` folder (the saved views plus the generated `<name>.code-workspace` files, regenerated on every open); deleting that folder removes every trace.
|
||||
|
||||
---
|
||||
|
||||
## Browsing Commands
|
||||
@@ -461,8 +194,9 @@ openspec list --json
|
||||
**Output (text):**
|
||||
|
||||
```
|
||||
Changes:
|
||||
add-dark-mode No tasks just now
|
||||
Active changes:
|
||||
add-dark-mode UI theme switching support
|
||||
fix-login-bug Session timeout handling
|
||||
```
|
||||
|
||||
---
|
||||
@@ -537,14 +271,12 @@ openspec show add-dark-mode --json
|
||||
|
||||
### `openspec validate`
|
||||
|
||||
Validate changes and specs for structural issues, and check a change's MODIFIED requirements against the main specs they would replace.
|
||||
Validate changes and specs for structural issues.
|
||||
|
||||
```
|
||||
openspec validate [item-name] [options]
|
||||
```
|
||||
|
||||
A change with zero spec deltas fails validation unless its `.openspec.yaml` declares `skip_specs: true` (for pure refactors, tooling, or docs work — see [Recipe 5](examples.md#recipe-5-a-refactor-with-no-behavior-change)).
|
||||
|
||||
**Arguments:**
|
||||
|
||||
| Argument | Required | Description |
|
||||
@@ -558,15 +290,12 @@ A change with zero spec deltas fails validation unless its `.openspec.yaml` decl
|
||||
| `--all` | Validate all changes and specs |
|
||||
| `--changes` | Validate all changes |
|
||||
| `--specs` | Validate all specs |
|
||||
| `--archived` | Validate that archived changes have all tasks completed (for pre-commit linting) |
|
||||
| `--type <type>` | Specify type when name is ambiguous: `change` or `spec` |
|
||||
| `--strict` | Enable strict validation mode |
|
||||
| `--json` | Output as JSON |
|
||||
| `--concurrency <n>` | Max parallel validations (default: 6, or `OPENSPEC_CONCURRENCY` env) |
|
||||
| `--no-interactive` | Disable prompts |
|
||||
|
||||
`--archived` is its own scope: it does not validate spec deltas (already applied at archive time), it verifies that every change under `changes/archive/` has all of its `tasks.md` checkboxes ticked, exiting non-zero if any are unchecked. This catches changes that were archived with unfinished work — handy in a pre-commit hook.
|
||||
|
||||
**Examples:**
|
||||
|
||||
```bash
|
||||
@@ -584,9 +313,6 @@ openspec validate --all --json
|
||||
|
||||
# Strict validation with increased parallelism
|
||||
openspec validate --all --strict --concurrency 12
|
||||
|
||||
# Fail if any archived change still has unchecked tasks
|
||||
openspec validate --archived
|
||||
```
|
||||
|
||||
**Output (text):**
|
||||
@@ -638,65 +364,38 @@ openspec archive [change-name] [options]
|
||||
|
||||
| Argument | Required | Description |
|
||||
|----------|----------|-------------|
|
||||
| `change-name` | No | Change to archive (prompts if omitted; required when nothing can answer the prompt) |
|
||||
| `change-name` | No | Change to archive (prompts if omitted) |
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `-y, --yes` | Skip confirmation prompts. Required when nothing can answer them — an AI agent, a CI job, or any run with stdin closed |
|
||||
| `--skip-specs` | Skip spec updates for one archive run. A change that permanently has no spec deltas should declare `skip_specs: true` in its `.openspec.yaml` instead — it archives with no flag |
|
||||
| `--no-validate` | Skip validation (requires confirmation). Also disables capability retirement — with no validator verdict, nothing is retired |
|
||||
| `-y, --yes` | Skip confirmation prompts |
|
||||
| `--skip-specs` | Skip spec updates (for infrastructure/tooling/doc-only changes) |
|
||||
| `--no-validate` | Skip validation (requires confirmation) |
|
||||
|
||||
**Examples:**
|
||||
|
||||
```bash
|
||||
# Interactive archive (asks which change, then confirms)
|
||||
# Interactive archive
|
||||
openspec archive
|
||||
|
||||
# Archive specific change
|
||||
openspec archive add-dark-mode
|
||||
|
||||
# Archive without prompts (agents, CI, scripts)
|
||||
# Archive without prompts (CI/scripts)
|
||||
openspec archive add-dark-mode --yes
|
||||
|
||||
# Archive a tooling change that doesn't affect specs
|
||||
openspec archive update-ci-config --skip-specs
|
||||
```
|
||||
|
||||
**Retire a capability:** Add the retirement marker to the change metadata:
|
||||
|
||||
```yaml
|
||||
# openspec/changes/retire-legacy/.openspec.yaml
|
||||
schema: spec-driven
|
||||
retire_capabilities: true
|
||||
```
|
||||
|
||||
Then archive the change normally:
|
||||
|
||||
```bash
|
||||
openspec archive retire-legacy --yes
|
||||
```
|
||||
|
||||
When the change removes the capability's last requirement, OpenSpec deletes its
|
||||
live `spec.md`. Other capability deltas in the same change still update their
|
||||
main specs. Without the marker, archive stops before changing any files and
|
||||
tells you to add it.
|
||||
|
||||
**What it does:**
|
||||
|
||||
1. Validates the change (unless `--no-validate`)
|
||||
2. Prompts for confirmation (unless `--yes`)
|
||||
3. Claims the archive destination before changing any main spec
|
||||
4. Validates and merges the active delta specs into `openspec/specs/` — a capability whose last requirement the change removes is retired, and its spec file deleted, but only when the change's `.openspec.yaml` declares `retire_capabilities: true` next to its `schema:`
|
||||
5. Moves the change folder to `openspec/changes/archive/YYYY-MM-DD-<name>/`
|
||||
6. If a spec mutation or final move fails before a complete archive is secured, restores the specs and leaves or returns the change at its active path
|
||||
7. If a verified fallback copy completes but staged-source cleanup fails, retains the complete archive and committed spec state for recovery
|
||||
|
||||
**Without a terminal:** an AI agent, a CI job, or any run with stdin closed cannot
|
||||
answer step 2, so archive stops before touching anything, exits 1, and names the
|
||||
command to rerun — `openspec archive <name> --yes`, carrying whatever other flags
|
||||
you passed. Pass `--yes` (and the change name) up front to skip the round trip.
|
||||
3. Merges delta specs into `openspec/specs/`
|
||||
4. Moves change folder to `openspec/changes/archive/YYYY-MM-DD-<name>/`
|
||||
|
||||
---
|
||||
|
||||
@@ -704,37 +403,6 @@ you passed. Pass `--yes` (and the change name) up front to skip the round trip.
|
||||
|
||||
These commands support the artifact-driven OPSX workflow. They're useful for both humans checking progress and agents determining next steps.
|
||||
|
||||
### `openspec new change`
|
||||
|
||||
Create a change directory and optional checked-in metadata in the resolved OpenSpec root.
|
||||
|
||||
```bash
|
||||
openspec new change <name> [options]
|
||||
```
|
||||
|
||||
Change names must use lowercase kebab-case: lowercase letters, numbers, and
|
||||
single hyphens. They cannot contain spaces, underscores, uppercase letters,
|
||||
consecutive hyphens, or leading/trailing hyphens. A leading number is allowed,
|
||||
so you can prefix names to order or tier changes, for example `100-add-feature`
|
||||
or `00001-add-auth`.
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `--description <text>` | Description to add to `README.md` |
|
||||
| `--goal <text>` | Optional goal metadata to store with the change |
|
||||
| `--schema <name>` | Workflow schema to use |
|
||||
| `--store <id>` | Store id to use as the OpenSpec root (a store is a standalone OpenSpec repo you've registered) |
|
||||
| `--json` | Output JSON |
|
||||
|
||||
Examples:
|
||||
|
||||
```bash
|
||||
openspec new change add-billing-api
|
||||
openspec new change add-billing-api --store team-context --json
|
||||
```
|
||||
|
||||
### `openspec status`
|
||||
|
||||
Display artifact completion status for a change.
|
||||
@@ -772,42 +440,28 @@ Schema: spec-driven
|
||||
Progress: 2/4 artifacts complete
|
||||
|
||||
[x] proposal
|
||||
[x] specs
|
||||
[ ] design
|
||||
[x] specs
|
||||
[-] tasks (blocked by: design)
|
||||
```
|
||||
|
||||
A change that declares `skip_specs: true` shows its specs stage as `[~] specs (skipped: change declares skip_specs)` and excludes it from the progress count.
|
||||
|
||||
**Output (JSON):**
|
||||
|
||||
```json
|
||||
{
|
||||
"changeName": "add-dark-mode",
|
||||
"schemaName": "spec-driven",
|
||||
"isPlanningComplete": false,
|
||||
"isComplete": false,
|
||||
"applyRequires": ["tasks"],
|
||||
"artifacts": [
|
||||
{"id": "proposal", "outputPath": "proposal.md", "status": "done", "requires": []},
|
||||
{"id": "specs", "outputPath": "specs/**/*.md", "status": "done", "requires": ["proposal"]},
|
||||
{"id": "design", "outputPath": "design.md", "status": "ready", "requires": ["proposal"]},
|
||||
{"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "requires": ["specs", "design"], "missingDeps": ["design"]}
|
||||
{"id": "proposal", "outputPath": "proposal.md", "status": "done"},
|
||||
{"id": "design", "outputPath": "design.md", "status": "ready"},
|
||||
{"id": "specs", "outputPath": "specs/**/*.md", "status": "done"},
|
||||
{"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "missingDeps": ["design"]}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
`isPlanningComplete` reports whether every non-skipped planning artifact exists;
|
||||
skipped artifacts count as satisfied without being created. It does not report
|
||||
whether implementation tasks are complete. `isComplete` is retained as a
|
||||
compatibility alias with the same value.
|
||||
|
||||
Artifacts are listed in dependency order - a dependency never appears after
|
||||
something that requires it - and artifacts that become ready at the same time
|
||||
(spec-driven's `specs` and `design` both need only `proposal`) keep the order the
|
||||
schema declares them rather than an alphabetical one. So the first `ready` entry
|
||||
is the artifact to write next.
|
||||
|
||||
---
|
||||
|
||||
### `openspec instructions`
|
||||
@@ -822,7 +476,7 @@ openspec instructions [artifact] [options]
|
||||
|
||||
| Argument | Required | Description |
|
||||
|----------|----------|-------------|
|
||||
| `artifact` | No | Artifact ID, or workflow input surface: `apply` or `archive` |
|
||||
| `artifact` | No | Artifact ID: `proposal`, `specs`, `design`, `tasks`, or `apply` |
|
||||
|
||||
**Options:**
|
||||
|
||||
@@ -832,9 +486,7 @@ openspec instructions [artifact] [options]
|
||||
| `--schema <name>` | Schema override |
|
||||
| `--json` | Output as JSON |
|
||||
|
||||
**Special cases:** Use `apply` to get task implementation instructions. Use
|
||||
`archive` to fetch current, read-only archive inputs (`context` and
|
||||
`operationGuidance`) for a valid change; it does not archive or mutate anything.
|
||||
**Special case:** Use `apply` as the artifact to get task implementation instructions.
|
||||
|
||||
**Examples:**
|
||||
|
||||
@@ -848,9 +500,6 @@ openspec instructions design --change add-dark-mode
|
||||
# Get apply/implementation instructions
|
||||
openspec instructions apply --change add-dark-mode
|
||||
|
||||
# Get current archive operation inputs without archiving
|
||||
openspec instructions archive --change add-dark-mode --json
|
||||
|
||||
# JSON for agent consumption
|
||||
openspec instructions design --change add-dark-mode --json
|
||||
```
|
||||
@@ -861,21 +510,6 @@ openspec instructions design --change add-dark-mode --json
|
||||
- Project context from config
|
||||
- Content from dependency artifacts
|
||||
- Per-artifact rules from config
|
||||
- Current project context and matching operation guidance for `apply`/`archive`
|
||||
|
||||
Operation inputs are read from the resolved repo or selected store on every
|
||||
invocation. Project context is a required prompt-level input: agents read it and
|
||||
apply relevant project facts, conventions, and constraints. Operation guidance is
|
||||
optional additive advice: agents consider every entry and follow only entries that
|
||||
are applicable and compatible with the built-in workflow. Both fields remain
|
||||
separate from explicit user choices, CLI-controlled state, built-in instructions,
|
||||
and artifact rules. Conflicting context is reported; conflicting or inapplicable
|
||||
guidance is not followed and the reason is explained. These are behavioral
|
||||
contracts for generated agents, not enforceable CLI checks. `instructions archive`
|
||||
returns only the selected change, optional inputs, and root metadata; it does not
|
||||
include the static archive workflow.
|
||||
|
||||
For an artifact skipped via `skip_specs: true`, the output is a warning only (JSON adds `skipped`/`warning` fields) — the artifact must not be created.
|
||||
|
||||
---
|
||||
|
||||
@@ -934,7 +568,6 @@ openspec schemas [options]
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `--json` | Output as JSON |
|
||||
| `--store <id>` | Use a registered store as the OpenSpec root |
|
||||
|
||||
**Example:**
|
||||
|
||||
@@ -1156,7 +789,7 @@ openspec config list
|
||||
# Get a specific value
|
||||
openspec config get telemetry.enabled
|
||||
|
||||
# Set a value (disable anonymous usage telemetry)
|
||||
# Set a value
|
||||
openspec config set telemetry.enabled false
|
||||
|
||||
# Set a string value explicitly
|
||||
@@ -1165,10 +798,6 @@ openspec config set user.name "My Name" --string
|
||||
# Remove a custom setting
|
||||
openspec config unset user.name
|
||||
|
||||
# Set a machine-level default store (fallback root when no --store,
|
||||
# local root, or project store: pointer resolves)
|
||||
openspec config set defaultStore team-plans
|
||||
|
||||
# Reset all configuration
|
||||
openspec config reset --all --yes
|
||||
|
||||
@@ -1182,11 +811,6 @@ openspec config profile
|
||||
openspec config profile core
|
||||
```
|
||||
|
||||
**Telemetry opt-out:** `telemetry.enabled` defaults to on when unset (opt-out model).
|
||||
Set it to `false` to disable anonymous usage stats and the `openspec update` version check.
|
||||
Environment variables take precedence over config: `OPENSPEC_TELEMETRY=0`, `DO_NOT_TRACK=1`,
|
||||
and a truthy `CI` value (e.g. `true`/`1`/`yes`) always disable telemetry regardless of the config value.
|
||||
|
||||
`openspec config profile` starts with a current-state summary, then lets you choose:
|
||||
- Change delivery + workflows
|
||||
- Change delivery only
|
||||
@@ -1194,7 +818,7 @@ and a truthy `CI` value (e.g. `true`/`1`/`yes`) always disable telemetry regardl
|
||||
- Keep current settings (exit)
|
||||
|
||||
If you keep current settings, no changes are written and no update prompt is shown.
|
||||
If there are no config changes but the current project files are out of sync with your global profile/delivery, OpenSpec will show a warning and suggest `openspec update`.
|
||||
If there are no config changes but the current project files are out of sync with your global profile/delivery, OpenSpec will show a warning and suggest running `openspec update`.
|
||||
Pressing `Ctrl+C` also cancels the flow cleanly (no stack trace) and exits with code `130`.
|
||||
In the workflow checklist, `[x]` means the workflow is selected in global config. To apply those selections to project files, run `openspec update` (or choose `Apply changes to this project now?` when prompted inside a project).
|
||||
|
||||
@@ -1228,13 +852,13 @@ openspec feedback <message> [options]
|
||||
|
||||
| Argument | Required | Description |
|
||||
|----------|----------|-------------|
|
||||
| `message` | Yes | Feedback summary; long text is shortened in the issue title and preserved in the body |
|
||||
| `message` | Yes | Feedback message |
|
||||
|
||||
**Options:**
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `--body <text>` | Additional details included after the summary |
|
||||
| `--body <text>` | Detailed description |
|
||||
|
||||
**Requirements:** GitHub CLI (`gh`) must be installed and authenticated.
|
||||
|
||||
@@ -1274,39 +898,13 @@ openspec completion install
|
||||
# Install for specific shell
|
||||
openspec completion install zsh
|
||||
|
||||
# Generate script for manual installation (bash)
|
||||
# Generate script for manual installation
|
||||
openspec completion generate bash > ~/.bash_completion.d/openspec
|
||||
|
||||
# Uninstall
|
||||
openspec completion uninstall
|
||||
```
|
||||
|
||||
**Windows (PowerShell):** Install completions for the current PowerShell host:
|
||||
|
||||
```powershell
|
||||
$env:PROFILE = $PROFILE
|
||||
openspec completion install powershell
|
||||
. $PROFILE
|
||||
```
|
||||
|
||||
`$env:PROFILE` tells OpenSpec which profile to configure in this session. The
|
||||
installer creates missing profile directories and adds a managed block that loads
|
||||
`OpenSpecCompletion.ps1`. Reloading the profile enables completions immediately.
|
||||
|
||||
To uninstall from the current host, run:
|
||||
|
||||
```powershell
|
||||
$env:PROFILE = $PROFILE
|
||||
openspec completion uninstall powershell
|
||||
```
|
||||
|
||||
Restart PowerShell after uninstalling to clear completions from the current session.
|
||||
|
||||
Completions are opt-in. The CLI mentions them once, on stderr, the first time you
|
||||
run a command in an interactive terminal, and never again — it also stays quiet
|
||||
if you already have completions installed. Set `OPENSPEC_NO_COMPLETIONS=1` to
|
||||
suppress that tip entirely.
|
||||
|
||||
---
|
||||
|
||||
## Exit Codes
|
||||
@@ -1322,15 +920,11 @@ suppress that tip entirely.
|
||||
|
||||
| Variable | Description |
|
||||
|----------|-------------|
|
||||
| `OPENSPEC_TELEMETRY` | Set to `0` to disable telemetry and the `openspec update` version check (overrides `telemetry.enabled` in global config) |
|
||||
| `DO_NOT_TRACK` | Set to `1` to disable telemetry and the `openspec update` version check (standard DNT signal; overrides config) |
|
||||
| `OPENSPEC_TELEMETRY` | Set to `0` to disable telemetry |
|
||||
| `DO_NOT_TRACK` | Set to `1` to disable telemetry (standard DNT signal) |
|
||||
| `OPENSPEC_CONCURRENCY` | Default concurrency for bulk validation (default: 6) |
|
||||
| `EDITOR` or `VISUAL` | Editor for `openspec config edit` |
|
||||
| `NO_COLOR` | Disable color output when set |
|
||||
| `OPENSPEC_NO_ANIMATION` | Disable the `openspec init` welcome animation when set |
|
||||
| `OPENSPEC_NO_COMPLETIONS` | Set to `1` to suppress the one-time tip about shell completions |
|
||||
| `OPENSPEC_NO_UPDATE_CHECK` | Disable the `openspec update` check for a newer published CLI when set (any value, including empty). Also skipped when `CI` is set (unless `false`/`0`/`no`/`off`) or `NODE_ENV=test` |
|
||||
| `npm_config_registry` | Registry the `openspec update` version check asks. Must be an `http(s)` URL or it falls back to `https://registry.npmjs.org`. No `.npmrc` file is read |
|
||||
|
||||
---
|
||||
|
||||
|
||||
+15
-90
@@ -1,14 +1,9 @@
|
||||
# Commands
|
||||
|
||||
This is the reference for OpenSpec's slash commands. These commands are invoked in your AI coding assistant's chat interface (e.g., Claude Code, Cursor, Devin Desktop).
|
||||
This is the reference for OpenSpec's slash commands. These commands are invoked in your AI coding assistant's chat interface (e.g., Claude Code, Cursor, Windsurf).
|
||||
|
||||
For workflow patterns and when to use each command, see [Workflows](workflows.md). For CLI commands, see [CLI](cli.md).
|
||||
|
||||
These pages use `/opsx:<command>` as the canonical name. Some tools spell it
|
||||
differently — Cursor and GitHub Copilot register `/opsx-propose`, Codex uses
|
||||
`$openspec-propose` — so check [How To Invoke](supported-tools.md#how-to-invoke)
|
||||
for your tool. The files OpenSpec generates already use the right form.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### Default Quick Path (`core` profile)
|
||||
@@ -18,8 +13,6 @@ for your tool. The files OpenSpec generates already use the right form.
|
||||
| `/opsx:propose` | Create a change and generate planning artifacts in one step |
|
||||
| `/opsx:explore` | Think through ideas before committing to a change |
|
||||
| `/opsx:apply` | Implement tasks from the change |
|
||||
| `/opsx:update` | Revise a change's planning artifacts and keep them coherent |
|
||||
| `/opsx:sync` | Merge delta specs into main specs |
|
||||
| `/opsx:archive` | Archive a completed change |
|
||||
|
||||
### Expanded Workflow Commands (custom workflow selection)
|
||||
@@ -30,6 +23,7 @@ for your tool. The files OpenSpec generates already use the right form.
|
||||
| `/opsx:continue` | Create the next artifact based on dependencies |
|
||||
| `/opsx:ff` | Fast-forward: create all planning artifacts at once |
|
||||
| `/opsx:verify` | Validate implementation matches artifacts |
|
||||
| `/opsx:sync` | Merge delta specs into main specs |
|
||||
| `/opsx:bulk-archive` | Archive multiple changes at once |
|
||||
| `/opsx:onboard` | Guided tutorial through the complete workflow |
|
||||
|
||||
@@ -78,8 +72,6 @@ AI: Created openspec/changes/add-dark-mode/
|
||||
|
||||
### `/opsx:explore`
|
||||
|
||||
> **Start here when you're unsure.** Explore is a no-stakes thinking partner: it reads your codebase, compares options, and sharpens a fuzzy idea into a concrete plan before any code gets written. It ships in the default profile. For the full case and more examples, see the [Explore First](explore.md) guide.
|
||||
|
||||
Think through ideas, investigate problems, and clarify requirements before committing to a change.
|
||||
|
||||
**Syntax:**
|
||||
@@ -97,7 +89,6 @@ Think through ideas, investigate problems, and clarify requirements before commi
|
||||
- Investigates the codebase to answer questions
|
||||
- Compares options and approaches
|
||||
- Creates visual diagrams to clarify thinking
|
||||
- Captures the exploration when you ask, or when you say yes to its offer: scaffolds a change with `openspec new change` and writes the planning artifacts you name, or updates an existing change's artifacts
|
||||
- Can transition to `/opsx:propose` (default) or `/opsx:new` (expanded workflow) when insights crystallize
|
||||
|
||||
**Example:**
|
||||
@@ -120,20 +111,14 @@ AI: Let me investigate your current auth setup...
|
||||
|
||||
Your API already has CORS configured. Which direction interests you?
|
||||
|
||||
You: Let's go with JWT.
|
||||
You: Let's go with JWT. Can we start a change for that?
|
||||
|
||||
AI: That's a decision worth keeping. Want me to start a change called
|
||||
add-jwt-auth? Just the change folder, nothing else yet.
|
||||
|
||||
You: Yes.
|
||||
|
||||
AI: Started openspec/changes/add-jwt-auth/. Say the word and I'll
|
||||
write the proposal, specs, and tasks from what we just worked out.
|
||||
AI: Ready when you are. Run /opsx:propose add-jwt-auth to begin.
|
||||
```
|
||||
|
||||
**Tips:**
|
||||
- Use when requirements are unclear or you need to investigate
|
||||
- It never writes code, and writes nothing else unless you ask, or say yes when it offers
|
||||
- No artifacts are created during exploration
|
||||
- Good for comparing multiple approaches before deciding
|
||||
- Can read files and search the codebase
|
||||
|
||||
@@ -217,7 +202,7 @@ AI: Change: add-dark-mode
|
||||
✓ proposal (done)
|
||||
◆ specs (ready)
|
||||
◆ design (ready)
|
||||
○ tasks (blocked - needs: specs, design)
|
||||
○ tasks (blocked - needs: specs)
|
||||
|
||||
Creating specs...
|
||||
|
||||
@@ -225,7 +210,7 @@ AI: Change: add-dark-mode
|
||||
|
||||
✓ Created openspec/changes/add-dark-mode/specs/ui/spec.md
|
||||
|
||||
Now available: design
|
||||
Now available: tasks
|
||||
Run /opsx:continue to create the next artifact.
|
||||
```
|
||||
|
||||
@@ -330,61 +315,6 @@ AI: Implementing add-dark-mode...
|
||||
|
||||
---
|
||||
|
||||
### `/opsx:update`
|
||||
|
||||
Revise a change's existing planning artifacts and keep them coherent with one another. Planning artifacts only - it never edits code.
|
||||
|
||||
**Syntax:**
|
||||
|
||||
```text
|
||||
/opsx:update [change-name]
|
||||
```
|
||||
|
||||
**Arguments:**
|
||||
|
||||
| Argument | Required | Description |
|
||||
|----------|----------|-------------|
|
||||
| `change-name` | No | Which change to update (inferred from context if not provided) |
|
||||
|
||||
**What it does:**
|
||||
|
||||
- Reads the change's artifacts via `openspec status --change <name> --json`
|
||||
- Applies your requested revision, or reviews the artifacts for contradictions if you didn't name one
|
||||
- Reconciles the other existing artifacts in any direction (a design edit may ripple back to the proposal)
|
||||
- Confirms every edit with you before writing, one artifact at a time
|
||||
- Ends by recommending the next step: `/opsx:continue` (unstarted artifacts), `/opsx:apply` (carry a revised plan into code), or `/opsx:archive` (all done)
|
||||
|
||||
**Missing files:**
|
||||
|
||||
- For a glob artifact such as `specs/**/*.md` with at least one existing file, update can propose a missing companion file. It uses the schema's instructions and asks you to confirm the concrete path before creating it.
|
||||
- Artifacts with no files yet remain with `/opsx:continue`. Intentionally skipped artifacts stay untouched.
|
||||
- New files must stay inside the change directory. If a file appears at the confirmed path before creation, update stops instead of overwriting it.
|
||||
|
||||
**Example:**
|
||||
|
||||
```text
|
||||
You: /opsx:update add-dark-mode - we're storing the theme in a cookie now, not localStorage
|
||||
|
||||
AI: Reading add-dark-mode artifacts...
|
||||
|
||||
The design references localStorage in two places; tasks 1.3 covers
|
||||
localStorage persistence; the proposal doesn't mention storage.
|
||||
|
||||
Proposed revisions:
|
||||
1. design.md - swap localStorage decision for cookie storage
|
||||
2. tasks.md - reword task 1.3 to cookie persistence
|
||||
|
||||
Apply revision 1? (design.md)
|
||||
```
|
||||
|
||||
**Tips:**
|
||||
|
||||
- It won't start an artifact with no existing files. Enable `/opsx:continue` for that, or use `openspec status` and `openspec instructions` if that optional workflow isn't installed.
|
||||
- If the change was already implemented, follow up with `/opsx:apply` so the code matches the revised plan
|
||||
- If your revision changes the *intent* of the change, start fresh with a new change instead (see [When to Update vs. Start Fresh](opsx.md#when-to-update-vs-start-fresh))
|
||||
|
||||
---
|
||||
|
||||
### `/opsx:verify`
|
||||
|
||||
Validate that implementation matches your change artifacts. Checks completeness, correctness, and coherence.
|
||||
@@ -682,20 +612,15 @@ AI: Welcome to OpenSpec!
|
||||
|
||||
Different AI tools use slightly different command syntax. Use the format that matches your tool:
|
||||
|
||||
| Your tool's command file | Syntax example | Example tools |
|
||||
|--------------------------|----------------|---------------|
|
||||
| `.../commands/opsx/<id>.*` | `/opsx:propose`, `/opsx:apply` | Claude Code, Gemini CLI, Crush |
|
||||
| `.../opsx-<id>.*` | `/opsx-propose`, `/opsx-apply` | Cursor, Devin Desktop, Copilot (IDE), Trae, Oh My Pi |
|
||||
| none — skills only | `/openspec-propose`, `/openspec-apply-change` | CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, shared `.agents` |
|
||||
| none — Kimi Code | `/skill:openspec-propose` | Kimi Code |
|
||||
| none — Codex CLI | `$openspec-propose` | Codex |
|
||||
| Tool | Syntax Example |
|
||||
|------|----------------|
|
||||
| Claude Code | `/opsx:propose`, `/opsx:apply` |
|
||||
| Cursor | `/opsx-propose`, `/opsx-apply` |
|
||||
| Windsurf | `/opsx-propose`, `/opsx-apply` |
|
||||
| Copilot (IDE) | `/opsx-propose`, `/opsx-apply` |
|
||||
| Trae | Skill-based invocations such as `/openspec-propose`, `/openspec-apply-change` (no generated `opsx-*` command files) |
|
||||
|
||||
> **Devin Desktop vs Devin Local:** the `.devin/workflows/opsx-*.md` files give
|
||||
> Devin Desktop `/opsx-propose`. Devin Local has no workflows — use the skills
|
||||
> OpenSpec writes to `.devin/skills/`, e.g. `/openspec-propose`, which work on
|
||||
> both agents.
|
||||
|
||||
The intent is the same across tools, but how commands are surfaced can differ by integration. [How To Invoke](supported-tools.md#how-to-invoke) lists every supported tool; this table shows only examples of each shape.
|
||||
The intent is the same across tools, but how commands are surfaced can differ by integration.
|
||||
|
||||
> **Note:** GitHub Copilot commands (`.github/prompts/*.prompt.md`) are only available in IDE extensions (VS Code, JetBrains, Visual Studio). GitHub Copilot CLI does not currently support custom prompt files — see [Supported Tools](supported-tools.md) for details and workarounds.
|
||||
|
||||
|
||||
@@ -1,21 +0,0 @@
|
||||
# Community Showcase
|
||||
|
||||
A community-owned awesome list of projects and resources built with and for OpenSpec. Tools, integrations, workflows, and learning resources are welcome. Community members grow and maintain this showcase through pull requests.
|
||||
|
||||
Listed projects are maintained independently. Inclusion does not imply official support or endorsement by OpenSpec. See each project's documentation and issue tracker for setup and support.
|
||||
|
||||
## Projects and resources
|
||||
|
||||
- **[OpenSpec Workbench](https://github.com/VeryComplexAndLongName/OpenSpec-UI)**: Running and supervising agents on OpenSpec changes.
|
||||
- **[MySpec](https://myspec.dev)**: Cloud beta (account required) that conducts guided spec interviews and exports four-file bundles or OpenSpec-compatible changes. The service sends submitted content to third-party AI providers and is not designed for sensitive data.
|
||||
- **[openspec-guard](https://github.com/guillaume-flambard/spec-guard)**: CLI and GitHub Action that reports which OpenSpec scenarios are covered by a Vitest or Jest test, without running the tests.
|
||||
|
||||
## Add your project
|
||||
|
||||
Open a pull request adding one line to this file with your project's name, a direct link, and a short description of how it relates to OpenSpec.
|
||||
|
||||
- Keep entries focused on something built with OpenSpec or supporting its use, rather than general product advertising.
|
||||
- Describe what people can use. Avoid promotional claims, referral links, and tracking links.
|
||||
- Disclose paid features or required accounts in the entry, if any.
|
||||
|
||||
Corrections and updates to existing entries are welcome too.
|
||||
+2
-5
@@ -190,7 +190,7 @@ openspec/changes/add-dark-mode/
|
||||
├── proposal.md # Why and what
|
||||
├── design.md # How (technical approach)
|
||||
├── tasks.md # Implementation checklist
|
||||
├── .openspec.yaml # Change metadata (optional): schema, created, skip_specs, retire_capabilities
|
||||
├── .openspec.yaml # Change metadata (optional)
|
||||
└── specs/ # Delta specs
|
||||
└── ui/
|
||||
└── spec.md # What's changing in ui/spec.md
|
||||
@@ -341,8 +341,6 @@ Tasks are the **implementation checklist** — concrete steps with checkboxes.
|
||||
- Group related tasks under headings
|
||||
- Use hierarchical numbering (1.1, 1.2, etc.)
|
||||
- Keep tasks small enough to complete in one session
|
||||
- State how each task is verified (a test, command, or observable result)
|
||||
- Land the tests and documentation each group's work calls for inside that group, not in a final catch-up group
|
||||
- Check tasks off as you complete them
|
||||
|
||||
## Delta Specs
|
||||
@@ -394,8 +392,7 @@ The system MUST expire sessions after 15 minutes of inactivity.
|
||||
|---------|---------|------------------------|
|
||||
| `## ADDED Requirements` | New behavior | Appended to main spec |
|
||||
| `## MODIFIED Requirements` | Changed behavior | Replaces existing requirement |
|
||||
| `## REMOVED Requirements` | Deprecated behavior | Deleted from main spec; removing the last requirement retires the capability and deletes its spec file, when the change declares `retire_capabilities: true` |
|
||||
| `## Purpose` | What a brand-new capability is for | Seeds the Purpose of the main spec being created; ignored when the spec already exists |
|
||||
| `## REMOVED Requirements` | Deprecated behavior | Deleted from main spec |
|
||||
|
||||
### Why Deltas Instead of Full Specs
|
||||
|
||||
|
||||
@@ -17,8 +17,6 @@ The `openspec/config.yaml` file is the easiest way to customize OpenSpec for you
|
||||
- **Set a default schema** - Skip `--schema` on every command
|
||||
- **Inject project context** - AI sees your tech stack, conventions, etc.
|
||||
- **Add per-artifact rules** - Custom rules for specific artifacts
|
||||
- **Add per-operation guidance** - Advisory preferences for apply and archive work
|
||||
- **Remember integration choices** - e.g. the [GitHub Copilot cloud coding agent](supported-tools.md#github-copilot-cloud-coding-agent) opt-in
|
||||
|
||||
### Quick Setup
|
||||
|
||||
@@ -45,19 +43,6 @@ rules:
|
||||
specs:
|
||||
- Use Given/When/Then format
|
||||
- Reference existing patterns before inventing new ones
|
||||
|
||||
operations:
|
||||
apply:
|
||||
guidance:
|
||||
- Run focused tests before the full suite
|
||||
archive:
|
||||
guidance:
|
||||
- Keep the completion summary concise
|
||||
|
||||
# Set by `openspec init` when you choose (or decline) the GitHub Copilot
|
||||
# cloud coding agent; controls whether `init`/`update` generate its files.
|
||||
githubCopilot:
|
||||
cloudAgent: false
|
||||
```
|
||||
|
||||
### How It Works
|
||||
@@ -95,60 +80,6 @@ Tech stack: TypeScript, React, Node.js, PostgreSQL
|
||||
- **Context** appears in ALL artifacts
|
||||
- **Rules** ONLY appear for the matching artifact
|
||||
|
||||
**Operation guidance:**
|
||||
|
||||
`operations.apply.guidance` and `operations.archive.guidance` are optional arrays
|
||||
of advisory instructions for how an agent should conduct those operations. They
|
||||
are separate from `rules`: operation guidance does not constrain artifact content,
|
||||
and artifact rules are never relabeled as operation guidance.
|
||||
|
||||
Apply and archive fetch these inputs at execution time:
|
||||
|
||||
```bash
|
||||
openspec instructions apply --change my-feature --json
|
||||
openspec instructions archive --change my-feature --json
|
||||
```
|
||||
|
||||
Both surfaces return current project `context` and matching
|
||||
`operationGuidance` as separate optional fields. Each invocation reads a fresh
|
||||
snapshot from the resolved root. When `--store <id>` is selected, the change,
|
||||
context, and guidance all come from that store rather than the current repository.
|
||||
The archive instruction command is read-only: it does not inspect or merge delta
|
||||
specs, write main specs, move the change, or run the static archive workflow.
|
||||
|
||||
Project context is a required prompt-level input. Generated workflows read it and
|
||||
apply relevant project facts, conventions, and constraints. Operation guidance is
|
||||
optional additive advice: workflows consider every entry and follow entries that
|
||||
are applicable and compatible with the built-in workflow.
|
||||
|
||||
Both fields remain separate from CLI-controlled state, resolved paths, built-in
|
||||
steps, explicit user choices, and artifact rules. A workflow reports context
|
||||
conflicts while preserving the controlling value. It does not follow inapplicable
|
||||
or conflicting guidance and explains why. Neither field is an enforceable check,
|
||||
and workflows do not copy their text into implementation files, specs, change
|
||||
artifacts, or summaries unless the user separately requests that content.
|
||||
|
||||
**Archive and spec-sync input safety:**
|
||||
|
||||
Archive, bulk archive, and standalone sync use
|
||||
`artifactPaths.specs.existingOutputPaths` from `openspec status --json` as the
|
||||
only delta-spec source. A schema without a `specs` artifact, or a change whose
|
||||
concrete output list is empty, has nothing to sync; other artifacts are not used
|
||||
to infer delta specs.
|
||||
|
||||
Before a semantic merge writes a main spec, the workflow consumes current
|
||||
`openspec instructions specs --change <name> --json` output. The returned
|
||||
`specs` rules constrain only the main specs produced by that merge. Single archive
|
||||
passes that snapshot into inline sync, standalone sync fetches it directly, and
|
||||
bulk archive obtains every required snapshot before its first spec write. A
|
||||
non-zero or invalid JSON archive/specs instruction response is a lookup failure,
|
||||
not an empty input: the workflow stops before the affected spec write or change
|
||||
move (for bulk archive, before any batch write or move).
|
||||
|
||||
This configuration does not change archive execution phases, user prompts,
|
||||
filesystem operations, semantic merge ownership, the direct `openspec archive`
|
||||
command, or the structure and output of artifact `rules`.
|
||||
|
||||
### Schema Resolution Order
|
||||
|
||||
When OpenSpec needs a schema, it checks in this order:
|
||||
@@ -266,10 +197,6 @@ apply:
|
||||
| `instruction` | AI instructions for creating this artifact |
|
||||
| `requires` | Dependencies - which artifacts must exist first |
|
||||
|
||||
List artifacts in the order you want them written. `requires` decides what is
|
||||
possible; the order of the `artifacts:` list decides what comes first when
|
||||
several artifacts are ready at once.
|
||||
|
||||
### Templates
|
||||
|
||||
Templates are markdown files that guide the AI. They're injected into the prompt when creating that artifact.
|
||||
@@ -410,24 +337,6 @@ Then edit `schema.yaml` to add:
|
||||
|
||||
---
|
||||
|
||||
## Community Schemas
|
||||
|
||||
OpenSpec also supports community-maintained schemas distributed via standalone repositories. These provide opinionated workflows that integrate OpenSpec with other tools or systems, similar to how [github/spec-kit's community extension catalog](https://github.com/github/spec-kit/tree/main/extensions) works for spec-kit.
|
||||
|
||||
Community schemas are not vendored into OpenSpec core — they live in their own repositories with their own release cadence. To use one, copy the schema bundle into your project's `openspec/schemas/<schema-name>/` directory (each repo's README has install instructions).
|
||||
|
||||
| Schema | Maintainer | Repository | Description |
|
||||
|--------|-----------|-----------|-------------|
|
||||
| `intent-driven` | @harikrishnan83 | [intent-driven-dev/openspec-schemas](https://github.com/intent-driven-dev/openspec-schemas/tree/main/openspec/schemas/intent-driven) | Captures change intent, observable behaviour, technical design, and durable architectural decisions before implementation. Adds a change-local ADR review manifest and writes qualifying long-lived decisions as immutable, supersedable ADRs. |
|
||||
| `superpowers-bridge` | @JiangWay | [JiangWay/openspec-schemas](https://github.com/JiangWay/openspec-schemas/tree/main/superpowers-bridge) | Integrates OpenSpec's artifact governance with [obra/superpowers](https://github.com/obra/superpowers) execution skills (brainstorming, writing-plans, TDD via subagents, code review, finishing). Adds an evidence-first `retrospective` artifact filling a gap Superpowers does not natively cover. |
|
||||
| `nanopm` | @nmrtn | [nmrtn/nanopm](https://github.com/nmrtn/nanopm/tree/main/openspec-schema) | PM-first workflow. Runs [nanopm](https://github.com/nmrtn/nanopm)'s planning pipeline (audit → strategy → roadmap → PRD) upstream of implementation. Bridges product planning to OpenSpec's spec-driven engineering workflow. Artifacts read from `.nanopm/` if present — proposal sources the audit, design sources the strategy, and tasks source the PRD breakdown. |
|
||||
| `e2e-runbooks` | @Lukk17 | [Lukk17/openspec-schemas](https://github.com/Lukk17/openspec-schemas/tree/master/openspec/schemas/e2e-runbooks) | Capability-level end-to-end test runbooks. Each capability gets an immutable spec, an immutable tasks-template, and one timestamped run record per execution. Assertions are observable behaviour only (HTTP status, response body, persisted state — never log substrings); each run records start/end UTC, duration, and best-estimate LLM token consumption. |
|
||||
| `anvil` | @jikkujoyce | [jikkujoyce/openspec-schemas](https://github.com/jikkujoyce/openspec-schemas/tree/main/schemas/anvil) | Spec-driven workflow with TDD discipline and an adversarial review step. Flow: `proposal` → `specs` → `design` → `review` → `test-plan` → `tasks` → `apply` → `verify`. `review` is written by a fresh-context, read-only reviewer (a second model when one is available) and emits a `VERDICT:` line telling the agent to gate `test-plan`, `tasks`, and `apply`; OpenSpec only checks that artifacts exist, so enforce the gate with your own CI or hook. `test-plan` maps every spec scenario to a named test and doubles as a red/green ledger that `verify` audits. |
|
||||
|
||||
> Want to contribute a community schema? Open an issue with a link to your repository, or submit a PR adding a row to this table.
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- [CLI Reference: Schema Commands](cli.md#schema-commands) - Full command documentation
|
||||
|
||||
@@ -1,91 +0,0 @@
|
||||
# Editing & Iterating on a Change
|
||||
|
||||
**Every artifact in a change is just a Markdown file you can edit at any time.** There is no locked "planning phase," no approval gate, no special edit mode to enter. Want to change the proposal after you've started building? Open `proposal.md` and change it. Realized the design is wrong mid-implementation? Fix `design.md` and keep going. That's the whole answer, and it's by design.
|
||||
|
||||
This page is for the moment you think "wait, can I go back and change that?" Yes. Here's how, for each common case.
|
||||
|
||||
## Two ways to edit anything
|
||||
|
||||
You always have both:
|
||||
|
||||
1. **Edit the file directly.** Artifacts are plain Markdown in `openspec/changes/<name>/`. Open `proposal.md`, `design.md`, `tasks.md`, or a delta spec under `specs/` in your editor and change it. Nothing else is required.
|
||||
|
||||
2. **Ask your AI to revise it.** In chat, just say what you want: "Update the proposal to drop the caching idea and add a rate-limit section," or "the design should use a queue, not polling." The AI edits the artifact for you, using the rest of the change as context.
|
||||
|
||||
Use whichever fits the moment. Small wording tweak? Edit the file. Substantive rethink? Let the AI revise with full context.
|
||||
|
||||
## "How do I update the proposal (or specs) after I've started?"
|
||||
|
||||
Just update it. Same change, refined.
|
||||
|
||||
If you're using the expanded commands, the natural flow is: edit the artifact, then run `/opsx:continue` to pick up from the new state, or `/opsx:apply` to keep implementing against the updated plan. If you're on the default `core` commands, edit the artifact and run `/opsx:apply`; it reads the current files, so it builds against whatever the artifacts now say.
|
||||
|
||||
The mental model: artifacts are the live plan, not a signed contract. The AI always works from their current contents, so editing them steers the work.
|
||||
|
||||
```text
|
||||
You: I want to change the approach in this change.
|
||||
|
||||
You: [edit design.md, or tell the AI:]
|
||||
Update design.md to use a background job instead of a synchronous call.
|
||||
|
||||
AI: Updated design.md. The task list still fits; want me to continue applying?
|
||||
|
||||
You: /opsx:apply
|
||||
```
|
||||
|
||||
This answers a very common question: there's no separate "update proposal" command because you don't need one. The file is the source of truth, and editing it (by hand or via the AI) is the update.
|
||||
|
||||
## "How do I go back to review after implementing?"
|
||||
|
||||
You don't have to "go back," because you never left. The workflow is fluid: review, edit, and implementation aren't sequential phases you're trapped in.
|
||||
|
||||
Concretely, after some `/opsx:apply` work:
|
||||
|
||||
- Want to re-examine the plan? Open the artifacts and read them, or run `openspec show <change>` in your terminal for a consolidated view.
|
||||
- Found something to change? Edit the artifact (or ask the AI to), then continue.
|
||||
- Want a structured check that the code matches the plan? Run `/opsx:verify` (expanded command). It reports completeness, correctness, and coherence without blocking anything. See [Workflows: Verify](workflows.md#verify-check-your-work).
|
||||
|
||||
There's no "review phase" to return to, because review is something you can do at any point, including after implementation.
|
||||
|
||||
## "I edited the code by hand. How do I reconcile that with OpenSpec?"
|
||||
|
||||
This happens constantly and it's fine. You tweaked something in your editor, and now the code and the artifacts disagree. Bring them back in sync in whichever direction is true:
|
||||
|
||||
- **The code is now correct, the spec is stale.** Update the delta spec (and tasks, if relevant) to describe the behavior you actually shipped. The spec should match reality before you archive, because archiving merges the spec into your source of truth.
|
||||
- **The spec is correct, the code drifted.** Keep building or fixing until the code matches the spec.
|
||||
|
||||
A fast way to surface mismatches is `/opsx:verify`: it reads your artifacts and your code and tells you where they diverge. Treat its output as a to-do list for reconciliation, then archive once they agree.
|
||||
|
||||
The principle: at archive time, your specs become the truth of record. So before you archive, make the specs honest about what the code does. Manual edits are welcome; just don't let them quietly desync the spec.
|
||||
|
||||
## Refining a proposal you're not happy with
|
||||
|
||||
If a generated proposal misses the mark, you have three good moves:
|
||||
|
||||
- **Iterate in place.** Tell the AI what's off ("the scope is too broad, drop the admin features") and let it revise. Cheapest and usually right.
|
||||
- **Explore first, then re-propose.** If the problem is that the idea itself is unclear, step back to `/opsx:explore`, think it through, and let a sharper proposal come out of that. See [Explore First](explore.md).
|
||||
- **Start fresh.** If the intent has fundamentally changed, a new change can be clearer than patching the old one.
|
||||
|
||||
That last move has its own decision guide, next.
|
||||
|
||||
## When to update vs. start a new change
|
||||
|
||||
Short version: **update when it's the same work refined; start new when the intent fundamentally changed or the scope exploded into different work.**
|
||||
|
||||
- Same goal, better approach? Update.
|
||||
- Scope narrowing (ship the MVP now, more later)? Update, then archive, then a new change for phase two.
|
||||
- The problem itself changed ("add dark mode" became "build a full theming system")? New change.
|
||||
|
||||
There's a full flowchart and worked examples in [Workflows: When to Update vs Start Fresh](workflows.md#when-to-update-vs-start-fresh) and a deeper treatment in [OPSX: When to Update vs. Start Fresh](opsx.md#when-to-update-vs-start-fresh).
|
||||
|
||||
## A note on tasks
|
||||
|
||||
`tasks.md` is a living checklist, not a frozen plan. As you implement, you can add tasks you discover, remove ones that turned out unnecessary, or reorder them. The AI checks items off as it completes them during `/opsx:apply`, and it resumes from the first unchecked task if you come back later. Editing the list mid-flight is expected.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Workflows](workflows.md) - patterns, plus the update-vs-new decision guide
|
||||
- [Reviewing a Change](reviewing-changes.md) - the two-minute pass on a plan before you build it
|
||||
- [Explore First](explore.md) - the place to step back to when an idea needs rethinking
|
||||
- [Commands](commands.md) - `/opsx:continue`, `/opsx:apply`, and `/opsx:verify` in detail
|
||||
- [Concepts: Artifacts](concepts.md#artifacts) - what each artifact is for
|
||||
@@ -1,224 +0,0 @@
|
||||
# Examples & Recipes
|
||||
|
||||
Real changes, start to finish. Each recipe shows the commands you'd type and what you'd see back, so you can match your situation to a pattern and copy it. These use the default **core** commands (`propose`, `explore`, `apply`, `update`, `sync`, `archive`); where the expanded set helps, it's noted.
|
||||
|
||||
A reminder before you start: slash commands like `/opsx:propose` go in your **AI assistant's chat**, and `openspec` commands go in your **terminal**. If that's new, read [How Commands Work](how-commands-work.md) first. In the transcripts below, `You:` and `AI:` are the chat, and lines starting with `$` are the terminal.
|
||||
|
||||
> **Not sure what you're building yet?** Most of these recipes are sharper if you start with `/opsx:explore` to think it through first. [Recipe 3](#recipe-3-exploring-before-you-commit) shows it in action, and the [Explore First](explore.md) guide makes the full case.
|
||||
|
||||
## Recipe 1: A small feature, the fast path
|
||||
|
||||
**When to use it:** you know what you want, and it's a contained piece of work. This is the most common recipe.
|
||||
|
||||
The whole thing is three commands. Propose, build, archive.
|
||||
|
||||
```text
|
||||
You: /opsx:propose add-logout-button
|
||||
|
||||
AI: Created openspec/changes/add-logout-button/
|
||||
✓ proposal.md — why and what
|
||||
✓ specs/ — the new requirement and its scenarios
|
||||
✓ design.md — technical approach
|
||||
✓ tasks.md — implementation checklist
|
||||
Ready for implementation. Run /opsx:apply.
|
||||
```
|
||||
|
||||
Now read the plan. Open the proposal and the delta spec. This is the moment OpenSpec is built for: catching a wrong assumption while it's still one paragraph, not 400 lines of code. Edit any artifact directly if something's off, then continue.
|
||||
|
||||
```text
|
||||
You: /opsx:apply
|
||||
|
||||
AI: Working through tasks...
|
||||
✓ 1.1 Add logout button to header
|
||||
✓ 1.2 Clear session on click
|
||||
✓ 1.3 Add confirmation dialog
|
||||
All tasks complete!
|
||||
|
||||
You: /opsx:archive
|
||||
|
||||
AI: Archiving add-logout-button...
|
||||
✓ Merged specs into openspec/specs/auth/spec.md
|
||||
✓ Moved to openspec/changes/archive/2026-06-22-add-logout-button/
|
||||
Done. Ready for the next change.
|
||||
```
|
||||
|
||||
That's it. The logout behavior is now part of your specs, and the change is filed away with its full context.
|
||||
|
||||
## Recipe 2: A bug fix
|
||||
|
||||
**When to use it:** something is broken and you want the fix recorded as a deliberate change to behavior, not a mystery commit.
|
||||
|
||||
Bug fixes work exactly like features. The difference is in how you frame the proposal: describe the *correct* behavior, not just "fix the bug."
|
||||
|
||||
```text
|
||||
You: /opsx:propose fix-login-redirect-loop
|
||||
|
||||
AI: Created openspec/changes/fix-login-redirect-loop/
|
||||
The proposal captures the current broken behavior and the
|
||||
intended behavior. The delta spec MODIFIES the redirect
|
||||
requirement so it's now precise and testable.
|
||||
Ready for implementation.
|
||||
```
|
||||
|
||||
Because the fix lands as a `MODIFIED` requirement with a fresh scenario, the next person (or the next AI session) sees not just that you fixed it, but what "correct" means. Then `/opsx:apply` and `/opsx:archive` as usual.
|
||||
|
||||
Tip: for a fix, a good scenario is the regression test in prose. "GIVEN a logged-out user, WHEN they submit valid credentials, THEN they land on the dashboard and are not redirected again." Write that, and the implementation has a clear target.
|
||||
|
||||
## Recipe 3: Exploring before you commit
|
||||
|
||||
**When to use it:** you have a problem but not yet a plan. You're not sure what to build, or which approach is right.
|
||||
|
||||
Start with `/opsx:explore`. It's a thinking partner with no structure. It never writes code, and writes nothing else unless you ask it to capture what you decided, or say yes when it offers. It reads your codebase and helps you decide.
|
||||
|
||||
```text
|
||||
You: /opsx:explore
|
||||
|
||||
AI: What would you like to explore?
|
||||
|
||||
You: Page loads feel slow but I don't know where the time goes.
|
||||
|
||||
AI: Let me look... I found three likely culprits:
|
||||
1. Large unoptimized images on the product list
|
||||
2. Synchronous data fetching that blocks render
|
||||
3. Re-renders triggered by context changes
|
||||
Which should we tackle first?
|
||||
|
||||
You: The data fetching one.
|
||||
|
||||
You: /opsx:propose optimize-product-list-fetching
|
||||
|
||||
AI: Created the change, with a proposal informed by what we just
|
||||
found. Ready for implementation.
|
||||
```
|
||||
|
||||
Exploration clarifies your thinking *before* you spend a change on it. When the insight crystallizes, propose, and the AI carries the context forward.
|
||||
|
||||
## Recipe 4: Juggling two changes at once
|
||||
|
||||
**When to use it:** you're mid-feature and an urgent fix jumps the queue.
|
||||
|
||||
Changes are independent folders, so parallel work doesn't conflict. Start the fix, ship it, then return to the feature right where you left off.
|
||||
|
||||
```text
|
||||
You: I'm partway through add-dark-mode, but I need to fix a login bug now.
|
||||
|
||||
You: /opsx:propose fix-login-redirect
|
||||
|
||||
AI: Created openspec/changes/fix-login-redirect/. Ready for implementation.
|
||||
|
||||
You: /opsx:apply
|
||||
|
||||
AI: Implemented the fix. All tasks complete.
|
||||
|
||||
You: /opsx:archive
|
||||
|
||||
AI: ✓ Archived fix-login-redirect.
|
||||
|
||||
You: Back to dark mode.
|
||||
|
||||
You: /opsx:apply add-dark-mode
|
||||
|
||||
AI: Resuming add-dark-mode. Picking up at task 2.3: Update Header...
|
||||
```
|
||||
|
||||
Naming the change in `/opsx:apply add-dark-mode` is how you point the AI at a specific change when more than one is active. Because tasks track completion in `tasks.md`, the AI knows exactly where you stopped.
|
||||
|
||||
When several changes are done at once, the expanded `/opsx:bulk-archive` files them together and resolves spec conflicts by checking what's actually implemented. See [Workflows](workflows.md#parallel-changes).
|
||||
|
||||
## Recipe 5: A refactor with no behavior change
|
||||
|
||||
**When to use it:** you're restructuring code, and externally visible behavior should stay identical.
|
||||
|
||||
This is the interesting case, because a pure refactor has *nothing to add to your specs*. The behavior contract doesn't change; only the implementation does. So the work lives in the design and tasks, and the spec delta is empty or absent.
|
||||
|
||||
```text
|
||||
You: /opsx:propose refactor-payment-module
|
||||
|
||||
AI: Created the change. The proposal states the goal (split the
|
||||
payment module, no behavior change) and the design captures
|
||||
the new structure. No spec changes, since behavior is identical.
|
||||
Ready for implementation.
|
||||
```
|
||||
|
||||
Declare the empty delta explicitly by setting `skip_specs: true` in the change's `.openspec.yaml`:
|
||||
|
||||
```yaml
|
||||
schema: spec-driven
|
||||
skip_specs: true
|
||||
```
|
||||
|
||||
Without the marker, `openspec validate` rejects a change with zero deltas (so a forgotten specs phase still gets caught); with it, validation passes and `openspec status` shows the specs stage as explicitly skipped rather than pending. If the refactor turns out to change behavior after all, remove `skip_specs` from `.openspec.yaml` and write the delta specs — validate treats the marker plus spec files as a conflict, so the stale marker can't linger silently.
|
||||
|
||||
Archiving a marked change needs no extra flags (there are no deltas to merge). Independently, the `--skip-specs` flag tells the terminal command to skip the spec step explicitly:
|
||||
|
||||
```bash
|
||||
$ openspec archive refactor-payment-module --skip-specs
|
||||
```
|
||||
|
||||
The same flag is handy for tooling, CI, and docs-only changes. The principle: specs describe behavior, so if behavior didn't change, the spec shouldn't either. See [Concepts](concepts.md#what-a-spec-is-and-is-not).
|
||||
|
||||
## Recipe 6: Step-by-step control (expanded commands)
|
||||
|
||||
**When to use it:** a complex or risky change where you want to review each artifact before moving on.
|
||||
|
||||
The core `/opsx:propose` drafts everything at once. When you'd rather go one step at a time, turn on the expanded commands:
|
||||
|
||||
```bash
|
||||
$ openspec config profile # select the expanded workflows
|
||||
$ openspec update # apply them to this project
|
||||
```
|
||||
|
||||
Now you can scaffold and build incrementally:
|
||||
|
||||
```text
|
||||
You: /opsx:new add-2fa
|
||||
|
||||
AI: Created openspec/changes/add-2fa/. Ready to create: proposal.
|
||||
|
||||
You: /opsx:continue
|
||||
|
||||
AI: Created proposal.md. Now available: specs, design.
|
||||
|
||||
You: /opsx:continue
|
||||
|
||||
AI: Created specs/auth/spec.md. Now available: design.
|
||||
```
|
||||
|
||||
Review each artifact as it lands, edit freely, and continue when you're happy. When you want the rest drafted in one go, `/opsx:ff` fast-forwards through the remaining planning artifacts. Before archiving, `/opsx:verify` checks that the implementation actually matches the specs. See [Workflows](workflows.md#opsxff-vs-opsxcontinue).
|
||||
|
||||
## Recipe 7: Learning the whole loop hands-on
|
||||
|
||||
**When to use it:** you've installed OpenSpec and want to *feel* the workflow on your own code, not a toy example.
|
||||
|
||||
Turn on the expanded commands (see Recipe 6), then:
|
||||
|
||||
```text
|
||||
You: /opsx:onboard
|
||||
|
||||
AI: Welcome to OpenSpec! I'll walk you through a complete change
|
||||
using your actual codebase. Let me scan for a small, safe
|
||||
improvement we can make together...
|
||||
```
|
||||
|
||||
`/opsx:onboard` finds a real (small) improvement, creates a change for it, implements it, and archives it, narrating every step. It takes 15 to 30 minutes and leaves you with a real change you can keep or discard. It's the gentlest way to learn. See [Commands](commands.md#opsxonboard).
|
||||
|
||||
## Checking your work from the terminal
|
||||
|
||||
Any time, from your terminal, you can inspect the state of things:
|
||||
|
||||
```bash
|
||||
$ openspec list # active changes
|
||||
$ openspec show add-dark-mode # one change in detail
|
||||
$ openspec validate add-dark-mode # check structure
|
||||
$ openspec view # interactive dashboard
|
||||
```
|
||||
|
||||
These are read-and-inspect tools. The proposing and building still happen through slash commands in chat. Full details in the [CLI reference](cli.md).
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Explore First](explore.md): the recommended way to start when you're unsure
|
||||
- [Workflows](workflows.md): the patterns above, with decision guidance on when to use each
|
||||
- [Commands](commands.md): every slash command in detail
|
||||
- [Getting Started](getting-started.md): the canonical first-change walkthrough
|
||||
- [Concepts](concepts.md): why the pieces fit together the way they do
|
||||
@@ -1,134 +0,0 @@
|
||||
# Using OpenSpec in an Existing Project
|
||||
|
||||
**You do not document your whole codebase to start. You write specs only for what you're about to change.** That's the single most important thing to know about adopting OpenSpec on an existing project, and it's why OpenSpec is built brownfield-first.
|
||||
|
||||
A common worry sounds like this: "My app is 80,000 lines old. Do I have to write specs for all of it before OpenSpec is useful?" No. You'd hate that, and so would we. OpenSpec grows your specs one change at a time. Your first change documents the slice it touches, the next change documents its slice, and over months your specs fill in naturally around the work you actually do.
|
||||
|
||||
This guide shows how to start on day one without boiling the ocean.
|
||||
|
||||
## The thirty-second version
|
||||
|
||||
```bash
|
||||
$ cd your-existing-project
|
||||
$ openspec init # adds openspec/ and your AI tool's commands
|
||||
```
|
||||
|
||||
Then, in your AI chat:
|
||||
|
||||
```text
|
||||
/opsx:explore # optional: have the AI read the area you'll touch
|
||||
/opsx:propose <a real, small change you actually need>
|
||||
/opsx:apply
|
||||
/opsx:archive
|
||||
```
|
||||
|
||||
Your specs now describe exactly the part of the system that change touched, and nothing more. That's correct. You're done worrying about the other 80,000 lines.
|
||||
|
||||
## Why delta-first is the whole trick
|
||||
|
||||
OpenSpec changes are written as **deltas**: `ADDED`, `MODIFIED`, `REMOVED`. A delta describes what's changing relative to current behavior, not the entire system.
|
||||
|
||||
This is exactly what brownfield work needs. You're rarely building from nothing. You're adding a field, fixing a redirect, tightening a timeout. A delta lets you specify that one change precisely without first writing a 40-page spec of everything around it.
|
||||
|
||||
So your `openspec/specs/` directory doesn't start full and complete. It starts nearly empty and accumulates. Each archived change merges its delta in. The spec for `auth/` becomes thorough only after you've made several auth changes, which is exactly when you want it thorough.
|
||||
|
||||
If you want the deeper mechanics, see [Concepts: Delta Specs](concepts.md#delta-specs).
|
||||
|
||||
## Your first change on a real codebase
|
||||
|
||||
Pick something small and real. Not a toy, not a rewrite. A change you were going to make this week anyway. Small first changes teach you the workflow with low stakes.
|
||||
|
||||
**Step 1: Let the AI read the relevant area.** This is where `/opsx:explore` earns its keep on an unfamiliar or large codebase. Point it at the part you're about to touch and let it map how things work before proposing anything.
|
||||
|
||||
```text
|
||||
You: /opsx:explore
|
||||
|
||||
AI: What would you like to explore?
|
||||
|
||||
You: I need to add rate limiting to our public API, but I'm not sure
|
||||
how requests currently flow through the middleware.
|
||||
|
||||
AI: Let me trace it... [reads the router, middleware stack, and config]
|
||||
Requests hit Express, pass through auth middleware, then your
|
||||
controllers. There's no rate-limiting layer today. The cleanest
|
||||
insertion point is a middleware right after auth. Want me to scope it?
|
||||
```
|
||||
|
||||
Notice the AI now understands your actual structure, so the proposal it writes will fit your code, not a generic template. On a big codebase, this single habit saves the most pain. See [Explore First](explore.md).
|
||||
|
||||
**Step 2: Propose the change.** The proposal and its delta spec capture just this change.
|
||||
|
||||
```text
|
||||
You: /opsx:propose add-api-rate-limiting
|
||||
```
|
||||
|
||||
**Step 3: Build and archive** with `/opsx:apply` and `/opsx:archive`, same as any change. After archiving, you have a real spec for your rate-limiting behavior, born from a change you needed anyway.
|
||||
|
||||
## Prefer a guided tour? Use onboard
|
||||
|
||||
If you'd rather watch the whole loop happen on your own code with narration, the expanded command `/opsx:onboard` does exactly that: it scans your codebase for a small, safe improvement, then walks you through proposing, building, and archiving it, explaining each step.
|
||||
|
||||
Turn on the expanded commands first:
|
||||
|
||||
```bash
|
||||
$ openspec config profile # select the expanded workflows
|
||||
$ openspec update # apply them to this project
|
||||
```
|
||||
|
||||
Then in chat:
|
||||
|
||||
```text
|
||||
/opsx:onboard
|
||||
```
|
||||
|
||||
It's the gentlest possible introduction on a real project, and it leaves you with a genuine (small) change you can keep or discard. See [Commands: `/opsx:onboard`](commands.md#opsxonboard).
|
||||
|
||||
## "But I already have requirements docs"
|
||||
|
||||
Maybe you have a PRD, an SRS, a formal spec, even TLA+ models. Good. You don't import them wholesale, and you don't throw them away either.
|
||||
|
||||
Treat existing docs as **source material for exploration**, not as specs to convert. When you start a change, paste or point the AI at the relevant section, and let it shape a focused OpenSpec delta from it. The delta captures the behavior you're changing now, in OpenSpec's testable requirement-and-scenario form. Your original documents stay where they are as background.
|
||||
|
||||
The honest reason: OpenSpec specs are deliberately behavior-first and scoped to changes. A 40-page PRD is a different artifact with a different job. Forcing a one-time bulk conversion tends to produce a large, stale spec nobody trusts. Letting specs grow from real changes keeps them accurate.
|
||||
|
||||
```text
|
||||
You: /opsx:explore
|
||||
You: Here's the section of our PRD about checkout. I'm implementing the
|
||||
"guest checkout" requirement next.
|
||||
[paste the relevant requirement]
|
||||
AI: [reads it, asks clarifying questions, then helps scope a change]
|
||||
You: /opsx:propose add-guest-checkout
|
||||
```
|
||||
|
||||
## Organizing specs in a big codebase
|
||||
|
||||
Specs live under `openspec/specs/`, grouped by **domain**: a logical area that matches how your team thinks about the system. You don't have to design the whole taxonomy up front. Create a domain folder when your first change in that area needs one.
|
||||
|
||||
Common ways to slice domains:
|
||||
|
||||
- **By feature area:** `auth/`, `payments/`, `search/`
|
||||
- **By component:** `api/`, `frontend/`, `workers/`
|
||||
- **By bounded context:** `ordering/`, `fulfillment/`, `inventory/`
|
||||
|
||||
Pick whatever makes a newcomer nod. You can refine later. See [Concepts: Specs](concepts.md#specs).
|
||||
|
||||
## Monorepos and work that spans repos
|
||||
|
||||
For a monorepo, the simplest model is one `openspec/` directory at the repo root, with domains that map to your packages or services. That covers most teams.
|
||||
|
||||
If your work genuinely spans **multiple repositories** (or several packages you treat as separate), OpenSpec has a beta **stores** feature: planning lives in its own standalone repo that any of your code repos can reference, so the plan does not have to live inside one repo's `openspec/` folder. It's beta, so treat its commands and state as evolving. Start with the [Stores User Guide](stores-beta/user-guide.md) for the mental model and the smallest useful path.
|
||||
|
||||
## A few honest cautions
|
||||
|
||||
- **Resist the urge to back-fill everything.** Writing specs for code you aren't changing feels productive and usually isn't. Those specs go stale, because nothing forces them to track reality. Let real changes drive your specs.
|
||||
- **Keep early changes small.** Your first few changes are as much about learning the rhythm as shipping. A tight scope makes the loop fast and the lessons cheap.
|
||||
- **Commit `openspec/` to git.** Your specs and archive belong in version control alongside the code they describe.
|
||||
- **Give the AI context.** On a large codebase with strong conventions, fill in `openspec/config.yaml`'s `context:` so every proposal respects your stack and patterns. See [Customization](customization.md#project-configuration).
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Explore First](explore.md) - the key habit for understanding code before you change it
|
||||
- [Getting Started](getting-started.md) - the full first-change walkthrough
|
||||
- [Editing & Iterating on a Change](editing-changes.md) - adjusting a change as you learn
|
||||
- [Concepts: Delta Specs](concepts.md#delta-specs) - why deltas make brownfield work clean
|
||||
- [Customization](customization.md) - teach OpenSpec your project's conventions
|
||||
-127
@@ -1,127 +0,0 @@
|
||||
# Explore First
|
||||
|
||||
**`/opsx:explore` is your thinking partner. Reach for it whenever you have a problem but not yet a plan.** It investigates your codebase, weighs options with you, and clarifies what you actually want, all before a line of code is written. When the picture is clear, it hands off to `/opsx:propose`.
|
||||
|
||||
If you take one habit from these docs, take this one: **when you're not sure, explore before you propose.**
|
||||
|
||||
Here's why that matters. AI coding assistants are eager. Ask vaguely and they'll confidently build *something*, just maybe not the thing you needed. Explore is the cure. It's a no-stakes conversation where you and the AI figure out the right move together, so that by the time you propose, you're proposing the right thing.
|
||||
|
||||
## When to explore
|
||||
|
||||
Explore is the right first step more often than people expect. Use it when any of these is true:
|
||||
|
||||
- You know the *problem* but not the *solution*. ("Pages feel slow." "Auth is a mess." "We keep getting duplicate orders.")
|
||||
- You're choosing between approaches and want the tradeoffs laid out against your actual code.
|
||||
- You're new to a codebase and need to understand how something works before you change it.
|
||||
- The requirements are fuzzy and you want to sharpen them before committing.
|
||||
- You suspect the work is bigger or smaller than it looks and want to scope it honestly.
|
||||
|
||||
Skip explore only when you already know exactly what you want and how. In that case go straight to [`/opsx:propose`](commands.md#opsxpropose).
|
||||
|
||||
## What it does (and doesn't)
|
||||
|
||||
Explore is a **conversation**, not a generator.
|
||||
|
||||
**It does:**
|
||||
- Read and search your codebase to answer real questions.
|
||||
- Compare options and name the tradeoffs of each.
|
||||
- Draw diagrams to make a design legible.
|
||||
- Help you narrow a vague idea into a concrete, buildable scope.
|
||||
- Capture the exploration when you ask, or when you accept its offer: it scaffolds the change with `openspec new change` and writes the planning artifacts you named, or updates an existing change's artifacts.
|
||||
- Transition to `/opsx:propose` when you're ready.
|
||||
|
||||
**It does not:**
|
||||
- Write or modify code. Explore never writes code, on any path, capture included.
|
||||
- Design or edit your schemas or templates. Shaping those is a change, not thinking.
|
||||
- Start a change or write an artifact on its own. It writes nothing unless you ask, or say yes when it offers, and then only what you agreed to, plus the setup files starting a change needs (see below).
|
||||
- Push you toward capturing. It offers when the thinking crystallizes; you decide.
|
||||
|
||||
That's the point. Exploring costs you nothing and commits you to nothing until you say so. You can explore three dead ends, learn something from each, and only then propose the path that survived.
|
||||
|
||||
## It's already installed
|
||||
|
||||
Good news: `/opsx:explore` ships in the default **core** profile, right alongside `propose`, `apply`, `update`, `sync`, and `archive`. You don't need to enable anything. If OpenSpec is set up in your project, explore is ready in your AI chat. (As with all `/opsx:*` commands, you type it in your assistant's chat, not the terminal. See [How Commands Work](how-commands-work.md).)
|
||||
|
||||
## A full example
|
||||
|
||||
Watch how a vague worry becomes a sharp, buildable change.
|
||||
|
||||
```text
|
||||
You: /opsx:explore
|
||||
|
||||
AI: What would you like to explore?
|
||||
|
||||
You: Our checkout sometimes creates duplicate orders. I don't know why
|
||||
and I don't know how to fix it safely.
|
||||
|
||||
AI: Let me dig into the checkout path...
|
||||
[reads the order service, the payment webhook handler, and the
|
||||
client submit logic]
|
||||
|
||||
Here's what I found. There are two ways a duplicate can happen:
|
||||
|
||||
1. The client can submit twice (double-click, retry on slow network).
|
||||
Nothing debounces it.
|
||||
2. The payment webhook can fire more than once, and the handler
|
||||
creates an order each time. There's no idempotency key.
|
||||
|
||||
Cause #2 is the dangerous one: it can charge and fulfill twice.
|
||||
|
||||
Three ways to fix it, roughly in order of robustness:
|
||||
- Idempotency key on the order-creation endpoint (handles both causes)
|
||||
- Dedup on the webhook by payment-intent id (handles #2 only)
|
||||
- Client-side debounce (handles #1 only, papers over the real bug)
|
||||
|
||||
Given your code already stores the payment-intent id, the
|
||||
idempotency-key approach is a small change with the biggest payoff.
|
||||
Want me to scope that?
|
||||
|
||||
You: Yes, let's do the idempotency key.
|
||||
|
||||
You: /opsx:propose add-order-idempotency-key
|
||||
|
||||
AI: Created openspec/changes/add-order-idempotency-key/, with a proposal
|
||||
and delta spec grounded in what we just found. Ready for implementation.
|
||||
```
|
||||
|
||||
Notice what happened. The starting point was "something is wrong and I'm scared to touch it." Twenty seconds of exploration turned that into a named root cause, three ranked options, a recommendation tied to the existing code, and a precise change. The proposal that follows is sharp because the thinking happened first.
|
||||
|
||||
## Handing off to propose
|
||||
|
||||
Explore doesn't archive into anything. When you're ready, you simply start a change, and the AI carries the context from your conversation into the artifacts.
|
||||
|
||||
```text
|
||||
explore ──► propose ──► apply ──► archive
|
||||
(think) (agree) (build) (record)
|
||||
```
|
||||
|
||||
You can say it in plain language ("let's turn this into a change") or run `/opsx:propose <name>` directly. Either way, the exploration you just did becomes the foundation of the proposal, not throwaway chat.
|
||||
|
||||
You can also ask explore to capture the change itself, without leaving the conversation: "start a change for this" scaffolds the folder, and "write the proposal too" writes exactly the artifacts you named. Scaffolding also lays down the change's own metadata, and fills in anything your project is missing at the top level (`openspec/specs/`, `openspec/changes/archive/`, a `config.yaml`).
|
||||
|
||||
That's the same destination as handing off, with one difference: propose writes the whole set your schema requires to reach implementation, while capture writes only the artifacts you named.
|
||||
|
||||
If you use the expanded command set, explore can hand off to `/opsx:new` instead, for step-by-step artifact creation. See [Workflows](workflows.md).
|
||||
|
||||
## Tips for a good exploration
|
||||
|
||||
- **Bring the problem, not the solution.** "Logins feel slow" gives the AI room to investigate. "Add a Redis cache" pre-commits you to an answer you haven't tested yet.
|
||||
- **Ask for the tradeoffs out loud.** "What are the downsides of each option?" gets you a more honest comparison.
|
||||
- **Let it read first.** The best explorations start with the AI actually looking at your code, not guessing. Point it at the relevant area if it helps.
|
||||
- **It's okay to bail.** If exploration reveals the idea isn't worth it, that's a win. You learned it cheaply.
|
||||
- **Explore again mid-change.** Stuck during `/opsx:apply`? You can step back and explore a sub-problem, then return.
|
||||
|
||||
## The honest tradeoffs
|
||||
|
||||
**What you gain:** explore catches wrong turns at the cheapest possible moment, before you've committed to anything. It's especially powerful in unfamiliar code, where the AI's ability to read and summarize the system saves you an afternoon of spelunking.
|
||||
|
||||
**What it costs:** a little patience. Explore is a conversation, so it's slower than firing off `/opsx:propose` and hoping. For work you genuinely understand already, that extra step is pure overhead, and you should skip it.
|
||||
|
||||
The rule of thumb: the fuzzier the task, the more explore pays off. The clearer the task, the more you can skip straight to proposing.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Commands: `/opsx:explore`](commands.md#opsxexplore): the precise reference
|
||||
- [Workflows](workflows.md): explore as part of the everyday loop
|
||||
- [Examples & Recipes](examples.md#recipe-3-exploring-before-you-commit): explore in a full walkthrough
|
||||
- [Getting Started](getting-started.md): the first-change guide, exploration included
|
||||
-155
@@ -1,155 +0,0 @@
|
||||
# FAQ
|
||||
|
||||
Quick answers to the questions people ask most. If your question is really a "something is broken" question, [Troubleshooting](troubleshooting.md) is the better page. If you want a term defined, see the [Glossary](glossary.md).
|
||||
|
||||
## The basics
|
||||
|
||||
### What is OpenSpec, in one sentence?
|
||||
|
||||
A lightweight layer that gets you and your AI coding assistant to agree on what to build, in writing, before any code is written.
|
||||
|
||||
### Why would I want that?
|
||||
|
||||
Because AI assistants are confident even when they're wrong. When the requirements live only in a chat thread, the AI fills gaps with guesses, and you find out after the code exists. OpenSpec moves the agreement earlier, where mistakes are cheap to fix. See [Core Concepts at a Glance](overview.md) for the full case.
|
||||
|
||||
### Do I have to use it for everything?
|
||||
|
||||
No. Use it where agreement matters, which is most non-trivial work. For a one-character typo fix, the ceremony probably isn't worth it, and that's fine.
|
||||
|
||||
### Can I use it on a big existing codebase, or only new projects?
|
||||
|
||||
Existing codebases are the main event. OpenSpec is brownfield-first: you do not document your whole app up front. You write specs only for what each change touches, and your specs fill in over time around the work you actually do. There's a dedicated guide: [Using OpenSpec in an Existing Project](existing-projects.md).
|
||||
|
||||
### Is it tied to one AI tool?
|
||||
|
||||
No. OpenSpec works with 30+ assistants, including Claude Code, Cursor, Devin Desktop, GitHub Copilot, Gemini CLI, Codex, and more. The full list and per-tool details are in [Supported Tools](supported-tools.md).
|
||||
|
||||
## Running commands
|
||||
|
||||
### Where do I type `/opsx:propose`?
|
||||
|
||||
In your AI assistant's chat, not your terminal. This is the single most common point of confusion, so it has its own page: [How Commands Work](how-commands-work.md). Short version: `openspec ...` runs in the terminal, `/opsx:...` runs in chat.
|
||||
|
||||
### How do I "start interactive mode"?
|
||||
|
||||
There isn't a separate mode to start. You open your AI assistant like normal and type a slash command into its chat. The slash command is how you "enter" OpenSpec. (The one genuinely interactive terminal feature is `openspec view`, a dashboard for browsing specs and changes.) Full explanation in [How Commands Work](how-commands-work.md).
|
||||
|
||||
### I typed a slash command and nothing happened. Why?
|
||||
|
||||
Most likely you typed it in the terminal instead of your AI chat, you used a spelling your tool doesn't register, or the commands aren't installed yet. If the files are missing — or you never set the tool up — run `openspec init`; `openspec update` only refreshes files that already exist. Then restart your assistant and use the form printed under "Getting started" — see [How To Invoke](supported-tools.md#how-to-invoke). [Troubleshooting](troubleshooting.md#commands-dont-show-up) has the full checklist.
|
||||
|
||||
### Why is the syntax `/opsx:propose` in one tool and `/opsx-propose` in another?
|
||||
|
||||
Each AI tool surfaces custom commands a little differently, and OpenSpec spells them the way your tool loads the file it wrote. A command file named `opsx-propose.md` is typed `/opsx-propose`; one filed under `commands/opsx/` is typed `/opsx:propose`. Tools that take skills instead of commands use the skill name — Codex needs `$openspec-propose`, Kimi Code `/skill:openspec-propose`. The `openspec init` "Getting started" line already prints the right form for the tools you picked; the full table is in [How To Invoke](supported-tools.md#how-to-invoke).
|
||||
|
||||
### What's the difference between a skill and a command?
|
||||
|
||||
Both are files OpenSpec writes so your assistant can run the workflow. Skills (`.../skills/openspec-*/SKILL.md`) are the newer cross-tool standard; commands (`.../commands/opsx-*`) are the older per-tool slash files. You don't need to pick. You just type the slash command, and OpenSpec installs whichever your tool uses.
|
||||
|
||||
## The workflow
|
||||
|
||||
### Where should I start if I'm not sure what to build?
|
||||
|
||||
With `/opsx:explore`. It's a no-stakes thinking partner that reads your codebase, lays out options, and turns a fuzzy problem into a concrete plan, all before any code gets written. It's in the default profile, so it's always available. When the plan is clear, it hands off to `/opsx:propose`. This is the single best habit to form, because it stops an eager AI from confidently building the wrong thing. See [Explore First](explore.md).
|
||||
|
||||
### What's the simplest possible flow?
|
||||
|
||||
```text
|
||||
/opsx:explore (optional) then /opsx:propose <what you want> then /opsx:apply then /opsx:archive
|
||||
```
|
||||
|
||||
Explore to think it through, propose to draft the plan, apply to build it, archive to file it away. Skip explore when you already know exactly what you want.
|
||||
|
||||
### What's the difference between `/opsx:propose` and `/opsx:new`?
|
||||
|
||||
`/opsx:propose` is the default one-step command: it creates the change and drafts all the planning artifacts at once. `/opsx:new` is part of the expanded command set and only scaffolds an empty change, leaving you to create artifacts one at a time with `/opsx:continue` (or all at once with `/opsx:ff`). Use propose unless you want step-by-step control. See [Commands](commands.md).
|
||||
|
||||
### What are `core` and expanded profiles?
|
||||
|
||||
A profile decides which slash commands get installed. **Core** (the default) gives you `propose`, `explore`, `apply`, `update`, `sync`, `archive`. The **expanded** set adds `new`, `continue`, `ff`, `verify`, `bulk-archive`, and `onboard` for finer control. Switch with `openspec config profile`, then apply with `openspec update`.
|
||||
|
||||
### Do I need to run `/opsx:sync`?
|
||||
|
||||
Usually not. Sync merges a change's delta specs into your main specs, and `/opsx:archive` will offer to do it for you. Run sync manually only when you want the specs merged before archiving, for example on a long-running change. See [Commands](commands.md#opsxsync).
|
||||
|
||||
### How do I edit a proposal, spec, or task after I've started?
|
||||
|
||||
Just edit the file. Every artifact is plain Markdown in `openspec/changes/<name>/`, and there's no locked phase or special edit mode. Change it by hand, or ask your AI to revise it ("update the design to use a queue"), then keep going. The AI always works from the current file contents. Full guide: [Editing & Iterating on a Change](editing-changes.md).
|
||||
|
||||
### Can I go back and change the plan after implementing some of it?
|
||||
|
||||
Yes, at any time. The workflow is fluid, so review and editing aren't phases you get locked out of. Edit the artifact, then continue. If you want a structured check that the code still matches the plan, run `/opsx:verify`. See [Editing & Iterating on a Change](editing-changes.md#how-do-i-go-back-to-review-after-implementing).
|
||||
|
||||
### I edited the code by hand. How do I reconcile it with the spec?
|
||||
|
||||
Bring them back in sync before you archive, since archiving makes your specs the record of truth. If the code is now correct, update the delta spec to match what you shipped; if the spec is correct, keep building until the code agrees. `/opsx:verify` surfaces the mismatches. See [Editing & Iterating on a Change](editing-changes.md#i-edited-the-code-by-hand-how-do-i-reconcile-that-with-openspec).
|
||||
|
||||
### When should I update an existing change versus start a new one?
|
||||
|
||||
Update when it's the same work, refined. Start fresh when the intent fundamentally changed or the scope exploded into different work. There's a decision flowchart and examples in [Workflows](workflows.md#when-to-update-vs-start-fresh).
|
||||
|
||||
### What if my session runs out of context, or requirements change mid-implementation?
|
||||
|
||||
This is where specs earn their keep. Because the plan lives in files (not only in chat history), you can clear your context, start a fresh AI session, and pick up with `/opsx:apply`; it reads the artifacts and resumes from the first unchecked task. If requirements change, edit the artifacts to match the new reality and continue. Keeping a clean context window also produces better results; clear it before implementation.
|
||||
|
||||
### Should I commit the `openspec/` folder to git?
|
||||
|
||||
Yes. Your specs, active changes, and archive are part of your project's history. Commit them like any other source. The archive in particular becomes a durable record of why your system works the way it does.
|
||||
|
||||
## Specs and changes
|
||||
|
||||
### What goes in a spec versus a design?
|
||||
|
||||
A spec describes observable behavior: what the system does, its inputs, outputs, and error conditions. A design describes how you'll build it: the technical approach, architecture decisions, file changes. If implementation could change without changing externally visible behavior, it belongs in the design, not the spec. [Concepts](concepts.md#what-a-spec-is-and-is-not) goes deeper.
|
||||
|
||||
### What's a delta spec?
|
||||
|
||||
A spec that describes only what's changing, using `ADDED`, `MODIFIED`, and `REMOVED` sections, rather than restating the whole spec. It's how OpenSpec handles edits to existing systems cleanly. See [Concepts](concepts.md#delta-specs).
|
||||
|
||||
### Where do archived changes go?
|
||||
|
||||
To `openspec/changes/archive/YYYY-MM-DD-<name>/`, with all change artifacts preserved. The change moves out of your active list. A change that explicitly declares `retire_capabilities: true` can also delete a main capability spec when it removes that capability's final requirement.
|
||||
|
||||
## Configuration and customization
|
||||
|
||||
### How do I tell the AI about my tech stack?
|
||||
|
||||
Put it in `openspec/config.yaml` under `context:`. That text is injected into every planning request, so the AI always knows your stack and conventions. See [Customization](customization.md#project-configuration).
|
||||
|
||||
### Can I generate specs in a language other than English?
|
||||
|
||||
Yes. Add a language instruction to your config's `context:`. [Multi-Language](multi-language.md) has copy-paste snippets for several languages.
|
||||
|
||||
### Can I change the workflow itself?
|
||||
|
||||
Yes, with custom schemas. A schema defines which artifacts exist and how they depend on each other. Fork the default with `openspec schema fork spec-driven my-workflow`, then edit it. See [Customization](customization.md#custom-schemas).
|
||||
|
||||
## Models, privacy, and upgrades
|
||||
|
||||
### Which AI model should I use?
|
||||
|
||||
OpenSpec works best with high-reasoning models. The README recommends models like Codex 5.5 and Opus 4.7 for both planning and implementation. Also keep your context window clean: clear it before implementation for best results.
|
||||
|
||||
### Does OpenSpec collect data?
|
||||
|
||||
It collects anonymous usage stats: command names and version only. No arguments, paths, content, or personal data, and it's off automatically in CI. Opt out with `export OPENSPEC_TELEMETRY=0` or `export DO_NOT_TRACK=1`.
|
||||
|
||||
### How do I upgrade?
|
||||
|
||||
Two steps. Upgrade the package (`npm install -g @fission-ai/openspec@latest`), then run `openspec update` inside each project to refresh the generated skills and commands.
|
||||
|
||||
### How do I uninstall OpenSpec?
|
||||
|
||||
There's no uninstall command, because it's just a global package plus files in your project. Remove the package (`npm uninstall -g @fission-ai/openspec`), and optionally delete the `openspec/` directory and the generated tool files. Step-by-step, including what's safe to keep, is in [Installation: Uninstalling](installation.md#uninstalling).
|
||||
|
||||
## Getting help
|
||||
|
||||
### Where do I ask questions or report bugs?
|
||||
|
||||
- **Discord:** [discord.gg/YctCnvvshC](https://discord.gg/YctCnvvshC)
|
||||
- **GitHub Issues:** [github.com/Fission-AI/OpenSpec/issues](https://github.com/Fission-AI/OpenSpec/issues)
|
||||
- **From your terminal:** `openspec feedback "your message"` opens a GitHub issue for you.
|
||||
|
||||
### These docs are wrong or confusing. What do I do?
|
||||
|
||||
Tell us, or fix it. Documentation PRs are welcome and valued. Open an issue or send a pull request.
|
||||
+3
-41
@@ -1,32 +1,6 @@
|
||||
# Getting Started
|
||||
|
||||
This guide explains how OpenSpec works after you've installed and initialized it. For installation instructions, see the [main README](../README.md#quick-start) or the [Installation guide](installation.md). New to the whole docs set? The [documentation home](README.md) maps everything.
|
||||
|
||||
> **Where do I type these commands?** Two places, and mixing them up is the most common early stumble.
|
||||
>
|
||||
> - `openspec ...` commands (like `openspec init`) run in your **terminal**.
|
||||
> - `/opsx:...` commands (like `/opsx:propose`) run in your **AI assistant's chat**, the same box where you'd ask it to write code.
|
||||
>
|
||||
> There's no separate "interactive mode" to start. You just type the slash command in chat and your assistant takes it from there. Full explanation: [How Commands Work](how-commands-work.md).
|
||||
|
||||
## Your First Five Minutes
|
||||
|
||||
The whole loop, with each step labeled by where it happens:
|
||||
|
||||
```text
|
||||
TERMINAL $ npm install -g @fission-ai/openspec@latest
|
||||
TERMINAL $ cd your-project && openspec init
|
||||
AI CHAT /opsx:explore (optional: think it through first)
|
||||
AI CHAT /opsx:propose add-dark-mode (AI drafts the plan; you review it)
|
||||
AI CHAT /opsx:apply (AI builds it)
|
||||
AI CHAT /opsx:archive (specs updated, change filed away)
|
||||
```
|
||||
|
||||
Two terminal steps to set up, then you live in chat. The rest of this guide unpacks what each step does and what you'll see.
|
||||
|
||||
**Don't want to do the terminal part yourself?** Paste the [setup prompt](installation.md#install-with-your-ai-assistant) into your assistant and it handles both lines, then reports what it created.
|
||||
|
||||
> **Not sure what to build yet? Start with `/opsx:explore`.** It's a no-stakes thinking partner that reads your codebase, weighs options, and sharpens a fuzzy idea into a concrete plan, all before any code gets written. When the picture is clear, it hands off to `/opsx:propose`. This is the single best habit for working with an AI that will otherwise confidently build the wrong thing. See the [Explore guide](explore.md).
|
||||
This guide explains how OpenSpec works after you've installed and initialized it. For installation instructions, see the [main README](../README.md#quick-start).
|
||||
|
||||
## How It Works
|
||||
|
||||
@@ -35,19 +9,16 @@ OpenSpec helps you and your AI coding assistant agree on what to build before an
|
||||
**Default quick path (core profile):**
|
||||
|
||||
```text
|
||||
/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
|
||||
(optional)
|
||||
/opsx:propose ──► /opsx:apply ──► /opsx:archive
|
||||
```
|
||||
|
||||
Start with `/opsx:explore` when you're figuring out what to do, or jump straight to `/opsx:propose` when you already know. Explore is in the default profile, so it's always there when you want it.
|
||||
|
||||
**Expanded path (custom workflow selection):**
|
||||
|
||||
```text
|
||||
/opsx:new ──► /opsx:ff or /opsx:continue ──► /opsx:apply ──► /opsx:verify ──► /opsx:archive
|
||||
```
|
||||
|
||||
The default global profile is `core`, which includes `propose`, `explore`, `apply`, `update`, `sync`, and `archive`. You can enable the expanded workflow commands with `openspec config profile` and then `openspec update`.
|
||||
The default global profile is `core`, which includes `propose`, `explore`, `apply`, and `archive`. You can enable the expanded workflow commands with `openspec config profile` and then `openspec update`.
|
||||
|
||||
## What OpenSpec Creates
|
||||
|
||||
@@ -276,16 +247,7 @@ openspec view
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Explore First](explore.md) - Use `/opsx:explore` to think through an idea before you commit
|
||||
- [Reviewing a Change](reviewing-changes.md) - What to check in the plan the AI drafts, before any code
|
||||
- [Writing Good Specs](writing-specs.md) - What a strong requirement and scenario look like
|
||||
- [Using OpenSpec in an Existing Project](existing-projects.md) - Start on a large brownfield codebase
|
||||
- [Editing & Iterating on a Change](editing-changes.md) - Update artifacts, go back, reconcile manual edits
|
||||
- [Core Concepts at a Glance](overview.md) - The whole mental model on one page
|
||||
- [Examples & Recipes](examples.md) - Real changes, start to finish
|
||||
- [Workflows](workflows.md) - Common patterns and when to use each command
|
||||
- [Commands](commands.md) - Full reference for all slash commands
|
||||
- [Concepts](concepts.md) - Deeper understanding of specs, changes, and schemas
|
||||
- [Customization](customization.md) - Make OpenSpec work your way
|
||||
- [Stores](stores-beta/user-guide.md) - Planning that spans repos or teams? Keep it in its own repo (beta)
|
||||
- [FAQ](faq.md) and [Troubleshooting](troubleshooting.md) - When you get stuck
|
||||
|
||||
@@ -1,91 +0,0 @@
|
||||
# Glossary
|
||||
|
||||
Every OpenSpec term in one place, defined in plain language. Skim it once and the rest of the docs read faster.
|
||||
|
||||
Terms are grouped by topic, then alphabetized within each group.
|
||||
|
||||
## The core nouns
|
||||
|
||||
**Spec.** A document describing how part of your system behaves. Specs live in `openspec/specs/`, are organized by domain, and are made of requirements and scenarios. The spec is the agreed-upon answer to "what does this software do?" See [Concepts](concepts.md#specs).
|
||||
|
||||
**Source of truth.** The `openspec/specs/` directory as a whole. It holds the current, agreed-upon behavior of your system. Changes propose edits to it; archiving applies them.
|
||||
|
||||
**Change.** One unit of work, packaged as a folder under `openspec/changes/<name>/`. A change holds everything about that work: its proposal, design, tasks, and the spec edits it introduces. One change, one feature or fix.
|
||||
|
||||
**Artifact.** A document inside a change. The standard artifacts are the proposal, the delta specs, the design, and the tasks. They're created in dependency order and feed into each other.
|
||||
|
||||
**Delta spec.** A spec inside a change that describes only what's changing, using `ADDED`, `MODIFIED`, and `REMOVED` sections, rather than restating the entire spec. This is what lets OpenSpec edit existing systems cleanly. See [Concepts](concepts.md#delta-specs).
|
||||
|
||||
**Domain.** A logical grouping for specs, like `auth/`, `payments/`, or `ui/`. You choose domains that match how you think about your system.
|
||||
|
||||
## Inside a spec
|
||||
|
||||
**Requirement.** A single behavior the system must have, usually written with an RFC 2119 keyword: "The system SHALL expire sessions after 30 minutes." Requirements state the *what*, not the *how*.
|
||||
|
||||
**Scenario.** A concrete, testable example of a requirement in action, typically in Given/When/Then form. Scenarios make a requirement verifiable: you could write an automated test from one.
|
||||
|
||||
**RFC 2119 keywords.** The words MUST, SHALL, SHOULD, and MAY, which carry standardized meaning about how strict a requirement is. MUST and SHALL are absolute. SHOULD is recommended with room for exceptions. MAY is optional. The name comes from the internet standards document that defined them.
|
||||
|
||||
## The artifacts
|
||||
|
||||
**Proposal (`proposal.md`).** The *why* and *what* of a change: its intent, scope, and high-level approach. The first artifact you create.
|
||||
|
||||
**Design (`design.md`).** The *how*: technical approach, architecture decisions, and the files you expect to touch. Optional for simple changes.
|
||||
|
||||
**Tasks (`tasks.md`).** The implementation checklist, with checkboxes. The AI works through it during `/opsx:apply` and checks items off as it goes.
|
||||
|
||||
## The lifecycle
|
||||
|
||||
**Archive.** The act of finishing a change. Its delta specs merge into the main specs, and the change folder moves to `openspec/changes/archive/YYYY-MM-DD-<name>/`. After archiving, your specs describe the new reality. See [Concepts](concepts.md#archive).
|
||||
|
||||
**Sync.** Merging a change's delta specs into the main specs *without* archiving the change. Usually automatic (archive offers to do it), but available on its own as `/opsx:sync` for long-running changes. See [Commands](commands.md#opsxsync).
|
||||
|
||||
## Workflow and commands
|
||||
|
||||
**OPSX.** The current standard OpenSpec workflow, built around fluid actions instead of rigid phases. Its slash commands all start with `/opsx:`. See [OPSX Workflow](opsx.md).
|
||||
|
||||
**Slash command.** A command you type into your AI assistant's chat, like `/opsx:propose`. Slash commands drive the workflow. They are not terminal commands. See [How Commands Work](how-commands-work.md).
|
||||
|
||||
**Explore (`/opsx:explore`).** The thinking-partner command. It reads your codebase, compares options, and clarifies a fuzzy idea into a concrete plan. It never writes code, and writes nothing else unless you ask it to capture the exploration as a change, or say yes when it offers. The recommended starting point whenever you have a problem but not yet a plan. See [Explore First](explore.md).
|
||||
|
||||
**CLI.** The `openspec` program you run in your terminal. It sets up projects, lists and validates changes, opens the dashboard, and archives. The terminal half of OpenSpec. See [CLI](cli.md).
|
||||
|
||||
**Skill.** A folder of instructions (`.../skills/openspec-*/SKILL.md`) that your AI assistant auto-detects and follows. Skills are the emerging cross-tool standard for delivering the OpenSpec workflow to your assistant.
|
||||
|
||||
**Command file.** A per-tool slash command file (`.../commands/opsx-*`). The older delivery mechanism, still supported alongside skills. You rarely touch these directly.
|
||||
|
||||
**Profile.** The set of slash commands installed in your project. **Core** (the default) is `propose`, `explore`, `apply`, `update`, `sync`, `archive`. The **expanded** set adds `new`, `continue`, `ff`, `verify`, `bulk-archive`, `onboard`. Change it with `openspec config profile`.
|
||||
|
||||
**Delivery.** Whether OpenSpec installs skills, command files, or both for your tools. Configured globally and applied with `openspec update`.
|
||||
|
||||
## Customization
|
||||
|
||||
**Schema.** The definition of which artifacts a workflow has and how they depend on one another. The built-in default is `spec-driven` (proposal → specs → design → tasks). You can fork it or write your own. See [Customization](customization.md#custom-schemas).
|
||||
|
||||
**Template.** A Markdown file inside a schema that shapes what the AI generates for a given artifact. Editing a template changes the AI's output immediately, with no rebuild.
|
||||
|
||||
**Project config (`openspec/config.yaml`).** Per-project settings: the default schema, the `context:` injected into every planning request, and per-artifact `rules:`. The easiest way to teach OpenSpec about your stack and conventions. See [Customization](customization.md#project-configuration).
|
||||
|
||||
**Context injection.** Putting project background in `config.yaml`'s `context:` field so it's automatically added to every artifact the AI generates. More reliable than hoping the AI reads a separate file.
|
||||
|
||||
**Dependency graph.** The directed graph formed by artifact `requires:` relationships. It's a DAG (directed acyclic graph: arrows only point forward, never in a loop), and OpenSpec uses it to know what you can create next.
|
||||
|
||||
**Enablers, not gates.** The principle that artifact dependencies show what becomes *possible* next, not what's *required* next. You can revisit and edit any artifact at any time. See [Core Concepts at a Glance](overview.md#enablers-not-gates).
|
||||
|
||||
## Coordination across repos (beta)
|
||||
|
||||
These terms apply only if your planning spans more than one repo. They're in beta. Most users can ignore them. See the [Stores User Guide](stores-beta/user-guide.md).
|
||||
|
||||
**Store.** A standalone repo whose whole job is planning. It has the same `openspec/` shape you already know (specs and changes) plus a small identity file. You register it on your machine once, by name, and then any OpenSpec command can work in it from anywhere.
|
||||
|
||||
**Reference.** A declaration, in a code repo's `openspec/config.yaml`, of a store that repo draws on. References are read-only: the repo keeps its own root, and `openspec instructions` gains an index of the referenced store's specs, each with the exact command to fetch it.
|
||||
|
||||
**Working context.** What `openspec context` assembles for the current repo: its OpenSpec root plus every store it references, each with how to fetch it. The answer to "what am I working with?"
|
||||
|
||||
**Workset.** A personal, machine-local set of folders you open together (a store alongside the code repos you work on). Created explicitly with `openspec workset create`; nothing about those local paths is committed to the shared planning repo.
|
||||
|
||||
## See also
|
||||
|
||||
- [Core Concepts at a Glance](overview.md): the five ideas, on one page
|
||||
- [Concepts](concepts.md): the long-form explanation
|
||||
- [How Commands Work](how-commands-work.md): slash commands versus the CLI
|
||||
@@ -1,173 +0,0 @@
|
||||
# How Commands Work
|
||||
|
||||
**The one thing to know: OpenSpec has two kinds of commands, and they run in two different places.**
|
||||
|
||||
- `openspec ...` commands run in your **terminal**. (Example: `openspec init`.)
|
||||
- `/opsx:...` commands run in your **AI assistant's chat**. (Example: `/opsx:propose`.)
|
||||
|
||||
If you ever type `/opsx:propose` into your terminal and nothing happens, this page is why. You are talking to the wrong half of OpenSpec. Slash commands are not terminal commands. They are instructions you give to your AI coding assistant, in the same chat box where you'd normally type "add a login form."
|
||||
|
||||
That single distinction is the most common stumbling block for new users, so let's make it crystal clear.
|
||||
|
||||
## The two halves
|
||||
|
||||
OpenSpec is one project wearing two hats.
|
||||
|
||||
**The CLI (terminal half).** A program named `openspec` that you install and run from your shell. It sets up your project, lists and validates changes, shows a dashboard, and archives finished work. You type these into iTerm, the VS Code terminal, PowerShell, anywhere you'd run `git` or `npm`.
|
||||
|
||||
```bash
|
||||
openspec init # set up OpenSpec in this project
|
||||
openspec list # see active changes
|
||||
openspec view # open the interactive dashboard
|
||||
```
|
||||
|
||||
**The slash commands (chat half).** Short commands like `/opsx:propose` and `/opsx:apply` that you type into your AI assistant. These tell the AI to follow the OpenSpec workflow: draft a proposal, write specs, build from the task list, archive when done. You type these into Claude Code, Cursor, Devin Desktop, Copilot, or whichever assistant you use.
|
||||
|
||||
```text
|
||||
/opsx:propose add-dark-mode (typed in your AI chat)
|
||||
/opsx:apply (typed in your AI chat)
|
||||
/opsx:archive (typed in your AI chat)
|
||||
```
|
||||
|
||||
Here's the mental model in one picture:
|
||||
|
||||
```text
|
||||
YOUR TERMINAL YOUR AI ASSISTANT'S CHAT
|
||||
┌──────────────────────┐ ┌──────────────────────────────┐
|
||||
│ $ openspec init │ installs │ /opsx:propose add-dark-mode │
|
||||
│ $ openspec list │ ──────────► │ /opsx:apply │
|
||||
│ $ openspec view │ commands │ /opsx:archive │
|
||||
└──────────────────────┘ & skills └──────────────────────────────┘
|
||||
run openspec here run /opsx:* here
|
||||
```
|
||||
|
||||
Notice the arrow. Running `openspec init` in your terminal is what *installs* the slash commands into your AI tool. The terminal half sets up the chat half. After that, day-to-day driving mostly happens in chat.
|
||||
|
||||
## "How do I start interactive mode?"
|
||||
|
||||
**There is no separate interactive mode to start.** This question comes up a lot, so it deserves a plain answer.
|
||||
|
||||
You don't enter a special OpenSpec mode. You just open your AI coding assistant like you always do, and type a slash command into the chat. The slash command *is* how you "enter" OpenSpec. Your assistant recognizes it, loads the matching OpenSpec skill, and starts following the workflow.
|
||||
|
||||
So the real instructions are:
|
||||
|
||||
1. Open your AI coding assistant (Claude Code, Cursor, Devin Desktop, and so on) in your project.
|
||||
2. Type `/opsx:propose` in its chat, the same place you type any other request.
|
||||
3. Watch the autocomplete: if OpenSpec is installed, you'll see `/opsx:propose`, `/opsx:apply`, and friends appear as you type the slash.
|
||||
|
||||
That's it. No mode to toggle, no daemon to launch, no separate window.
|
||||
|
||||
One thing that *is* genuinely interactive lives in the terminal: `openspec view`. It opens a dashboard for browsing your specs and changes. But that's a viewer, not the thing you propose and build with. The building happens through slash commands in chat.
|
||||
|
||||
## Why this split exists
|
||||
|
||||
It's worth understanding, because it explains why OpenSpec works with 30+ different AI tools.
|
||||
|
||||
The CLI is the **engine**. It knows the rules: what a change folder looks like, which artifacts depend on which, how to merge a delta spec into your source of truth. It's the same everywhere.
|
||||
|
||||
The slash commands are the **steering wheel**, and every AI tool has a slightly different one. Claude Code calls them commands. Cursor and Devin Desktop have their own formats. Some tools call them skills. When you run `openspec init`, OpenSpec generates the right kind of file for each tool you selected, so the same `/opsx:propose` intent works no matter which assistant you prefer.
|
||||
|
||||
The strength of this design: you learn the workflow once and carry it across tools. The tradeoff: the exact syntax of a command can differ slightly between tools, which is the next section.
|
||||
|
||||
## Slash command syntax by tool
|
||||
|
||||
The intent is identical everywhere. The spelling follows the file your tool loads.
|
||||
|
||||
| Your tool's command file | How you type it | Example tools |
|
||||
|--------------------------|-----------------|---------------|
|
||||
| `.../commands/opsx/<id>.*` | `/opsx:propose` | Claude Code, Gemini CLI, Crush |
|
||||
| `.../opsx-<id>.*` | `/opsx-propose` | Cursor, GitHub Copilot (IDE), Devin Desktop, Trae, Oh My Pi |
|
||||
| `.amazonq/prompts/opsx-<id>.md` | `@opsx-propose` | Amazon Q Developer |
|
||||
| none — skills only | `/openspec-propose` | CodeArts, ForgeCode, Hermes, Mistral Vibe, Zed Agent, shared `.agents` |
|
||||
| none — Kimi Code | `/skill:openspec-propose` | Kimi Code |
|
||||
| none — Codex CLI | `$openspec-propose` | Codex |
|
||||
|
||||
Devin is the one tool that spans two rows. Devin Desktop reads
|
||||
`.devin/workflows/`, so `/opsx-propose` works there; [Devin Local does
|
||||
not](https://docs.devin.ai/desktop/devin-local), so on that agent use the
|
||||
`/openspec-propose` skill instead. The skills OpenSpec writes to
|
||||
`.devin/skills/` work on both, which is why they reference each other by skill
|
||||
name.
|
||||
|
||||
Every tool is listed in [How To Invoke](supported-tools.md#how-to-invoke) — that
|
||||
table is the authoritative one. Two rows are not slash commands at all: Amazon Q
|
||||
loads its files into a prompt library invoked with `@`, and the last three rows
|
||||
use the *skill* name, which is not the command id (`/opsx:apply` is the
|
||||
`openspec-apply-change` skill).
|
||||
|
||||
When in doubt, read the "Getting started" line `openspec init` printed: it already
|
||||
uses the form your tools registered. Typing a slash and watching the autocomplete
|
||||
works too, for the tools that surface slash commands at all.
|
||||
|
||||
## How the commands got there: skills and commands
|
||||
|
||||
When you run `openspec init` (or `openspec update`), OpenSpec writes small files into your project so your AI tool can find the workflow. Depending on your tool and settings, these are **skills**, **commands**, or both.
|
||||
|
||||
- **Skills** live in places like `.claude/skills/openspec-*/SKILL.md`. They're the emerging cross-tool standard: a folder of instructions your assistant auto-detects.
|
||||
- **Commands** live in places like `.cursor/commands/opsx-<id>.md` or `.claude/commands/opsx/<id>.md` — the layout is the tool's, and it decides how you type the command. They're the older per-tool slash command files. Codex does not get generated command files; use `.agents/skills/openspec-*`.
|
||||
|
||||
You don't have to care which one your tool uses. You just type the slash command and it works. But knowing these files exist helps when something goes wrong: if your commands vanish, it usually means these files are missing or stale, and `openspec update` regenerates them.
|
||||
|
||||
See [Supported Tools](supported-tools.md) for the exact paths per tool, and [Migration Guide](migration-guide.md) for how skills replaced the older command-only approach.
|
||||
|
||||
## Confirming it's installed
|
||||
|
||||
Quick checks, fastest first:
|
||||
|
||||
1. **Type a slash in your AI chat.** Start typing `/opsx` and watch for autocomplete suggestions. If they appear, you're set. On a skills-only tool (Codex, Kimi Code, CodeArts, ForgeCode, Hermes, Mistral Vibe, Zed Agent, or the shared `.agents` target) `/opsx` never completes even on a healthy install — try the skill name from the table above instead.
|
||||
2. **Look for the files.** For Claude Code, check that `.claude/skills/` contains `openspec-*` folders. Other tools use their own directories ([Supported Tools](supported-tools.md) lists them).
|
||||
3. **Re-run setup.** From your project root, run `openspec update`. This regenerates the skill and command files for whatever tools you configured.
|
||||
4. **Restart your assistant.** Many tools scan for skills and commands at startup, so a fresh window can be the missing step.
|
||||
|
||||
## Which commands do I even have?
|
||||
|
||||
By default, OpenSpec installs the **core** set of slash commands:
|
||||
|
||||
- `/opsx:explore`: think through an idea with the AI before committing to a change (great first step when you're unsure)
|
||||
- `/opsx:propose`: create a change and draft all its planning artifacts in one step
|
||||
- `/opsx:apply`: build the change by working through its task list
|
||||
- `/opsx:update`: revise a change's planning artifacts and keep them coherent
|
||||
- `/opsx:sync`: merge a change's spec updates into your main specs (usually automatic)
|
||||
- `/opsx:archive`: finish a change and file it away
|
||||
|
||||
A good default rhythm: `explore` when you're figuring out what to do, then `propose`, `apply`, `archive`. The [Explore First](explore.md) guide explains why that opening step pays off.
|
||||
|
||||
There's also an **expanded** set for people who want finer control (`/opsx:new`, `/opsx:continue`, `/opsx:ff`, `/opsx:verify`, `/opsx:bulk-archive`, `/opsx:onboard`). You turn it on with `openspec config profile`, then apply it with `openspec update`.
|
||||
|
||||
New to all of this? `/opsx:onboard` (in the expanded set) walks you through a complete change on your own codebase, narrating each step. It's the friendliest possible introduction.
|
||||
|
||||
For what each command does in detail, see [Commands](commands.md). For when to reach for which, see [Workflows](workflows.md).
|
||||
|
||||
## A clean first run
|
||||
|
||||
Putting it together, here is the whole sequence with each step labeled by where it happens.
|
||||
|
||||
```text
|
||||
TERMINAL $ npm install -g @fission-ai/openspec@latest
|
||||
TERMINAL $ cd your-project
|
||||
TERMINAL $ openspec init
|
||||
(installs slash commands into your AI tool)
|
||||
|
||||
AI CHAT /opsx:explore
|
||||
(optional: think the idea through with the AI first)
|
||||
|
||||
AI CHAT /opsx:propose add-dark-mode
|
||||
(AI drafts proposal, specs, design, tasks)
|
||||
|
||||
AI CHAT /opsx:apply
|
||||
(AI builds it, checking off tasks)
|
||||
|
||||
AI CHAT /opsx:archive
|
||||
(change is merged into your specs and filed away)
|
||||
```
|
||||
|
||||
Two terminal steps to set up. Then you live in chat. That's the rhythm.
|
||||
|
||||
## Related
|
||||
|
||||
- [Getting Started](getting-started.md): the full first-change walkthrough
|
||||
- [Commands](commands.md): every slash command in detail
|
||||
- [CLI](cli.md): every terminal command in detail
|
||||
- [Supported Tools](supported-tools.md): per-tool syntax and file locations
|
||||
- [FAQ](faq.md): more quick answers
|
||||
- [Troubleshooting](troubleshooting.md): fixes when commands don't show up
|
||||
@@ -4,78 +4,6 @@
|
||||
|
||||
- **Node.js 20.19.0 or higher** — Check your version: `node --version`
|
||||
|
||||
## Install with your AI assistant
|
||||
|
||||
Rather not do this by hand? Paste the prompt below into any coding assistant that can run shell commands — Claude Code, Codex, Cursor, Gemini CLI, Copilot, and the rest of the [supported tools](supported-tools.md). It installs the CLI, initializes this project, and reports back what actually happened.
|
||||
|
||||
The manual steps below are the source of truth — the prompt just runs them for you. If your assistant stops and hands something back, that's by design: it asks before anything privileged and never edits your shell startup files. Finish those bits yourself with [Package Managers](#package-managers) and [Troubleshooting](troubleshooting.md).
|
||||
|
||||
```text
|
||||
Install OpenSpec in this project and set it up for me. Follow these steps in
|
||||
order, and stop where a step tells you to stop.
|
||||
|
||||
1. RUNTIME. Run `node --version`. OpenSpec needs Node.js 20.19.0 or higher. If
|
||||
Node is missing or older, say so and stop — don't install Node, switch
|
||||
versions, or reconfigure my version manager for me.
|
||||
|
||||
2. INSTALL. Use whichever package manager is already on my PATH, preferring npm:
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
pnpm add -g @fission-ai/openspec@latest
|
||||
bun add -g @fission-ai/openspec@latest
|
||||
yarn global add @fission-ai/openspec@latest (Yarn 1.x only)
|
||||
Don't pick based on this project's lockfile — a global install has nothing to
|
||||
do with how this repo's own dependencies are installed. If none of those four
|
||||
is available, stop and tell me — don't improvise an install. (If I'm on Nix,
|
||||
point me at the Nix section of the OpenSpec installation docs instead.)
|
||||
Show me the exact command and let me confirm before you run it; this installs
|
||||
software outside the project, and I may want a different package manager to
|
||||
own it.
|
||||
Stop and ask me again if the install needs sudo or admin rights, fails with a
|
||||
permissions error, or reports that its global bin directory is missing or
|
||||
unconfigured. Never edit my shell startup files (.bashrc, .zshrc, .profile,
|
||||
fish, PowerShell profile), and never run a setup command that edits them for
|
||||
me — show me the change and let me make it.
|
||||
|
||||
3. PATH. Run `openspec --version`. If the command isn't found, it may just be
|
||||
missing from this shell: tell me where the package manager installed it and
|
||||
how to add that directory to PATH for my shell and OS, then stop until I
|
||||
confirm. If it prints an older version than the one the install just
|
||||
reported, an earlier copy is shadowing it on PATH — tell me both versions
|
||||
instead of continuing. If I use a version manager, say so rather than editing
|
||||
PATH around it: with nvm or fnm the CLI is tied to the Node version that was
|
||||
active when you installed it, and with asdf or volta a shim may need
|
||||
regenerating.
|
||||
|
||||
4. INITIALIZE. Ask me which AI coding tool or tools I use and map each to an id
|
||||
from `openspec init --help` (Copilot is `github-copilot`, Zoo Code is
|
||||
`roocode`). `--tools` takes a comma-separated list, so name all of them.
|
||||
`openspec init --tools <ids>` deletes leftovers from older OpenSpec versions
|
||||
automatically, without asking — including `opsx-*.md` prompt files in my home
|
||||
directory (Codex keeps them in ~/.codex/prompts). Before you run it, look for
|
||||
those: `.../commands/openspec/` folders, OpenSpec marker blocks in files like
|
||||
CLAUDE.md or AGENTS.md, and home-directory `opsx-*.md` prompts. List whatever
|
||||
you find and wait for my go-ahead; if you find nothing, say so and carry on
|
||||
without asking. An existing `openspec/` folder is not a problem — init
|
||||
refreshes it and leaves my specs and changes alone.
|
||||
Confirm I'm in the right folder too: init creates `openspec/` wherever it
|
||||
runs, including inside a monorepo package.
|
||||
Then run: openspec init --tools <ids>
|
||||
|
||||
5. REPORT. Don't assume what should exist — tell me what init actually printed:
|
||||
how many skills and/or commands it created and where, the config file line,
|
||||
any "Setup required" note, and what to restart or reload. Some tools are
|
||||
skills-only and correctly create zero command files, so missing commands is
|
||||
not a failure on its own. If init said nothing was generated, relay the fix
|
||||
it suggested instead of retrying. Finish by telling me how to invoke OpenSpec
|
||||
in my tool, and take the exact spelling from the files init created rather
|
||||
than from its summary line: the punctuation differs per tool (/opsx:propose
|
||||
in some, /opsx-propose in others, @opsx-propose in Amazon Q), and tools that
|
||||
get skills instead of commands are invoked by skill name (/openspec-propose,
|
||||
or $openspec-propose in Codex, or /skill:openspec-propose in Kimi Code).
|
||||
```
|
||||
|
||||
Nothing in the prompt is vendor-specific: it's plain instructions plus the same commands documented on this page. It works on macOS, Linux, and Windows, and it deliberately stops rather than improvising when a step needs your permission. Your assistant does need to be able to run shell commands — a few IDE integrations can't.
|
||||
|
||||
## Package Managers
|
||||
|
||||
### npm
|
||||
@@ -96,30 +24,8 @@ pnpm add -g @fission-ai/openspec@latest
|
||||
yarn global add @fission-ai/openspec@latest
|
||||
```
|
||||
|
||||
Yarn 2 and later (Berry) removed the `global` command. On those versions, install OpenSpec with npm, pnpm, or bun instead — a global CLI doesn't need to share your project's package manager.
|
||||
|
||||
### deno
|
||||
|
||||
Deno sometimes has issues parsing the @latest tag, but we can specify a version while installing initially.
|
||||
If that happens, you could try to change the @latest tag with the version, something like `@^1.3.1`
|
||||
|
||||
```bash
|
||||
deno install --global \
|
||||
--allow-read --allow-write --allow-env --allow-sys=cpus,homedir --allow-net=edge.openspec.dev \
|
||||
npm:@fission-ai/openspec@latest
|
||||
# or
|
||||
deno install --global \
|
||||
--allow-read --allow-write --allow-env --allow-sys=cpus,homedir --allow-net=edge.openspec.dev \
|
||||
npm:@fission-ai/openspec@^1.3.1
|
||||
```
|
||||
|
||||
Note: If your subcommands launch external tools, like config edit, feedback, or workspace open, you may need a scoped --allow-run=<program>.
|
||||
|
||||
### bun
|
||||
|
||||
Bun can install OpenSpec globally, but OpenSpec currently runs on Node.js.
|
||||
You still need Node.js 20.19.0 or higher available on `PATH`.
|
||||
|
||||
```bash
|
||||
bun add -g @fission-ai/openspec@latest
|
||||
```
|
||||
@@ -161,39 +67,6 @@ Or add to your development environment in `flake.nix`:
|
||||
openspec --version
|
||||
```
|
||||
|
||||
## Updating
|
||||
|
||||
Upgrade the package, then refresh each project's generated files:
|
||||
|
||||
```bash
|
||||
npm install -g @fission-ai/openspec@latest # or pnpm/yarn/bun equivalent
|
||||
openspec update # run inside each project
|
||||
```
|
||||
|
||||
`openspec update` regenerates the skill and command files for the tools you've configured, so your slash commands stay current with the installed version. It also checks whether a newer CLI has been published and offers to upgrade, since upgrading is what makes new workflows available in the first place — see [CLI Reference](cli.md#openspec-update).
|
||||
|
||||
## Uninstalling
|
||||
|
||||
There's no `openspec uninstall` command, because OpenSpec is just a global package plus some files in your project. Removing it is a few manual steps, and nothing here touches your source code.
|
||||
|
||||
**1. Remove the global package:**
|
||||
|
||||
```bash
|
||||
npm uninstall -g @fission-ai/openspec # or: pnpm rm -g / yarn global remove / bun rm -g
|
||||
```
|
||||
|
||||
**2. Remove OpenSpec from a project (optional).** Delete the `openspec/` directory if you no longer want its specs and changes:
|
||||
|
||||
```bash
|
||||
rm -rf openspec/
|
||||
```
|
||||
|
||||
Think before you do this: `openspec/specs/` and `openspec/changes/archive/` are your record of how the system behaves and why it changed. If you might want that history, keep the folder (or keep it in git) even after uninstalling.
|
||||
|
||||
**3. Remove generated AI tool files (optional).** OpenSpec writes skill and command files into per-tool directories like `.claude/skills/openspec-*/`, `.cursor/commands/opsx-*`, and so on. Delete the `openspec-*` skills and `opsx-*` commands for whichever tools you configured. The exact paths per tool are listed in [Supported Tools](supported-tools.md).
|
||||
|
||||
If you also have OpenSpec marker blocks in files like `CLAUDE.md` or `AGENTS.md`, remove those blocks by hand; your own content in those files is yours to keep.
|
||||
|
||||
## Next Steps
|
||||
|
||||
After installing, initialize OpenSpec in your project:
|
||||
|
||||
+4
-13
@@ -8,7 +8,7 @@ OPSX replaces the old phase-locked workflow with a fluid, action-based approach.
|
||||
|
||||
| Aspect | Legacy | OPSX |
|
||||
|--------|--------|------|
|
||||
| **Commands** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` | Default: `/opsx:propose`, `/opsx:explore`, `/opsx:apply`, `/opsx:update`, `/opsx:sync`, `/opsx:archive` (expanded workflow commands optional) |
|
||||
| **Commands** | `/openspec:proposal`, `/openspec:apply`, `/openspec:archive` | Default: `/opsx:propose`, `/opsx:apply`, `/opsx:archive` (expanded workflow commands optional) |
|
||||
| **Workflow** | Create all artifacts at once | Create incrementally or all at once—your choice |
|
||||
| **Going back** | Awkward phase gates | Natural—update any artifact anytime |
|
||||
| **Customization** | Fixed structure | Schema-driven, fully hackable |
|
||||
@@ -43,11 +43,10 @@ Only OpenSpec-managed files that are being replaced:
|
||||
|
||||
- Claude Code: `.claude/commands/openspec/`
|
||||
- Cursor: `.cursor/commands/openspec-*.md`
|
||||
- Devin Desktop, formerly Windsurf: `.windsurf/workflows/openspec-*.md`
|
||||
- Windsurf: `.windsurf/workflows/openspec-*.md`
|
||||
- Cline: `.clinerules/workflows/openspec-*.md`
|
||||
- Roo: `.roo/commands/openspec-*.md`
|
||||
- GitHub Copilot: `.github/prompts/openspec-*.prompt.md` (IDE extensions only; not supported in Copilot CLI)
|
||||
- Codex: OpenSpec now uses the canonical `.agents/skills/openspec-*` path. OpenSpec-managed `SKILL.md` files under the former `.codex/skills` path are reconciled only after replacements exist; custom files and divergent copies stay in place. If an unmarked `.agents` tree already contains OpenSpec skills, OpenSpec preserves its existing Codex (`$openspec-*`) or generic (`/openspec-*`) rendering instead of guessing from the legacy directory. Select `codex` explicitly with `openspec init` to switch ownership. Legacy prompt cleanup still targets only OpenSpec's allowlisted filenames in `$CODEX_HOME/prompts` or `~/.codex/prompts`.
|
||||
- And others (Augment, Continue, Amazon Q, etc.)
|
||||
|
||||
The migration detects whichever tools you have configured and cleans up their legacy files.
|
||||
@@ -85,7 +84,7 @@ Don't worry about getting it perfect. We're still learning what works best here,
|
||||
|
||||
Both `openspec init` and `openspec update` detect legacy files and guide you through the same cleanup process. Use whichever fits your situation:
|
||||
|
||||
- New installs default to profile `core` (`propose`, `explore`, `apply`, `update`, `sync`, `archive`).
|
||||
- New installs default to profile `core` (`propose`, `explore`, `apply`, `archive`).
|
||||
- Migrated installs preserve your previously installed workflows by writing a `custom` profile when needed.
|
||||
|
||||
### Using `openspec init`
|
||||
@@ -157,8 +156,6 @@ openspec init --force --tools claude
|
||||
|
||||
The `--force` flag skips prompts and auto-accepts cleanup.
|
||||
|
||||
This includes cleanup of OpenSpec-managed Codex prompt files in the global Codex prompt directory. Cleanup only targets OpenSpec's allowlisted legacy Codex prompt filenames, removes them only after replacement `.agents/skills/openspec-*` skills exist, and preserves all other files.
|
||||
|
||||
---
|
||||
|
||||
## Migrating project.md to config.yaml
|
||||
@@ -290,8 +287,6 @@ Command availability is profile-dependent:
|
||||
| `/opsx:propose` | Create a change and generate planning artifacts in one step |
|
||||
| `/opsx:explore` | Think through ideas with no structure |
|
||||
| `/opsx:apply` | Implement tasks from tasks.md |
|
||||
| `/opsx:update` | Revise a change's planning artifacts and keep them coherent |
|
||||
| `/opsx:sync` | Merge delta specs into main specs |
|
||||
| `/opsx:archive` | Finalize and archive the change |
|
||||
|
||||
**Expanded workflow (custom selection):**
|
||||
@@ -302,6 +297,7 @@ Command availability is profile-dependent:
|
||||
| `/opsx:continue` | Create the next artifact (one at a time) |
|
||||
| `/opsx:ff` | Fast-forward—create planning artifacts at once |
|
||||
| `/opsx:verify` | Validate implementation matches specs |
|
||||
| `/opsx:sync` | Preview/spec-merge without archiving |
|
||||
| `/opsx:bulk-archive` | Archive multiple changes at once |
|
||||
| `/opsx:onboard` | Guided end-to-end onboarding workflow |
|
||||
|
||||
@@ -411,8 +407,6 @@ OPSX uses the emerging **skills** standard:
|
||||
|
||||
Skills are recognized across multiple AI coding tools and provide richer metadata.
|
||||
|
||||
Codex is skills-only in OPSX. OpenSpec no longer generates Codex custom prompt files; use the generated `.agents/skills/openspec-*` directories instead.
|
||||
|
||||
---
|
||||
|
||||
## Continuing Existing Changes
|
||||
@@ -567,9 +561,6 @@ project/
|
||||
│ ├── openspec-propose/ # default core profile
|
||||
│ ├── openspec-explore/
|
||||
│ ├── openspec-apply-change/
|
||||
│ ├── openspec-update-change/
|
||||
│ ├── openspec-sync-specs/
|
||||
│ ├── openspec-archive-change/
|
||||
│ └── ... # expanded profile adds new/continue/ff/etc.
|
||||
├── CLAUDE.md # OpenSpec markers removed, your content preserved
|
||||
└── AGENTS.md # OpenSpec markers removed, your content preserved
|
||||
|
||||
@@ -4,18 +4,6 @@ Configure OpenSpec to generate artifacts in languages other than English.
|
||||
|
||||
## Quick Setup
|
||||
|
||||
For a new project, set the language during initialization:
|
||||
|
||||
```bash
|
||||
openspec init --language "Portuguese (pt-BR)"
|
||||
```
|
||||
|
||||
This writes the language instruction to `openspec/config.yaml`. If the project
|
||||
already has a config, edit its `context` field directly so existing project
|
||||
guidance is preserved.
|
||||
|
||||
You can also configure the same behavior manually:
|
||||
|
||||
Add a language instruction to your `openspec/config.yaml`:
|
||||
|
||||
```yaml
|
||||
@@ -24,7 +12,6 @@ schema: spec-driven
|
||||
context: |
|
||||
Language: Portuguese (pt-BR)
|
||||
All artifacts must be written in Brazilian Portuguese.
|
||||
Keep OpenSpec structural headings and SHALL/MUST keywords in English.
|
||||
|
||||
# Your other project context below...
|
||||
Tech stack: TypeScript, React, Node.js
|
||||
@@ -32,10 +19,6 @@ context: |
|
||||
|
||||
That's it. All generated artifacts will now be in Portuguese.
|
||||
|
||||
OpenSpec's document structure and normative `SHALL`/`MUST` keywords remain in
|
||||
English because validation relies on them. The surrounding requirement and
|
||||
scenario prose can use your selected language.
|
||||
|
||||
## Language Examples
|
||||
|
||||
### Portuguese (Brazil)
|
||||
|
||||
+6
-22
@@ -65,7 +65,7 @@ openspec init
|
||||
|
||||
This creates skills in `.claude/skills/` (or equivalent) that AI coding assistants auto-detect.
|
||||
|
||||
By default, OpenSpec uses the `core` workflow profile (`propose`, `explore`, `apply`, `update`, `sync`, `archive`). If you want the expanded workflow commands (`new`, `continue`, `ff`, `verify`, `bulk-archive`, `onboard`), configure them with `openspec config profile` and apply with `openspec update`.
|
||||
By default, OpenSpec uses the `core` workflow profile (`propose`, `explore`, `apply`, `archive`). If you want the expanded workflow commands (`new`, `continue`, `ff`, `verify`, `sync`, `bulk-archive`, `onboard`), configure them with `openspec config profile` and apply with `openspec update`.
|
||||
|
||||
During setup, you'll be prompted to create a **project config** (`openspec/config.yaml`). This is optional but recommended.
|
||||
|
||||
@@ -163,9 +163,8 @@ rules:
|
||||
| `/opsx:continue` | Create the next artifact (expanded workflow) |
|
||||
| `/opsx:ff` | Fast-forward planning artifacts (expanded workflow) |
|
||||
| `/opsx:apply` | Implement tasks, updating artifacts as needed |
|
||||
| `/opsx:update` | Revise a change's planning artifacts and keep them coherent |
|
||||
| `/opsx:verify` | Validate implementation against artifacts (expanded workflow) |
|
||||
| `/opsx:sync` | Merge delta specs into main specs (optional) |
|
||||
| `/opsx:sync` | Sync delta specs to main (expanded workflow, optional) |
|
||||
| `/opsx:archive` | Archive when done |
|
||||
| `/opsx:bulk-archive` | Archive multiple completed changes (expanded workflow) |
|
||||
| `/opsx:onboard` | Guided walkthrough of an end-to-end change (expanded workflow) |
|
||||
@@ -209,20 +208,6 @@ Creates all planning artifacts at once. Use when you have a clear picture of wha
|
||||
```
|
||||
Works through tasks, checking them off as you go. If you're juggling multiple changes, you can run `/opsx:apply <name>`; otherwise it should infer from the conversation and prompt you to choose if it can't tell.
|
||||
|
||||
### Updating a change
|
||||
```
|
||||
/opsx:update add-dark-mode - we're storing the theme in a cookie now
|
||||
```
|
||||
Revises the change's existing planning artifacts and keeps them coherent in any direction (a design edit may ripple back to the proposal). It never edits code. Every edit is confirmed with you first. See [the update reference](commands.md#opsxupdate) for how it handles missing files without starting a new artifact.
|
||||
|
||||
If the change was already implemented, it recommends `/opsx:apply` so the code catches up with the revised plan. If your revision changes the change's *intent*, start fresh instead. See [When to Update vs. Start Fresh](#when-to-update-vs-start-fresh).
|
||||
|
||||
### Sync delta specs
|
||||
```text
|
||||
/opsx:sync
|
||||
```
|
||||
Merges the current change's delta specs into your main `openspec/specs/` without archiving — the change stays active. It applies the whole delta: a requirement under `## REMOVED` is deleted from the main spec and a renamed one is retitled in place, while content the delta doesn't mention is left untouched. Syncing is optional — archive prompts you to sync first if you haven't. Reach for it when you want main specs updated before archiving, when a parallel change needs to build on specs this one just added, or when you want to review the merged main spec before archiving.
|
||||
|
||||
### Finish up
|
||||
```
|
||||
/opsx:archive # Move to archive when done (prompts to sync specs if needed)
|
||||
@@ -328,7 +313,7 @@ Think of it like git branches:
|
||||
## Architecture Deep Dive
|
||||
|
||||
This section explains how OPSX works under the hood and how it compares to the legacy workflow.
|
||||
Examples in this section use the expanded command set (`new`, `continue`, etc.); default `core` users can map the same flow to `propose → apply → sync → archive`.
|
||||
Examples in this section use the expanded command set (`new`, `continue`, etc.); default `core` users can map the same flow to `propose → apply → archive`.
|
||||
|
||||
### Philosophy: Phases vs Actions
|
||||
|
||||
@@ -427,7 +412,7 @@ Examples in this section use the expanded command set (`new`, `continue`, etc.);
|
||||
│ ▼ │
|
||||
│ Skill Files (.claude/skills/openspec-*/SKILL.md) │
|
||||
│ │
|
||||
│ • Cross-editor compatible (Claude Code, Cursor, Devin) │
|
||||
│ • Cross-editor compatible (Claude Code, Cursor, Windsurf) │
|
||||
│ • Skills query CLI for structured data │
|
||||
│ • Fully customizable via schema files │
|
||||
│ │
|
||||
@@ -486,7 +471,7 @@ Artifacts form a directed acyclic graph (DAG). Dependencies are **enablers**, no
|
||||
│ • Create proposal.md │
|
||||
│ • Create tasks.md │
|
||||
│ • Create design.md │
|
||||
│ • Create delta spec files │
|
||||
│ • Create specs/<capability>/spec.md │
|
||||
│ │
|
||||
│ No awareness of what exists or │
|
||||
│ dependencies between artifacts │
|
||||
@@ -512,8 +497,7 @@ Artifacts form a directed acyclic graph (DAG). Dependencies are **enablers**, no
|
||||
│ │ {"id": "proposal", "status": "done"}, │ │
|
||||
│ │ {"id": "specs", "status": "ready"}, ◄── First ready │ │
|
||||
│ │ {"id": "design", "status": "ready"}, │ │
|
||||
│ │ {"id": "tasks", "status": "blocked", │ │
|
||||
│ │ "missingDeps": ["specs", "design"]} │ │
|
||||
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
|
||||
│ │ ] │ │
|
||||
│ │ } │ │
|
||||
│ └────────────────────────────────────────────────────────────────────┘ │
|
||||
|
||||
@@ -1,91 +0,0 @@
|
||||
# Core Concepts at a Glance
|
||||
|
||||
**OpenSpec is a lightweight agreement layer between you and your AI.** You write down what a change should do, the AI drafts the details, you both look at the same plan, and only then does code get written. This page is the whole mental model on one screen. When you want the long version, [Concepts](concepts.md) has it.
|
||||
|
||||
Here's the entire idea in five words: **agree first, then build confidently.**
|
||||
|
||||
## The five ideas
|
||||
|
||||
Everything in OpenSpec is built from five concepts. Learn these and the rest is detail.
|
||||
|
||||
**1. Specs are the truth.** A spec describes how your system behaves *right now*. It lives in `openspec/specs/`, organized by domain (`auth/`, `payments/`, `ui/`). Specs are made of requirements ("the system SHALL expire sessions after 30 minutes") and scenarios (concrete given/when/then examples). Think of specs as the single agreed-upon answer to "what does this software do?"
|
||||
|
||||
**2. A change is one unit of work.** When you want to add, modify, or remove behavior, you create a change: a folder in `openspec/changes/` holding everything about that work in one place. A proposal, a design, a task list, and the spec edits. One change, one folder, one feature.
|
||||
|
||||
**3. Delta specs describe what's changing, not the whole world.** Inside a change, you don't rewrite the entire spec. You write a small delta: `ADDED` this requirement, `MODIFIED` that one, `REMOVED` this other one. This is the trick that makes OpenSpec good at editing existing systems, not just green-field ones. You describe the diff, not the destination.
|
||||
|
||||
**4. Artifacts build on each other.** A change contains a few documents, created in a natural order, each feeding the next:
|
||||
|
||||
```text
|
||||
proposal ──► specs ──► design ──► tasks ──► implement
|
||||
why what how steps do it
|
||||
```
|
||||
|
||||
You can revisit any of them at any time. They're enablers, not gates. (More on that below.)
|
||||
|
||||
**5. Archiving folds the change back into the truth.** When the work is done, you archive the change. Its delta specs merge into your main specs, and the change folder moves to `changes/archive/` with a date stamp. Now your specs describe the new reality, and you're ready for the next change. The cycle closes.
|
||||
|
||||
## The picture
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ openspec/ │
|
||||
│ │
|
||||
│ ┌──────────────────┐ ┌──────────────────────────┐ │
|
||||
│ │ specs/ │ │ changes/ │ │
|
||||
│ │ │ ◄───── │ │ │
|
||||
│ │ source of truth │ merge │ one folder per change │ │
|
||||
│ │ how things work │ on │ proposal · design · │ │
|
||||
│ │ today │ archive │ tasks · delta specs │ │
|
||||
│ └──────────────────┘ └──────────────────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
Two folders. `specs/` is what's true. `changes/` is what you're proposing. Archiving moves a proposal into truth.
|
||||
|
||||
## The loop you'll actually run
|
||||
|
||||
In the default setup, your day looks like this. Optionally think it through first; then one command drafts the plan, you read it, the next builds it, and the last files it away.
|
||||
|
||||
```text
|
||||
/opsx:explore → (optional) think it through with the AI first
|
||||
/opsx:propose add-dark-mode → AI drafts proposal, specs, design, tasks
|
||||
(you read and adjust the plan)
|
||||
/opsx:apply → AI builds it, checking off tasks
|
||||
/opsx:archive → specs updated, change archived
|
||||
```
|
||||
|
||||
**When in doubt, start by exploring.** `/opsx:explore` is a no-stakes thinking partner: it reads your code, lays out options, and turns a fuzzy idea into a concrete plan before any code gets written. It's the best antidote to an AI that will otherwise build *something* from a vague prompt. Already know exactly what you want? Skip straight to `/opsx:propose`. Either way, explore ships in the default profile, so it's always there. See the [Explore guide](explore.md).
|
||||
|
||||
Those are slash commands, typed in your AI assistant's chat. Setup (`openspec init`) happens in your terminal. If that split is new to you, read [How Commands Work](how-commands-work.md) first; it's the most common point of confusion.
|
||||
|
||||
## "Enablers, not gates"
|
||||
|
||||
This phrase shows up everywhere in OpenSpec, so here's what it means in plain terms.
|
||||
|
||||
Old-school spec processes are waterfalls: finish planning, *then* you're allowed to implement, and going back is painful. OpenSpec refuses that. The order `proposal → specs → design → tasks` shows what becomes *possible* next, not what you're *forced* to do next.
|
||||
|
||||
Discover during implementation that the design was wrong? Edit `design.md` and keep going. Realize the scope should shrink? Update the proposal. Nothing locks. The dependencies exist only so the AI has the context it needs (you can't write good tasks without specs to base them on), not to box you in.
|
||||
|
||||
The strength here is honesty: real work is messy and iterative, and OpenSpec lets it be. The tradeoff is discipline: because nothing forces you forward, it's on you to keep a change focused rather than letting it sprawl. The [Workflows](workflows.md) guide has good habits for that.
|
||||
|
||||
## Why this is worth the small overhead
|
||||
|
||||
Plain truth: OpenSpec adds a step. You write a short plan before building. So what do you get for it?
|
||||
|
||||
- **You catch wrong turns before they cost you.** Fixing a misunderstanding in a one-paragraph proposal is free. Fixing it after the AI wrote 400 lines is not.
|
||||
- **The plan and the code stay in the same repo.** Six months later, the spec tells you (and the next AI session) why the system works the way it does.
|
||||
- **Changes are reviewable.** A change folder is a tidy package: read the proposal, skim the deltas, check the tasks. No archaeology through chat history.
|
||||
- **It fits existing codebases.** Deltas mean you can specify a change to a 50,000-line app without first documenting the whole thing.
|
||||
|
||||
And the honest tradeoff: for a truly trivial one-line fix, the ceremony may not pay off, and that's fine. OpenSpec is designed to be lightweight, but it isn't free. Use it where agreement matters, which turns out to be most of the time once you're working with an AI that will confidently build whatever you vaguely asked for.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- New here? [Getting Started](getting-started.md) walks the first change in full.
|
||||
- Not sure what to build yet? [Explore First](explore.md) is the place to start.
|
||||
- Confused about where commands run? [How Commands Work](how-commands-work.md).
|
||||
- Want the deep version of everything above? [Concepts](concepts.md).
|
||||
- Learn by example? [Examples & Recipes](examples.md).
|
||||
- Need a term defined? [Glossary](glossary.md).
|
||||
@@ -1,143 +0,0 @@
|
||||
# Reviewing a Change
|
||||
|
||||
OpenSpec's whole promise is that you and your AI **agree on what to build before any code is written.** That agreement only means something if you actually read what the AI drafted. This page is about the two minutes where you do that — what to open, in what order, and what to look for.
|
||||
|
||||
The bet is simple: catching a wrong turn in a one-paragraph plan is nearly free. Catching the same wrong turn in 300 lines of code is not. Review is where you collect on that bet.
|
||||
|
||||
## The two moments you review
|
||||
|
||||
There are exactly two:
|
||||
|
||||
```
|
||||
/opsx:propose ──► REVIEW THE PLAN ──► /opsx:apply ──► REVIEW THE CODE ──► /opsx:archive
|
||||
(before any code) (/opsx:verify)
|
||||
```
|
||||
|
||||
1. **After `/opsx:propose`** (or `/opsx:ff`), before `/opsx:apply` — read the plan while it's still just words.
|
||||
2. **After building**, with `/opsx:verify` — check that the code actually did what the plan said.
|
||||
|
||||
The first review is the one that saves you the most, and the one people skip. This page spends most of its time there.
|
||||
|
||||
## Read it in this order
|
||||
|
||||
A change is a folder of plain Markdown in `openspec/changes/<name>/`. Read the files in the order that lets you quit earliest if something's wrong:
|
||||
|
||||
```
|
||||
openspec/changes/add-dark-mode/
|
||||
├── proposal.md 1. the intent and scope ← if this is wrong, stop here
|
||||
├── specs/…/spec.md 2. the requirements ← the heart of the review
|
||||
├── design.md (only for bigger changes) — the technical approach
|
||||
└── tasks.md 3. the plan of work
|
||||
```
|
||||
|
||||
You don't need to read every line. You need to answer three questions, one per file.
|
||||
|
||||
## The proposal: is this the right problem?
|
||||
|
||||
Open `proposal.md` first. It captures the "why" and "what" — the intent, the scope, the approach in a paragraph or two.
|
||||
|
||||
**What good looks like:** one clear intent, a scope you recognize, and a reason this is worth doing now.
|
||||
|
||||
**Red flags:**
|
||||
|
||||
- It solves a slightly *different* problem than the one you asked for.
|
||||
- The scope has grown — you asked for a theme toggle and the proposal also touches auth "while we're in there."
|
||||
- It's vague. "Improve the settings page" is not a scope; "add a dark-mode toggle that respects the OS preference" is.
|
||||
|
||||
**The question to answer:** *Does this match what I actually asked for, and is anything sneaking in?* If the answer is no, stop — don't read further, fix the proposal (see [Pushing back](#pushing-back-is-cheap)).
|
||||
|
||||
## The spec deltas: is "done" defined correctly?
|
||||
|
||||
This is the heart of the review. The delta specs under `specs/` say what will be *true* when the change ships — as requirements and the scenarios that prove them:
|
||||
|
||||
```markdown
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Dark Mode Toggle
|
||||
The system SHALL let a user switch between light and dark themes.
|
||||
|
||||
#### Scenario: Respects the OS preference on first load
|
||||
- GIVEN a user who has never set a theme
|
||||
- WHEN they open the app on a device set to dark mode
|
||||
- THEN the app renders in dark mode
|
||||
```
|
||||
|
||||
**What a good requirement looks like:** one clear `SHALL`/`MUST` statement you could hand to a tester, and at least one scenario whose GIVEN/WHEN/THEN actually exercises that statement.
|
||||
|
||||
**Red flags:**
|
||||
|
||||
- **A vague requirement.** "The system SHALL be fast" can't be built or tested. What's fast?
|
||||
- **A requirement with no scenario**, or a scenario that doesn't test the requirement it sits under.
|
||||
- **The most valuable catch of all: what's missing.** The AI faithfully writes down what you *said*. Your job is to notice what you *forgot* to say. If you cared most about the OS-preference case and no scenario mentions it, that's the review paying for itself.
|
||||
|
||||
Read the deltas asking *would I be happy if the system did exactly — and only — this?* Nothing here is about code yet, so it stays cheap to change.
|
||||
|
||||
## The tasks: is the plan of work sane?
|
||||
|
||||
Open `tasks.md` last. It's the implementation checklist the AI will work through.
|
||||
|
||||
**What good looks like:** ordered steps, each traceable to a requirement, nothing mysterious.
|
||||
|
||||
**Red flags:**
|
||||
|
||||
- A task with no matching requirement (where did that come from?).
|
||||
- One giant "implement the feature" task that hides all the real decisions.
|
||||
- A task that touches something outside the scope you just approved.
|
||||
|
||||
You're not estimating or micromanaging here — you're checking that the plan matches the requirements you already accepted.
|
||||
|
||||
## Pushing back is cheap
|
||||
|
||||
If any of the three questions came back wrong, say so. There are no phases and nothing is locked — you fix it and move on. Two ways, exactly as in [Editing a change](editing-changes.md):
|
||||
|
||||
- **Edit the file yourself.** It's plain Markdown; change the scope line, tighten a requirement, delete a task.
|
||||
- **Tell the AI what's wrong** and let it revise: *"drop the auth changes — out of scope,"* *"add a scenario for when the user has already picked a theme,"* *"split task 3 into schema and UI."*
|
||||
|
||||
Then re-read the part you changed. Re-draft until it's a plan you'd sign your name to. That back-and-forth *is* the product working.
|
||||
|
||||
## After the code: verify
|
||||
|
||||
Once the work is built, `/opsx:verify` is your second review. It re-reads the artifacts and the code and reports mismatches across three dimensions:
|
||||
|
||||
| Dimension | What it checks |
|
||||
|-----------|----------------|
|
||||
| **Completeness** | Every task done, every requirement implemented, scenarios covered |
|
||||
| **Correctness** | The implementation matches the spec's intent, edge cases handled |
|
||||
| **Coherence** | Design decisions actually show up in the code |
|
||||
|
||||
```
|
||||
You: /opsx:verify
|
||||
|
||||
AI: Verifying add-dark-mode...
|
||||
|
||||
COMPLETENESS
|
||||
✓ All 8 tasks in tasks.md are checked
|
||||
✓ All requirements in specs have corresponding code
|
||||
⚠ Scenario "Respects the OS preference on first load" has no test coverage
|
||||
```
|
||||
|
||||
It flags issues as CRITICAL, WARNING, or SUGGESTION, and it does **not** block archiving — it surfaces the gaps and leaves the call to you. This is the difference between "did the AI write code" and "did it build what we agreed."
|
||||
|
||||
`/opsx:verify` is in the expanded profile. If you don't have it, turn it on with `openspec config profile` (then `openspec update`), or just re-read the change and the diff yourself.
|
||||
|
||||
## Right-size the review
|
||||
|
||||
Not every change earns the full pass. A one-file typo fix deserves a twenty-second skim. A change that touches auth, payments, or data you can't recover deserves every question above. The point was never ceremony — it's spending your attention where a mistake would be expensive, and skimming where it wouldn't.
|
||||
|
||||
## The two-minute checklist
|
||||
|
||||
- [ ] The proposal's intent matches what I asked for.
|
||||
- [ ] Nothing extra has crept into the scope.
|
||||
- [ ] Every requirement is specific enough to test.
|
||||
- [ ] Every requirement has a scenario that actually exercises it.
|
||||
- [ ] The case I care about most is covered.
|
||||
- [ ] Tasks map to requirements; nothing is mysterious or out of scope.
|
||||
- [ ] I'd be comfortable if the AI built exactly this and nothing more.
|
||||
|
||||
If all seven pass, run `/opsx:apply` with confidence. If any fail, that's not a setback — it's the two minutes doing its job.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Writing Good Specs](writing-specs.md) — the flip side: how to draft requirements and scenarios worth approving.
|
||||
- [Editing & Iterating on a Change](editing-changes.md) — the mechanics of changing a plan after you've started.
|
||||
- [Workflows](workflows.md) — where review fits in the larger loop.
|
||||
@@ -1,462 +0,0 @@
|
||||
# Stores: Plan in Its Own Repo
|
||||
|
||||
> **Beta.** Stores, references, working context, and worksets are
|
||||
> new. Command names, flags, file formats, and JSON output may still change
|
||||
> shape between releases. Every walkthrough below was run against the
|
||||
> current build, but re-read this guide after upgrading.
|
||||
|
||||
## The problem this solves
|
||||
|
||||
OpenSpec normally lives inside one code repo: an `openspec/` folder next to
|
||||
your code, holding specs and changes for that repo.
|
||||
|
||||
That stops fitting the moment your planning is bigger than one repo:
|
||||
|
||||
- Your work spans several repos — one feature touches the API server, the
|
||||
web app, and a shared library. Whose `openspec/` folder does the plan
|
||||
live in?
|
||||
- Your team plans before code exists, or plans things that never become
|
||||
code in *this* repo.
|
||||
- Requirements are owned by one team and consumed by others. The wiki
|
||||
version drifts, and your coding agent can't read it anyway.
|
||||
|
||||
A **store** is the answer: a standalone repo whose whole job is planning.
|
||||
It has the same `openspec/` shape you already know — specs and changes —
|
||||
plus a small identity file. You register it on your machine once, by name,
|
||||
and then every normal OpenSpec command can work in it from anywhere.
|
||||
|
||||
## The shape
|
||||
|
||||
```
|
||||
team-plans (a store: planning in its own repo)
|
||||
├── .openspec-store/store.yaml identity: "I am team-plans"
|
||||
└── openspec/
|
||||
├── specs/ what is true
|
||||
└── changes/ what is in motion
|
||||
▲
|
||||
│ registered on each machine by name;
|
||||
│ shared by pushing/cloning like any repo
|
||||
┌─────────────┼─────────────┐
|
||||
│ │ │
|
||||
web-app api-server mobile-app
|
||||
(code repo) (code repo) (code repo)
|
||||
```
|
||||
|
||||
Two rules keep this simple:
|
||||
|
||||
1. **A store is just a git repo.** You commit, push, pull, and review it
|
||||
yourself. OpenSpec never clones, syncs, or pushes anything on its own.
|
||||
2. **Declarations, not machinery.** Repos can *declare* how they relate to
|
||||
stores (shown below). Declarations change what OpenSpec can tell you —
|
||||
never where your commands act.
|
||||
|
||||
## Five minutes to your first store
|
||||
|
||||
Two commands take you from nothing to a working, store-scoped change:
|
||||
|
||||
```bash
|
||||
openspec store setup team-plans --path ~/openspec/team-plans
|
||||
```
|
||||
|
||||
```
|
||||
Store ready: team-plans
|
||||
Location: /Users/you/openspec/team-plans
|
||||
OpenSpec root: ready
|
||||
Registry: registered
|
||||
|
||||
Next: run normal OpenSpec commands against this store, for example:
|
||||
openspec new change <change-id> --store team-plans
|
||||
Share this store by committing and pushing it like any Git repo.
|
||||
```
|
||||
|
||||
```bash
|
||||
openspec new change add-login --store team-plans
|
||||
```
|
||||
|
||||
```
|
||||
Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
|
||||
Created change 'add-login' at /Users/you/openspec/team-plans/openspec/changes/add-login/
|
||||
Schema: spec-driven
|
||||
Next: openspec status --change add-login --store team-plans
|
||||
```
|
||||
|
||||
That's the whole model. From here the lifecycle is exactly what you know —
|
||||
`status`, `instructions`, `validate`, `archive` — with `--store team-plans`
|
||||
on each command, and every printed hint carries the flag for you. The
|
||||
`Using OpenSpec root:` line always tells you where a command is acting.
|
||||
|
||||
## Story: one team, one planning repo
|
||||
|
||||
A team keeps its specs and changes in `team-plans` instead of scattering
|
||||
them across code repos.
|
||||
|
||||
**Day one (whoever sets it up):**
|
||||
|
||||
```bash
|
||||
openspec store setup team-plans --path ~/openspec/team-plans \
|
||||
--remote git@github.com:acme/team-plans.git
|
||||
git -C ~/openspec/team-plans push -u origin main
|
||||
```
|
||||
|
||||
Passing `--remote` records the clone URL inside the store's own identity
|
||||
file (`.openspec-store/store.yaml`), in the initial commit. Every future
|
||||
clone is born knowing where it came from, so health checks and error
|
||||
messages can print a complete, pasteable fix for teammates who don't have
|
||||
it yet.
|
||||
|
||||
**Every teammate (once per machine):**
|
||||
|
||||
```bash
|
||||
git clone git@github.com:acme/team-plans.git ~/openspec/team-plans
|
||||
openspec store register ~/openspec/team-plans
|
||||
```
|
||||
|
||||
From then on, everyone works in the same planning repo by name:
|
||||
|
||||
```bash
|
||||
openspec status --store team-plans --change add-login
|
||||
openspec show add-login --store team-plans
|
||||
```
|
||||
|
||||
**Sharing work is git, on purpose.** A change you create exists only in
|
||||
your checkout until you commit and push it — same as code. Plans get
|
||||
branches, pull requests, and review for free, because a store is an
|
||||
ordinary repo.
|
||||
|
||||
**Connecting the team's code repos.** A code repo whose planning is fully
|
||||
externalized needs exactly one line, in `openspec/config.yaml`:
|
||||
|
||||
```yaml
|
||||
# web-app/openspec/config.yaml
|
||||
store: team-plans
|
||||
```
|
||||
|
||||
Now every OpenSpec command run inside `web-app` acts on `team-plans` with
|
||||
no flags at all:
|
||||
|
||||
```bash
|
||||
cd ~/src/web-app
|
||||
openspec status --change add-login
|
||||
```
|
||||
|
||||
```
|
||||
Using OpenSpec root: team-plans (/Users/you/openspec/team-plans)
|
||||
...
|
||||
```
|
||||
|
||||
The pointer is a fallback, never an override: an explicit `--store` always
|
||||
wins, and if the repo grows real planning folders of its own, those win
|
||||
(with a warning to remove the stale pointer).
|
||||
|
||||
**One default for every repo on your machine.** If you work across many
|
||||
code repos that all plan into the same store, set it once, globally,
|
||||
instead of adding the `store:` line to each repo:
|
||||
|
||||
```bash
|
||||
openspec config set defaultStore team-plans
|
||||
```
|
||||
|
||||
Now any command run outside a planning root — and with no `--store` and no
|
||||
project pointer — resolves to `team-plans`. It sits at the bottom of the
|
||||
precedence list, so `--store`, a local root, and a project `store:` pointer
|
||||
all still win. The root banner and JSON `root` block report
|
||||
`source: "global_default"` with the store id, so you can always tell a
|
||||
machine-wide default from a repo's own pointer. Clear it with
|
||||
`openspec config unset defaultStore`. If the id is not registered, commands
|
||||
error and tell you to register it or clear the stale default.
|
||||
|
||||
## Example: one feature, two component repos
|
||||
|
||||
Suppose `add-checkout-promo` changes both `checkout-api` and
|
||||
`checkout-web`. The team wants one shared product contract, while each code
|
||||
repo still needs its own implementation tasks, branch, and review.
|
||||
|
||||
Use two layers:
|
||||
|
||||
1. Keep the shared behavior in `team-plans`.
|
||||
2. Keep implementation plans in each component repo and reference the store
|
||||
as read-only upstream context.
|
||||
|
||||
First, plan the shared contract in the store:
|
||||
|
||||
```bash
|
||||
openspec new change add-checkout-promo --store team-plans
|
||||
openspec status --change add-checkout-promo --store team-plans
|
||||
```
|
||||
|
||||
The proposal and specs should describe the behavior at the boundary between
|
||||
the components — for example, the promotion fields returned by the service
|
||||
and how the frontend handles an ineligible checkout. Review this change in
|
||||
the store repo like any other branch and pull request.
|
||||
|
||||
### What context does planning see?
|
||||
|
||||
Selecting a store changes the OpenSpec root; it does not discover or read
|
||||
every code repo that uses that store. Store instructions see the artifacts
|
||||
and configured context in the store. They see component code only when those
|
||||
folders are also available to the agent or editor and the agent reads them.
|
||||
|
||||
A workset is a convenient way to open the planning store and both code repos
|
||||
together:
|
||||
|
||||
```bash
|
||||
openspec workset create checkout-promo \
|
||||
--member ~/openspec/team-plans \
|
||||
--member ~/src/checkout-api \
|
||||
--member ~/src/checkout-web \
|
||||
--tool code
|
||||
openspec workset open checkout-promo
|
||||
```
|
||||
|
||||
This makes the folders visible in one IDE workspace. It does not copy source
|
||||
context into the store, select affected repos, or grant an agent permission
|
||||
to edit them. Put durable cross-component facts in the shared specs; do not
|
||||
rely on a planner remembering source it happened to inspect.
|
||||
|
||||
### How does implementation start in each repo?
|
||||
|
||||
When no explicit `--store` or nearer `openspec/` root applies, a
|
||||
`store: team-plans` pointer routes commands to that store. It does not split
|
||||
one store task list by the directory from which `apply` was invoked. OpenSpec
|
||||
currently does not route tasks to repos.
|
||||
|
||||
When each component needs an independently scoped apply/review cycle, give it
|
||||
a local OpenSpec root and reference the central store instead of pointing at
|
||||
it:
|
||||
|
||||
```yaml
|
||||
# checkout-api/openspec/config.yaml (and likewise in checkout-web)
|
||||
schema: spec-driven
|
||||
references:
|
||||
- team-plans
|
||||
```
|
||||
|
||||
After the shared contract is approved and available in the store's main
|
||||
specs, create a small local change for the component's part:
|
||||
|
||||
```bash
|
||||
cd ~/src/checkout-api
|
||||
openspec new change implement-checkout-promo-api
|
||||
|
||||
cd ~/src/checkout-web
|
||||
openspec new change implement-checkout-promo-ui
|
||||
```
|
||||
|
||||
The reference index in each repo's instructions supplies the store spec's
|
||||
summary and exact `openspec show ... --store team-plans` fetch command. Each
|
||||
local proposal cites that shared contract, and its tasks describe only work
|
||||
in that component. Then run `/opsx:apply` in each repo separately; root
|
||||
resolution keeps the artifacts and implementation edits scoped to that repo.
|
||||
The service and frontend changes can now be tested, reviewed, merged, and
|
||||
archived independently.
|
||||
|
||||
If implementation must begin while the shared store change is still active,
|
||||
fetch it explicitly with
|
||||
`openspec show add-checkout-promo --store team-plans`; reference indexes list
|
||||
canonical store specs, not active store changes. Keep the store branch and
|
||||
component branches linked in their pull-request descriptions so reviewers
|
||||
can see which version of the contract each implementation follows.
|
||||
|
||||
## Story: requirements that cross team lines
|
||||
|
||||
A platform team owns the requirements. Product teams build against them,
|
||||
in their own repos, with their own designs. A reference describes that
|
||||
relationship without moving anyone's work.
|
||||
|
||||
```
|
||||
platform-reqs (store) api-server (code repo)
|
||||
owned by the platform team owned by a product team
|
||||
┌──────────────────────────┐ ┌──────────────────────────┐
|
||||
│ openspec/specs/ │ ◀────────│ openspec/config.yaml │
|
||||
│ payments/spec.md │ reads │ references: │
|
||||
│ auth/spec.md │ │ - platform-reqs │
|
||||
│ │ │ openspec/specs/ │
|
||||
│ openspec/changes/ │ │ (their own designs) │
|
||||
│ platform work │ │ openspec/changes/ │
|
||||
│ │ │ (their own work) │
|
||||
│ │ └──────────────────────────┘
|
||||
└──────────────────────────┘
|
||||
```
|
||||
|
||||
**The product team declares what it draws on** in its repo's
|
||||
`openspec/config.yaml`:
|
||||
|
||||
```yaml
|
||||
references:
|
||||
- platform-reqs
|
||||
```
|
||||
|
||||
References are read-only context. The repo keeps its own `openspec/` root;
|
||||
work stays there. What changes: `openspec instructions` in that repo now
|
||||
includes an index of the referenced store's specs — each with a one-line
|
||||
summary and the exact fetch command (`openspec show <spec-id> --type spec
|
||||
--store platform-reqs`). An agent working in `api-server` can find the
|
||||
upstream payment requirements, cite them, and write its low-level design in
|
||||
the repo's own root — without anyone pasting context around.
|
||||
|
||||
A reference can carry its clone source, so teammates who don't have the
|
||||
store yet get a complete fix instead of a dead end:
|
||||
|
||||
```yaml
|
||||
references:
|
||||
- { id: platform-reqs, remote: "git@github.com:acme/platform-reqs.git" }
|
||||
```
|
||||
|
||||
**When you want the plan and code open together, make a workset.** This is
|
||||
personal and explicit: each person chooses the folders they actually work
|
||||
with on their machine. Nothing about those local checkout paths is
|
||||
committed to the shared planning repo.
|
||||
|
||||
```bash
|
||||
openspec workset create platform \
|
||||
--member ~/openspec/platform-reqs \
|
||||
--member ~/src/api-server \
|
||||
--member ~/src/web-app
|
||||
```
|
||||
|
||||
## Two questions you can always ask
|
||||
|
||||
**"Is my setup healthy?"** — `openspec doctor` checks the current root and
|
||||
its referenced stores, read-only, with a pasteable fix per finding:
|
||||
|
||||
```
|
||||
Doctor
|
||||
|
||||
Root
|
||||
Location: /Users/you/src/api-server
|
||||
OpenSpec root: ok
|
||||
|
||||
References
|
||||
- platform-reqs: ok (/Users/you/openspec/platform-reqs)
|
||||
- design-system: Referenced store 'design-system' is not registered on this machine.
|
||||
Fix: git clone -- git@github.com:acme/design-system.git '/Users/you/openspec/design-system' && openspec store register '/Users/you/openspec/design-system' --id design-system
|
||||
|
||||
```
|
||||
|
||||
**"What am I working with?"** — `openspec context` assembles the working
|
||||
set from OpenSpec declarations: the root and the stores it references.
|
||||
|
||||
```
|
||||
Working context for api-server (/Users/you/src/api-server)
|
||||
|
||||
OpenSpec root
|
||||
api-server /Users/you/src/api-server
|
||||
|
||||
Referenced stores
|
||||
platform-reqs /Users/you/openspec/platform-reqs
|
||||
Fetch: openspec show <spec-id> --type spec --store platform-reqs
|
||||
```
|
||||
|
||||
Both support `--json` for agents. `openspec context --code-workspace
|
||||
<path>` additionally writes a VS Code workspace file containing the whole
|
||||
set — the only write this command performs.
|
||||
|
||||
## Worksets: reopen the folders you work on together
|
||||
|
||||
Separate from all of the above: most people open the same few folders
|
||||
together every session — the planning repo plus two or three code repos.
|
||||
A **workset** is a personal, named view of exactly that, reopened with one
|
||||
command in your tool of choice.
|
||||
|
||||
```
|
||||
workset "platform" openspec workset open platform
|
||||
├── team-plans ~/openspec/team-plans │
|
||||
├── api-server ~/src/api-server ▼
|
||||
└── web-app ~/src/web-app all three open in your tool
|
||||
```
|
||||
|
||||
```bash
|
||||
openspec workset create platform \
|
||||
--member ~/openspec/team-plans --member ~/src/api-server \
|
||||
--tool code
|
||||
openspec workset list
|
||||
```
|
||||
|
||||
```
|
||||
platform (opens in VS Code)
|
||||
team-plans /Users/you/openspec/team-plans
|
||||
api-server /Users/you/src/api-server
|
||||
```
|
||||
|
||||
`openspec workset open platform` then launches the saved tool: editors
|
||||
(VS Code, Cursor) open one window with every member and return. The first
|
||||
member is the primary. Override the tool any time with `--tool <id>`.
|
||||
|
||||
Worksets are deliberately *not* shared state. They live on your machine,
|
||||
are never committed, and make no claims about the work — they only record
|
||||
what you like open together. Removing one never touches the member
|
||||
folders. New tools are configuration, not code: anything launched via a
|
||||
workspace file or per-folder attach flags can be added under the `openers`
|
||||
key in the global config (`openspec config edit`).
|
||||
|
||||
## How commands decide where to act
|
||||
|
||||
Every normal command resolves its root the same way, in this order:
|
||||
|
||||
```
|
||||
1. --store <id> you said so explicitly → that store
|
||||
2. nearest openspec/ a real planning root here → this repo
|
||||
(walking up from cwd)
|
||||
3. store: pointer config.yaml declares a store → that store
|
||||
4. defaultStore global config sets a machine → that store
|
||||
default
|
||||
5. none of the above stores registered on this → error with a
|
||||
machine? selection hint
|
||||
no stores registered? → the current
|
||||
directory
|
||||
(classic behavior)
|
||||
```
|
||||
|
||||
The `Using OpenSpec root:` line (and the `root` block in `--json` output)
|
||||
tells you which case you're in.
|
||||
|
||||
## Known limitations
|
||||
|
||||
- **Beta shape.** Everything on this page may change between releases —
|
||||
names, flags, file formats, JSON keys.
|
||||
- **One checkout per store id per machine.** Registering a second checkout
|
||||
under the same id fails with a hint to `store unregister` first.
|
||||
- **No sync, ever — by design.** OpenSpec never clones, pulls, or pushes.
|
||||
A stale checkout shows stale specs until *you* pull; references are
|
||||
indexed live from whatever is on disk.
|
||||
- **Empty planning folders can be absent.** A new store may not have
|
||||
`openspec/changes/`, `openspec/specs/`, or `openspec/changes/archive/` in Git
|
||||
yet. That is accepted during the beta; those folders appear once normal
|
||||
commands create files for them.
|
||||
- **Pointer repos stay pointers.** A config-only repo whose
|
||||
`openspec/config.yaml` declares `store: <id>` is treated as externalized
|
||||
planning, not as a store checkout to register. Remove the `store:` line first
|
||||
if you intentionally want to convert that repo into a local store root.
|
||||
- **Some commands stay where they are.** `templates` and the
|
||||
deprecated noun forms (`openspec change show`, ...) act on the current
|
||||
directory only — no `--store`. `schemas` follows the canonical root-selection
|
||||
precedence and accepts `--store <id>` while keeping its successful JSON array
|
||||
shape unchanged.
|
||||
- **Per-machine state is per-machine.** The store registry and worksets
|
||||
are local settings. Nothing about your machine's layout is
|
||||
ever committed to shared planning.
|
||||
- **Two launch styles for worksets.** A tool that can't be launched with a
|
||||
workspace file or per-folder attach flags can't be added as an opener.
|
||||
- **Agent JSON has a known casing split** (store-family keys are
|
||||
snake_case, workflow-family camelCase). Documented in the
|
||||
[agent contract](../agent-contract.md); unifying it is deferred to a
|
||||
versioned release.
|
||||
|
||||
## Where things live
|
||||
|
||||
| What | Where | Shared? |
|
||||
|---|---|---|
|
||||
| A store's planning | `<store>/openspec/` (specs, changes) | Yes — commit and push it |
|
||||
| A store's identity | `<store>/.openspec-store/store.yaml` | Yes — committed with the store |
|
||||
| The store registry | `<data dir>/openspec/stores/registry.yaml` | No — this machine only |
|
||||
| Worksets | `<data dir>/openspec/worksets/` | No — this machine only |
|
||||
|
||||
`<data dir>` is `~/.local/share/openspec` on macOS and Linux (or
|
||||
`$XDG_DATA_HOME/openspec` when set), and `%LOCALAPPDATA%\openspec` on
|
||||
Windows.
|
||||
|
||||
## Reference
|
||||
|
||||
Exact flags and JSON shapes for every command on this page:
|
||||
[CLI reference](../cli.md) (Stores, Doctor, Working context, Personal
|
||||
worksets) and the [agent contract](../agent-contract.md).
|
||||
+12
-161
@@ -9,56 +9,13 @@ For each selected tool, OpenSpec can install:
|
||||
1. **Skills** (if delivery includes skills): `.../skills/openspec-*/SKILL.md`
|
||||
2. **Commands** (if delivery includes commands): tool-specific `opsx-*` command files
|
||||
|
||||
Codex is skills-only: OpenSpec installs `.agents/skills/openspec-*/SKILL.md` for Codex even when delivery is set to `commands`, and it does not generate Codex custom prompt files. Existing OpenSpec-managed skills under the legacy `.codex/skills` path are reconciled after their replacements are written; custom and divergent files are preserved.
|
||||
|
||||
By default, OpenSpec uses the `core` profile, which includes:
|
||||
- `propose`
|
||||
- `explore`
|
||||
- `apply`
|
||||
- `update`
|
||||
- `sync`
|
||||
- `archive`
|
||||
|
||||
You can enable expanded workflows (`new`, `continue`, `ff`, `verify`, `bulk-archive`, `onboard`) via `openspec config profile`, then run `openspec update`.
|
||||
|
||||
## How To Invoke
|
||||
|
||||
These docs use `/opsx:propose` as the canonical name, but each tool spells it the
|
||||
way it loads the file OpenSpec wrote. Find your tool's command path in the
|
||||
[Tool Directory Reference](#tool-directory-reference) below, then match its shape here.
|
||||
|
||||
| Command file OpenSpec writes | You type | Tools |
|
||||
|------------------------------|----------|-------|
|
||||
| `.../commands/opsx/<id>.*` — an `opsx/` folder namespaces it | `/opsx:<id>` | Claude Code, CodeBuddy, Crush, Gemini CLI, Lingma, Qoder, ZCode |
|
||||
| `.../opsx-<id>.*` — the filename is the command | `/opsx-<id>` | Every other tool with generated command files, except Amazon Q and Devin |
|
||||
| `.devin/workflows/opsx-<id>.md` — read by only one of Devin's two agents | `/opsx-<id>` on Devin Desktop, `/openspec-<skill>` on Devin Local | Devin Desktop\*\*\*\* |
|
||||
| `.amazonq/prompts/opsx-<id>.md` — a prompt, not a command | `@opsx-<id>` | Amazon Q Developer |
|
||||
| none — skills only | `/openspec-<skill>` | CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, shared `.agents` |
|
||||
| none — Kimi Code | `/skill:openspec-<skill>` | Kimi Code |
|
||||
| none — Codex CLI | `$openspec-<skill>` | Codex ([`/openspec-<skill>` is not recognized](https://github.com/openai/codex/issues/11817)) |
|
||||
|
||||
So `/opsx:propose` is `/opsx-propose` in Cursor, `@opsx-propose` in Amazon Q, and
|
||||
`$openspec-propose` in Codex.
|
||||
|
||||
Two things vary independently, which is why the rows do not collapse:
|
||||
|
||||
- **The name.** Rows 1–2 differ only in how the file names the command, and the
|
||||
`opsx-<id>` / `opsx:<id>` stem is the same for every tool with generated
|
||||
command files.
|
||||
- **The wrapper.** Amazon Q loads its files into a prompt library invoked with
|
||||
`@`. Skills-only tools generate no command files at all, so their last three
|
||||
rows use *skill* names — listed under
|
||||
[Generated Skill Names](#generated-skill-names) — which do not map one-to-one
|
||||
onto command ids (`/opsx:apply` is the `openspec-apply-change` skill).
|
||||
|
||||
The command path patterns above are extension-neutral (`.*`) on purpose: the
|
||||
extension is the tool's (`.toml` for Gemini CLI, `.prompt` for Continue,
|
||||
`.prompt.md` for Kiro and GitHub Copilot), and a few tools show the name with
|
||||
its extension in the picker. Match the directory shape, not the extension.
|
||||
|
||||
The files OpenSpec generates, and the "Getting started" hint printed after setup,
|
||||
already use the right form for the tools you selected — so the fastest answer is
|
||||
to read the hint.
|
||||
You can enable expanded workflows (`new`, `continue`, `ff`, `verify`, `sync`, `bulk-archive`, `onboard`) via `openspec config profile`, then run `openspec update`.
|
||||
|
||||
## Tool Directory Reference
|
||||
|
||||
@@ -70,11 +27,8 @@ to read the hint.
|
||||
| IBM Bob Shell (`bob`) | `.bob/skills/openspec-*/SKILL.md` | `.bob/commands/opsx-<id>.md` |
|
||||
| Claude Code (`claude`) | `.claude/skills/openspec-*/SKILL.md` | `.claude/commands/opsx/<id>.md` |
|
||||
| Cline (`cline`) | `.cline/skills/openspec-*/SKILL.md` | `.clinerules/workflows/opsx-<id>.md` |
|
||||
| Command Code (`command-code`) | `.commandcode/skills/openspec-*/SKILL.md` | `.commandcode/commands/opsx-<id>.md` |
|
||||
| CodeArts (`codeartsagent`) | `.codeartsdoer/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
|
||||
| CodeBuddy (`codebuddy`) | `.codebuddy/skills/openspec-*/SKILL.md` | `.codebuddy/commands/opsx/<id>.md` |
|
||||
| Codex (`codex`) | `.agents/skills/openspec-*/SKILL.md` | Not generated (skills-only; use `$openspec-*`) |
|
||||
| Devin Desktop, formerly Windsurf (`devin`) | `.devin/skills/openspec-*/SKILL.md` | `.devin/workflows/opsx-<id>.md`\*\*\*\* |
|
||||
| Codex (`codex`) | `.codex/skills/openspec-*/SKILL.md` | `$CODEX_HOME/prompts/opsx-<id>.md`\* |
|
||||
| ForgeCode (`forgecode`) | `.forge/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
|
||||
| Continue (`continue`) | `.continue/skills/openspec-*/SKILL.md` | `.continue/prompts/opsx-<id>.prompt` |
|
||||
| CoStrict (`costrict`) | `.cospec/skills/openspec-*/SKILL.md` | `.cospec/openspec/commands/opsx-<id>.md` |
|
||||
@@ -83,123 +37,21 @@ to read the hint.
|
||||
| Factory Droid (`factory`) | `.factory/skills/openspec-*/SKILL.md` | `.factory/commands/opsx-<id>.md` |
|
||||
| Gemini CLI (`gemini`) | `.gemini/skills/openspec-*/SKILL.md` | `.gemini/commands/opsx/<id>.toml` |
|
||||
| GitHub Copilot (`github-copilot`) | `.github/skills/openspec-*/SKILL.md` | `.github/prompts/opsx-<id>.prompt.md`\*\* |
|
||||
| Hermes Agent (`hermes`) | `.hermes/skills/openspec-*/SKILL.md`\*\*\* | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
|
||||
| iFlow (`iflow`) | `.iflow/skills/openspec-*/SKILL.md` | `.iflow/commands/opsx-<id>.md` |
|
||||
| Junie (`junie`) | `.junie/skills/openspec-*/SKILL.md` | `.junie/commands/opsx-<id>.md` |
|
||||
| Kilo Code (`kilocode`) | `.kilocode/skills/openspec-*/SKILL.md` | `.kilo/command/opsx-<id>.md` |
|
||||
| Kimi Code (`kimi`) | `.kimi-code/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/skill:openspec-*` invocations) |
|
||||
| Kilo Code (`kilocode`) | `.kilocode/skills/openspec-*/SKILL.md` | `.kilocode/workflows/opsx-<id>.md` |
|
||||
| Kiro (`kiro`) | `.kiro/skills/openspec-*/SKILL.md` | `.kiro/prompts/opsx-<id>.prompt.md` |
|
||||
| Lingma (`lingma`) | `.lingma/skills/openspec-*/SKILL.md` | `.lingma/commands/opsx/<id>.md` |
|
||||
| MiniMax Code (`minimax-code`) | `~/.minimax/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use MiniMax Code skills) |
|
||||
| Mistral Vibe (`vibe`) | `.vibe/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
|
||||
| Oh My Pi (`oh-my-pi`) | `.omp/skills/openspec-*/SKILL.md` | `.omp/commands/opsx-<id>.md` |
|
||||
| OpenCode (`opencode`) | `.opencode/skills/openspec-*/SKILL.md` | `.opencode/commands/opsx-<id>.md` |
|
||||
| Pi (`pi`) | `.pi/skills/openspec-*/SKILL.md` | `.pi/prompts/opsx-<id>.md` |
|
||||
| SourceCraft Code Assistant for VS Code (`codeassistant`) | `.codeassistant/skills/openspec-*/SKILL.md` | `.codeassistant/commands/opsx-<id>.md` |
|
||||
| Qoder (`qoder`) | `.qoder/skills/openspec-*/SKILL.md` | `.qoder/commands/opsx/<id>.md` |
|
||||
| Qwen Code (`qwen`) | `.qwen/skills/openspec-*/SKILL.md` | `.qwen/commands/opsx-<id>.md` |
|
||||
| [Rovo Dev CLI](https://support.atlassian.com/rovo/docs/use-rovo-dev-cli/) (`rovodev`) | `.rovodev/skills/openspec-*/SKILL.md` | Not generated. Rovo has no slash-command surface — it matches skills automatically or by prompt (e.g. "use the openspec-propose skill"); `/skills` only manages them. Generated content references skills by name, never as `/openspec-*` commands. |
|
||||
| [Zoo Code](https://github.com/Zoo-Code-Org/Zoo-Code) (`roocode`) | `.roo/skills/openspec-*/SKILL.md` | `.roo/commands/opsx-<id>.md` |
|
||||
| Trae (`trae`) | `.trae/skills/openspec-*/SKILL.md` | `.trae/commands/opsx-<id>.md` |
|
||||
| [Zed Agent](https://zed.dev/docs/ai/skills) (`zed`) | `.agents/skills/openspec-*/SKILL.md` | Not generated (skills-only; use `/openspec-*` or `@openspec-*`) |
|
||||
| ZCode (`zcode`) | `.zcode/skills/openspec-*/SKILL.md` | `.zcode/commands/opsx/<id>.md` |
|
||||
| Shared `.agents` skills (`agents`) | `.agents/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
|
||||
| Qwen Code (`qwen`) | `.qwen/skills/openspec-*/SKILL.md` | `.qwen/commands/opsx-<id>.toml` |
|
||||
| RooCode (`roocode`) | `.roo/skills/openspec-*/SKILL.md` | `.roo/commands/opsx-<id>.md` |
|
||||
| Trae (`trae`) | `.trae/skills/openspec-*/SKILL.md` | Not generated (no command adapter; use skill-based `/openspec-*` invocations) |
|
||||
| Windsurf (`windsurf`) | `.windsurf/skills/openspec-*/SKILL.md` | `.windsurf/workflows/opsx-<id>.md` |
|
||||
|
||||
\*\* GitHub Copilot prompt files are recognized as custom slash commands in IDE extensions (VS Code, JetBrains, Visual Studio). Copilot CLI does not currently consume `.github/prompts/*.prompt.md` directly. Selecting `github-copilot` can also set up the GitHub-hosted **cloud coding agent** — see [GitHub Copilot cloud coding agent](#github-copilot-cloud-coding-agent) below.
|
||||
\* Codex commands are installed in the global Codex home (`$CODEX_HOME/prompts/` if set, otherwise `~/.codex/prompts/`), not your project directory.
|
||||
|
||||
\*\*\* Hermes loads skills from `~/.hermes/skills/` by default. To use project-local OpenSpec skills, add the project `.hermes/skills/` directory to `skills.external_dirs` in `~/.hermes/config.yaml`; Hermes then exposes skills with user-facing slash invocations such as `/openspec-propose`.
|
||||
|
||||
\*\*\*\* Windsurf was [rebranded to Devin Desktop](https://docs.devin.ai/desktop/devin-desktop-faq) on June 2, 2026, and its config directory moved: `.devin/` is the preferred read + write location, `.windsurf/` a legacy read-only fallback. OpenSpec follows the rename — the tool id is `devin`, and `--tools windsurf` still resolves to it so existing setup scripts keep working. A project still holding OpenSpec files in `.windsurf/` is offered the move on the next `openspec update`; declining leaves them in place, and files you wrote yourself are never touched. Workflows are invoked by filename, so `.devin/workflows/opsx-apply.md` is `/opsx-apply`. The [Devin Local agent does not support workflows](https://docs.devin.ai/desktop/devin-local) — only skills, and it does not read `.windsurf/` at all — so whenever OpenSpec writes Devin skills it keeps their bodies, and the getting-started hint, on `/openspec-*` skill invocations, which work on both agents. Under commands-only delivery no skills are written and both fall back to `/opsx-*`.
|
||||
|
||||
SourceCraft Code Assistant support targets its VS Code extension. Its [custom commands](https://sourcecraft.dev/portal/docs/en/code-assistant/operations/agent/slash-commands) and [skills](https://sourcecraft.dev/portal/docs/ru/code-assistant/operations/agent/skills) are available only in VS Code. This integration does not configure SourceCraft web or JetBrains.
|
||||
|
||||
With skills-only delivery, ask Code Assistant to use the `openspec-propose` skill with your idea. Skills activate through request matching; OpenSpec does not generate `/openspec-*` commands for this tool.
|
||||
|
||||
MiniMax Code is a global skills-only integration. OpenSpec writes only its
|
||||
`openspec-*` directories under `~/.minimax/skills/`; it does not create
|
||||
repo-local `.minimax` or `.mavis` directories. Commands-only delivery leaves
|
||||
existing global MiniMax Code skills untouched so one project's delivery setting
|
||||
cannot remove skills used by another project.
|
||||
|
||||
### GitHub Copilot cloud coding agent
|
||||
|
||||
GitHub's [Copilot coding agent](https://docs.github.com/en/copilot/using-github-copilot/coding-agent) runs on GitHub in a GitHub Actions environment — separate from Copilot in your editor. OpenSpec can set it up to use the OpenSpec CLI by generating two files:
|
||||
|
||||
- `.github/workflows/copilot-setup-steps.yml` — installs `@fission-ai/openspec` in the agent's environment
|
||||
- `.github/agents/openspec.agent.md` — tells the agent how to drive OpenSpec
|
||||
|
||||
Because this writes a GitHub Actions workflow into your repository, it is **opt-in**:
|
||||
|
||||
| How | Behavior |
|
||||
|-----|----------|
|
||||
| `openspec init` (interactive) | Asks whether to set up cloud files. Default is **No**. |
|
||||
| `openspec init --copilot-cloud` | Sets them up without prompting (for scripts/CI). |
|
||||
| `openspec init --no-copilot-cloud` | Skips them without prompting, and removes any previously generated ones. |
|
||||
| `openspec update` | Never prompts. Refreshes the files only if you opted in (or the project already has them). If you opted out, it removes OpenSpec-managed cloud files. |
|
||||
|
||||
Your choice is saved in `openspec/config.yaml` as `githubCopilot.cloudAgent: true|false`, so non-interactive updates honor it. OpenSpec only ever writes or removes files whose content it generated — if you customize `copilot-setup-steps.yml` or `openspec.agent.md`, or already have your own, it is left untouched (and `init`/`update` tell you so).
|
||||
|
||||
### When to pick the shared `.agents` target
|
||||
|
||||
`agents` is the vendor-neutral option: it writes skills to `.agents/skills/`, the
|
||||
shared root many agent tools read, instead of a tool-specific directory.
|
||||
|
||||
| Situation | Pick |
|
||||
|-----------|------|
|
||||
| Your tool has its own row above | Its own ID — you get that tool's integration, including slash commands where it supports them |
|
||||
| Several agents on one repo, all reading `.agents/skills` | `agents` — one skill tree instead of one per tool |
|
||||
| Your tool isn't listed yet but reads `.agents/skills` | `agents` |
|
||||
|
||||
Selecting it alongside a tool-specific ID is fine; each normally writes to its
|
||||
own root. Codex and Zed Agent are the exceptions because they use the same canonical
|
||||
`.agents` root. If Codex is selected with Zed or `agents`, OpenSpec keeps one
|
||||
Codex-led tree. Its handoffs name both `$openspec-*` for Codex and
|
||||
`/openspec-*` for other agents, so `--tools all` and existing multi-agent
|
||||
setups keep working without two writers overwriting the same files.
|
||||
OpenSpec also offers it automatically once a project has a `.agents/skills/`
|
||||
directory — a bare `.agents/` is not enough, since tools use that root for rules
|
||||
and subagent definitions too. Note `.agents` is not `.agent`: the singular
|
||||
directory belongs to Antigravity.
|
||||
|
||||
Two things to know:
|
||||
|
||||
- **Skills only.** No command adapter exists, so no `opsx-*` command files are
|
||||
written; with a commands-inclusive delivery mode `openspec init` lists `agents`
|
||||
among the tools it reports under `Commands skipped for: … (no adapter)`.
|
||||
Invoke the workflows by skill name —
|
||||
most assistants that read `.agents/skills` spell that `/openspec-propose`, the form
|
||||
OpenSpec's setup hint prints. The target is vendor-neutral, so check your
|
||||
assistant's own docs if it uses another form.
|
||||
- **No `AGENTS.md` is created or edited.** The target is the `.agents/` directory.
|
||||
If your root `AGENTS.md` still carries OpenSpec marker blocks from an older
|
||||
version, `openspec update` strips them — see the [Migration Guide](migration-guide.md).
|
||||
|
||||
Zed support here is for the built-in Zed Agent. Zed External Agents and Terminal
|
||||
Threads use their own integrations. Agent Skills require
|
||||
[Zed v1.4.2](https://github.com/zed-industries/zed/releases/tag/v1.4.2) or newer.
|
||||
Project-local skills are unavailable in an untrusted worktree until you
|
||||
[grant trust](https://zed.dev/docs/worktree-trust).
|
||||
|
||||
Because `.agents/skills/` is shared by Codex, Zed Agent, and the vendor-neutral target,
|
||||
it is worth knowing what OpenSpec claims there:
|
||||
it writes, refreshes, and removes only the `openspec-*` skill directories for your
|
||||
selected workflows, plus an `.openspec-target` marker that records whether Codex,
|
||||
Zed Agent, or the vendor-neutral target rendered that shared tree. Anything else in that
|
||||
directory is left alone. Treat the `openspec-*` names and marker as OpenSpec's —
|
||||
edits inside them are replaced on the next `openspec update`, the same as for
|
||||
every other tool.
|
||||
|
||||
For pre-marker projects, OpenSpec infers ownership from managed skill references:
|
||||
`$openspec-*` means Codex and `/openspec-*` means the vendor-neutral target. A
|
||||
generic canonical tree alongside legacy `.codex/skills` is treated as an older
|
||||
dual-target install and consolidated into the compatible shared tree.
|
||||
|
||||
`openspec update` honors this ownership too. If a project owns `.agents` as the
|
||||
vendor-neutral target and a leftover Codex install is detected only from stray
|
||||
prompt files, the update leaves the established `agents` tree in place instead of
|
||||
rewriting it with Codex syntax, and preserves those legacy prompt files rather
|
||||
than deleting them. To hand the shared tree to Codex, run `openspec init --tools
|
||||
codex` explicitly.
|
||||
\*\* GitHub Copilot prompt files are recognized as custom slash commands in IDE extensions (VS Code, JetBrains, Visual Studio). Copilot CLI does not currently consume `.github/prompts/*.prompt.md` directly.
|
||||
|
||||
## Non-Interactive Setup
|
||||
|
||||
@@ -219,15 +71,15 @@ openspec init --tools none
|
||||
openspec init --profile core
|
||||
```
|
||||
|
||||
**Available tool IDs (`--tools`)** — `windsurf` is also accepted, as an alias for `devin`: `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `command-code`, `codeartsagent`, `codex`, `devin`, `forgecode`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `gemini`, `github-copilot`, `hermes`, `iflow`, `junie`, `kilocode`, `kimi`, `kiro`, `lingma`, `minimax-code`, `vibe`, `oh-my-pi`, `opencode`, `pi`, `qoder`, `qwen`, `roocode`, `codeassistant`, `trae`, `zed`, `zcode`, `agents`
|
||||
**Available tool IDs (`--tools`):** `amazon-q`, `antigravity`, `auggie`, `bob`, `claude`, `cline`, `codex`, `codebuddy`, `continue`, `costrict`, `crush`, `cursor`, `factory`, `forgecode`, `gemini`, `github-copilot`, `iflow`, `junie`, `kilocode`, `kiro`, `opencode`, `pi`, `qoder`, `qwen`, `roocode`, `trae`, `windsurf`
|
||||
|
||||
## Workflow-Dependent Installation
|
||||
|
||||
OpenSpec installs workflow artifacts based on selected workflows:
|
||||
|
||||
- **Core profile (default):** `propose`, `explore`, `apply`, `update`, `sync`, `archive`
|
||||
- **Core profile (default):** `propose`, `explore`, `apply`, `archive`
|
||||
- **Custom selection:** any subset of all workflow IDs:
|
||||
`propose`, `explore`, `new`, `continue`, `apply`, `update`, `ff`, `sync`, `archive`, `bulk-archive`, `verify`, `onboard`
|
||||
`propose`, `explore`, `new`, `continue`, `apply`, `ff`, `sync`, `archive`, `bulk-archive`, `verify`, `onboard`
|
||||
|
||||
In other words, skill/command counts are profile-dependent and delivery-dependent, not fixed.
|
||||
|
||||
@@ -240,7 +92,6 @@ When selected by profile/workflow config, OpenSpec generates these skills:
|
||||
- `openspec-new-change`
|
||||
- `openspec-continue-change`
|
||||
- `openspec-apply-change`
|
||||
- `openspec-update-change`
|
||||
- `openspec-ff-change`
|
||||
- `openspec-sync-specs`
|
||||
- `openspec-archive-change`
|
||||
|
||||
@@ -1,74 +0,0 @@
|
||||
# OpenSpec on a Team
|
||||
|
||||
Everything in the other guides works the same whether you're solo or on a team of twenty. What changes on a team is the questions around the edges: where do the specs live, how do teammates review a plan, and how does any of this fit the pull-request flow we already have?
|
||||
|
||||
The short answer: a change is just files, and OpenSpec never touches git. So it fits your existing workflow instead of replacing it. This page spells out the conventions that work well.
|
||||
|
||||
## One rule: OpenSpec doesn't touch git
|
||||
|
||||
OpenSpec reads and writes plain Markdown under `openspec/`. It never commits, branches, pushes, or pulls in your project — and it never clones or syncs a [store](stores-beta/user-guide.md) on its own. That means:
|
||||
|
||||
- **You commit `openspec/` like any source.** Specs, active changes, and the archive are part of your project's history. (Yes, commit the whole folder — see the [FAQ](faq.md#should-i-commit-the-openspec-folder-to-git).)
|
||||
- **A change is a folder you version like code.** `openspec/changes/add-dark-mode/` is just files on a branch.
|
||||
- **Everything below is convention, not enforcement.** OpenSpec won't make you do it this way; it just fits cleanly.
|
||||
|
||||
## The everyday loop
|
||||
|
||||
The workflow that works well maps a change onto a branch and a pull request:
|
||||
|
||||
```
|
||||
git switch -c add-dark-mode start a branch, as usual
|
||||
│
|
||||
/opsx:propose add-dark-mode draft the plan (proposal + specs + tasks)
|
||||
│
|
||||
REVIEW THE PLAN you read it before any code — see Reviewing a Change
|
||||
│
|
||||
/opsx:apply build it; artifacts + code change together
|
||||
│
|
||||
git commit && open a PR the PR contains the spec delta AND the code
|
||||
│
|
||||
teammate reviews, merges
|
||||
│
|
||||
/opsx:archive fold the delta into specs/, move the change to archive/
|
||||
```
|
||||
|
||||
The plan and the code live side by side in the same branch, so your teammates review both together, and six months later the archived spec still explains why the code looks the way it does.
|
||||
|
||||
## Reviewing specs in a pull request
|
||||
|
||||
This is where a team feels the payoff. When a PR includes the change's delta spec, the reviewer gets something a raw diff never gives them: **a plain-language statement of what this change is supposed to do**, before they read a single line of code.
|
||||
|
||||
A good review order for the reviewer:
|
||||
|
||||
1. **Read `proposal.md`** — is this the right problem and scope?
|
||||
2. **Read the delta under `specs/`** — is "done" defined correctly? (This is the [Reviewing a Change](reviewing-changes.md) two-minute pass, now happening in the PR.)
|
||||
3. **Then read the code diff** — does it deliver exactly those requirements?
|
||||
|
||||
A reviewer who disagrees with the *approach* can say so against the proposal, cheaply, instead of relitigating it across 300 lines of code. Put the delta spec near the top of the PR description, or point reviewers at the change folder, so they start there.
|
||||
|
||||
## When to archive
|
||||
|
||||
Archiving folds a change's deltas into your main `openspec/specs/` and moves the change folder to `openspec/changes/archive/YYYY-MM-DD-<name>/`. Because `specs/` is the **shared source of truth**, the timing matters on a team. Two workable conventions:
|
||||
|
||||
- **Archive after the PR merges (recommended).** The branch carries the active change; once it's merged to your main branch, archive there (often a tiny follow-up commit or a scheduled cleanup). This keeps the shared `specs/` moving forward only with work that actually shipped.
|
||||
- **Archive inside the PR.** Simpler for small teams: the same PR that adds the code also syncs and archives. The tradeoff is that your `specs/` diff and your code diff land together, which can make the PR noisier.
|
||||
|
||||
Pick one and be consistent. Either way, `/opsx:archive` checks that tasks are complete and offers to sync first, so nothing merges half-finished by accident.
|
||||
|
||||
## Two people, parallel changes
|
||||
|
||||
Because changes are separate folders, they don't collide:
|
||||
|
||||
- **Different changes, different people — no problem.** `add-dark-mode` and `rate-limit-login` are different folders on different branches; they never touch each other until they both archive.
|
||||
- **One change, one owner.** Two people editing the same change folder conflict exactly like two people editing the same file. Keep a change to a single author, or split it into two changes (another reason to [right-size](writing-specs.md#right-size-the-change)).
|
||||
- **The one place conflicts show up is `specs/`.** If two changes both modify the *same* requirement, archiving the second one will conflict in `openspec/specs/…/spec.md` — resolve it like any merge conflict, keeping the requirement that reflects reality. This is rare, and it's a feature: it's git telling you two changes disagreed about how the system should behave.
|
||||
|
||||
## When planning outgrows one repo
|
||||
|
||||
Everything above assumes the plan lives in the code repo's own `openspec/` folder, which is the right default. When your planning genuinely spans several repos or teams — one feature touching three services, or requirements one team owns and others consume — that's what the beta **stores** feature is for: planning gets its own repo that any code repo can point at. Start with the [Stores User Guide](stores-beta/user-guide.md).
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Reviewing a Change](reviewing-changes.md) — the review pass, now inside your PR.
|
||||
- [Writing Good Specs](writing-specs.md) — including how to right-size a change so it fits one branch.
|
||||
- [Stores User Guide](stores-beta/user-guide.md) — planning that spans repos and teams.
|
||||
@@ -1,195 +0,0 @@
|
||||
# Troubleshooting
|
||||
|
||||
Concrete fixes for concrete problems. Each entry names a symptom, explains the likely cause in a sentence, and gives you the fix. If you don't see your issue here, the [FAQ](faq.md) may help, and the [Discord](https://discord.gg/YctCnvvshC) definitely will.
|
||||
|
||||
## Installation and setup
|
||||
|
||||
### `openspec: command not found`
|
||||
|
||||
The CLI isn't installed, or your shell can't find it. Install it globally and check:
|
||||
|
||||
```bash
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
openspec --version
|
||||
```
|
||||
|
||||
If it installed but still isn't found, your global npm bin directory probably isn't on your `PATH`. Run `npm prefix -g` to see where global packages live: on macOS and Linux the binaries are in that directory's `bin/`, and on Windows they sit directly in it. Make sure that path is on your `PATH`. (`npm bin -g` was removed in npm 9.)
|
||||
|
||||
If you used the [AI-assisted install](installation.md#install-with-your-ai-assistant), this is the expected hand-off point: that prompt tells your assistant to show you the `PATH` change rather than edit your shell startup files itself.
|
||||
|
||||
### "Requires Node.js 20.19.0 or higher"
|
||||
|
||||
OpenSpec runs on Node 20.19.0+. Check your version and upgrade if needed:
|
||||
|
||||
```bash
|
||||
node --version
|
||||
```
|
||||
|
||||
If you use bun to install OpenSpec, note that OpenSpec still *runs* on Node, so you need Node 20.19.0+ available on your `PATH` regardless. See [Installation](installation.md).
|
||||
|
||||
### `openspec init` didn't configure my AI tool
|
||||
|
||||
Init asks which tools to set up. If you skipped your tool or want to add another, just run it again, or use the non-interactive form:
|
||||
|
||||
```bash
|
||||
openspec init --tools claude,cursor
|
||||
```
|
||||
|
||||
The full list of tool IDs is in [Supported Tools](supported-tools.md). Use `--tools all` for everything, `--tools none` to skip tool setup.
|
||||
|
||||
## Commands don't show up
|
||||
|
||||
If `/opsx:propose` (or your tool's equivalent) doesn't appear or doesn't do anything, work down this list. They're ordered fastest-to-check first.
|
||||
|
||||
1. **You may be in the wrong place.** Slash commands go in your AI assistant's chat, not your terminal. If you typed `/opsx:propose` into your shell, that's the issue. See [How Commands Work](how-commands-work.md).
|
||||
|
||||
2. **Regenerate the files.** From your project root:
|
||||
|
||||
```bash
|
||||
openspec update
|
||||
```
|
||||
|
||||
This rewrites the skill and command files for every tool you've configured.
|
||||
|
||||
Instruction files come from the *installed* CLI, so an outdated CLI reports everything up to date without ever writing the newer workflows. `openspec update` now checks for that and offers to upgrade — take the offer if you see it.
|
||||
|
||||
3. **Restart your assistant.** Most tools scan for skills and commands at startup. A fresh window often does it.
|
||||
|
||||
4. **Confirm the files exist.** For Claude Code, check that `.claude/skills/` contains `openspec-*` folders. Other tools use their own directories, all listed in [Supported Tools](supported-tools.md).
|
||||
|
||||
5. **Check you initialized this project.** Skills are written per project. If you cloned a repo or switched folders, run `openspec init` (or `openspec update`) there.
|
||||
|
||||
6. **Confirm your tool supports command files.** Codex, CodeArts, ForgeCode, Hermes, Kimi Code, Mistral Vibe, Zed Agent, and the shared `.agents` target don't get generated `opsx-*` command files; they use skill-based invocations instead, so `/opsx` will never autocomplete for them. Type `$openspec-propose` in Codex, `/skill:openspec-propose` in Kimi Code, and `/openspec-propose` in the rest. The shared `.agents` target is vendor-neutral, so `/openspec-propose` is the common form rather than a guaranteed one — if your assistant does not answer to it, check its own docs for how it invokes a skill. Amazon Q does get command files, but loads them into its prompt library rather than its slash menu — type `@opsx-propose` there, not `/opsx`. Every tool's form is listed in [How To Invoke](supported-tools.md#how-to-invoke).
|
||||
|
||||
## Working with changes
|
||||
|
||||
### "Change not found"
|
||||
|
||||
The command couldn't tell which change you meant. Name it explicitly, or check what exists:
|
||||
|
||||
```bash
|
||||
openspec list # see active changes
|
||||
/opsx:apply add-dark-mode # name the change in chat
|
||||
```
|
||||
|
||||
Also confirm you're in the right project directory.
|
||||
|
||||
### "No artifacts ready"
|
||||
|
||||
Every artifact is either already created or blocked waiting on a dependency. See what's blocking:
|
||||
|
||||
```bash
|
||||
openspec status --change <name>
|
||||
```
|
||||
|
||||
Then create the missing dependency first. Remember the order: proposal enables specs and design; specs and design together enable tasks.
|
||||
|
||||
### `openspec validate` reports warnings or errors
|
||||
|
||||
Validation checks your specs and changes for structural problems. Read the message: it names the file and the issue.
|
||||
|
||||
```bash
|
||||
openspec validate <name> # validate one item
|
||||
openspec validate --all # validate everything
|
||||
openspec validate --all --strict # stricter checks, good for CI
|
||||
openspec validate --archived # fail if archived changes have unchecked tasks
|
||||
```
|
||||
|
||||
Common causes are a missing required section (like a spec with no scenarios) or a malformed delta header. Fix the file and re-run. The [CLI reference](cli.md#openspec-validate) documents the output format.
|
||||
|
||||
One message deserves its own note:
|
||||
|
||||
```text
|
||||
MODIFIED "<requirement>" omits scenario(s) the current spec still has: "<scenario>"
|
||||
```
|
||||
|
||||
A `MODIFIED` requirement replaces the whole requirement block, so it has to carry every scenario that survives the change, not only the ones you edited. Copy the named scenarios from `openspec/specs/<capability-path>/spec.md` back into the delta, preserving any domain directories in the path. This often appears on an older change after someone else's change added a scenario to the same requirement — archive refuses that change either way, and validation now says so before you implement it.
|
||||
|
||||
### The AI created incomplete or wrong artifacts
|
||||
|
||||
The AI didn't have enough context. A few levers help:
|
||||
|
||||
- Add project context in `openspec/config.yaml` so your stack and conventions are injected into every request. See [Customization](customization.md#project-configuration).
|
||||
- Add per-artifact `rules:` for guidance that only applies to, say, specs.
|
||||
- Give a more detailed description when you propose.
|
||||
- Use the expanded `/opsx:continue` to create one artifact at a time and review each, instead of `/opsx:ff` doing them all at once.
|
||||
|
||||
### Archive won't finish, or warns about incomplete tasks
|
||||
|
||||
Archive won't *block* on incomplete tasks, but it warns you, because archiving usually means the work is done. If tasks remain on purpose (you're filing a partial change), proceed. Otherwise finish the tasks first. Archive will also offer to sync your delta specs into the main specs if you haven't synced yet; say yes unless you have a reason not to.
|
||||
|
||||
### "User force closed the prompt with 0 null"
|
||||
|
||||
Something ran `openspec archive` where nothing can answer a question — an AI agent calling it from a tool, a CI job, or any shell with stdin closed. Archive asks up to three confirmations, and an unanswerable one used to fail with that raw message.
|
||||
|
||||
Pass `--yes` to answer them up front:
|
||||
|
||||
```bash
|
||||
openspec archive <change-name> --yes
|
||||
```
|
||||
|
||||
Keep any flags you were already passing — `--skip-specs` and `--no-validate` change what archive does, so a bare `--yes` rerun is not the same command. Current versions name the flag for you and print a `Fix:` line you can paste. If you meant to pick from a list, pass the change name explicitly: the picker needs an answer too.
|
||||
|
||||
If you instead ran archive with its output redirected to a file or captured by a tool and *did* pipe an answer (`printf 'y\n' | openspec archive …`), older versions wrote terminal escape codes into that capture while drawing the prompt — in some environments enough to bloat the file badly. Current versions read the confirmation prompts as plain text whenever stdout is not a terminal, and a no-argument `openspec archive` (which would otherwise draw an interactive change picker) asks you to pass a change name up front instead of rendering a menu into the capture. Either way, redirected and agent runs stay clean; passing `--yes` (with a change name) skips the prompts entirely.
|
||||
|
||||
## Configuration
|
||||
|
||||
### My `config.yaml` isn't being applied
|
||||
|
||||
Three usual suspects:
|
||||
|
||||
1. **Wrong filename.** It must be `openspec/config.yaml`, not `.yml`.
|
||||
2. **Invalid YAML.** Run it through any YAML validator; the CLI also reports syntax errors with line numbers.
|
||||
3. **You expected a restart.** You don't need one. Config changes take effect immediately.
|
||||
|
||||
### "Unknown artifact ID in rules: X"
|
||||
|
||||
A key under `rules:` doesn't match any artifact in your schema. For the default `spec-driven` schema the valid IDs are `proposal`, `specs`, `design`, `tasks`. To see the IDs for any schema:
|
||||
|
||||
```bash
|
||||
openspec schemas --json
|
||||
```
|
||||
|
||||
### "Context too large"
|
||||
|
||||
The `context:` field is capped at 50KB, on purpose, because it's injected into every request. Summarize it, or link out to longer docs instead of pasting them. Lean context also produces better, faster results.
|
||||
|
||||
### "Schema not found"
|
||||
|
||||
The schema name you referenced doesn't exist. List what's available and check spelling:
|
||||
|
||||
```bash
|
||||
openspec schemas # list available schemas
|
||||
openspec schema which <name> # see where a schema resolves from
|
||||
openspec schema init <name> # create a custom one
|
||||
```
|
||||
|
||||
See [Customization](customization.md#custom-schemas).
|
||||
|
||||
## Migration from the legacy workflow
|
||||
|
||||
### "Legacy files detected in non-interactive mode"
|
||||
|
||||
You're in CI or a non-interactive shell, and OpenSpec found old files to clean up but can't prompt you. Approve automatically:
|
||||
|
||||
```bash
|
||||
openspec init --force
|
||||
```
|
||||
|
||||
For Codex, OpenSpec may detect old managed prompt files in `$CODEX_HOME/prompts` or `~/.codex/prompts`. That cleanup is limited to OpenSpec's allowlisted legacy Codex prompt filenames, and non-interactive `openspec init` removes only the files whose replacement `.agents/skills/openspec-*` skills exist. Non-interactive `openspec update` leaves all legacy cleanup untouched unless you pass `--force`.
|
||||
|
||||
### Commands didn't appear after migrating
|
||||
|
||||
Restart your IDE. Skills are detected at startup. If they still don't appear, run `openspec update` and check the file locations in [Supported Tools](supported-tools.md).
|
||||
|
||||
### My old `project.md` wasn't migrated
|
||||
|
||||
That's intentional. OpenSpec never deletes `project.md` automatically because it may hold context you wrote. Move the useful parts into `config.yaml`'s `context:` section, then delete it yourself. The [Migration Guide](migration-guide.md#migrating-projectmd-to-configyaml) walks through this, including a prompt you can hand to your AI to do the distilling.
|
||||
|
||||
## Still stuck?
|
||||
|
||||
- **Discord:** [discord.gg/YctCnvvshC](https://discord.gg/YctCnvvshC)
|
||||
- **GitHub Issues:** [github.com/Fission-AI/OpenSpec/issues](https://github.com/Fission-AI/OpenSpec/issues)
|
||||
- **From your terminal:** `openspec feedback "what went wrong"` opens an issue for you.
|
||||
|
||||
When you report a problem, include your OpenSpec version (`openspec --version`), your Node version (`node --version`), your AI tool, and the exact command and output. It makes help much faster.
|
||||
+5
-106
@@ -28,123 +28,25 @@ OPSX (fluid actions):
|
||||
|
||||
> **Customization:** OPSX workflows are driven by schemas that define artifact sequences. See [Customization](customization.md) for details on creating custom schemas.
|
||||
|
||||
## Workflow at a Glance
|
||||
|
||||
The default workflow stays fluid: exploration and verification are optional, and
|
||||
you can update planning artifacts whenever implementation reveals something new.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Idea["Idea or problem"] --> Explore["/opsx:explore<br/>(optional)"]
|
||||
Idea --> Propose["/opsx:propose"]
|
||||
Explore --> Propose
|
||||
Propose --> Review{"Planning artifacts<br/>ready?"}
|
||||
Review -->|"Refine"| Update["/opsx:update"]
|
||||
Update --> Review
|
||||
Review -->|"Implement"| Apply["/opsx:apply"]
|
||||
Apply -->|"Plan changed"| Update
|
||||
Apply --> Archive["/opsx:archive"]
|
||||
Apply --> Verify["/opsx:verify<br/>(optional, custom selection)"]
|
||||
Apply --> Sync["/opsx:sync<br/>(optional before archive)"]
|
||||
Verify --> Verified{"Ready to archive?"}
|
||||
Verified -->|"Fix implementation"| Apply
|
||||
Verified -->|"Revise plan"| Update
|
||||
Verified -->|"Ready"| Sync
|
||||
Verified -->|"Ready"| Archive
|
||||
Sync --> Archive
|
||||
```
|
||||
|
||||
The AI assistant drives the workflow, while the CLI provides deterministic
|
||||
scaffolding, status, and artifact instructions:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
actor Human
|
||||
participant Assistant as AI assistant
|
||||
participant CLI as OpenSpec CLI
|
||||
participant Files as Planning and implementation files
|
||||
|
||||
Human->>Assistant: /opsx:propose "change"
|
||||
Assistant->>CLI: openspec new change
|
||||
CLI->>Files: Scaffold change metadata
|
||||
Assistant->>CLI: Request status and artifact instructions
|
||||
CLI-->>Assistant: Build order, paths, and templates
|
||||
Assistant->>Files: Write schema-defined planning artifacts
|
||||
Assistant-->>Human: Present artifacts for review
|
||||
|
||||
Human->>Assistant: /opsx:apply
|
||||
Assistant->>CLI: Request apply instructions
|
||||
CLI-->>Assistant: Context files and task state
|
||||
Assistant->>Files: Implement tasks and update checkboxes
|
||||
Assistant-->>Human: Report implementation status
|
||||
|
||||
Human->>Assistant: /opsx:archive
|
||||
Assistant->>CLI: Request archive inputs and artifact status
|
||||
CLI-->>Assistant: Planning paths and artifact completion
|
||||
Assistant->>Files: Read task state and compare delta specs
|
||||
opt Delta specs exist
|
||||
Assistant-->>Human: Offer to sync before archiving
|
||||
alt Sync accepted
|
||||
Human->>Assistant: Confirm sync
|
||||
Assistant->>Files: Merge delta specs into main specs
|
||||
else Sync skipped
|
||||
Human->>Assistant: Archive without syncing
|
||||
end
|
||||
end
|
||||
Assistant->>Files: Move the change into the archive
|
||||
Assistant-->>Human: Report archive location and sync result
|
||||
|
||||
Note over Human,CLI: CLI alternative: openspec archive change-name --yes skips confirmation prompts. It still validates, then applies any delta specs and archives
|
||||
```
|
||||
|
||||
## Two Modes
|
||||
|
||||
### Default Quick Path (`core` profile)
|
||||
|
||||
New installs default to `core`, which provides:
|
||||
- `/opsx:explore`
|
||||
- `/opsx:propose`
|
||||
- `/opsx:explore`
|
||||
- `/opsx:apply`
|
||||
- `/opsx:update`
|
||||
- `/opsx:sync`
|
||||
- `/opsx:archive`
|
||||
|
||||
Typical flow:
|
||||
|
||||
```text
|
||||
/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
|
||||
(optional)
|
||||
/opsx:propose ──► /opsx:apply ──► /opsx:archive
|
||||
```
|
||||
|
||||
#### Start by exploring (the habit worth forming)
|
||||
|
||||
`/opsx:explore` is part of the default profile, not an advanced add-on. It's the move to make whenever you have a problem but not yet a plan, which, with an AI assistant, is most of the time.
|
||||
|
||||
```text
|
||||
You: /opsx:explore
|
||||
|
||||
AI: What would you like to explore?
|
||||
|
||||
You: Our search results feel stale. I'm not sure if it's caching,
|
||||
indexing, or the query itself.
|
||||
|
||||
AI: Let me look... [reads the search service and cache layer]
|
||||
It's the index: it only rebuilds nightly, so edits don't show
|
||||
up until the next day. Two options: rebuild on write (simple,
|
||||
more load) or a short-TTL cache invalidation (more moving parts,
|
||||
less load). Given your write volume is low, rebuild-on-write is
|
||||
the cleaner fix. Want to scope it?
|
||||
|
||||
You: Yes.
|
||||
|
||||
You: /opsx:propose rebuild-search-index-on-write
|
||||
```
|
||||
|
||||
Explore never writes code, and writes nothing else unless you ask, or say yes when it offers. It's a free, no-stakes conversation that turns a vague worry into a precise change, so the proposal that follows is sharp. Already know exactly what you want? Skip it and go straight to `/opsx:propose`. Full guide: [Explore First](explore.md).
|
||||
|
||||
### Expanded/Full Workflow (custom selection)
|
||||
|
||||
If you want explicit scaffold-and-build commands (`/opsx:new`, `/opsx:continue`, `/opsx:ff`, `/opsx:verify`, `/opsx:bulk-archive`, `/opsx:onboard`), enable them with:
|
||||
If you want explicit scaffold-and-build commands (`/opsx:new`, `/opsx:continue`, `/opsx:ff`, `/opsx:verify`, `/opsx:sync`, `/opsx:bulk-archive`, `/opsx:onboard`), enable them with:
|
||||
|
||||
```bash
|
||||
openspec config profile
|
||||
@@ -493,7 +395,7 @@ AI: Let me investigate your current setup and options...
|
||||
Your current stack suggests #1 or #2. What's your scale?
|
||||
```
|
||||
|
||||
Exploration clarifies thinking before any code gets written.
|
||||
Exploration clarifies thinking before you create artifacts.
|
||||
|
||||
### Verify Before Archiving
|
||||
|
||||
@@ -532,7 +434,7 @@ For full command details and options, see [Commands](commands.md).
|
||||
| Command | Purpose | When to Use |
|
||||
|---------|---------|-------------|
|
||||
| `/opsx:propose` | Create change + planning artifacts | Fast default path (`core` profile) |
|
||||
| `/opsx:explore` | Think through ideas with the AI | Start here when unsure: unclear requirements, investigation, comparing options |
|
||||
| `/opsx:explore` | Think through ideas | Unclear requirements, investigation |
|
||||
| `/opsx:new` | Start a change scaffold | Expanded mode, explicit artifact control |
|
||||
| `/opsx:continue` | Create next artifact | Expanded mode, step-by-step artifact creation |
|
||||
| `/opsx:ff` | Create all planning artifacts | Expanded mode, clear scope |
|
||||
@@ -544,9 +446,6 @@ For full command details and options, see [Commands](commands.md).
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Writing Good Specs](writing-specs.md) - What a strong requirement and scenario look like, and how to right-size a change
|
||||
- [Reviewing a Change](reviewing-changes.md) - The two-minute pass on a drafted plan before any code
|
||||
- [OpenSpec on a Team](team-workflow.md) - How changes fit branches and pull requests
|
||||
- [Commands](commands.md) - Full command reference with options
|
||||
- [Concepts](concepts.md) - Deep dive into specs, artifacts, and schemas
|
||||
- [Customization](customization.md) - Create custom workflows
|
||||
|
||||
@@ -1,103 +0,0 @@
|
||||
# Writing Good Specs
|
||||
|
||||
You rarely write a spec from a blank page. You describe a change in plain language, `/opsx:propose` drafts the requirements and scenarios, and then you make them good. This page is about that last part — what "good" looks like, and how to steer the AI toward it.
|
||||
|
||||
It's the companion to [Reviewing a Change](reviewing-changes.md): reviewing is catching the weak spots in a draft, writing is knowing what a strong one is made of.
|
||||
|
||||
## A spec is behavior, not code
|
||||
|
||||
A spec says what your system *does*, in terms anyone could check — not how it's built. It's made of **requirements** (statements of behavior) and **scenarios** (concrete examples that prove them).
|
||||
|
||||
```markdown
|
||||
### Requirement: Session Timeout
|
||||
The system SHALL expire a session after 30 minutes of inactivity.
|
||||
|
||||
#### Scenario: Idle timeout
|
||||
- GIVEN an authenticated session
|
||||
- WHEN 30 minutes pass with no activity
|
||||
- THEN the session is invalidated and the user must re-authenticate
|
||||
```
|
||||
|
||||
Keep the *how* — the queue, the library, the table schema — in `design.md` or the code. When behavior and implementation get mixed into one requirement, the requirement stops being testable and starts going stale the moment the code changes.
|
||||
|
||||
## What makes a good requirement
|
||||
|
||||
A good requirement is one behavior, stated so plainly you could hand it to someone else to test.
|
||||
|
||||
- **One statement, one `SHALL`/`MUST`.** If a requirement has three "and also" clauses, it's really three requirements. Split them.
|
||||
- **Observable.** Someone outside the code should be able to tell whether it holds. "The system SHALL show an error banner when the upload exceeds 10 MB" is observable. "The system SHALL handle large uploads gracefully" is not.
|
||||
- **The right strength.** OpenSpec uses the RFC 2119 keywords, and they mean different things:
|
||||
|
||||
| Keyword | Meaning |
|
||||
|---------|---------|
|
||||
| `MUST` / `SHALL` | A hard requirement. Non-negotiable. |
|
||||
| `SHOULD` | A strong recommendation, with room for a justified exception. |
|
||||
| `MAY` | Genuinely optional. |
|
||||
|
||||
Reach for `MUST`/`SHALL` by default. Use `SHOULD` only when you truly mean "unless there's a good reason not to."
|
||||
|
||||
The test for a requirement: *could a tester who's never seen the code tell whether it passed?* If not, it needs sharpening.
|
||||
|
||||
## What makes a good scenario
|
||||
|
||||
Scenarios are where a requirement earns its keep. Each one is a concrete GIVEN / WHEN / THEN that could become an automated test.
|
||||
|
||||
- **It exercises its requirement.** A scenario that just restates the requirement in other words tests nothing. Make it a specific situation with a specific outcome.
|
||||
- **Cover the cases that matter, not just the happy path.** The valid login is easy. The empty input, the expired token, the second click, the thing that goes wrong — those are where bugs live, and where a scenario is worth the most.
|
||||
- **Name the case in the title.** "Scenario: Rejects an expired token" tells a reviewer what's covered at a glance; "Scenario: Test 2" doesn't.
|
||||
|
||||
A useful habit: before approving, ask *what's the one case I'd be upset to see broken?* — and make sure a scenario names it.
|
||||
|
||||
## Pick the right kind of delta
|
||||
|
||||
A change describes its edits to the specs with three section types. Using the right one keeps your archived specs honest:
|
||||
|
||||
- **`## ADDED Requirements`** — brand-new behavior that didn't exist before.
|
||||
- **`## MODIFIED Requirements`** — behavior that already existed and is changing. Include the full new version; a short note on what changed helps a reviewer.
|
||||
- **`## REMOVED Requirements`** — behavior going away, with a line on why.
|
||||
|
||||
On archive, ADDED gets appended to the main spec, MODIFIED replaces the old version, and REMOVED is dropped from it. Remove the last requirement a capability has and you retire it: rather than leave a spec with nothing in it, archive deletes `openspec/specs/<capability>/spec.md`. Because that is the one archive step that removes a file, it has to be asked for — add `retire_capabilities: true` to the change's `.openspec.yaml`, alongside the `schema:` that file already needs. Without it the archive aborts and tells you so. Retirement deletes the whole file, so it is also refused while the spec holds anything outside its title, `## Purpose`, and its requirement blocks — a `## Notes` section, a comment under a requirement. The abort names those lines; move them into `## Purpose` or a requirement, or delete the spec by hand. For a spec in the caller's checkout, the archive output also names the `git checkout` that restores a committed file; selected stores receive checkout-scoped recovery guidance instead. If you mark a real change as ADDED, you end up with two competing requirements; if you describe new behavior as MODIFIED, there's nothing to replace. When in doubt, open the current spec and see whether the requirement is already there.
|
||||
|
||||
One more section is worth knowing about. When your delta creates a capability that doesn't exist yet, open it with `## Purpose` — a sentence or two on what the capability is for. Archive uses it as the Purpose of the main spec it creates; skip it and you get a `TBD` placeholder to fill in by hand. An existing spec already has a Purpose, so a delta's is ignored there — edit `openspec/specs/<capability-path>/spec.md` directly to change one. Here, `<capability-path>` is the directory relative to `specs/`, such as `user-auth` in a flat project or `identity/user-auth` in a project organized by domain.
|
||||
|
||||
## Right-size the change
|
||||
|
||||
The single most common authoring mistake isn't a badly worded requirement — it's a change that's trying to be three changes.
|
||||
|
||||
**A good change has one intent you can say in a sentence.** "Add a dark-mode toggle." "Rate-limit the login endpoint." "Migrate sessions off cookies." If describing the change needs a lot of "and also," that's the signal to split it.
|
||||
|
||||
Signs a change is too big:
|
||||
|
||||
- The proposal's scope reads like a list of unrelated features.
|
||||
- Reviewing it would take an afternoon, so nobody will.
|
||||
- Two people couldn't work on it without colliding.
|
||||
- Half the tasks could ship on their own.
|
||||
|
||||
Smaller changes are easier to review, easier to build in one focused session, and easier to reason about six months later when the archive is all that's left. You can always run several changes in parallel — see [Editing & iterating](editing-changes.md) and [Workflows](workflows.md).
|
||||
|
||||
The opposite also happens: a one-line typo fix doesn't need three requirements and a design doc. Match the ceremony to the stakes.
|
||||
|
||||
## How to steer the AI toward a good draft
|
||||
|
||||
Because `/opsx:propose` does the first draft, the quality of what you get back tracks the quality of what you give it. You don't have to write requirements by hand — you have to aim the AI well:
|
||||
|
||||
- **State the intent and the boundary.** *"Add a dark-mode toggle that follows the OS setting on first load — don't touch the existing theme API."* The out-of-scope half matters as much as the in-scope half.
|
||||
- **Name the cases you care about.** *"Make sure there's a scenario for a user who already picked a theme manually."* The AI covers what you point at.
|
||||
- **Then edit.** It's plain Markdown. Tighten a vague `SHALL`, delete a scenario that tests nothing, add the case it missed — or ask the AI to: *"the timeout requirement is vague, pin it to 30 minutes."*
|
||||
|
||||
Draft, sharpen, repeat. A few rounds of that produces a spec you'd trust, which is the whole point.
|
||||
|
||||
## A quick checklist
|
||||
|
||||
- [ ] Each requirement is one observable behavior with a `SHALL`/`MUST`.
|
||||
- [ ] No implementation details are baked into the requirements.
|
||||
- [ ] Every requirement has at least one scenario that actually exercises it.
|
||||
- [ ] The important edge and error cases have scenarios, not just the happy path.
|
||||
- [ ] Deltas use ADDED / MODIFIED / REMOVED correctly against the current spec.
|
||||
- [ ] The whole change has one intent you can state in a sentence.
|
||||
|
||||
## Where to go next
|
||||
|
||||
- [Reviewing a Change](reviewing-changes.md) — the two-minute pass that catches what slipped through.
|
||||
- [Concepts](concepts.md) — the deeper model behind specs, changes, and deltas.
|
||||
- [Examples & Recipes](examples.md) — real changes from start to finish.
|
||||
@@ -15,98 +15,70 @@
|
||||
"aarch64-darwin"
|
||||
];
|
||||
|
||||
forAllSystems = f: nixpkgs.lib.genAttrs supportedSystems f;
|
||||
|
||||
pkgsFor =
|
||||
system:
|
||||
import nixpkgs {
|
||||
inherit system;
|
||||
overlays = [ self.overlays.default ];
|
||||
};
|
||||
forAllSystems = f: nixpkgs.lib.genAttrs supportedSystems (system: f system);
|
||||
in
|
||||
{
|
||||
overlays.default = final: _prev: {
|
||||
openspec = final.stdenv.mkDerivation (finalAttrs: {
|
||||
pname = "openspec";
|
||||
version = (builtins.fromJSON (builtins.readFile ./package.json)).version;
|
||||
|
||||
src = final.lib.fileset.toSource {
|
||||
root = ./.;
|
||||
fileset = final.lib.fileset.unions [
|
||||
./src
|
||||
./bin
|
||||
./schemas
|
||||
./scripts
|
||||
./test
|
||||
./package.json
|
||||
./pnpm-lock.yaml
|
||||
./pnpm-workspace.yaml
|
||||
./tsconfig.json
|
||||
./build.js
|
||||
./vitest.config.ts
|
||||
./vitest.setup.ts
|
||||
./eslint.config.js
|
||||
];
|
||||
};
|
||||
|
||||
pnpmDeps = final.fetchPnpmDeps {
|
||||
inherit (finalAttrs) pname version src;
|
||||
pnpm = final.pnpm_10;
|
||||
fetcherVersion = 3;
|
||||
hash = "sha256-gPGdwmj4oLb/j3D/BGNCaI0hFfrHKCjH4I71UYzmhfk=";
|
||||
};
|
||||
|
||||
nativeBuildInputs = with final; [
|
||||
installShellFiles
|
||||
nodejs_22
|
||||
npmHooks.npmInstallHook
|
||||
pnpmConfigHook
|
||||
pnpm_10
|
||||
];
|
||||
|
||||
buildPhase = ''
|
||||
runHook preBuild
|
||||
|
||||
pnpm run build
|
||||
|
||||
runHook postBuild
|
||||
'';
|
||||
|
||||
dontNpmPrune = true;
|
||||
|
||||
# `openspec completion generate` renders a static command registry, so it
|
||||
# needs no project and no network. Opting out of telemetry also disables
|
||||
# the update check, keeping the build offline.
|
||||
postInstall = final.lib.optionalString (final.stdenv.buildPlatform.canExecute final.stdenv.hostPlatform) ''
|
||||
export OPENSPEC_TELEMETRY=0
|
||||
completions=$(mktemp -d)
|
||||
for shell in bash fish zsh; do
|
||||
$out/bin/openspec completion generate "$shell" > "$completions/openspec.$shell"
|
||||
done
|
||||
installShellCompletion --cmd openspec \
|
||||
--bash "$completions/openspec.bash" \
|
||||
--fish "$completions/openspec.fish" \
|
||||
--zsh "$completions/openspec.zsh"
|
||||
'';
|
||||
|
||||
meta = with final.lib; {
|
||||
description = "AI-native system for spec-driven development";
|
||||
homepage = "https://github.com/Fission-AI/OpenSpec";
|
||||
license = licenses.mit;
|
||||
maintainers = [ ];
|
||||
mainProgram = "openspec";
|
||||
};
|
||||
});
|
||||
};
|
||||
|
||||
packages = forAllSystems (
|
||||
system:
|
||||
let
|
||||
pkgs = pkgsFor system;
|
||||
pkgs = nixpkgs.legacyPackages.${system};
|
||||
inherit (pkgs) lib;
|
||||
in
|
||||
{
|
||||
default = pkgs.openspec;
|
||||
inherit (pkgs) openspec;
|
||||
default = pkgs.stdenv.mkDerivation (finalAttrs: {
|
||||
pname = "openspec";
|
||||
version = (builtins.fromJSON (builtins.readFile ./package.json)).version;
|
||||
|
||||
src = lib.fileset.toSource {
|
||||
root = ./.;
|
||||
fileset = lib.fileset.unions [
|
||||
./src
|
||||
./bin
|
||||
./schemas
|
||||
./scripts
|
||||
./test
|
||||
./package.json
|
||||
./pnpm-lock.yaml
|
||||
./tsconfig.json
|
||||
./build.js
|
||||
./vitest.config.ts
|
||||
./vitest.setup.ts
|
||||
./eslint.config.js
|
||||
];
|
||||
};
|
||||
|
||||
pnpmDeps = pkgs.fetchPnpmDeps {
|
||||
inherit (finalAttrs) pname version src;
|
||||
pnpm = pkgs.pnpm_9;
|
||||
fetcherVersion = 3;
|
||||
hash = "sha256-9s2kdvd7svK4hofnD66HkDc86WTQeayfF5y7L2dmjNg=";
|
||||
};
|
||||
|
||||
nativeBuildInputs = with pkgs; [
|
||||
nodejs_20
|
||||
npmHooks.npmInstallHook
|
||||
pnpmConfigHook
|
||||
pnpm_9
|
||||
];
|
||||
|
||||
buildPhase = ''
|
||||
runHook preBuild
|
||||
|
||||
pnpm run build
|
||||
|
||||
runHook postBuild
|
||||
'';
|
||||
|
||||
dontNpmPrune = true;
|
||||
|
||||
meta = with pkgs.lib; {
|
||||
description = "AI-native system for spec-driven development";
|
||||
homepage = "https://github.com/Fission-AI/OpenSpec";
|
||||
license = licenses.mit;
|
||||
maintainers = [ ];
|
||||
mainProgram = "openspec";
|
||||
};
|
||||
});
|
||||
}
|
||||
);
|
||||
|
||||
@@ -125,8 +97,8 @@
|
||||
{
|
||||
default = pkgs.mkShell {
|
||||
buildInputs = with pkgs; [
|
||||
nodejs_22
|
||||
pnpm_10
|
||||
nodejs_20
|
||||
pnpm_9
|
||||
];
|
||||
|
||||
shellHook = ''
|
||||
|
||||
-70
@@ -1,70 +0,0 @@
|
||||
# openspec
|
||||
|
||||
> OpenSpec gives you and your coding agent a shared, reviewable plan before code is written. This file installs its CLI and sets up your project.
|
||||
|
||||
I want you to install OpenSpec and set up my project. Follow the steps below in order, and stop where a step tells you to stop.
|
||||
|
||||
OBJECTIVE: Install the OpenSpec CLI globally and initialize the user's project.
|
||||
|
||||
DONE WHEN:
|
||||
|
||||
- `openspec --version` prints a version number
|
||||
- the project the user confirmed has an `openspec/` folder created or refreshed by `openspec init`
|
||||
- the user has been told the exact spelling to invoke OpenSpec in their AI coding tool
|
||||
|
||||
TODO:
|
||||
|
||||
- [ ] Check the Node.js runtime
|
||||
- [ ] Install the CLI globally, with the user's confirmation
|
||||
- [ ] Verify `openspec` is on PATH
|
||||
- [ ] Confirm which folder to set up, then run `openspec init --tools <ids>` there
|
||||
- [ ] Report what init actually created and how to invoke it
|
||||
|
||||
## 1. Runtime
|
||||
|
||||
Run `node --version`. OpenSpec needs Node.js 20.19.0 or higher. If Node is missing or older, say so and stop, but leave the user with their next move: point them at https://nodejs.org, or if they use a version manager like nvm, name the command that would switch to a newer version. Don't install Node, switch versions, or reconfigure the user's version manager yourself.
|
||||
|
||||
## 2. Install
|
||||
|
||||
Run `openspec --version` first. If it already prints a version, the CLI is installed: say so, offer to update it with the install command below, and if the user declines skip ahead to step 4.
|
||||
|
||||
Use whichever package manager is already on PATH, preferring npm:
|
||||
|
||||
```bash
|
||||
npm install -g @fission-ai/openspec@latest
|
||||
pnpm add -g @fission-ai/openspec@latest
|
||||
bun add --global @fission-ai/openspec@latest
|
||||
yarn global add @fission-ai/openspec@latest # Yarn 1.x only
|
||||
```
|
||||
|
||||
Don't pick based on this project's lockfile: a global install has nothing to do with how this repo's own dependencies are installed. If none of those four is available, stop and say so; don't improvise an install. (On Nix, point the user at the Nix section of https://openspec.dev/docs/installation instead.)
|
||||
|
||||
Show the exact command and get confirmation before running it; this installs software outside the project, and the user may want a different package manager to own it.
|
||||
|
||||
Stop and ask again if the install needs sudo or admin rights, fails with a permissions error, or reports that its global bin directory is missing or unconfigured. Never edit shell startup files (.bashrc, .zshrc, .profile, fish, PowerShell profile), and never run a setup command that edits them; show the change and let the user make it.
|
||||
|
||||
## 3. PATH
|
||||
|
||||
Run `openspec --version`. If the command isn't found, it may only be missing from this shell: say where the package manager installed it and how to add that directory to PATH for the user's shell and OS, then stop until they confirm. If it prints an older version than the one the install just reported, an earlier copy is shadowing it on PATH; report both versions instead of continuing. If the user uses a version manager, say so rather than editing PATH around it: with nvm or fnm the CLI is tied to the Node version that was active at install time, and with asdf or volta a shim may need regenerating.
|
||||
|
||||
## 4. Initialize
|
||||
|
||||
Work out where `openspec/` should go, and lead with your best guess rather than an open question: the root of the project the user is working in is almost always right. Name the folder you picked and let them correct it, for example "you're in ~/code/acme-api, so I'll set OpenSpec up there". Prefer the version control root over the current directory, and in a monorepo say which package you chose and why. To target a folder other than the current one, pass it: `openspec init <path> --tools <ids>`.
|
||||
|
||||
init creates `openspec/` wherever you point it and won't warn you when that's wrong. If the folder is a home directory, a temp directory, or holds no project at all, stop and ask where the project is.
|
||||
|
||||
Then work out which AI coding tools the user works with, and again lead with an inference instead of an open question: you are probably running inside one of them, so name it and ask what else they use, suggesting a few common options (Claude Code, Cursor, Copilot, Codex). Say what the answer changes: each tool named gets its own skill and command files in the project, and re-running init later adds more, so a short list now costs nothing. Map each tool to an id from `openspec init --help` (Copilot is `github-copilot`, Zoo Code is `roocode`). `--tools` takes a comma-separated list, so name all of them.
|
||||
|
||||
`openspec init --tools <ids>` deletes leftovers from older OpenSpec versions automatically, without asking, including `opsx-*.md` prompt files in the home directory (Codex keeps them in `~/.codex/prompts`). Before running it, look for those: `.../commands/openspec/` folders, OpenSpec marker blocks in files like CLAUDE.md or AGENTS.md, and home-directory `opsx-*.md` prompts. List whatever you find, say plainly that init will delete these, and wait for a go-ahead; if you find nothing, say so and carry on without asking. An existing `openspec/` folder is not a problem: init refreshes it and leaves specs and changes alone.
|
||||
|
||||
Then run: `openspec init --tools <ids>`, adding the path when it isn't the current folder.
|
||||
|
||||
## 5. Report
|
||||
|
||||
Don't assume what should exist; relay what init actually printed: how many skills and/or commands it created and where, the config file line, any "Setup required" note, and what to restart or reload. Some tools are skills-only and correctly create zero command files, so missing commands is not a failure on its own. If init said nothing was generated, relay the fix it suggested instead of retrying.
|
||||
|
||||
Finish by telling the user how to invoke OpenSpec in their tool, taking the exact spelling from the files init created rather than from its summary line: the punctuation differs per tool (`/opsx:propose` in some, `/opsx-propose` in others, `@opsx-propose` in Amazon Q), and tools that get skills instead of commands are invoked by skill name (`/openspec-propose`, or `$openspec-propose` in Codex, or `/skill:openspec-propose` in Kimi Code).
|
||||
|
||||
EXECUTE NOW: Complete the TODO list above to achieve: the OpenSpec CLI installed, this project initialized, and the user told exactly how to invoke OpenSpec in their AI coding tool.
|
||||
|
||||
More context for agents: https://openspec.dev/llms.txt
|
||||
@@ -1,2 +0,0 @@
|
||||
schema: spec-driven
|
||||
created: 2025-12-29
|
||||
@@ -1,31 +0,0 @@
|
||||
## Why
|
||||
|
||||
Amp reads project skills from `.agents/skills/`, but OpenSpec does not list Amp in its tool picker or accept `amp` through `--tools`. Amp users can select the universal `.agents` target, but only if they already know how Amp discovers skills.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Add Amp as a supported skills-only tool with `amp` as its tool id.
|
||||
- Generate Amp's OpenSpec skills through the existing shared `.agents/skills/` pipeline.
|
||||
- Detect Amp projects from `.amp/` and recognize Amp-owned OpenSpec skill trees during update.
|
||||
- Document Amp's paths and invocation syntax in the docs-lab supported-tools reference.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
|
||||
_None._
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
- `ai-tool-paths`: define Amp's shared Agent Skills path and skills-only behavior.
|
||||
|
||||
## Impact
|
||||
|
||||
- `src/core/config.ts`: add the Amp tool metadata.
|
||||
- `test/core/init.test.ts`, `test/core/update.test.ts`, and `test/core/available-tools.test.ts`: cover generation, refresh, and detection.
|
||||
- `docs-lab/reference/supported-tools.md`: add Amp to the support matrix and shared-folder notes.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Adding an Amp command adapter. Amp's supported project extension surface is Agent Skills.
|
||||
- Adding a second Amp-specific skill generator or template set.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user