release-skill 0.9.36 → 0.9.38

package/adapters/cursor/schemas/release-plan.schema.json

@@ -13,6 +13,7 @@
   ],
   "additionalProperties": false,
   "properties": {
+    "replacesPlanDigest": { "type": "string", "pattern": "^[a-f0-9]{64}$" },
     "planVersion": {
       "type": "integer",
       "enum": [

package/adapters/cursor/schemas/test-intake.schema.json

@@ -206,6 +206,7 @@
         "prepared": {
           "type": "object",
           "properties": {
+            "replacesPlanDigest": { "type": "string", "pattern": "^[a-f0-9]{64}$" },
             "status": false,
             "digest": false,
             "testAcceptance": false

package/adapters/cursor/skills/release-config/SKILL.md

@@ -15,36 +15,29 @@ description: "Config-only workflow profile: route confirms config-only diff, ass
 
 ## 触发
 
-用户询问或执行纯配置变更的发布流程。包含 `.release-skill/project.yaml`、配置 schema 等配置文件的修改，且无代码、文档或 marketplace 变更。
+用户发起仅配置变更的发布流程，涉及 `.release-skill/project.yaml`、配置 schema、`releaseUnits` 映射、`policy` 策略定义等配置文件的修改，且无代码、文档或 marketplace 变更。
 
 ## 当前状态
 
-`release-config` 是工作流配置文件 (§4) 定义的独立工作流之一，专门处理仅配置变更的场景。它遵循简化生命周期，专注于配置验证和发布路径决策分支。
+`release-config` 是工作流配置文件（§4）定义的独立工作流之一，专门处理仅配置变更场景。其遵循简化生命周期，专注于配置验证与发布路径决策分支。
 
-**机械实现**: `prepare --workflow config` 确定性地裁剪代码类门禁（H5），并比较当前
-per-unit `snapshotDigest` 与最新冻结 plan——公开字节未变 → `publishPath:
-'no-publish-needed'`（externalActions 被移除，无 publish 路径）；字节变化或无对比
-plan → `publishPath: 'publish-needed'`（fail-safe）。决策以 `workflowDecision` 绑定
-进 plan digest，不可篡改。**不存在** `NO_PUBLISH_NEEDED`/`REPORTED` 虚构状态：
-prepare 的真实输出是 plan 内的 `workflowDecision`。
+**机械实现**：`prepare --workflow config` 确定性地裁剪代码类门禁（H5），并比较当前 per-unit `snapshotDigest` 与最新冻结 plan——公开字节未变 → `publishPath: 'no-publish-needed'`（`externalActions` 被移除，无 publish 路径）；字节变化或无对比 plan → `publishPath: 'publish-needed'`（fail-safe）。决策以 `workflowDecision` 绑定进 plan digest，不可篡改。**不存在** `NO_PUBLISH_NEEDED`/`REPORTED` 虚构状态：prepare 的真实输出是 plan 内的 `workflowDecision`。
 
 **边界**：裁剪代码类检查（declared hooks、snapshot-verify gates、skill-resource-closure），保留基线、快照、计划冻结和文档新鲜度检查。来源权威检查按发布分支决定，不能一并裁掉：
 
-- 场景 A：公开字节未变，`externalActions=[]`，不生成 `plan.sourceAuthority`（冻结的源码来源权威），也不进入 approve/publish/verify。即使配置了公开来源收据，这一边界也不变。
-- 场景 B：公开字节变化或不可判定，需要发布。production prepare 必须通过现有来源权威检查并冻结 `plan.sourceAuthority`；publish、reconcile、verify 继续校验冻结绑定和远端一致性，consumer-verify 保留。
+- **场景 A**：公开字节未变，`externalActions=[]`，不生成 `plan.sourceAuthority`（冻结的源码来源权威），也不进入 approve/publish/verify。即使配置了公开来源收据，这一边界也不变。
+- **场景 B**：公开字节变化或不可判定，需要发布。production prepare 必须通过现有来源权威检查并冻结 `plan.sourceAuthority`；publish、reconcile、verify 继续校验冻结绑定和远端一致性，consumer-verify 保留。
 
 旧 production 计划缺少 `sourceAuthority` 时，仍在外部写入前拒绝。未发生外部写入的旧计划必须重新 prepare 并批准新摘要，不补字段、不迁移旧批准。已有 `PARTIAL` 保留检查点，走匹配版本的恢复路径。docs production 同样要求来源权威；marketplace 委托目标工作区发布的边界不变。
 
 ## 职责与边界
 
-- **步骤① diff 确认 config-only**: 调用 `release-skill route` command 确认仅有配置变更
-- **步骤② assess with schema validation**: 执行配置结构验证、schema 检查、contract 一致性
-- **步骤③ prepare --workflow config**: 本地 freeze 检查，生成只读计划；输出 `workflowDecision`
-- **步骤④ decision branch**（来自 plan.workflowDecision）:
-  - 场景 A：`publishPath === 'no-publish-needed'`（公开字节未变化）→ 记录决策并结束，
-    无 publish 路径，不运行 approve/publish/verify
-  - 场景 B：`publishPath === 'publish-needed'`（公开 surface 变化或不可判定）→ 运行
-    轻链 (approve→publish→verify)
+- **步骤① diff 确认 config-only**：调用 `release-skill route` 命令确认仅有配置变更
+- **步骤② assess with schema validation**：执行配置结构验证、schema 检查、contract 一致性
+- **步骤③ prepare --workflow config**：本地 freeze 检查，生成只读计划；输出 `workflowDecision`
+- **步骤④ decision branch**（来自 plan.workflowDecision）：
+  - **场景 A**：`publishPath === 'no-publish-needed'`（公开字节未变化）→ 记录决策并结束，无 publish 路径，不运行 approve/publish/verify
+  - **场景 B**：`publishPath === 'publish-needed'`（公开 surface 变化或不可判定）→ 运行轻链（approve→publish→verify）
 
 存量增量只改本轮目标映射。已有合法字段、历史发行记录与精确授权保持不变，不要重建 `.release-skill/project.yaml`。
 
@@ -52,25 +45,27 @@ prepare 的真实输出是 plan 内的 `workflowDecision`。
 
 `delivery.include/exclude` 不是文件包含或排除。排除不得覆盖 `requiredPublicFiles`。互相冲突的配置必须失败关闭。Foundation 建议不能作为发布批准。未经精确批准不产生远端动作。分类文字不会机械识别全部私有内容。接入评估缺失码 `REQUIRED_PUBLIC_FILE_MISSING` 不属于本技能的 prepare 路径；config-only prepare 仍走 `release-prepare` 原生错误。
 
-**授权边界**: 命令调用本身即授权执行配置的 hooks/gates。config-only 工作流的远程写操作受标准 approval 机制约束，不 bypass 安全 gate。
+**授权边界**：命令调用本身即授权执行配置的 hooks/gates。config-only 工作流的远程写操作受标准 approval 机制约束，不 bypass 安全 gate。
 
-**阶段通过规则**:
-- 场景 A: prepare 输出 `workflowDecision.decision === 'public-bytes-unchanged'`（无 publish 路径）
-- 场景 B: `status === 'VERIFIED'` + CLI exit code 0
+**接入选择**：进入本入口的新一轮生产准备前，必须按 `release-prepare` 同一完整流程核对 `testIntake`。若缺失，须说明缺项并默认推动 `skill-family-test:skill-family-test-plan`，再在授权范围内调用 `skill-family-test:skill-family-test-run`，由 TEST 组织检查并交回结果。跳过须先明确征询，再依据本轮适用且范围匹配的明确同意决定。**沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过**。本轮匹配答复可复用。**不得把跳过写成测试已达标，也不得用跳过清除已声明的适用要求**。已冻结计划的批准、发布、对账与正式验证不回头追加接入义务。只读和非生产准备不新增接入义务。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。答复与适用范围记入既有任务或执行计划。
+
+**阶段通过规则**：
+- **场景 A**：prepare 输出 `workflowDecision.decision === 'public-bytes-unchanged'`（无 publish 路径）
+- **场景 B**：`status === 'VERIFIED'` + CLI exit code 0
 
 ## 正向执行路径
 
-1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类；已知目标版本时显式传入，route 只是工作流建议
+1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类；已知目标版本时显式传入，`route` 只是工作流建议
 2. 若推荐 `workflowKind === 'config-only'`，则使用本技能
 3. 执行步骤②：运行 `release-skill assess --root <path> --offline --json` 进行 schema validation
-4. 执行步骤③：运行 `release-skill prepare --offline --workflow config --target-version <ver> --json`
-5. 读取输出中的 `workflowDecision`：
-   - **A**: `publishPath === 'no-publish-needed'` → 记录决策（plan 已冻结，无
-     externalActions），结束。无需 approve/publish/verify
-   - **B**: `publishPath === 'publish-needed'` → 继续 approve → publish → verify 链条
-6. (场景 B 续) 执行步骤⑥：运行 `release-skill approve --plan <path> --actor <name>`
-7. (场景 B 续) 执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`
-8. (场景 B 续) 执行步骤⑧：运行 `release-skill verify --plan <path> --run <path>`
+4. 进入本入口新一轮生产准备前完成接入选择：按 `release-prepare` 同一完整流程核对 `testIntake`，默认推动 `skill-family-test:skill-family-test-plan` 与授权范围内的 `skill-family-test-run`。跳过须先明确征询再依据本轮匹配答复决定。未完成接入且无有效跳过时，不进入下一步 `prepare`。该分支只决定后续是否进入发布链，不改变生产 prepare 前的测试接入要求。
+5. 执行步骤③：运行 `release-skill prepare --offline --workflow config --target-version <ver> --json`
+6. 读取输出中的 `workflowDecision`：
+   - **A**：`publishPath === 'no-publish-needed'` → 记录决策（plan 已冻结，无 `externalActions`），结束。无需 approve/publish/verify
+   - **B**：`publishPath === 'publish-needed'` → 继续 approve → publish → verify 链条
+7. （场景 B 续）执行步骤⑥：运行 `release-skill approve --plan <path> --actor <name>`
+8. （场景 B 续）执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`
+9. （场景 B 续）执行步骤⑧：运行 `release-skill verify --plan <path> --run <path> --json`
 
 ## 确定性脚本调用
 
@@ -143,21 +138,21 @@ node "$RELEASE_SKILL_ENTRY" verify \
 
 ## 与其他工作流的关系
 
-- **docs-only**: 纯文档变更时使用 `release-docs`
-- **marketplace-only**: 仅 marketplace 变更时使用独立工作流
-- **full-happy-end**: 混合变更（code+config+docs）时降级到此完整路径
+- **docs-only**：纯文档变更时使用 `release-docs`
+- **marketplace-only**：仅 marketplace 变更时使用独立工作流
+- **full-happy-end**：混合变更（code+config+docs）时降级到此完整路径
 
 ## 关联技能
 
-- `release-skill route`: 快速入门决策路由（§4.3）
-- `release-assess`: 配置 schema/contract 验证入口
-- `release-prepare`: 离线冻结检查（`--workflow config` 输出 publish-path 决策）
-- `release-approve`: Plan approval（仅场景 B）
-- `release-publish`: 制品发布（仅在 public surface 变化时执行）
-- `release-verify`: 消费者验证（场景 B 的最终验证门）
+- `release-skill route`：快速入门决策路由（§4.3）
+- `release-assess`：配置 schema/contract 验证入口
+- `release-prepare`：离线冻结检查（`--workflow config` 输出 publish-path 决策）
+- `release-approve`：Plan approval（仅场景 B）
+- `release-publish`：制品发布（仅在 public surface 变化时执行）
+- `release-verify`：消费者验证（场景 B 的最终验证门）
 
 ## 人类最终回复
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明实际分支、已完成步骤、未执行步骤，以及既有计划、`workflowDecision` 产物和限制。`publishPath` 为 `no-publish-needed` 时按原合同结束，无发布路径。场景 B 只写入已经执行的 approve、publish、verify 结果。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。
+执行路径说明实际分支、已完成步骤、未执行步骤，以及既有计划、`workflowDecision` 产物和限制。`publishPath` 为 `no-publish-needed` 时按原合同结束，无发布路径。场景 B 只写入已经执行的 approve、publish、verify 结果。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。

package/adapters/cursor/skills/release-docs/SKILL.md

@@ -15,44 +15,47 @@ description: "Docs-only workflow profile: route confirms docs-only diff, style-g
 
 ## 触发
 
-用户询问或执行纯文档变更的发布流程。包含 `docs/public/site/`, `README*`, `CHANGELOG`, `release-notes/` 等文件的修改，且无代码、配置或 marketplace 变更。
+用户发起纯文档变更的发布流程，涉及 `docs/public/site/`、`README*`、`CHANGELOG`、`release-notes/` 等文件的修改，且无代码、配置或 marketplace 变更。
 
 ## 当前状态
 
-`release-docs` 是工作流配置文件 (§4) 定义的独立工作流之一，专门处理仅文档变更的场景。它遵循标准发布生命周期，裁剪代码类检查（声明式 hooks、snapshot-verify gates、skill-resource-closure），保留文档质量检查。
+`release-docs` 是工作流配置文件（§4）定义的独立工作流之一，专门处理仅文档变更场景。其遵循标准发布生命周期，但裁剪了代码类检查（如声明式 hooks、snapshot-verify gates、skill-resource-closure），保留文档质量与发布表面一致性检查。
 
-docs production 仍由 release-skill 执行发布，因此 prepare 必须通过现有来源权威检查，并冻结 `plan.sourceAuthority`（源码来源权威）。publish、reconcile、verify 继续校验冻结绑定和远端一致性，不能把来源权威当作代码类检查裁掉。config 场景 B 适用同一要求；场景 A 无发布动作、不生成该字段。marketplace 委托目标工作区发布的边界不变。
+文档生产仍由 `release-skill` 执行发布，因此 `prepare` 阶段必须通过现有来源权威检查，并冻结 `plan.sourceAuthority`（源码来源权威）。`publish`、`reconcile`、`verify` 阶段继续校验冻结绑定与远端一致性，**不可将来源权威视为代码类检查而裁掉**。配置场景 B 适用相同要求；场景 A 无发布动作，不生成该字段。marketplace 委托目标工作区发布的边界不变。
 
-旧 production 计划缺少 `sourceAuthority` 时，仍在外部写入前拒绝。未发生外部写入的旧计划必须重新 prepare 并批准新摘要，不补字段、不迁移旧批准。已有 `PARTIAL` 保留检查点，走匹配版本的恢复路径。
+旧 production 计划若缺少 `sourceAuthority`，在外部写入前即被拒绝。未发生外部写入的旧计划必须重新 `prepare` 并批准新摘要，**不补字段、不迁移旧批准**。已有 `PARTIAL` 状态保留检查点，走匹配版本的恢复路径。
 
-**机械实现**: `prepare --workflow docs` 在 prepare 内确定性地裁剪代码类门禁（H5），
-plan 记录 `workflowKind: 'docs'` 与 `workflowDecision`（绑定进 plan digest）。
-**边界**: NOT merging repos；不对代码类 gates（如 schema validation、contract verification）负责。
+**机械实现**：`prepare --workflow docs` 在 `prepare` 阶段确定性地裁剪代码类门禁（H5），`plan` 记录 `workflowKind: 'docs'` 与 `workflowDecision`（绑定进 `plan digest`）。
+
+**边界**：不合并仓库；不对代码类 gates（如 schema validation、contract verification）负责。
 
 ## 职责与边界
 
-- **步骤① diff 分类确认**: 调用 `release-skill route` command 对工作树 diff 分类，确认仅有文档变更
-- **步骤② style-guard 三道门**: 调用 `check-style.mjs`（只接受文件路径参数，exit 0/1/2）执行事实性/可读性/风格检查
-- **步骤③ render-public-site --check**: 调用 `render-public-site.mjs --check [--repo <name>]` 做渲染漂移扫描（内存泄漏扫描 + 树基线对比）
-- **步骤④ docs refresh**: 执行 rehearsal → binder 写入（本地文档更新，不 commit/push）
-- **步骤⑤ prepare --workflow docs**: 轻量 freeze（裁剪代码类 gates，保留 docs freshness/public-surface/baseline/snapshots/plan freeze）
-- **步骤⑥–⑧**: approve → publish → verify（consumer-verify 保留）
+- **步骤① diff 分类确认**：调用 `release-skill route` 命令对工作树 diff 分类，确认仅含文档变更  
+- **步骤② style-guard 三道门**：调用 `check-style.mjs`（仅接受文件路径参数，exit 0/1/2）执行事实性、可读性、风格检查  
+- **步骤③ render-public-site --check**：调用 `render-public-site.mjs --check [--repo <name>]` 执行渲染漂移扫描（内存泄漏扫描 + 树基线对比）  
+- **步骤④ docs refresh**：执行 rehearsal → binder 写入（本地文档更新，不 commit/push）  
+- **步骤⑤ prepare --workflow docs**：轻量级冻结（裁剪代码类 gates，保留 docs freshness/public-surface/baseline/snapshots/plan freeze）  
+- **步骤⑥–⑧**：approve → publish → verify（consumer-verify 保留）
+
+**授权边界**：命令调用本身即授权执行配置的 hooks/gates。本地文档写入授权仅覆盖声明的本地文档目标，**不等同于 Git commit/push/publish 或安装的授权**。
 
-**授权边界**: 命令调用本身即授权执行配置的 hooks/gates。本地文档写入授权只覆盖声明的本地文档目标，不是 Git commit/push/publish 或安装的授权。
+**接入选择**：进入本入口的新一轮生产准备前，按 `release-prepare` 同一完整流程核对 `testIntake`。若缺失，说明缺项并默认推动 `skill-family-test:skill-family-test-plan`，再在授权范围内调用 `skill-family-test:skill-family-test-run`，由 TEST 组织检查并交回结果。跳过须先明确征询，再依据本轮适用且范围匹配的明确同意决定。**沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过**。本轮匹配答复可复用。**不得把跳过写成测试已达标，也不得用跳过清除已声明的适用要求**。已冻结计划的批准、发布、对账与正式验证不回头追加接入义务。只读、非生产准备不新增接入义务。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。答复与适用范围记入既有任务或执行计划。
 
-**阶段通过规则**: `status === 'VERIFIED'` 且 CLI exit code 为 0。`PARTIAL` 状态保留并跳过已成功的检查点，只安全重试未完成的步骤。
+**阶段通过规则**：`status === 'VERIFIED'` 且 CLI exit code 为 0。`PARTIAL` 状态保留并跳过已成功的检查点，仅安全重试未完成的步骤。
 
 ## 正向执行路径
 
-1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类和工作流建议；已知目标版本时显式传入，route 不承担发布授权
-2. 若推荐 `workflowKind === 'docs-only'`，则使用本技能
-3. 执行步骤②：调用 `check-style.mjs <doc-path>...` 执行事实/可读性/风格检查
-4. 执行步骤③：调用 `render-public-site.mjs --check [--repo <name>]` 验证渲染无漂移
-5. 执行步骤④：运行 `release-skill docs refresh --unit <id> --write --confirm-refresh <digest> --ack-local-document-write`
-6. 执行步骤⑤：运行 `release-skill prepare --offline --workflow docs --target-version <ver>`
-7. 执行步骤⑥：人工审阅后运行 `release-skill approve --plan <path> --actor <name>`
-8. 执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`
-9. 执行步骤⑧：运行 `release-skill verify --plan <path> --run <path>`
+1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类和工作流建议；已知目标版本时显式传入，`route` 不承担发布授权  
+2. 若推荐 `workflowKind === 'docs-only'`，则使用本技能  
+3. 执行步骤②：调用 `check-style.mjs <doc-path>...` 执行事实/可读性/风格检查  
+4. 执行步骤③：调用 `render-public-site.mjs --check [--repo <name>]` 验证渲染无漂移  
+5. 执行步骤④：运行 `release-skill docs refresh --unit <id> --write --confirm-refresh <digest> --ack-local-document-write`  
+6. 进入本入口新一轮生产准备前完成接入选择：按 `release-prepare` 同一完整流程核对 `testIntake`，默认推动 `skill-family-test:skill-family-test-plan` 与授权范围内的 `skill-family-test:skill-family-test-run`。跳过须先明确征询再依据本轮匹配答复决定。未完成接入且无有效跳过时，不进入下一步 `prepare`  
+7. 执行步骤⑤：运行 `release-skill prepare --offline --workflow docs --target-version <ver>`  
+8. 执行步骤⑥：人工审阅后运行 `release-skill approve --plan <path> --actor <name>`  
+9. 执行步骤⑦：运行 `release-skill publish --plan <path> --approval <path>`  
+10. 执行步骤⑧：运行 `release-skill verify --plan <path> --run <path>`
 
 ## 确定性脚本调用
 
@@ -105,22 +108,22 @@ node "$RELEASE_SKILL_ENTRY" verify \
 
 ## 与其他工作流的关系
 
-- **config-only**: 仅配置变更时使用 `release-config`
-- **marketplace-only**: 仅 marketplace 变更时使用独立工作流
-- **full-happy-end**: 混合变更（code+docs）时降级到此完整路径
+- **config-only**：仅配置变更时使用 `release-config`  
+- **marketplace-only**：仅 marketplace 变更时使用独立工作流  
+- **full-happy-end**：混合变更（code+docs）时降级到此完整路径
 
 ## 关联技能
 
-- `release-skill route`: 快速入门决策路由（§4.3）
-- `release-assess`: 项目发布就绪度评估
-- `release-prepare`: 冻结发布计划（`--workflow docs` 裁剪代码类门禁）
-- `release-publish`: 发布 GitHub/npm 制品
-- `release-verify`: 消费者验证和远程状态重检
-- `skill-family-docs-style-guard`（skill-family-docs adapter）: `check-style.mjs` 文档质量三道门
-- `render-public-site`（skill-family-doc-render）: 站点渲染漂移与泄漏扫描
+- `release-skill route`：快速入门决策路由（§4.3）  
+- `release-assess`：项目发布就绪度评估  
+- `release-prepare`：冻结发布计划（`--workflow docs` 裁剪代码类门禁）  
+- `release-publish`：发布 GitHub/npm 制品  
+- `release-verify`：消费者验证和远程状态重检  
+- `skill-family-docs-style-guard`（skill-family-docs adapter）：`check-style.mjs` 文档质量三道门  
+- `render-public-site`（skill-family-doc-render）：站点渲染漂移与泄漏扫描
 
 ## 人类最终回复
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明实际分支、已完成步骤、未执行步骤，以及演练或写入产物和限制。本地文档写入只在 `--write --confirm-refresh --ack-local-document-write` 三项绑定已经实际执行后报告。发布链只报告已经跑完的 prepare、approve、publish、verify；仅当退出码为 0 且状态为 `VERIFIED` 时，把发布终态写为已验证。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。
+执行路径说明实际分支、已完成步骤、未执行步骤，以及演练或写入产物和限制。**本地文档写入仅在 `--write --confirm-refresh --ack-local-document-write` 三项绑定已实际执行后报告**。发布链只报告已经跑完的 `prepare`、`approve`、`publish`、`verify`；**仅当退出码为 0 且状态为 `VERIFIED` 时，把发布终态写为已验证**。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。

package/adapters/cursor/skills/release-help/SKILL.md

@@ -16,66 +16,63 @@ description: "Discoverable entry point for release-skill: dependency and environ
 
 ## 触发
 
-询问 release-skill 的用法、发布流程、依赖、环境、只读诊断或 dry-run 时使用。本入口只做能力说明和分诊；专用工作流交给对应 Skill。
+用户询问 `release-skill` 用法、流程、依赖、环境、只读诊断或 `dry-run` 时使用。
 
 ## 只读边界
 
-`help` 不联网、不检查认证、不改文件、不生成计划，也不执行 Git、宿主安装或外部发布写入。它只根据当前环境报告准备度并给出下一步。优先调用插件自带入口；不可用时才回退到源码入口。
+`help` 命令不联网、不检查认证、不修改文件、不生成发布计划，也不执行 Git 操作、宿主安装或外部发布写入。它根据环境评估准备度，并给出下一步建议。
 
-核心流程跨平台；WorkBuddy 本机收尾仅支持 macOS。Node.js >= 22 和 Git 决定本地准备度。npm、gh 只影响生产发布依赖；pnpm 缺失只进入建议。
+核心流程跨平台；WorkBuddy 本机收尾仅支持 macOS。本地准备度由 Node.js ≥ 22 和 Git 决定。`npm` 与 `gh` 仅影响生产发布依赖；`pnpm` 缺失仅触发建议，不影响准备度判断。
 
-本地阶段通过须同时满足 `status: "READY"` 和 exit code 0。读取 `readiness.localPreparation.status` 与 `missingRequired`。生产另读 `readiness.productionPublish`：缺 npm/gh 为 `NOT_READY`，已安装也只是 `AUTH_CHECK_REQUIRED`，不代表认证、权限或发布授权已经成立。
+本地阶段通过需同时满足：
+- `status: "READY"`
+- 退出码为 0
 
-## 治理诊断分流
-
-用户只要求治理诊断时，按意图选择一个入口：
-
-- 了解能力、依赖或安全边界：留在 `release-help`。
-- 检查接入：转 `release-setup`，运行 `setup --assess-adoption`；`NOT_CONFIGURED` 指向首次接入，不创建配置。
-- 分析配置、文档和发布就绪缺口：转 `release-assess`，运行离线 `assess`。
-- 核对历史记录：转 `release-assess`，只核对用户显式提供的 plan、approval 和 run 文件。
-- 读取已有共同证明：转 `release-assess`，运行 `read-proof`。三个只读入口可用 `--conclusion-output` 排他写出证明；读取不重新扫描目标。
+本地阶段是否通过，由 `readiness.localPreparation.status` 与 `missingRequired` 判断。生产发布另需检查 `readiness.productionPublish`：
+- 缺失 `npm` 或 `gh` 时为 `NOT_READY`
+- 已安装时仅为 `AUTH_CHECK_REQUIRED`，不代表认证、权限或发布授权已成立
 
-治理诊断只运行 release-skill 自己的只读检查程序，不运行目标 Skill、业务脚本、构建、hook 或发布动作，也不把 `prepare`、`verify`、`release-finish` 当作静态治理入口。用户要求实际接入或发布时，把已有授权带到对应原业务入口；各入口继续执行原有确认、副作用和状态机合同。
-
-## 0.9.36 能力与证据边界
-
-四类工程材料接到现有 `release-project` 字段。公开正式材料写入 `publicFiles`（`sourceScope` / `from` / `to` / `mode`）。运行必需资源写入 `requiredPublicFiles`，必须被同一单元 `publicFiles[].to` 精确覆盖。私有正式材料与非正式运行材料不列入 `publicFiles`，需要挡住时使用 `forbiddenPaths` / `forbiddenContentPatterns`。正式不等于公开。是否进入公开快照由 `publicFiles` 是否列出决定。npm 是载荷渠道。`package.json` 的 `files` 与入口闭包和公开映射同时约束。`delivery.include` / `delivery.exclude` 只选择宿主，不是文件包含或排除。排除不得拿掉运行必需资源。互相冲突的配置必须失败关闭。
+## 治理诊断分流
 
-首次接线使用 `release-setup`。已有 `.release-skill/project.yaml` 返回 `ALREADY_CONFIGURED` / `CONFIG_EXISTS`，不覆盖。存量增量由 `release-assess` 诊断，再由已有 `release-config` Skill 处理。`release-config` 不是新增 CLI。必须先 `route`：实际为 `config-only` 才执行 `prepare --workflow config`；`full-happy-end` 或混合走普通 full。不得无条件触发 `prepare --workflow config`。
+只请求治理诊断时，按意图选择入口：
 
-`REQUIRED_PUBLIC_FILE_MISSING` 只属于 `setup --assess-adoption`。接入评估按 `requiredPublicFiles` 的快照目标找到对应 `publicFiles[].to`，再检查仓根相对 `from` 是否存在；缺失记该码。普通 `assess` 与 `verify-records` 不使用该码。`prepare` 仍使用自身原生错误，例如 `PUBLIC_FILE_MISSING`、`CONFIG_INVALID`。`LICENSE_MISSING` 不能代替运行必需资源。Foundation 建议不能作为发布批准。
+| 意图 | 推荐入口 | 说明 |
+|------|----------|------|
+| 了解能力、依赖或安全边界 | `release-help`（当前入口） | 仅提供能力说明与分诊 |
+| 检查接入状态 | `release-setup --assess-adoption` | `NOT_CONFIGURED` 表示首次接入，不创建配置 |
+| 分析配置、文档与发布就绪缺口 | `release-assess --offline` | 离线诊断，不运行构建或发布动作 |
+| 核对历史记录 | `release-assess`（显式提供 plan/approval/run 文件） | 仅读取用户提供的文件，不重新扫描 |
+| 读取已有证明 | `release-skill read-proof --proof-root <root> --proof <relative> --json`，只读现有文件、不扫描目标 | 三个只读入口可用 `--conclusion-output <absolute-path>` 排他输出共同证明 |
 
-Skill Family Hub 保持统一市场。GitHub Git Data API 机制延续，写入采用 `compare-and-swap` 语义；不自动回滚或覆盖已完成步骤。这是已有机制，不是本轮新实现的 Hub，也不表示已经完成发布。本轮未变更远端写入授权。确认边界、冻结安装 URL/ref/sha、安装后 name/version 与载荷核对规则仍有效。Hub 门禁失败将阻止 GitHub Git Data API 写入。写入绑定已观察的分支头并比较后写入；部分发布不回滚、不覆盖已完成步骤、不自动强推。独立检查点批准、历史冻结计划不重放、`ALREADY_CURRENT` 仍强制执行。
+诊断只运行 `release-skill` 自身只读检查，不调用目标 Skill、业务脚本、构建、hook 或发布动作。`prepare`、`verify`、`release-finish` 不作为静态治理入口。用户要求实际接入或发布时，应将已有授权带入对应原业务入口，各入口继续执行原有确认、副作用与状态机规则。
 
-继续采用 Foundation 0.25.0 精确依赖，不能因为邻仓版本较新就升级。空白项目走 `release-setup`；已有配置保留合法字段，用 `release-assess` / `release-config` 做增量。仅禁路径一类的 `config-only` 增量，离线非生产 `prepare` 可为 `PREPARED`，`workflowDecision` 为 `indeterminable` / `publish-needed`，这是合法结果。npm 入口缺失时失败关闭，错误为 `GATE_FAILED` / `npm-entry-closure` / `entry_missing`。旧版独立的 `release-skill` 市场已弃用，使用 `ifoohoo/skill-family-hub` 与 `release-skill@skill-family-hub`。
+## 0.9.38 能力与证据边界
 
-**0.9.32 历史事实**  
-Kimi 2.2.0 移除菜单移动后，真实终端只重绘变动的菜单行，不重发插件标题，末行也没有换行；适配器曾因等待完整标题失败。适配器在移动后必须先重新观察选中项，确认唯一选中 `Remove plugin` 后才允许提交操作。读取帧前先核实初始精确插件 ID，读完该帧后才发送方向键，再读取完整增量帧并核对唯一选中项，完整标题重绘时仍核对精确 ID。未知、歧义、未移动、帧未完成、timeout、EOF 均导致失败关闭，不继续安装。移除确认页仍采用 `Remove <displayName> (<id>)?`，包含 Cancel 和 Remove plugin 选项；已选中 `Remove plugin` 时无需方向键。显示名含 Confirm 或 Sure，或标题分块到达，仍核对精确身份，不触发旧宽泛正则路径。保留 Kimi 0.40.1 实际确认措辞 `Confirm remove plugin "<id>"?`、括号粘贴与 CSI Enter 输入方式。该修复面向真实更新流程，提供方升级不扩大宿主授权，也无需重发原领域插件。真实 Kimi 2.2.0 已完成确认前的精确身份、移动及选中项观察，随后按 Esc 取消并退出，未执行移除、安装或更新。47 项聚焦测试通过，独立代码审阅无发现；真实消费者的完整更新与加载验收仍待执行。
+`release-project` 的四类材料：公开正式（`publicFiles`：`sourceScope`、`from`、`to`、`mode`）、运行必需（`requiredPublicFiles`）、私有正式与非正式。公开≠正式。`requiredPublicFiles` 须被同单元的 `publicFiles[].to` 精确覆盖。私有材料由 `forbiddenPaths`、`forbiddenContentPatterns` 拦截，不进 `publicFiles`。`npm` 包由 `package.json.files`、入口闭包与映射共同限定；`delivery.include`、`delivery.exclude` 仅选宿主，不删必需资源，冲突拒绝。字段见 [配置](https://github.com/ifoohoo/release-skill/blob/release-skill-v0.9.38/references/02-project-config.md)及 `release-prepare`。
 
-同一 `unitId/plugin/version` 的共享环境 setup 按单元、插件、版本归并，Claude/Codex 不同物理 `skillFile` 路径不再视为多个 setup 归属。仅需一个已加载宿主的精确 setup 反馈即可满足共享环境检查要求。各宿主的安装、加载及专属配置仍需分别核实，反馈继续绑定 `host/unit/path/plan/config/root`；真正多插件归属仍需消歧，Kimi 失败或其他宿主失败均导致收尾状态为 FAILED，不改变 `VERIFIED`/`DISTRIBUTED` 发布状态。
+首次 `release-setup`：若已有配置（`ALREADY_CONFIGURED`/`CONFIG_EXISTS`），不得覆盖；合法旧字段保留。增量操作（`release-assess` / `release-config`）：先运行 `route`，仅 `config-only` 走 `prepare --workflow config`；`full-happy-end` / `mixed` 走完整流程。Foundation 0.25.0 版本精确，不因邻仓升级而变更。
 
-可选宿主覆盖诊断输入 `--host-coverage <file>` 与 `--observe-hosts`、Codex 0.154.0 对 11 份真实生成 Skill 的原字节静态检查能力未变。静态检查不证明安装、会话选择或业务执行通过，批准、发布和验证状态以对应计划、批准及执行记录为准。
+`REQUIRED_PUBLIC_FILE_MISSING`：仅 `setup --assess-adoption` 触发，按 `requiredPublicFiles` 匹配 `publicFiles[].to`，再检查仓根相对 `from` 是否存在。普通 `assess` / `verify-records` 无此码；`prepare` 原有 `PUBLIC_FILE_MISSING` / `CONFIG_INVALID`。`LICENSE_MISSING` 不能替代运行必需资源。仅禁路径类 `config-only` 增量在离线非生产 `prepare` 中可为 `PREPARED`，`workflowDecision` 为 `indeterminable` / `publish-needed`；`npm-entry-closure` / `entry_missing` 触发 `GATE_FAILED`。Foundation 建议不是发布批准。
 
-Qoder 本机更新路径处理维持既有能力，支持 `./adapters/qoder/skills/` 与 `./skills/` 两种布局，仍核对安装 name/version/skills、路径包含性与实际载荷。私有 Hub 的 `RELEASE_SKILL_HUB_RELEASE_EVIDENCE` 环境变量继续要求原始描述符指向的已有普通文件绝对路径（拒绝符号链接），交由 `npm run release:check -- --release-evidence <file>` 验证。
+GitHub Git Data API `compare-and-swap` 绑定已观察分支头，远端授权不变。冻结安装 URL/ref/sha，安装后核对 name/version/载荷，门禁失败不写入。独立 checkpoint 批准；不支持回滚覆盖强推或重放旧计划。`ALREADY_CURRENT` 仍需核验。市场使用 `ifoohoo/skill-family-hub` 及 `release-skill@skill-family-hub`，旧独立市场弃用。
 
-在冻结前，`prepare` 或新建 `ship` 状态时可重复传入 `--unit <id>`；未传入则默认选择全部单元。延期单元不进入发布计划，亦不获得发布状态。完整配置、生成物新鲜度检查及顶层 Hook 仍作用于全项目范围。`publicSourceAuthorityReceipt` 的 coordinator 与全部 subjects 必须共同选择。
+`release-finish`：Kimi 2.2.0 变动行/无换行与 0.40.1 旧确认措辞兼容，始终核精确 ID/完整帧/唯一选中项再提交。未知歧义/未移动/不完整/timeout/EOF 拒绝。共享环境 setup 按 `unitId/plugin/version` 归并，Claude/Codex 的不同物理 `skillFile` 不会分裂 setup 归属。一个已加载宿主的精确 setup 反馈可满足共享环境，但各宿主安装加载专属配置分别核，反馈绑定 `host/unit/path/plan/config/root`。真正多插件归属仍须消歧；任一宿主失败则收尾为 `FAILED`，不改 `VERIFIED` / `DISTRIBUTED`。
 
-可选 `testIntake` 只在生产 prepare 生效。首次准备返回 `NEEDS_INPUT` 和一份非正式候选，退出码 13；同一候选用 `prepare --candidate <path>` 续接，接受后才有正式计划。候选不能批准或发布，也不能清除 `PARTIAL`、`PUBLISHED` 或 `VERIFIED`。未声明的项目、原有 hook 和完整门保持不变。轻量工作流和单元选择都不免除项目级要求。非生产 prepare 遇到 `testIntake` 返回 `CONFIG_INVALID`。
+`--host-coverage <file>` / `--observe-hosts` 仍可诊断。Codex 0.154.0 对 11 份真实 Skill 的原字节静态检查不证明安装、会话选择或业务通过。批准、发布和验证状态以对应计划、批准及执行记录为准。
 
-冻结后，发布流程（publish、reconcile、verify、distribute）不再接受 `--unit` 参数，仅以 `plan.units` 为唯一有效范围。
+Qoder 支持路径：`./adapters/qoder/skills/` 与 `./skills/`，核对 `name/version/skills`、包含性与载荷。私有 Hub 的 `RELEASE_SKILL_HUB_RELEASE_EVIDENCE` 必须由原始描述符指向已有普通文件的绝对路径，拒绝 `symlink`。交 `npm run release:check -- --release-evidence <file>` 核验。
 
-每个单元必须声明 `previousPublicBaseline`：只有确认没有前序公开版本时，才使用 `none`；否则必须提供 `bound`，并包含 `repo/ref/commit` 信息。`none` 不绕过 publish 阶段的唯一性预检。
+冻结前 `prepare` / 新 `ship` 可重复 `--unit <id>`，默认全部；延期不进计划，不获状态。完整配置、生成物新鲜度及顶层 Hook 仍作用于全项目。`publicSourceAuthorityReceipt` 的 coordinator 与全部 subjects 必须共同选择。冻结后 `publish` / `reconcile` / `verify` / `distribute` 拒 `--unit`，只认 `plan.units`。
 
-Hook 缓存 v2 仅复用绝对路径，或已通过真实 cwd 核验的 cwd-relative 可执行文件身份；若依赖裸 PATH、PATHEXT、Windows 环境或观察不可用，将触发冷执行并失败关闭。稳定隔离安装树仅在宿主命令退出、目录隔离且扫描期间无并发写入时记录；附加链接仅记录，不跟随；声明载荷中出现 symlink 将导致失败关闭。
+推荐 production ship 或转入新生产准备前核对 `testIntake`。缺失时默认推动 `skill-family-test:skill-family-test-plan` → 授权内 `skill-family-test:skill-family-test-run`。跳过须先征询，并取得本轮项目、版本、范围匹配的明确同意。沉默/拒绝/普通发布预授权/旧轮次、其他项目、版本或范围不匹配均不可跳过。本轮匹配答复可复用。不得把跳过写成测试已达标。只读路径只报告缺口。声明后仅生产 `prepare`：首次 `NEEDS_INPUT` / `exit13` 非正式候选，`--candidate` 续接才正式。候选不可 `approve` / `publish`，不能清除 `PARTIAL` / `PUBLISHED` / `VERIFIED`。轻量工作流和单元选择不免除项目级要求，未声明时原 hook 与完整门不变。非生产 `CONFIG_INVALID`；非交互 CLI 仍可选 `testIntake`，不新增选择参数。
 
-实际版本能力不能等同于发布状态或真实宿主验收。
+每个单元必须声明 `previousPublicBaseline`；确认无前版为 `none`，否则为 `bound` + `repo/ref/commit`。`none` 不绕唯一性预检。Hook cache v2 仅绝对或真实 `cwd` 核验相对可执行身份复用；裸 `PATH` / `PATHEXT` / `Windows` / 观察不可用冷执行且失败关闭。隔离安装树仅宿主退出 + 隔离 + 扫描无并发才记录；附加链接记录不跟随，声明载荷 `symlink` 拒绝。
 
 ## 最短路径
 
-1. 从插件根运行 `help --json`，检查本地准备度；生产发布再检查生产准备度。
-2. 只检查治理接入时，按上节选择 `release-setup` 或 `release-assess`，结束于范围明确的结论和下一入口。
-3. 实际接入时进入 `release-setup`；实际发布评估使用 `release-assess`，准备发布时再进入 `prepare --offline`。
+1. 从插件根运行 `help --json`，检查本地准备度；生产发布再检查生产准备度。 
+2. 只检查治理接入时，按上节选择 `release-setup` 或 `release-assess`，结束于范围明确的结论和下一入口。 
+3. 实际接入时进入 `release-setup`；实际发布评估使用 `release-assess`，准备发布时再进入 `prepare --offline`。 
 4. 生产发布优先使用可恢复的 `ship`；也可走 `prepare --online --production → approve → publish → verify`。
 
 ```bash
@@ -99,7 +96,7 @@ node "$RELEASE_SKILL_ENTRY" route --root <path> --target-version <version> --jso
 
 声明的 `postVerify` hook 可由 `postverify` 独立执行或由 `ship` 编排。计划声明该 hook 时，本机收尾必须等待完成的 postVerify run；没有声明时使用同一计划的 `VERIFIED` verify run。
 
-随后进入 `release-finish`，通过公共入口编排宿主更新、加载确认、已配置 setup 和源码分支检查：
+随后进入 `release-finish`，通过公共入口编排宿主更新、加载确认、已配置 setup 和源码分支检查。
 
 ```bash
 node "$RELEASE_SKILL_LOCAL_FINISH_ENTRY" \
@@ -107,33 +104,41 @@ node "$RELEASE_SKILL_LOCAL_FINISH_ENTRY" \
   --finish --json
 ```
 
-首次结果可能请求用户选择分支和本机宿主，或返回需要智能体实际加载并调用 setup 的请求。将绑定反馈写入文件后，以同一入口增加 `--finish-feedback <feedback-path>` 再次汇总。完整参数、反馈合同、宿主限制和 macOS Cursor 安装见 `release-finish`。仅有 `VERIFIED` 不构成本机写入、插件更新、分支合并或 setup 写入授权；收尾结果也不改写发布状态。
+完整参数、反馈合同、宿主限制和 macOS Cursor 安装见 `release-finish`。仅有 `VERIFIED` 不构成本机写入、插件更新、分支合并或 setup 写入授权；收尾结果也不改写发布状态。
 
 ## 专用工作流路由
 
-- 消费项目的 Cursor 场景配置、受控可执行目录、用户状态目录、结果不确定时的现场保留与复验，见 `release-verify`。
-- README、CHANGELOG 和双语说明的 `docs refresh` 演练、摘要确认与受管写入，见 `release-docs`。
-- VERIFIED 后的分支决定、宿主更新、加载反馈、setup 和源码检查，见 `release-finish`。
-- 纯配置变更，见 `release-config`。
+- 消费项目的 Cursor 场景配置、受控可执行目录、用户状态目录、结果不确定时的现场保留与复验，见 `release-verify`。 
+- README、CHANGELOG 和双语说明的 `docs refresh` 演练、摘要确认与受管写入，见 `release-docs`。 
+- VERIFIED 后的分支决定、宿主更新、加载反馈、setup 和源码检查，见 `release-finish`。 
+- 纯配置变更，见 `release-config`。 
 - 纯 marketplace 索引与快照变更，见 `release-marketplace`。
 
 这些入口保留各自的参数、确认和失败关闭规则；help 不复制或放宽它们。
 
 ## 故障分诊
 
-- Node.js 或 Git 缺失：读取 `missingRequired`，补齐依赖后重跑 help。
-- npm/gh 缺失或未认证：本地准备仍可继续；生产发布前另行完成 gh、Git HTTPS credential 与 npm auth 检查。
-- CLI 入口缺失：确认 `$RELEASE_SKILL_ENTRY` 存在；缺失时重新安装插件。
-- 项目配置缺失：进入 `release-setup` 的只读发现，不直接生成或覆盖 README/配置。
-- assess 失败：运行 `release-assess` 的离线诊断并按错误码处理。
-- `PARTIAL` 或远端冲突：进入 `release-reconcile`，保留已经成功的 checkpoint。
-- `testIntake` 返回 `NEEDS_INPUT`：停留在给出的候选上补齐结果，再用 `--candidate` 续接。不要把候选文件交给 approve 或 publish。
-- 文档、Cursor、宿主更新或本机收尾失败：转到上节对应专用 Skill，不在 help 中猜测恢复步骤。
+| 错误 | 处理 |
+|------|------|
+| Node.js 或 Git 缺失 | 读取 `missingRequired`，补齐依赖后重跑 help |
+| npm/gh 缺失或未认证 | 本地准备仍可继续；生产发布前另行完成 gh、Git HTTPS credential 与 npm auth 检查 |
+| CLI 入口缺失 | 确认 `$RELEASE_SKILL_ENTRY` 存在；缺失时重新安装插件 |
+| 项目配置缺失 | 进入 `release-setup` 的只读发现，不直接生成或覆盖 README/配置 |
+| assess 失败 | 运行 `release-assess` 的离线诊断并按错误码处理 |
+| `PARTIAL` 或远端冲突 | 进入 `release-reconcile`，保留已经成功的 checkpoint |
+| `testIntake` 返回 `NEEDS_INPUT` | 停留在给出的候选上补齐结果，再用 `--candidate` 续接。不要把候选文件交给 approve 或 publish |
+| 文档、Cursor、宿主更新或本机收尾失败 | 转到上节对应专用 Skill，不在 help 中猜测恢复步骤 |
 
-## 后续引导
+## 人类最终回复
 
-本地就绪后运行 `release-assess`；需要生产发布时，再确认 npm、gh、认证、冻结计划和有效批准。
+纯问询或转交时短答：写明这次实际回答了什么、适用范围或转交理由、仍然有效的限制、以及下一步入口。已有 JSON 按既定输出格式在回复中呈现。`route` 分类、推荐命令和未执行动作保持为建议。栏目只收录当前命令或分支已经返回的事实；有内容才设标题，短答直接成段。
 
-## 人类最终回复
+## 0.9.38：替代未发布计划
+
+仅生产 `testIntake` 启用：项目、发布单元ID集合、目标版本及外部目标均相同，旧计划 `PREPARED` 且从未产生发布运行权威。已有首个运行状态或 `PARTIAL`、`PUBLISHED`、`VERIFIED` 均拒绝。替代不代表发布成功或独立验收。
+
+首次 `prepare` 须显式指定 `--replace-unpublished-plan <path>`，选择本项目 `.release-skill/plans/<digest>.json` 不可变旧正式计划。首个新候选冻结前驱（旧计划），`--candidate` 续接不可后补前驱；重传不符前驱即拒绝。新候选用独立 `resultFile`，旧要求、判据、结果、计划、批准、运行全保留，由原接受方对新对象重新核收 `TEST`。
+
+新正式计划排他原子写入 `plans/<digest>.json` 才生效；写前失败无效，写后即使最新计划指针、FROZEN 标记或证据封口失败，也不得恢复旧计划发布资格，保留失败记录，沿原幂等路径核对新权威。新计划须新批准，旧批准不可跨用；`approve`、`publish`、`ship` 拒绝已替代计划。已发布或部分发布走原恢复谱系，不得以替代冒充恢复。来源提交须与远端 `main` 精确相等，`TEST`、远端冲突和批准门不变。Foundation 0.25.0 机制不变；0.9.38 入口不承诺全局撤销任意旧软件。
 
-纯问询或转交时短答。写明这次实际回答了什么、适用范围或转交理由、仍然有效的限制、以及下一步入口。已有 JSON 按原合同在回复中呈现。route 分类、推荐命令和未执行动作保持为建议。栏目只收录当前命令或分支已经返回的事实；有内容才设标题，短答直接成段。
+字段、精确历史 writer 分支及失败处理见 `release-prepare`、`release-reconcile` 与[状态机](https://github.com/ifoohoo/release-skill/blob/release-skill-v0.9.38/references/01-state-machine.md)。

package/adapters/cursor/skills/release-marketplace/SKILL.md

@@ -15,51 +15,47 @@ description: "Marketplace-only workflow profile: route confirms marketplace-only
 
 ## 触发
 
-用户询问或执行纯 marketplace 变更的发布流程。包含 `plugins.mjs` 入口文件、`public-snapshot/` 制品目录的修改，且无代码、文档或配置变更。
+用户发起仅 marketplace 索引变更的发布流程，涉及 `plugins.mjs` 入口文件或 `public-snapshot/` 制品目录的修改，且无代码、文档或配置类变更。
 
 ## 当前状态
 
-`release-marketplace` 是工作流配置文件 (§4) 定义的独立工作流之一，专门处理仅 marketplace 索引变更的场景。
+`release-marketplace` 是工作流配置文件（§4）定义的独立工作流之一，专门处理仅 marketplace 索引变更的场景。
 
-**机械实现**: `prepare --workflow marketplace` 确定性地裁剪代码类门禁（H5），plan
-记录 `workflowKind: 'marketplace'` 与 `workflowDecision`。**本工作流不执行发布**：
-发布委托给目标 workspace 的**专属发布技能**（各 marketplace workspace 有独立的
-`publish-marketplace` 流程，如 artifact-skill-set-workspace、glaf4-skill-set-workspace
-等）。release-skill 的 CLI 没有 `sync` 命令，也没有 `exclusive-release.mjs`——
-这些接口不存在，不得调用。
+**机械实现**：`prepare --workflow marketplace` 确定性地裁剪代码类门禁（H5），记录 `workflowKind: 'marketplace'` 与 `workflowDecision`。**本工作流不执行发布**：发布动作委托给目标 workspace 的专属发布技能（如 `publish-marketplace`，具体路径依 workspace 而定，如 `artifact-skill-set-workspace`、`glaf4-skill-set-workspace`、`skill-family-hub-workspace` 等）。`release-skill` CLI 无 `sync` 命令，也无 `exclusive-release.mjs` 接口——这些接口不存在，不得调用。
 
-**边界**: plugin source unmodified（不修改 plugin 源码）。市场索引一致性、snapshot
-byte、platform manifest 是核心 gate，由 workspace 自己的生成器与
-`generate-platform-manifest.mjs --check` 机械保证。
+**边界**：插件源码未被修改（plugin source unmodified）。市场索引一致性、快照字节、平台清单（platform manifest）是核心校验门禁，由目标 workspace 自身的生成器与 `generate-platform-manifest.mjs --check` 机械保证。
 
 ## 职责与边界
 
-- **步骤① diff 确认 marketplace-only**: 调用 `release-skill route` command 确认仅有 marketplace 变更（`plugins.mjs` / `public-snapshot/` 归 marketplace 类）
-- **步骤② workspace plugins.mjs 更新**: 手动审查更新入口文件（entry 是唯一 truth source，`plugins.mjs` 属 marketplace 类而非 code 类）
-- **步骤③ 再生成 public-snapshot**: 调用 workspace 自己的快照生成器
-- **步骤④ 一致性验证**: 快照字节 + `generate-platform-manifest.mjs --check`（平台清单漂移检测）
-- **步骤⑤ prepare --workflow marketplace**: 冻结计划，记录 workflow 裁剪决策
-- **步骤⑥ 委托发布**: 调用目标 workspace 的专属 `publish-marketplace` 技能执行发布
+- **步骤① diff 确认 marketplace-only**：调用 `release-skill route` 命令确认变更仅限 marketplace 类（`plugins.mjs` / `public-snapshot/`）
+- **步骤② workspace plugins.mjs 更新**：手动审查并更新入口文件（entry 是唯一 truth source，`plugins.mjs` 属 marketplace 类而非 code 类）
+- **步骤③ 再生成 public-snapshot**：调用目标 workspace 自有的快照生成器重新生成 `public-snapshot/`
+- **步骤④ 一致性验证**：运行 `generate-platform-manifest.mjs --check` 验证平台清单与快照字节无漂移
+- **步骤⑤ prepare --workflow marketplace**：冻结计划，记录 workflow 裁剪决策
+- **步骤⑥ 委托发布**：调用目标 workspace 的专属 `publish-marketplace` 技能执行发布
 
-**授权边界**:
-- Step②需要人工确认（entry 是唯一 truth source）
-- Step③–④自动验证，不允许不一致状态通过
-- Step⑥依赖外部 workspace 的发布技能，不直接控制其执行
+**授权边界**：
+- Step② 需人工确认（entry 是唯一 truth source）
+- Step③–④ 自动验证，不允许不一致状态通过
+- Step⑥ 依赖外部 workspace 的发布技能，不直接控制其执行
 
-**阶段通过规则**:
-- Steps①–⑤完成且一致：plan `workflowKind === 'marketplace'` 冻结
-- Step⑥成功：以目标 workspace 的发布技能验收标准为准（通常 `status === 'VERIFIED'`）
+**接入选择**：仅当本入口新建一轮生产准备时，按 `release-prepare` 同一完整流程核对 `testIntake`。缺失则说明缺项并默认推动 `skill-family-test:skill-family-test-plan`，再在授权范围内调用 `skill-family-test:skill-family-test-run`，由 TEST 组织检查并交回结果。跳过须先明确征询，再依据本轮适用且范围匹配的明确同意决定。**沉默、拒绝、仅普通发布预授权、旧轮次、其他项目、版本或范围不匹配均不可跳过**。本轮匹配答复可复用。**不得把跳过写成测试已达标，也不得用跳过清除已声明的适用要求**。已冻结计划与委托给目标工作区的 marketplace-only 发布不回头追加接入义务。只读、非生产准备不新增接入义务。直接非交互 CLI 仍接受可选 `testIntake`，不新增选择参数。答复与适用范围记入既有任务或执行计划。
+
+**阶段通过规则**：
+- Steps①–⑤ 完成且一致：plan 中 `workflowKind === 'marketplace'` 冻结
+- Step⑥ 成功：以目标 workspace 的发布技能验收标准为准（通常 `status === 'VERIFIED'`）
 
 ## 正向执行路径
 
-1. 运行 `release-skill route --root <path> [--target-version <ver>] --json` 获取 diff 分类；已知目标版本时显式传入，route 只是工作流建议
+1. 运行 `release-skill route --root <workspace-root> [--target-version <version>] --json` 获取 diff 分类；已知目标版本时显式传入，`route` 仅作工作流建议
 2. 若推荐 `workflowKind === 'marketplace-only'`，则使用本技能
 3. 执行步骤②：手动审查并更新 `plugins.mjs`（唯一 truth source）
-4. 执行步骤③：调用 workspace 自己的生成器再生成 `public-snapshot/`
+4. 执行步骤③：调用 workspace 自有生成器重新生成 `public-snapshot/`
 5. 执行步骤④：运行 `generate-platform-manifest.mjs --check` 验证平台清单与快照字节无漂移
-6. 执行步骤⑤：运行 `release-skill prepare --offline --workflow marketplace --target-version <ver>` 冻结计划
-7. 执行步骤⑥：调用目标 workspace 的专属发布技能（如 `publish-marketplace`）执行发布
-8. (Step⑥续) 汇总目标 workspace 流程的最终状态
+6. 仅当本入口新建一轮生产准备时完成接入选择：按 `release-prepare` 同一完整流程核对 `testIntake`，默认推动 `skill-family-test:skill-family-test-plan` 与授权范围内的 `skill-family-test:skill-family-test-run`。跳过须先明确征询再依据本轮匹配答复决定。未完成接入且无有效跳过时，不进入下一步 `prepare`
+7. 执行步骤⑤：运行 `release-skill prepare --offline --workflow marketplace --target-version <version>` 冻结本地工作流计划
+8. 执行步骤⑥：调用目标 workspace 的专属发布技能（如 `publish-marketplace`）执行发布
+9. （Step⑥续）汇总目标 workspace 流程的最终状态
 
 ## 确定性脚本调用
 
@@ -103,7 +99,7 @@ node "$RELEASE_SKILL_ENTRY" prepare --offline \
 | snapshot ≠ manifest | SNAPSHOT_MANIFEST_CONFLICT | 人工决策：以哪个为准后继续 |
 | workspace 发布技能不可用 | WORKSPACE_SKILL_NOT_FOUND | 检查 workspace 发布流程路径，不绕过其安全门禁 |
 
-## 一致性验证 (Step 4)
+## 一致性验证（Step 4）
 
 ```
 ┌──────────────────────────────────────┐
@@ -132,32 +128,28 @@ node "$RELEASE_SKILL_ENTRY" prepare --offline \
 
 ## 与其他工作流的关系
 
-- **docs-only**: 若 marketplace 更新伴随文档变更，使用 `marketplace-docs` 组合推荐
-- **config-only**: 若同时修改 project.yaml，使用 `marketplace-config` 组合推荐
-- **full-happy-end**: 多类型混合变更（code+marketplace）时降级到此路径
+- **docs-only**：若 marketplace 更新伴随文档变更，使用 `marketplace-docs` 组合推荐
+- **config-only**：若同时修改 `project.yaml`，使用 `marketplace-config` 组合推荐
+- **full-happy-end**：多类型混合变更（code+marketplace）时降级到此路径
 
 ## 关联技能
 
-- `release-skill route`: 快速入门决策路由（§4.3）
-- `release-prepare`: 冻结计划（`--workflow marketplace`）
-- 各 workspace 的专属发布技能（`publish-marketplace`，如 artifact-skill-set-workspace、
-  glaf4-skill-set-workspace、skill-family-hub-workspace 等）
-- `generate-platform-manifest.mjs`: 平台清单漂移检测（--check）
+- `release-skill route`：快速入门决策路由（§4.3）
+- `release-prepare`：冻结计划（`--workflow marketplace`）
+- 各 workspace 的专属发布技能（`publish-marketplace`，如 `artifact-skill-set-workspace`、`glaf4-skill-set-workspace`、`skill-family-hub-workspace` 等）
+- `generate-platform-manifest.mjs`：平台清单漂移检测（`--check`）
 
 ## Workspace Coordination Notes
 
 每个 workspace 管理自己的 marketplace 入口和制品，并通过其专属发布技能发布：
-- `artifact-skill-set-workspace`: `plugins.mjs` 是条目唯一事实源，`publish-marketplace`
-  技能执行发布
-- `glaf4-skill-set-workspace`: 同上，项目专属 `publish-marketplace` 技能
-- `skill-family-hub-workspace`: `plugins.mjs` 只记录已满足公开收录条件的插件
+- `artifact-skill-set-workspace`：`plugins.mjs` 是条目唯一事实源，`publish-marketplace` 技能执行发布
+- `glaf4-skill-set-workspace`：同上，项目专属 `publish-marketplace` 技能
+- `skill-family-hub-workspace`：`plugins.mjs` 只记录已满足公开收录条件的插件
 
-本技能作为协调器，确认 route 分类并冻结 marketplace 工作流计划，但发布动作必须
-委托给目标 workspace 自己的发布技能执行，release-skill 不直接操作其他 workspace
-的代码库。
+本技能作为协调器，确认 route 分类并冻结 marketplace 工作流计划，但发布动作必须委托给目标 workspace 自己的发布技能执行，`release-skill` 不直接操作其他 workspace 的代码库。
 
 ## 人类最终回复
 
 纯问询或转交时短答：写明实际回答、适用范围或理由、必要限制和下一步。建议保持为建议。
 
-执行路径说明实际分支、已完成步骤、未执行步骤，以及 route 或 prepare 产物和限制。发布按原合同委托目标工作区专属发布技能；本入口只报告本入口实际完成的步骤，以及委托结果里已经返回的事实。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。
+执行路径说明实际分支、已完成步骤、未执行步骤，以及 route 或 prepare 产物和限制。发布按原合同委托目标工作区专属发布技能；本入口只报告本入口实际完成的步骤，以及委托结果里已经返回的事实。已有文件输出按原合同呈现。栏目只收录当前命令或分支已经返回的事实。