re0-merge

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Land a contribution fairly: credit preserved, the maintainer's changes legible, accepted on the record.

公平地合并贡献：保留署名权益，维护者的修改清晰可查，合并记录可追溯。

Goal

目标

A contribution is a gift with a permanent carrying cost, and a review either honors both or fails one.

re0-merge

walks whoever reviews — any collaborator or maintainer, not just the author — through accepting a pull request the way this suite does: judged against the thesis, landed with the author's authorship intact, the maintainer's own edits kept as separate commits, and closed with an approval and a credit rather than a silent rejection.

贡献是一份带有长期维护成本的馈赠，评审工作要么兼顾两者，要么顾此失彼。

re0-merge

引导任何进行评审的人员——包括所有协作者或维护者，而非仅作者本人——按照此套件的流程接受拉取请求（PR）：依据项目核心准则进行评判，保留作者的署名信息，维护者自身的修改作为独立提交，以批准和署名致谢的方式关闭PR，而非静默拒绝。

Workflow

工作流程

Gate before landing. An additive contribution is declined by default; the burden is on the addition to show the suite is worse without it, not on you to justify a no. Judge each PR alone, never as a batch: a bug-fix subtracts a defect and is the easy yes; new tooling earns a place only if it mechanizes a rule already enforced by hand; a new skill lands only if it closes a real gap no existing one covers. A well-reasoned decline is a shipped outcome, not a failure.
Cold-read it first. Read the contribution end to end with fresh eyes (a
```
shower
```
pass when installed) before deciding; a name or claim that reads clean to its author may not to a stranger.
Verify, do not re-fix. Where the author already pushed a fix, prove it with a throwaway regression case rather than rewriting it; the credit for the fix is theirs.
Approve as you accept, then land on a
land/pr-<n>
branch (a range only for a genuine multi-PR batch). Submit the approving review the moment you decide to accept, before the land — it is a verdict on the contributor's code, not a receipt for a release, and giving it now (not bundled with the later close) is what keeps a closed-not-merged PR reading as accepted. Then accept each contributor commit with its authorship preserved (you become the committer; clean the message with
```
re0-git
```
), add every maintainer change as its own separate commit so the credit split stays legible, and fast-forward into
```
main
```
.
Complete a new skill, don't merge it raw. Get the name right (a plain real word or tight compression, no opaque coinage), the invocation right (model- vs user-invoked), and the home right; then register it on every roster surface (
```
plugin.json
```
, the README Index in root and every localized copy,
```
re0-upgrade
```
's Current catalog,
```
scripts/catalog.cjs
```
) so no drift-guard trips.
After the release the contribution shipped in confirms, close the PR with the comment. Close it in the same motion as a comment that credits and explains — never a silent close, and never before the release lands. The approval from step 4 already records it as accepted; this step only closes and explains.
The comment credits and explains, warmly. Shout the contribution out in the release notes with its PR number and author handle; and if you renamed or reframed anything, the closing comment thanks the author, says what changed and why, points at the release it shipped in, and hands the credit for the core idea back to them.

合并前准入审核。默认拒绝新增类贡献；新增内容需证明缺少它会导致套件功能受损，而非由你去阐述拒绝的理由。单独评审每个PR，绝不批量处理：修复bug的PR消除了缺陷，应直接批准；新增工具类内容只有在能够将已手动执行的规则自动化时才被接纳；新增Skill只有在填补了现有Skill未覆盖的真实空白时才可合并。有理有据的拒绝也是一种有效结果，而非失败。
先客观通读。以全新视角完整阅读贡献内容（安装
```
shower
```
工具后可使用其功能辅助）再做决定；对作者而言清晰易懂的命名或表述，对其他人可能并非如此。
验证而非重写修复。若作者已提交修复内容，通过临时回归用例验证其有效性，而非重写；修复的署名权益归作者所有。
接受时即批准，随后在
land/pr-<n>
分支合并（仅当确实是多PR批量处理时才使用范围分支）。一旦决定接受，立即提交批准评审，无需等到合并完成——这是对贡献者代码的评判，而非发布的回执，提前批准（而非与后续关闭操作捆绑）可确保“已关闭未合并”的PR仍被视为已接受。然后保留作者署名信息接受每个贡献者的提交（你将成为提交者；可使用
```
re0-git
```
清理提交信息），将维护者的每一处修改作为独立提交，确保署名划分清晰可查，最后快进合并到
```
main
```
分支。
完善新增Skill，而非直接原始合并。确保命名准确（使用平实的常用词或简洁缩写，避免晦涩自创词汇）、调用方式正确（模型触发 vs 用户触发）、归属正确；随后在所有清单表面注册（
```
plugin.json
```
、根目录及所有本地化副本的README索引、
```
re0-upgrade
```
的当前目录、
```
scripts/catalog.cjs
```
），避免触发任何漂移防护机制。
确认贡献已随版本发布后，附带评论关闭PR。关闭PR的同时附上署名致谢并作出说明的评论——绝不静默关闭，且绝不在版本发布前关闭。步骤4中的批准已记录其为已接受；此步骤仅用于关闭PR并作出说明。
评论需包含署名致谢与清晰说明，态度友好。在发布说明中提及该贡献，包含PR编号和作者账号；若你对内容进行了重命名或重构，关闭评论中需感谢作者，说明修改内容及原因，指明其所属的发布版本，并将核心创意的署名权益归还给作者。

Rules

规则

Default-deny for surface, but decline well: a reason tied to the thesis, the branch kept, never a silent close (negatives-as-corpus).
Preserve authorship. The contributor authors their commit; every maintainer edit is a separate commit under the maintainer's name.
Approve as you accept, before the land — not bundled with the close after the release. The approval is a verdict on the contributor's code, not a receipt for a release that could fail. Any collaborator or maintainer with review access does this, not one fixed reviewer.
Explain every deviation to the author, in their favor. A rename or reframe they did not ask for gets its reason.
Reviewer-agnostic and self-degrading: run whatever pipeline skills are installed (
```
shower
```
,
```
re0-git
```
,
```
re0-release
```
), and do their step by hand when they are not.

默认拒绝新增表面内容，但需合理拒绝：给出与项目核心准则相关的理由，保留分支，绝不静默关闭（将拒绝案例作为参考 corpus）。
保留署名权益。贡献者为其提交署名；维护者的每一处修改均作为独立提交，使用维护者本人的署名。
接受时即批准，无需等到合并完成——不要与版本发布后的关闭操作捆绑。批准是对贡献者代码的评判，而非可能失败的发布的回执。任何拥有评审权限的协作者或维护者均可执行此操作，而非固定的单一评审者。
向作者解释所有偏离其提交的修改，且需以友好的方式。若进行了作者未要求的重命名或重构，需说明原因。
评审者无关性与自适应性：运行已安装的所有流水线Skill（
```
shower
```
、
```
re0-git
```
、
```
re0-release
```
），未安装时则手动执行相应步骤。

Verification

验证

Before finishing:

Every landed contribution kept its author's authorship, with maintainer edits as separate commits.
The PR was approved before it was closed, and closed with a credit comment.
A new skill is registered on every roster surface, checks green.
Every decline names a thesis-tied reason and keeps its branch.
Any rename or reframe was explained to the author.

完成前需确认：

所有合并的贡献均保留了作者的署名信息，维护者的修改为独立提交。
PR在关闭前已获得批准，且关闭时附带了署名致谢评论。
新增Skill已在所有清单表面注册，检查全部通过。
每一次拒绝均给出了与项目核心准则相关的理由，并保留了分支。
任何重命名或重构均已向作者说明原因。