@jspg-ai/coding-bb 0.0.3-beta.6 → 0.0.3-beta.8

package/config/openspec/schemas/spec-driven/schema.yaml

@@ -17,15 +17,15 @@ artifacts:
       2. 拿到用户输入后，整理并复述目标，**让用户确认**理解是否正确。未确认前禁止进入下一阶段。
       3. 信息不足或目标模糊时，继续追问，直到目标清晰无歧义。
 
-      ### 阶段二：查阅知识库（需求确认后，代码扫描前）
+      ### 阶段二：收集参考材料（需求确认后，代码扫描前）
 
-      1. 询问用户是否有知识库、参考文档等可提供。
-      2. 若有知识库：通过 INDEX.md（路径见 CLAUDE.md "知识库" 章节）按层级进入。从 INDEX.md → 域索引 → 子域 → 知识条目。仅跟随索引中的已有链接，**禁止 glob 或全库搜索**。记录每个被引用的文档。
-      3. 若无知识库或 INDEX.md 不存在：记录"知识库暂无覆盖"，直接进入阶段三，**禁止编造或强行搜索**。
+      1. 用 AskUserQuestion 询问用户：除 PRD 外还有哪些参考材料（设计文档、WIKI 链接、历史方案等）？
+      2. 用户指认了文档/目录：定向阅读所指范围。指认到目录级时，可浏览该目录内的文件名并阅读相关文档；目录之外的内容与全库 glob 搜索仍然禁止。
+      3. 无参考材料：记录"暂无参考文档"，直接进入阶段三，禁止凭空编造背景信息。
 
-      ### 阶段三：扫描代码（带着确认后的目标 + 知识库结果去扫）
+      ### 阶段三：扫描代码（带着确认后的目标 + 参考材料去扫）
 
-      1. 以阶段一确认的目标和阶段二收集的知识库为上下文，扫描代码库。
+      1. 以阶段一确认的目标和阶段二收集的参考材料为上下文，扫描代码库。
       2. 只扫与本次需求相关的入口类/方法、已有实现、依赖链。**禁止无目标的全库扫描**。
       3. 扫描结果应直接支撑「四、代码改动清单」的编写。
 
@@ -37,7 +37,7 @@ artifacts:
       - **禁止推测**：需求细节必须来自上述三阶段的产出；信息不足时回退到对应阶段补充
       - **来源标注**：一、为什么 / 二、变更简述 / 三、变更清单 / 四、代码改动清单 / 五、影响 中每一条断言后附来源，示例：
         - "（来自 PRD §3.2）"
-        - "（知识库: myb-user-domain/auth-flow.md）"
+        - "（文档: docs/design/auth-flow.md）"
         - "（代码: com.x.user.facade.UserFacade#resetPassword）"
       - **存疑必问，禁止猜测**：撰写过程中遇到以下情况，必须暂停并用 AskUserQuestion 让用户决策，禁止自行假设后继续：
         - 需求逻辑不合理或自相矛盾
@@ -45,18 +45,17 @@ artifacts:
         - 存在潜在风险（资损、性能、兼容性、安全）
         - 多种可行方案各有取舍
         每次向用户确认后，将决策逐条记录到「六、决策记录」表格中。
-      - **知识库引用**还应一并带到 design.md 的"知识库参考"章节
 
       章节（顺序：动机 → 变更简述 → 能力契约 → 代码入口 → 影响 → 决策记录；每章带中文数字序号）：
       - **一、为什么**（必选）：1-3 句话说清问题或机会。要解决什么？为什么是现在？
-      - **二、变更简述**（必选）：1-5 句话最精简易读地描述本需求要做的事情
+      - **二、变更简述**（必选）：1-3 句话最精简易读地描述本需求要做的事情。破坏性变更（接口不兼容、数据结构破坏等）在句尾标注 **BREAKING**
       - **三、变更清单**（必选）：能力维度的变更盘点（新增 / 修改 / 删除）。每个能力对应 `openspec/specs/<name>/spec.md`。identifier 与中文名解耦
         - **identifier 与展示名解耦**：identifier 列（`能力名` / `现有 spec 名` / `已废弃 spec 名`）填英文 kebab-case（用于 path / CLI / 跨引用），新增一列 `中文名` 填人类阅读用名
         - **新增能力**：每个对应一份新建 `specs/<name>/spec.md`
-        - **修改能力**：每个对应一份 delta spec 文件
+        - **修改能力**：每个对应一份 delta spec 文件。仅限 spec 级行为变化——纯实现细节重构不算，避免生成无意义 delta
         - **删除能力**：整段能力下线。spec 文件保留并写 `## REMOVED Requirements` 段，避免后续误用
       - **四、代码改动清单**（必选）：每个代码入口一行。
-        - **必须基于实际扫代码 + 读知识库得出，禁止凭 PRD 直接推测**
+        - **必须基于实际扫代码 + 读参考文档得出，禁止凭 PRD 直接推测**
         - 字段：应用 / 变更类型 / 代码入口类型 / 代码入口 / 所属能力 / 变更简述 / 备注
         - 后端 代码入口类型 仅允许：rpc / rest / mq / job / sql / config / constant / enum
         - 前端 代码入口类型 固定为 `前端`；代码入口列允许 `文件路径 —— 简短描述` 自然语言
@@ -67,7 +66,14 @@ artifacts:
       - **五、影响**（必选）：列出受影响的代码、接口、依赖、上下游系统。**复杂影响分析**（灰度步骤、回滚方案、跨团队协作）进入 § design 阶段
       - **六、决策记录**（必选）：撰写过程中向用户确认过的每个决策点，逐条填入表格。字段：序号 / 决策点 / 用户决策 / 影响。无决策则填一行"无"
 
-      重要：变更清单章节是 proposal 与 spec 阶段的契约核心。动笔前先研究现有 spec。每列出的能力都对应一份 spec 文件。
+      重要：变更清单章节是 proposal 与 spec 阶段的契约核心。动笔前先研究现有 spec，禁止凭空起名：
+      1. `openspec list --specs` 拉取项目能力清单
+      2. 对疑似相关的 spec 先用 `openspec show "<spec-id>" --type spec --json --no-scenarios` 概览（返回能力用途与需求文本，不拉全文）
+      3. 决定增改前，对相关 spec 全文阅读：`openspec show "<spec-id>" --type spec`（含 scenarios）
+      4. 修改能力必须复用 `openspec/specs/` 下已有能力的准确路径，禁止引入近似重复名
+      每列出的能力都对应一份 spec 文件。
+
+      零能力变更的处理：若本次变更不涉及任何能力（纯重构、工具、文档、纯基础设施改动），变更清单三个子表留空，并在 change 的 `.openspec.yaml` 中设置 `skip_specs: true` —— `openspec validate` 会拒绝零 delta 的 change，该标记是唯一出口。禁止为通过校验编造能力或需求。
 
       保持简洁（1-2 页）。专注"为什么"而非"怎么做"——实现细节归 design.md。
 
@@ -105,23 +111,9 @@ artifacts:
     instruction: |
       Create the design document that explains HOW to implement the change.
 
-      **Knowledge Base Reference (MANDATORY):**
-      Before writing design, you MUST consult the project's knowledge base:
-      1. Read the knowledge base root INDEX.md (path defined in CLAUDE.md under "知识库")
-      2. Navigate from INDEX.md → relevant domain index → sub-domain → knowledge chunks
-      3. Collect all knowledge documents relevant to this change's design sections
-      4. Fill the "知识库参考" section in the template with: knowledge point name, full file path, corresponding design section
-      5. If a design section has no matching knowledge base coverage, note it as "知识库暂无覆盖，建议补充"
-
-      Knowledge-to-design-section mapping reference:
-      - 需求背景 → business domain indexes (myb-*-domain/)
-      - 架构设计 → application indexes (project/<app>/)
-      - 领域模型设计 → domain indexes (myb-*-domain/)
-      - 核心流程设计 → domain knowledge chunks
-      - 数据库模型 → application indexes + domain knowledge
-      - MQ设计 → domain knowledge chunks
-      - 稳定性设计 → tech-asset/tech-gray/
-      - 防资损设计 → domain knowledge chunks
+      **Reference documents:**
+      Build on the reference documents gathered during the proposal phase (see its source annotations, e.g. "（文档: …）").
+      If the design needs additional documents, ask the user to designate them (targeted reading only, no repo-wide globbing).
 
       When to include design.md (create only if any apply):
       - Cross-cutting change (multiple services/modules) or new architectural pattern
@@ -130,7 +122,6 @@ artifacts:
       - Ambiguity that benefits from technical decisions before coding
 
       Sections (follow design.md template):
-      - **知识库参考**（必选）：列出本次设计参考的知识库文档路径及对应章节
       - **需求或项目背景**（必选）：问题/目标、PRD/DMPT链接
       - **Checklist事项**（必选）：逐项检查技术风险（新接口、改接口、新枚举、新依赖、新表/MQ、sentinel、敏感数据、SQL、历史兼容、Redis、验签）
       - **功能拆解**（必选）：按模块拆分功能点，标注变更类型和FTAPI

package/config/openspec/schemas/spec-driven/templates/design.md

@@ -12,24 +12,6 @@
 
 ---
 
-## 零、知识库参考（必选）
-
-<!-- AI理解要点：此章节记录本次设计参考了哪些知识库文档，确保设计基于已有知识而非凭空构思。
-     通过知识库索引（INDEX.md）逐级定位后，列出实际读取的知识文档路径。 -->
-
-| 序号 | 参考知识点 | 知识库路径 | 对应设计章节 | 备注 |
-| ---- | ---------- | ---------- | ------------ | ---- |
-| 1    | <!-- 知识点名称 --> | <!-- 从INDEX.md逐级定位的完整路径 --> | <!-- 架构设计/领域模型/... --> | <!-- 参考了什么 --> |
-
-<!-- 知识库导航方式：
-1. 从知识库根索引 INDEX.md 出发
-2. 按业务域/技术域逐级定位到具体知识文档
-3. 将实际读取的文档路径填入上表
-4. 如果某章节无对应知识库文档，在备注中标注"知识库暂无覆盖，建议补充"
--->
-
----
-
 ## 一、需求或项目背景（必选）
 
 <!-- AI理解要点：此章节提供需求的上下文信息，帮助理解业务背景和目标 -->

package/config/openspec/schemas/spec-driven/templates/proposal.md

@@ -2,16 +2,17 @@
 
 <!-- 说明这次变更的动机。要解决什么问题？为什么是现在？ -->
 
-## 二、变更摘要
+## 二、变更简述
 
-<!-- 1-3 句话最精简易读地描述本需求要做的事情。 -->
+<!-- 1-3 句话最精简易读地描述本需求要做的事情。破坏性变更（接口不兼容、数据结构破坏等）在句尾标注 **BREAKING**。 -->
 
 ## 三、变更清单
 
 <!-- 能力维度的变更盘点（新增 / 修改 / 删除）。每个能力对应 `openspec/specs/<name>/spec.md`。
      表格同时承载"能力本身的静态信息（identifier / 中文名 / 简述）"和"本次变更对它的动作"。
      第四章"代码改动清单"是落到代码层的具体改动点。两章通过 identifier 字段双向关联。
-     **identifier 与展示名解耦**：identifier 列填英文 kebab-case（用于 path / CLI / 跨引用）；`中文名` 列填人类阅读用名，可与 identifier 不同。 -->
+     **identifier 与展示名解耦**：identifier 列填英文 kebab-case（用于 path / CLI / 跨引用）；`中文名` 列填人类阅读用名，可与 identifier 不同。
+     零能力变更：三章全部留空（纯重构 / 工具 / 文档 / 纯基础设施），并在 change 的 `.openspec.yaml` 设 `skip_specs: true` —— `openspec validate` 拒绝零 delta 的 change，该标记是唯一出口；禁止为通过校验编造能力。 -->
 
 ### 新增能力
 

package/config/upstream-mirrors.json

@@ -0,0 +1,12 @@
+{
+  "_comment": "维护者拉取上游内容时的镜像前缀列表，按顺序尝试，首个成功即用。空字符串 \"\" 表示直连。",
+  "superpowers": [
+    "https://gh-proxy.com/",
+    "https://ghfast.top/",
+    ""
+  ],
+  "openspec": [
+    "https://registry.npmmirror.com",
+    "https://registry.npmjs.org"
+  ]
+}

package/config/workspace-agents.sample.md

@@ -7,7 +7,7 @@
 
 1. **本目录不做需求开发**。本目录（业务空间主分支）只负责组织与调度；需求开发的**写操作**都在 `.worktrees/worktree-<需求名>/` 隔离目录内进行，**AI 会话仍停在空间根**（worktree 内不装 AI 配置）。
 2. **AI 配置安装在空间根**：编码规范、OpenSpec 命令、worktree 管理技能都装在本目录（`cbb setup` / `cbb update` 安装）；worktree 内**不安装** AI 配置，AI 会话始终以空间根为基础。
-3. **接到新需求先建 worktree**：在本目录执行 `/cbb:worktree-init <需求名>`（opencode 写法：`/cbb-worktree-init`）。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
+3. **接到新需求先建 worktree**：使用 `/cbb-worktree-init <需求名>`（skill 形态，各工具写法见文末），或直接自然语言说"为 <需求名> 创建工作空间"。它会为 `workspace-config.json` 中的全量关联应用同步创建同名 worktree。
 4. **开发命令在本会话执行，写操作指向 worktree**：需求提案 / 实现 / 验证 / 归档（`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:archive`）在空间根会话执行；但所有产生写操作的命令（git commit / openspec / 构建 / 测试 / 文件修改）必须以 `.worktrees/worktree-<需求名>/`（或其应用子目录）为工作目录（显式 `cd` 或绝对路径）；**禁止在空间根（主分支）执行写操作**。
 5. **关联应用增减只改配置**：编辑 `workspace-config.json` 的 `apps` 数组（`name` / `repo` / `side` / `desc`），然后用同一需求名重跑 worktree 初始化即幂等补齐；不要手工 `git clone` 应用仓库。
 6. **不要绕过 worktree 直接修改 `.codespace/` 或本目录的代码**。`.codespace/` 是工具维护的基准代码，不是开发区。
@@ -20,19 +20,19 @@
 | `.codespace/` | 各关联应用的基准代码（每个应用一个子目录） | `cbb setup` 与 worktree 流程自动 clone / fetch；**勿手动编辑**；已 gitignore，不提交 |
 | `.worktrees/` | 需求隔离开发区（每个需求一个 `worktree-<需求名>/` 目录） | worktree 命令自动创建 / 清理；不提交（首次执行 worktree 流程时自动加入 .gitignore） |
 | `openspec/` | OpenSpec 工作流配置（`config.yaml` + `schemas/`） | 由 cbb 安装；需求变更产物（`openspec/changes/` 等）在**需求工作树内**生成，随需求分支提交 |
-| `.claude/` `.qoder/` `.opencode/` `.codebuddy/` `.trae/` | AI 工具适配目录：编码规范规则、OpenSpec 命令、worktree 管理命令 | 由 cbb 按 setup 时选择的工具安装；已 gitignore，不提交，勿手动改 |
-| `.cbb/` | cbb 安装清单 + worktree 运行时（`.cbb/skills/`：流程文档与脚本，各工具命令共用） | 由 cbb 管理；**勿手动编辑** |
+| `.claude/` `.qoder/` `.opencode/` `.codebuddy/` `.trae/` | AI 工具适配目录：编码规范规则、OpenSpec 命令、worktree 管理技能（skill 形态） | 由 cbb 按 setup 时选择的工具安装；已 gitignore，不提交，勿手动改 |
+| `.cbb/` | cbb 安装清单与状态（`.managed-by-cbb`、`.last-tools`） | 由 cbb 管理；**勿手动编辑** |
 
 ## 典型流程
 
 ```
-本目录：/cbb:worktree-init <需求名>
+本目录：对 AI 说"为 <需求名> 创建工作空间"（或 /cbb-worktree-init <需求名>）
   → 继续在当前会话开发：写操作命令以 .worktrees/worktree-<需求名>/ 为工作目录
     （/opsx:propose → /opsx:apply → /opsx:verify → /opsx:archive）
-  → /cbb:worktree-push 推送 → 合并后 /cbb:worktree-close 关闭
+  → 说"提交并推送"（或 /cbb-worktree-push）→ 合并后说"关闭工作空间"（或 /cbb-worktree-close）
 ```
 
-> 命令写法因 AI 工具而异：Claude Code / Qoder / WorkBuddy / Trae 为 `/cbb:worktree-init`、`/opsx:propose`；opencode 因「文件名即命令名」且 Windows 文件名不允许 `:`，扁平化为 `/cbb-worktree-init`、`/opsx-propose`。
+> worktree 管理三件套（init / close / push）以 **skill 形态**分发：既能被 AI 在对话中按意图**自动触发**，也能用斜杠命令手动指定（`/cbb-worktree-init` 等，各工具一致）。OpenSpec 命令为 `/opsx:propose`（opencode 扁平化为 `/opsx-propose`）。
 
 ---
 

package/openspec/.version

@@ -1,6 +1,5 @@
 {
-  "sha": "9d4e5974e5c0d9a09b9c6c1e1eb0975e80ec4461",
-  "branch": "main",
+  "version": "1.13.1",
   "repo": "Fission-AI/OpenSpec",
-  "updatedAt": "2026-09-12T00:00:00.000Z"
+  "renderedAt": "2026-09-19T13:22:53.815Z"
 }

package/openspec/commands/apply.md

@@ -4,179 +4,193 @@ description: Implement tasks from an OpenSpec change (Experimental)
 category: Workflow
 tags: [workflow, artifacts, experimental]
 ---
-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`). 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.
-
-**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**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-   - Optional `context`: current required project instruction input from the selected root
-   - Optional `operationGuidance`: current advisory guidance for apply
-
-   **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: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-   Treat `context` as a required prompt-level input. Read and consider it, and
-   apply relevant project facts, conventions, and constraints while implementing.
-   Treat `operationGuidance` as optional additive advice. Read and consider every
-   entry, and follow entries that are applicable and compatible with the built-in
-   workflow.
-
-   Keep both fields separate from CLI-returned state, missing artifacts, tasks,
-   progress, `contextFiles`, and the built-in `instruction`. They are not
-   evidence of task completion, do not replace the built-in instruction, and do
-   not permit bypassing a blocked state. If context conflicts with the built-in
-   instruction, an explicit user choice, or a CLI-controlled value, report the
-   conflict and preserve the controlling value. If guidance is inapplicable or
-   conflicts with those controlling inputs, do not follow it and explain why.
-   These are prompt-level behavior contracts, not enforceable checks.
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-   Do not copy `context` or `operationGuidance` verbatim into implementation
-   files or planning artifacts unless the user separately asks for that content.
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
-- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
-- Use contextFiles from CLI output, don't assume specific file names
-- Do not use context or operation guidance as proof that a task is complete
-- Apply relevant project context; report conflicts with controlling workflow inputs
-- Consider every guidance entry; explain any inapplicable or conflicting advice
-- Do not copy runtime context or operation guidance into implementation files or planning artifacts
-- Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+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., `/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**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and ask the user to select one
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - 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"`: show the message and pause implementation.
+     - If `missingArtifacts` is non-empty: suggest using `/opsx:continue` 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
+
+   Treat `context` as a required prompt-level input. Read and consider it, and
+   apply relevant project facts, conventions, and constraints while implementing.
+   Treat `operationGuidance` as optional additive advice. Read and consider every
+   entry, and follow entries that are applicable and compatible with the built-in
+   workflow.
+
+   Keep both fields separate from CLI-returned state, missing artifacts, tasks,
+   progress, `contextFiles`, and the built-in `instruction`. They are not
+   evidence of task completion, do not replace the built-in instruction, and do
+   not permit bypassing a blocked state. If context conflicts with the built-in
+   instruction, an explicit user choice, or a CLI-controlled value, report the
+   conflict and preserve the controlling value. If guidance is inapplicable or
+   conflicts with those controlling inputs, do not follow it and explain why.
+   These are prompt-level behavior contracts, not enforceable checks.
+
+4. **Read context files**
+
+   Read every file path listed under `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+   Do not copy `context` or `operationGuidance` verbatim into implementation
+   files or planning artifacts unless the user separately asks for that content.
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - A task needs work beyond what the spec and tasks describe, or you are tempted to drop, narrow, defer, or accept exceptions to specified behavior to make it fit → surface the added scope and ask; do not absorb it silently
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- When a task needs work beyond what the spec describes, surface the added scope and pause - never silently narrow, defer, or simplify away specified behavior
+- Only mark a task `- [x]` when its specified behavior is fully implemented, not when it is partially done or deferred
+- Use contextFiles from CLI output, don't assume specific file names
+- Do not use context or operation guidance as proof that a task is complete
+- Apply relevant project context; report conflicts with controlling workflow inputs
+- Consider every guidance entry; explain any inapplicable or conflicting advice
+- Do not copy runtime context or operation guidance into implementation files or planning artifacts
+- Preserve CLI-controlled blocked/ready/all-done behavior and completion criteria
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
 - **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly