re0-release

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Run this repo's shipping and releasing checklist on a pending change, then tag and publish once confirmed.

引导待处理变更走完本仓库的发布与交付检查清单，确认无误后进行打标签和发布。

Goal

目标

Make "prepare and ship a release" a single deliberate command instead of re-deriving the shipping and releasing checklist by hand every time. It runs

sip

when installed, applies commit-economy directly, and never auto-fires another user-invoked skill. It treats "commit" and "tag + push" as two separately-staked moments: a commit stays local and reversible, tag + push is the one step that goes public.

让「准备并发布版本」成为一个单一的明确命令，而非每次都手动梳理发布与交付检查清单。安装后运行

sip

，直接应用commit-economy原则，且绝不会自动触发其他用户调用的skill。它将「提交」和「打标签+推送」视为两个独立的关键节点：提交仅保留在本地且可撤销，打标签+推送是唯一公开的步骤。

Workflow

工作流程

Confirm shipping readiness against the pending diff — every applicable item from CLAUDE.md's Shipping checklist except the version bump and the
```
sip
```
run, which are steps 2 and 3 here:
- any new or changed
```
SKILL.md
```
  has the right shape (frontmatter
```
name
```
  +
```
description
```
  ,
```
disable-model-invocation
```
  only if user-invoked, body sections Goal/Workflow/Rules/Verification);
- the README and every localized copy under
```
docs/readme/
```
  list it accurately, with the right invocation column and in the roster's logical order — the same order held across
```
plugin.json
```
  ,
```
scripts/catalog.cjs
```
  , and
```
re0-upgrade
```
  's catalog, kept in lockstep with
```
reorder
```
  ; the README's Problem removes-list and Fixes narrative include it only if it carries the thesis (most skills earn neither — both are curated);
- ```
plugin.json
```
  registers its path;
- any rename appends an old -> new row to
```
re0-upgrade
```
  's deprecations checklist, in release order;
- shared cross-skill rules (edit-safety, negatives-as-corpus, commit-economy) stay coherent across every copy that carries them. Report any gap and stop rather than guessing past it.
Classify the version bump: a new skill is minor; a fix or docs-only change is patch; a skill removed with no replacement path is major. For an enhancement to an existing skill — the boundary case — decide by kind, not size: relative to the skill's own prior spec, was the old behavior wrong (a fix → patch; new plumbing that only serves a fix stays patch) or correct but narrower / missing a dimension (a new capability a user newly reaches for → minor)? State that answer, not just the bump.
Run
```
sip
```
if it is installed, and apply its findings. If it is not installed, run its checks directly in order — cold-read (
```
shower
```
), truth checks only when there is a claim or an eval (
```
factchk
```
/
```
mandela
```
), consistency (
```
ssotize
```
audit first, consolidation only after approval), then tidy (
```
re0
```
) — and apply what they find.
Bump
```
package.json
```
's version to the classification from step 2.
Draft the commit message to commit-economy — one bullet per real, durable change with supporting edits folded in, nothing the diff or version already proves, no co-author tags, matched to the local log's own shape or, absent one, a subject and one
```
-
```
bullet per change on a single unwrapped line — from the first draft, not appended to across edits. If a commit already exists and needs cleanup, ask the human to run
```
re0-git
```
; do not invoke it automatically.
Ask for explicit confirmation, then commit.
Write
```
.re0/release/RELEASE_NOTES.local.md
```
— a gitignored, never-shipped local scratch file that rides the signed tag as its message — to this house style: one
```
##
```
heading naming the release's durable idea, not the version; one short present-tense paragraph of what is true now; only the sections the release earns (
```
### New
```
,
```
### Also
```
,
```
### The catalog (N skills)
```
only when the roster needs re-mapping,
```
### Install
```
always last as an indented block); each externally-contributed change credited inline with its PR number and author handle (
```
(#123, @handle)
```
); skill names and paths in backticks; nothing the tag or version already proves.
Ask for a second, separate confirmation before tagging and pushing — this is the one step that goes public. Then:
```
git tag -s vX.Y.Z -F .re0/release/RELEASE_NOTES.local.md --cleanup=verbatim
```
, push
```
main
```
, push the tag.
Watch the triggered release workflow to completion; report success or the actual failure, never assume it landed. If it failed, fix the cause and re-run it or roll the version forward — never finish its work by hand.
Once success is confirmed, close out each external contribution the release landed: whoever reviewed it approves the PR before closing it — a contribution squashed or rebuilt into the release is closed, not merged, so the approval is what records it as accepted rather than rejected — and the closing comment carries the credit the release notes gave it. Any collaborator or maintainer with review access can do this; it is not tied to one reviewer.
Then retire the shipped cycle: move its
```
.re0/iteration/<version>-<workname>/
```
folder into
```
.re0/iteration/completed/<version>-<workname>/
```
, unrenamed.
```
.re0/
```
is gitignored and never tracked, so use a plain filesystem move (
```
mv
```
), never
```
git mv
```
— the latter fails outright on an untracked path. Skip this step only when the cycle was never planned with
```
re0-plan
```
and has no matching iteration folder.

根据待处理差异确认发布就绪状态——核对CLAUDE.md中发布检查清单的所有适用项，版本升级和
```
sip
```
运行除外（这两项是步骤2和3的内容）：
- 所有新增或修改的
```
SKILL.md
```
  格式正确（包含前置属性
```
name
```
  +
```
description
```
  ，仅当为用户触发时添加
```
disable-model-invocation
```
  ，正文包含Goal/Workflow/Rules/Verification章节）；
- README及
```
docs/readme/
```
  下的所有本地化副本均准确列出该变更，调用列正确且在技能列表中按逻辑排序——此排序需与
```
plugin.json
```
  、
```
scripts/catalog.cjs
```
  和
```
re0-upgrade
```
  的技能列表保持一致，通过
```
reorder
```
  命令同步；仅当变更承载核心主题时，才将其加入README的Problem移除列表和Fixes说明（大多数技能无需加入，这两部分均为精选内容）；
- ```
plugin.json
```
  已注册其路径；
- 若有重命名操作，需在
```
re0-upgrade
```
  的弃用检查清单中按发布顺序添加一条旧路径→新路径的记录；
- 跨技能共享规则（编辑安全性、negatives-as-corpus、commit-economy）在所有相关副本中保持一致。若发现任何遗漏，需立即报告并停止流程，不得自行猜测跳过。
确定版本升级类型：新增技能为次要版本（minor）；修复或仅文档变更为补丁版本（patch）；无替代方案的技能移除为主要版本（major）。对于现有技能的增强这种边界情况——需根据类型而非规模判断：相对于技能之前的规范，旧行为是错误的（属于修复→补丁版本；仅为支持修复而新增的底层逻辑仍属于补丁版本），还是正确但范围较窄/缺少维度（新增用户需要的功能→次要版本）？需明确说明判断依据，而非仅给出升级类型。
若已安装
```
sip
```
则运行它并应用其检查结果。若未安装
```
sip
```
，则直接按顺序执行其检查步骤——冷读检查（
```
shower
```
）、仅在存在声明或评估时进行事实核查（
```
factchk
```
/
```
mandela
```
）、一致性检查（先执行
```
ssotize
```
审计，获得批准后再进行合并），然后整理（
```
re0
```
）——并应用检查结果。
将
```
package.json
```
中的版本号更新为步骤2确定的版本类型。
按照commit-economy原则撰写提交信息——每个真实、持久的变更对应一个项目符号，附带相关编辑内容，无需包含差异或版本已能体现的信息，无需添加协作者标签，格式需与本地提交日志一致；若本地无日志格式，则主题行加一个
```
-
```
开头的项目符号，所有内容放在一行不换行——提交信息需一次成型，而非多次编辑后追加。若已有提交需要清理，请告知用户运行
```
re0-git
```
；不得自动触发该命令。
请求明确确认后，执行提交操作。
编写
```
.re0/release/RELEASE_NOTES.local.md
```
——这是一个被git忽略、不会被发布的本地临时文件，将作为签名标签的消息内容——需遵循以下格式：一个
```
##
```
标题，命名该版本的核心持久理念，而非版本号；一段简短的现在时段落说明当前状态；仅包含该版本对应的章节（
```
### New
```
、
```
### Also
```
、
```
### 技能列表（共N个技能）
```
仅当技能列表需要重新映射时添加，
```
### Install
```
始终作为缩进块放在最后）；每个外部贡献的变更需在文中注明PR编号和作者账号（
```
(#123, @handle)
```
）；技能名称和路径用反引号包裹；无需包含标签或版本已能体现的信息。
在打标签和推送前请求第二次独立确认——这是唯一公开的步骤。执行命令：
```
git tag -s vX.Y.Z -F .re0/release/RELEASE_NOTES.local.md --cleanup=verbatim
```
，推送
```
main
```
分支，推送标签。
监控触发的发布工作流直至完成；报告成功或实际失败原因，不得假设发布已完成。若发布失败，需修复问题后重新运行流程或升级版本——不得手动完成后续工作。
确认发布成功后，处理每个纳入版本的外部贡献：由审核者在关闭PR前批准该PR——被合并或重构到版本中的贡献需关闭而非合并，批准操作将记录该贡献被接受而非拒绝——关闭PR时的评论需包含发布说明中给出的致谢信息。任何具有审核权限的协作者或维护者均可执行此操作，无需指定单一审核者。
然后结束已发布的迭代周期：将
```
.re0/iteration/<version>-<workname>/
```
文件夹移动到
```
.re0/iteration/completed/<version>-<workname>/
```
，保持文件名不变。
```
.re0/
```
已被git忽略且未被追踪，因此需使用普通文件系统移动命令（
```
mv
```
），不得使用
```
git mv
```
——后者在未追踪路径上会直接失败。仅当该迭代未通过
```
re0-plan
```
规划且无对应迭代文件夹时，才可跳过此步骤。

Rules

规则

Never invent or assume a CLI command or flag; verify it against official docs or a real run before writing it into a step you will execute.
The push is the whole manual step. Never run a step the release workflow owns — publishing, titling the release page, moving a tag — by hand, least of all to rescue a failed run. A hand-run step drops what the workflow adds beyond the artifact (a signed provenance attestation, a title convention, a dist-tag) while still looking like a good release, so nothing fails and only a comparison against the previous release reveals it.
If the pending diff mixes unrelated concerns, say so and propose a split before drafting a message — don't let one commit's message do a diff's job.
Never push before the local version match holds (
```
package.json
```
equals the tag about to be created); the CI check is a backstop, not the first line of defense.
negatives-as-corpus — retirement moves the iteration folder, never deletes it. If the release fails or is rolled back, leave the folder live rather than retiring a cycle that didn't actually ship.

不得凭空创造或假设任何CLI命令或参数；在写入将执行的步骤前，需对照官方文档或实际运行结果进行验证。
推送是唯一的手动步骤。 不得手动执行发布工作流负责的步骤——如发布包、命名发布页面、移动标签——即使是为了挽救失败的运行也不行。手动执行步骤会丢失工作流除产物外添加的内容（签名来源证明、标题规范、dist-tag），但看起来仍像正常发布，因此不会报错，只有与上一版本对比才能发现问题。
若待处理差异包含无关内容，需告知用户并建议拆分后再撰写提交信息——不得让一个提交信息承担差异的说明工作。
在本地版本与即将创建的标签匹配前，不得推送；CI检查是兜底措施，而非第一道防线。
negatives-as-corpus原则——迭代文件夹需移动归档，不得删除。若发布失败或回滚，需保留文件夹而非归档未实际发布的周期。

Verification

验证

Before finishing:

```
package.json
```
's version matches the tag.
The commit message reads as a clean handoff on its own, without the diff.
Release notes follow the house style and mention only what this release earns.
The pushed tag's triggered workflow run completed successfully — confirmed, not assumed.
No step the workflow owns was run by hand, including to rescue a failed run.
Each external contribution the release landed had its PR approved before it was closed, with the credit comment attached.
The shipped cycle's iteration folder was retired into
```
.re0/iteration/completed/
```
, or correctly skipped because none existed.
Report any skipped step or unresolved gap.

完成前需确认：

```
package.json
```
的版本号与标签一致。
提交信息本身清晰易懂，无需依赖差异内容。
发布说明遵循格式规范，仅提及该版本对应的内容。
推送标签触发的工作流已成功完成——需确认，不得假设。
未手动执行任何工作流负责的步骤，包括为挽救失败运行而执行的步骤。
每个纳入版本的外部贡献的PR在关闭前已被批准，并附上致谢评论。
已发布周期的迭代文件夹已归档到
```
.re0/iteration/completed/
```
，或因无对应文件夹而正确跳过此步骤。
报告任何跳过的步骤或未解决的遗漏。