已决定发布时，端到端走完仓库…

适用于已决定发布某个待处理变更、且仓库有固定 shipping/releasing 检查清单和 CI 发布工作流时，把准备与发布收敛成一次有确认、可回滚、最终公开的流程。

适用场景

解决思路

1. 不要自动触发另一个用户调用的 skill；把 commit 与 tag + push 当作两个分别下注的时刻：commit 留在本地且可逆，tag + push 是唯一会公开的一步。
2. 对照待发布 diff 确认发布就绪：检查 AGENTS.md 的 Shipping checklist 中除版本 bump 和 `sip` 运行之外的所有适用项（版本 bump 和 `sip` 分别是第 2、3 步）。具体包括：任何新增或修改的 `SKILL.md` 形状正确（frontmatter 含 `name`+`description`；仅用户调用时才含 `disable-model-invocation`；正文含 Goal/Workflow/Rules/Verification）；README 和 `docs/readme/` 下每个本地化副本准确列出它，调用列正确，并处于 roster 的逻辑顺序中；同一顺序在 `plugin.json`、`scripts/catalog.cjs` 和 `re0-upgrade` 的 catalog 中保持一致，并与 `reorder` 同步；README 的 Problem removes-list 和 Fixes narrative 仅当它承载 thesis 时才收录（大多数 skill 两者都不收录——两者都是 curated）；`plugin.json` 注册其路径；任何重命名都按发布顺序向 `re0-upgrade` 的 deprecations checklist 追加 old -> new 行；共享跨 skill 规则（edit-safety、negatives-as-corpus、commit-economy）在所有携带它们的副本中保持一致。报告任何缺口并停止，不要靠猜越过它。
3. 分类版本 bump：新 skill 是 minor；修复或纯文档变更是 patch；移除 skill 且无替代路径是 major。对现有 skill 的增强——边界情况——按 kind 而不是 size 决定：相对于该 skill 自身先前 spec，旧行为是「错误」（修复 → patch；仅为修复服务的新 plumbing 仍为 patch）还是「正确但更窄/缺失某个维度」（用户新主动使用的新能力 → minor）？说明这个答案，而不只是 bump。
4. 如果安装了 `sip` 就运行它，并应用其发现。如果未安装，按顺序直接运行它的检查——cold-read（`shower`）、仅当有 claim 或 eval 时做 truth checks（`factchk`/`mandela`）、一致性（先 `ssotize` audit，批准后才 consolidation）、然后 tidy（`re0`）——并应用它们发现的问题。
5. 将 `package.json` 的 version bump 为第 2 步分类所得版本。
6. 按 commit-economy 起草提交信息——每个真实、持久变更一条 bullet，辅助编辑并入其中；不写 diff 或版本已能证明的内容；不加 co-author tags；匹配本地 log 自身形态，没有则用主题加每个变更一条 `-` bullet、单行不折行——从第一稿就这样，不要随编辑追加。如果已存在提交且需要清理，请人工运行 `re0-git`；不要自动调用它。
7. 请求明确确认，然后提交。
8. 写 `.re0/release/RELEASE_NOTES.local.md`——一个 gitignored、永不发布的本地暂存文件，作为签名标签的 message 随标签走——遵循 house style：一个 `##` 标题命名该发布的持久理念，而不是版本号；一段简短的现在时段落说明现在什么是真的；只写该发布挣得的章节（`### New`、`### Also`、仅当 roster 需要重新映射时的 `### The catalog (N skills)`、`### Install` 总是最后并以缩进块呈现）；每个外部贡献的变更以内联方式署名其 PR number 和作者 handle（`(#123, @handle)`）；skill 名称和路径用反引号；不写 tag 或 version 已能证明的内容。
9. 在打标签并推送前请求第二次、单独确认——这是唯一会公开的步骤。然后：`git tag -s vX.Y.Z -F .re0/release/RELEASE_NOTES.local.md --cleanup=verbatim`，推送 `main`，推送 tag。
10. 观察触发的 release workflow 直到完成；报告成功或实际失败，绝不假设它已落地。如果失败，修复原因并重跑它，或向前滚动版本——绝不要手工完成它的工作。
11. 一旦确认成功，关闭该发布落地的每个外部贡献：由审查过它的人先批准 PR 再关闭；被 squash 或重建进发布中的贡献是关闭而不是合并，所以批准才是将其记录为 accepted 而非 rejected 的动作；关闭评论要带上 release notes 给予的署名。任何有 review access 的 collaborator 或 maintainer 都可以做这件事；这不绑定到某一个 reviewer。
12. 然后退役已发布周期：将其 `.re0/iteration/<version>-<workname>/` 文件夹移入 `.re0/iteration/completed/<version>-<workname>/`，不重命名。`.re0/` 是 gitignored 且从不 tracked，所以用普通文件系统移动（`mv`），绝不用 `git mv`——后者在 untracked 路径上会直接失败。仅当该周期从未用 `re0-plan` 规划过且没有匹配的 iteration 文件夹时才跳过此步。
13. 绝不要发明或假设 CLI 命令或 flag；在写入将要执行的步骤前，对照官方文档或真实运行验证它。
14. 推送是全部人工步骤。绝不要手工运行 release workflow 拥有的步骤——发布、给 release page 命名、移动 tag——尤其不要为了抢救失败 run。手工运行的步骤会丢掉 workflow 在 artifact 之外附加的东西（signed provenance attestation、title convention、dist-tag），同时仍看起来像一次好的发布，所以什么都不会失败，只有与上一个 release 对比才会发现。
15. 如果待发布 diff 混合了不相关关注点，先说明并提议拆分，再起草信息——不要让一个提交的信息承担 diff 的工作。
16. 绝不要在本地版本匹配成立前推送（`package.json` 等于即将创建的 tag）；CI 检查是后备，不是第一道防线。
17. negatives-as-corpus——退役时移动 iteration 文件夹，绝不删除它。如果发布失败或回滚，让文件夹保持 live，而不是退役一个实际未发布的周期。
18. 完成前验证：`package.json` 的 version 与 tag 匹配。
19. 完成前验证：commit message 脱离 diff 也能独立读作干净的交接。
20. 完成前验证：release notes 遵循 house style 且只提本发布挣得的内容。
21. 完成前验证：已推送 tag 触发的 workflow run 成功完成——经确认，而非假设。
22. 完成前验证：没有手工运行任何 workflow 拥有的步骤，包括为抢救失败 run。
23. 完成前验证：该发布落地的每个外部贡献都已在关闭前批准 PR，并附上署名评论。
24. 完成前验证：已发布周期的 iteration 文件夹已退役到 `.re0/iteration/completed/`，或因为没有而正确跳过。
25. 完成前验证：报告任何跳过的步骤或未解决的缺口。

适用边界 · 注意事项

• 不适用于缺少本仓库发布约定的项目：没有 AGENTS.md Shipping checklist、`.re0/` 迭代目录、`package.json`、`plugin.json`、`scripts/catalog.cjs` 或对应 release workflow。
• 不适用于尚未决定发布、待发布 diff 尚未准备好，或只想做普通提交而不是进入发布流程的场景。
• 不适用于需要手工接管 CI/release workflow 步骤、绕过两次确认或自动触发其他 user-invoked skill 的场景。