release-skill 0.2.9 → 0.4.0

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "release-skill",
       "source": "./",
-      "version": "0.2.9",
+      "version": "0.4.0",
       "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification"
     }
   ]

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.2.9",
+  "version": "0.4.0",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/.codebuddy-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.2.9",
+  "version": "0.4.0",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.2.9",
+  "version": "0.4.0",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"
@@ -19,7 +19,7 @@
     ],
     "defaultPrompt": [
       "Assess this project for release readiness.",
-      "Prepare a release plan for version 0.2.9.",
+      "Prepare a release plan for version 0.4.0.",
       "Help me understand the release workflow."
     ]
   }

package/.kimi-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.2.9",
+  "version": "0.4.0",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/CHANGELOG.md

@@ -1,5 +1,46 @@
 # Changelog
 
+<!-- release-skill:changelog:start version=0.4.0 locale=en baseline=sha256:099d9db24049aeaae78a21d3bd5152582bb20d4efad1ceff085f9609e8e6d52e -->
+## [0.4.0] - 2026-08-02
+
+v0.4.0 simplifies the production release path to one frozen-plan approval and moves unavailable Kimi or CodeBuddy installations into non-blocking manual follow-up tasks.
+
+### Added
+
+- **Manual consumer follow-ups**: when Kimi or CodeBuddy cannot be installed automatically, the release records an installation task after publishing without requiring system attestation.
+
+### Changed
+
+- **Single release approval**: the normal production path now asks only for approval of the immutable release plan; invoking a command authorizes its configured hooks and gates.
+- **Non-blocking human consumers**: Kimi and CodeBuddy manual installation tasks no longer prevent the automated release from reaching `VERIFIED`.
+
+### Removed
+
+- **Redundant confirmation flags**: legacy plan-digest repetition, production-confirmation, hook-authorization, and manual-attestation interactions were removed from the normal release path.
+<!-- release-skill:changelog:end version=0.4.0 locale=en -->
+
+
+<!-- release-skill:changelog:start version=0.3.0 locale=en baseline=sha256:ee0626856918a8fae3b49f3e1645b8f2dc4149519499edbd04e175939faa1b2e -->
+## [0.3.0] - 2026-07-31
+
+v0.3.0 streamlines production releases into a resumable orchestration with reusable hook receipts, consolidated approvals, and stronger consumer-install evidence.
+
+### Added
+
+- **Resumable ship orchestration**: the new `ship` command persists the active release state and resumes prepare, approval, publish, reconcile, and verification without rebuilding authority from conversational context.
+- **Reusable hook receipts**: `hooks validate` executes declared hooks through the same content-bound cache used by prepare, so unchanged checks do not need to run again.
+- **Manual consumer follow-ups**: Kimi and CodeBuddy installation tasks are emitted after automated publishing and explicitly remain outside system verification.
+- **Git transport preflight**: production publishing selects one repository-consistent HTTPS or SSH transport before any remote write and blocks conflicting remote identities.
+
+### Changed
+
+- **Consolidated human decisions**: the normal path requires one immutable-plan approval; invoking a command authorizes its configured hooks and gates, while manual consumer tasks are collected after publishing.
+- **Parallel consumer verification**: independent consumer checks run concurrently, drain before failure reporting, and produce deterministically ordered evidence.
+- **Automatic release metadata**: successful verification advances each unit's `previousPublicBaseline` to the frozen public commit, tree, and manifest digest.
+- **Compact prepare output**: JSON output references the immutable plan by path and digest instead of embedding the full plan.
+<!-- release-skill:changelog:end version=0.3.0 locale=en -->
+
+
 <!-- release-skill:changelog:start version=0.2.9 locale=en baseline=sha256:22b3d94c5d99fca0e6016334a108e4be5f3419f45507fae795b4d0714ca7ad6d -->
 ## [0.2.9] - 2026-07-31
 

package/INSTALL.md

@@ -2,7 +2,7 @@
 
 [简体中文](INSTALL.zh-CN.md)
 
-<!-- release-skill:release-version: 0.2.9 -->
+<!-- release-skill:release-version: 0.4.0 -->
 ## Prerequisites
 
 - Node.js 22.0.0 or later
@@ -78,9 +78,9 @@ Then install `release-skill` from the interactive `/plugins` browser.
 
 **Kimi Code** (interactive session):
 
-Kimi Code has no marketplace install API. Installation is manual, pinned to a
-specific release tag. See the [Kimi Code section](#install-as-a-kimi-code-plugin)
-for the version-pinned manual install and attestation closed loop.
+Kimi Code has no marketplace install API. Installation is a post-release manual
+task pinned to a specific release tag. release-skill reports the task but does
+not verify its completion.
 
 ### Alternative: direct repository install (advanced)
 
@@ -103,61 +103,24 @@ Kimi Code plugin manifest lives at `.kimi-plugin/plugin.json`, mirroring
 `.claude-plugin/plugin.json` and `.codex-plugin/plugin.json`, and the package
 ships `adapters/kimi/` next to `adapters/claude/` and `adapters/codex/`.
 
-For day-to-day installation, prefer the
-[unified marketplace path](#install-as-a-plugin-unified-marketplace--recommended)
-above. The remainder of this section documents the version-pinned manual
-closed loop that release-skill's own publish/verify pipeline relies on.
-
 Kimi Code has an interactive plugin marketplace but **no scriptable,
-non-interactive install API**. release-skill therefore models Kimi installation
-as a version-pinned **manual** install plus trusted observation/attestation:
-`publish`/`verify` never auto-install Kimi plugins. The closed loop is:
-
-1. `publish` performs the automated remote writes (Git branch/tag, npm, GitHub
-   Release). The `kimi-marketplace-install` action is recorded as `DEFERRED`
-   during publish — the marketplace adapter is not called, and the automated
-   install path fails closed. The run enters `PUBLISHED` after all remote
-   permanent writes are consistent. The run record gives the pinned install URL
-   and the attestation path.
-2. Read the requirement at
-   `<root>/.release-skill/kimi-attestations/<plugin>/release-skill-kimi-manual-install.json`.
-3. Launch Kimi Code and install from the release tag pinned to the exact
-   version (never the bare repository URL, which installs the latest release or
-   default branch), confirm the trust prompt, then reload. Before writing the
-   attestation you MUST confirm the installed plugin manifest version equals the
-   frozen version; otherwise do NOT issue an attestation.
+non-interactive install API**. For new release plans, `publish` completes the
+automated remote writes and returns a non-blocking `manualFollowUps` entry with
+the pinned install URL. `verify` does not install or inspect Kimi and reports
+`verifiedBySystem: false`; the task does not block `VERIFIED`.
+
+After publishing, a maintainer can launch Kimi Code and install from the release
+tag pinned to the exact version (never the bare repository URL, which installs
+the latest release or default branch), confirm the trust prompt, then reload:
 
    ```
-   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.2.9
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.4.0
    /plugins reload
    ```
 
-4. Write the attestation JSON to
-   `<root>/.release-skill/kimi-attestations/<plugin>/release-skill-kimi-attestation.json`.
-   `planDigest` MUST be the frozen **plan** digest; `result` accepts only
-   `"passed"` or `"failed"`. Example:
-
-```json
-{
-  "platform": "kimi",
-  "version": "0.2.9",
-  "planDigest": "<64-hex frozen plan digest>",
-  "result": "passed",
-  "actor": "<person who confirmed>",
-  "confirmedAt": "2026-07-23T00:00:00.000Z",
-  "note": "<optional note>"
-}
-```
-
-5. Run `release-skill verify --run <publish-run>` (→
-   `VERIFIED`). The verify command reads the attestation from the stable
-   plugin-level directory, so the fresh run directory does not lose the proof.
-
-When a platform has no reliable automated verification, the bound human
-`passed`/`failed` attestation is authoritative. The `verify` command consumes
-the human result and transitions to `VERIFIED` on success. However, identity,
-version, payload, marketplace source, or installation contract inconsistencies
-MUST NOT be overridden by a human `passed` result.
+No receipt or attestation is required. The `attest` command remains available
+only for frozen plans created by older versions that lack the
+`humanConsumersStrategy: manualFollowUps` marker.
 
 ## Install as a CodeBuddy/WorkBuddy plugin
 
@@ -172,56 +135,15 @@ expands inline like Claude Code expands `${CLAUDE_PLUGIN_ROOT}`. The build
 adapter directory is named `workbuddy` while the platform / distribution id is
 `codebuddy`; the two names refer to the same target.
 
-For day-to-day installation, prefer the
-[unified marketplace path](#install-as-a-plugin-unified-marketplace--recommended)
-above. The remainder of this section documents the manual attestation closed loop
-that release-skill's own publish/verify pipeline relies on.
-
 The codebuddy CLI can add a marketplace and install a plugin, but **neither
 `plugin marketplace add` nor `plugin install` accepts a ref option** — the install
 tracks the marketplace default branch / latest. An automated install checkpoint
 therefore cannot guarantee the frozen artifact's identity, so release-skill models
-CodeBuddy installation as a **manual** install plus trusted observation/
-attestation (the same capability gap and closed loop as Kimi Code):
-`publish`/`verify` never auto-install CodeBuddy plugins. The closed loop is:
-
-1. `publish` performs the automated remote writes (Git branch/tag, npm, GitHub
-   Release). The `codebuddy-marketplace-install` action is recorded as `DEFERRED`
-   during publish — the marketplace adapter is not called, and the automated
-   install path fails closed. The run enters `PUBLISHED` after all remote
-   permanent writes are consistent. The run record gives the attestation path.
-2. Read the requirement at
-   `<root>/.release-skill/codebuddy-attestations/<plugin>/release-skill-codebuddy-manual-install.json`.
-3. Install release-skill from the bundled-family marketplace `ifoohoo/release-skill`
-   (https://github.com/ifoohoo/release-skill). Before writing the
-   attestation you MUST confirm the installed plugin manifest version equals the
-   frozen version; otherwise do NOT issue an attestation.
-4. Write the attestation JSON to
-   `<root>/.release-skill/codebuddy-attestations/<plugin>/release-skill-codebuddy-attestation.json`.
-   `planDigest` MUST be the frozen **plan** digest; `result` accepts only
-   `"passed"` or `"failed"`. Example:
-
-```json
-{
-  "platform": "codebuddy",
-  "version": "0.2.9",
-  "planDigest": "<64-hex frozen plan digest>",
-  "result": "passed",
-  "actor": "<person who confirmed>",
-  "confirmedAt": "2026-07-23T00:00:00.000Z",
-  "note": "<optional note>"
-}
-```
-
-5. Run `release-skill verify --run <publish-run>` (→
-   `VERIFIED`). The verify command reads the attestation from the stable
-   plugin-level directory, so the fresh run directory does not lose the proof.
-
-When a platform has no reliable automated verification, the bound human
-`passed`/`failed` attestation is authoritative. The `verify` command consumes
-the human result and transitions to `VERIFIED` on success. However, identity,
-version, payload, marketplace source, or installation contract inconsistencies
-MUST NOT be overridden by a human `passed` result.
+CodeBuddy installation as a non-blocking post-release team task. `publish`
+returns it in `manualFollowUps`; `verify` does not inspect the installation and
+reports `verifiedBySystem: false`. Install from the bundled-family marketplace
+`ifoohoo/release-skill` after publishing. No receipt or attestation is required
+for new plans; `attest` exists only for old frozen-plan compatibility.
 
 For a single session from a source checkout you can also point CodeBuddy at the
 generated plugin directory with `--plugin-dir <path>/adapters/workbuddy`; the
@@ -408,9 +330,9 @@ documentation, and supply chain, then outputs a gap report. Without an explicit
 `prepare` is different: it writes release artifacts under the target project's
 `.release-skill/` directory and may run configured hooks. Hooks are unsandboxed
 arbitrary processes. They may write outside the project, access credentials,
-use the network, or perform remote writes. Review the displayed executable,
-arguments, and working directory before granting
-`--acknowledge-hook-side-effects`.
+use the network, or perform remote writes. The `prepare` command invocation
+itself authorizes execution of configured hooks and gates; no separate
+acknowledgement flag is required.
 
 For a Git repository, keep the human-owned project configuration while ignoring
 generated authority and evidence:
@@ -466,8 +388,9 @@ releaseUnits:
 
 ### Advanced: hooks (optional)
 
-Hooks are optional and run arbitrary local processes. They require explicit
-`--acknowledge-hook-side-effects` authorization when used with `prepare`.
+Hooks are optional and run arbitrary local processes. The `prepare` command
+invocation itself authorizes execution of configured hooks; no separate
+acknowledgement flag is required.
 
 ```yaml
 hooks:
@@ -507,12 +430,13 @@ script and every dependency it needs must exist in the frozen public snapshot;
 the gate cannot borrow tests, development dependencies, or `node_modules` from
 the parent workspace.
 
-Prepare and verify require `--acknowledge-gate-side-effects` whenever their
-planned phase contains gates. Hooks and gates are project processes without a
-network sandbox; release-skill limits their inputs and evidence but cannot
-guarantee that a custom command will not modify files or access the network.
-Never register Git push, tag, default-branch changes, GitHub Releases, or npm
-publish as a hook/gate; those are controlled plan actions.
+The `prepare` and `verify` command invocations authorize execution of
+configured gates; no separate acknowledgement flag is required. Hooks and
+gates are project processes without a network sandbox; release-skill limits
+their inputs and evidence but cannot guarantee that a custom command will not
+modify files or access the network. Never register Git push, tag,
+default-branch changes, GitHub Releases, or npm publish as a hook/gate; those
+are controlled plan actions.
 
 ### Advanced: release-document refresh (optional)
 

package/INSTALL.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.2.9 -->
+<!-- release-skill:release-version: 0.4.0 -->
 ## 前置条件
 
 - Node.js 22.0.0 或更高版本
@@ -73,8 +73,8 @@ codex plugin marketplace add ifoohoo/release-skill
 
 **Kimi Code**（交互会话中）：
 
-Kimi Code 没有市场安装接口，需手动安装并钉死到特定 release tag。详见
-[Kimi Code 小节](#安装为-kimi-code-插件)的版本钉死手动安装与证明闭环。
+Kimi Code 没有市场安装接口，发布后需手动安装并钉死到特定 release tag。
+release-skill 会返回待办，但不核验其完成结果。
 
 ### 备选：直接从仓库安装（进阶）
 
@@ -95,51 +95,21 @@ Kimi Code 是与 Claude Code 和 Codex 并列的受支持插件宿主。Kimi Cod
 `.codex-plugin/plugin.json` 对应；包内同时提供 `adapters/kimi/`，与
 `adapters/claude/`、`adapters/codex/` 并列。
 
-日常安装请优先使用上文的
-[统一市场路径](#安装为插件统一市场推荐)。本节其余部分记录的是
-release-skill 自身 publish/verify 流水线所依赖的“版本钉死手动闭环”。
-
 Kimi Code 有交互式插件市场，但**没有可脚本化的非交互安装接口**。因此
-release-skill 把 Kimi 安装建模为“版本钉死的手动安装 + 可信观测/人工证明”：
-`publish`/`verify` 从不对 Kimi 执行自动安装。完整闭环如下：
+新发布计划中，`publish` 完成自动化远端写入后返回非阻塞的
+`manualFollowUps`，其中含钉死的安装 URL；`verify` 不安装也不检查 Kimi，返回
+`verifiedBySystem: false`，该待办不阻塞 `VERIFIED`。
 
-1. `publish` 先完成自动化远端写入（Git branch/tag、npm、GitHub Release）。
-   `kimi-marketplace-install` 动作在 publish 阶段记录为 `DEFERRED`，不调用市场适配器，自动化安装路径失败关闭。全部远端永久写入一致后运行进入 `PUBLISHED`。运行记录会给出钉死的安装 URL 与证明写入路径。
-2. 读取 requirement：
-   `<root>/.release-skill/kimi-attestations/<plugin>/release-skill-kimi-manual-install.json`。
-3. 启动 Kimi Code，从钉死到精确版本的 release tag 安装（切勿使用裸仓库地址，
-   它会安装最新 release 或默认分支），确认信任提示后重新加载。写出证明之前，
-   必须核实已安装插件清单版本等于冻结版本；否则**不得**出具证明。
+发布完成后，维护者可启动 Kimi Code，从钉死到精确版本的 release tag 安装
+（切勿使用裸仓库地址，它会安装最新 release 或默认分支），确认信任提示后重新加载：
 
    ```
-   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.2.9
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.4.0
    /plugins reload
    ```
 
-4. 把人工结果 JSON 写入
-   `<root>/.release-skill/kimi-attestations/<plugin>/release-skill-kimi-attestation.json`。
-   `planDigest` 必须是冻结**计划**摘要；`result` 只接受 `"passed"` 或 `"failed"`。
-   示例：
-
-```json
-{
-  "platform": "kimi",
-  "version": "0.2.9",
-  "planDigest": "<64 位十六进制冻结计划摘要>",
-  "result": "passed",
-  "actor": "<确认人>",
-  "confirmedAt": "2026-07-23T00:00:00.000Z",
-  "note": "<可选备注>"
-}
-```
-
-5. 运行 `release-skill verify --run <publish-run>`（→
-   `VERIFIED`）。verify 命令从稳定的插件级目录读取证明，因此新的
-   run 目录不会丢失该证明。
-
-当平台没有可靠的自动化验证时，绑定后的人工 `passed`/`failed` 结果即为权威判定。
-`verify` 命令消费人工结果，成功后进入 `VERIFIED`。但身份、版本、载荷、市场来源
-或安装契约不一致时，不可被人工 `passed` 结果覆盖。
+新计划无需收据或人工证明。`attest` 命令仅兼容缺少
+`humanConsumersStrategy: manualFollowUps` 标记的旧冻结计划。
 
 ## 安装为 CodeBuddy/WorkBuddy 插件
 
@@ -152,48 +122,12 @@ CodeBuddy（桌面端产品 WorkBuddy）是与 Claude Code、Codex、Kimi Code
 `${CLAUDE_PLUGIN_ROOT}` 一样内联展开该变量。build adapter 目录名为 `workbuddy`，
 而平台 / 分发 id 为 `codebuddy`，两个名字指向同一目标。
 
-日常安装请优先使用上文的
-[统一市场路径](#安装为插件统一市场推荐)。本节其余部分记录的是
-release-skill 自身 publish/verify 流水线所依赖的“手动安装 + 可信证明闭环”。
-
 codebuddy CLI 可以添加市场并安装插件，但 **`plugin marketplace add` 与
 `plugin install` 均无 ref 选项**——安装会跟踪市场默认分支 / latest。因此自动化
 安装检查点无法保证冻结产物的同一性，release-skill 把 CodeBuddy 安装建模为
-“**手动**安装 + 可信观测/人工证明”（与 Kimi Code 相同的能力缺口与闭环）：
-`publish`/`verify` 从不对 CodeBuddy 执行自动安装。完整闭环如下：
-
-1. `publish` 先完成自动化远端写入（Git branch/tag、npm、GitHub Release）。
-   `codebuddy-marketplace-install` 动作在 publish 阶段记录为 `DEFERRED`，不调用
-   市场适配器，自动化安装路径失败关闭。全部远端永久写入一致后运行进入 `PUBLISHED`。运行记录会给出证明写入路径。
-2. 读取 requirement：
-   `<root>/.release-skill/codebuddy-attestations/<plugin>/release-skill-codebuddy-manual-install.json`。
-3. 从 bundled-family 市场 `ifoohoo/release-skill`
-   （https://github.com/ifoohoo/release-skill）安装 release-skill。
-   写出证明之前，必须核实已安装插件清单版本等于冻结版本；否则**不得**出具证明。
-4. 把人工结果 JSON 写入
-   `<root>/.release-skill/codebuddy-attestations/<plugin>/release-skill-codebuddy-attestation.json`。
-   `planDigest` 必须是冻结**计划**摘要；`result` 只接受 `"passed"` 或 `"failed"`。
-   示例：
-
-```json
-{
-  "platform": "codebuddy",
-  "version": "0.2.9",
-  "planDigest": "<64 位十六进制冻结计划摘要>",
-  "result": "passed",
-  "actor": "<确认人>",
-  "confirmedAt": "2026-07-23T00:00:00.000Z",
-  "note": "<可选备注>"
-}
-```
-
-5. 运行 `release-skill verify --run <publish-run>`（→
-   `VERIFIED`）。verify 命令从稳定的插件级目录读取证明，因此新的
-   run 目录不会丢失该证明。
-
-当平台没有可靠的自动化验证时，绑定后的人工 `passed`/`failed` 结果即为权威判定。
-`verify` 命令消费人工结果，成功后进入 `VERIFIED`。但身份、版本、载荷、市场来源
-或安装契约不一致时，不可被人工 `passed` 结果覆盖。
+发布后的非阻塞团队待办。`publish` 在 `manualFollowUps` 中返回任务；`verify`
+不检查安装并返回 `verifiedBySystem: false`。发布后从 bundled-family 市场
+`ifoohoo/release-skill` 安装即可。新计划无需收据或人工证明；`attest` 只兼容旧冻结计划。
 
 源码检出后也可以用 `--plugin-dir <path>/adapters/workbuddy` 把 CodeBuddy 指向
 生成的插件目录做单会话使用；适配器不引用自身目录之外的任何文件。
@@ -346,7 +280,7 @@ node -e 'require("node:fs").rmSync(process.argv[1],{recursive:true,force:false})
 
 该命令只读地检查项目结构、配置、文档和供应链；未显式传入 `--output` 时不写报告，也不运行项目 hook。
 
-`prepare` 不同：它在目标项目的 `.release-skill/` 下写入发布工件，并可能运行已配置 hook。hook 是无沙箱的任意进程，可能写到项目外、访问凭据、使用网络或执行远端写入。授予 `--acknowledge-hook-side-effects` 前必须审阅可执行文件、参数和工作目录。
+`prepare` 不同：它在目标项目的 `.release-skill/` 下写入发布工件，并可能运行已配置 hook。hook 是无沙箱的任意进程，可能写到项目外、访问凭据、使用网络或执行远端写入。`prepare` 命令调用本身即授权执行已配置的 hook 和 gate，无需额外授权参数。
 
 Git 仓库应保留人工配置，同时忽略生成的权威文件和证据：
 
@@ -400,7 +334,7 @@ releaseUnits:
 
 ### 进阶：hook（可选）
 
-hook 是可选的任意本地进程。prepare 使用 hook 时必须显式授予 `--acknowledge-hook-side-effects`：
+hook 是可选的任意本地进程。`prepare` 命令调用本身即授权执行已配置的 hook：
 
 ```yaml
 hooks:
@@ -432,7 +366,7 @@ verificationGates:
 
 这个自包含示例只读取已映射的公开文件。若替换成项目脚本，该脚本及全部依赖必须存在于冻结公开快照；gate 不能借用父工作空间中的测试、开发依赖或 `node_modules`。
 
-当计划的当前阶段包含 gate 时，prepare 或 verify 必须传入 `--acknowledge-gate-side-effects`。hook/gate 都是无网络沙箱的项目进程；release-skill 约束其输入与证据，但无法保证自定义命令不修改文件或不访问网络。禁止把 Git push、tag、默认分支修改、GitHub Release 或 npm publish 注册为 hook/gate，它们只能由受控的计划动作完成。
+`prepare` 和 `verify` 命令调用本身即授权执行已配置的 gate，无需额外授权参数。hook/gate 都是无网络沙箱的项目进程；release-skill 约束其输入与证据，但无法保证自定义命令不修改文件或不访问网络。禁止把 Git push、tag、默认分支修改、GitHub Release 或 npm publish 注册为 hook/gate，它们只能由受控的计划动作完成。
 
 ### 进阶：发布文档刷新（可选）