re0-merge

让贡献者的贡献得到公正认可：保留署名，让维护者的修改清晰可见，并以正式记录接受贡献。

目标

贡献是一份礼物，却也带来永久的维护成本；评审要么兼顾这两点，要么辜负其中一点。re0-merge 会引导所有评审者——任何协作者或维护者，而不只是作者——按照本套件的方式接受拉取请求：以项目主张为准进行评判，合并时保留作者的署名，将维护者自己的修改作为独立提交保留，并以批准和致谢结束，而非悄无声息地拒绝。

工作流

1. 合并前先把关。 默认拒绝增量式贡献；举证责任在新增内容一方，要证明没有它套件会更差，而不是由你来解释为什么不接受。逐个评审 PR，绝不打包评审：修复缺陷能消除问题，是最容易接受的；新增工具只有在能将已有的手动执行规则自动化时才有立足之地；新增技能只有在填补现有技能都无法覆盖的实际空缺时才能合并。理由充分的拒绝也是已交付的结果，并非失败。
2. 先从头到尾阅读。 决定前，以全新的视角通读贡献（如果已安装，则使用 shower 流程）；作者看来清晰的名称或说法，陌生人未必能看懂。
3. 验证，不要重复修复。 如果作者已经推送了修复，就用一次性回归用例验证，而不是重写；修复的功劳归作者。
4. 接受时批准，然后在 land/pr-<n> 分支上合并（只有真正的多 PR 批次才使用范围）。决定接受后，立即提交批准评审，再进行合并——这是对贡献者代码的判定，不是发布的收据；现在就批准（而非与之后的关闭操作捆绑），才能让已关闭但未合并的 PR 仍清楚地显示为已接受。然后接受每个贡献者提交，同时保留其作者署名（你成为提交者；使用 re0-git 清理提交消息），将每项维护者修改都作为单独提交添加，以清晰呈现功劳分配，最后快进合并到 main。
5. 完善新技能，不要原样合并。 确定合适的名称（普通实词或简洁缩写，不要晦涩生造词）、调用方式（由模型还是用户调用）和归属位置；然后在所有清单位置登记该技能（plugin.json、根目录及每个本地化副本中的 README Index、re0-upgrade 的 Current 目录、scripts/catalog.cjs），以免触发漂移检查。
6. 确认发布版本中包含该贡献后，再用评论关闭 PR。 关闭 PR 时要同时发表评论，致谢并说明情况——绝不悄无声息地关闭，也绝不在发布合并前关闭。第 4 步中的批准已经记录了接受结果；这一步只负责关闭并解释。
7. 评论要热情地致谢并说明情况。 在发布说明中注明 PR 编号和作者账号，公开致谢；如果你重命名或重新界定了内容，关闭评论要感谢作者、说明改了什么及原因、指出该内容随哪个版本发布，并将核心想法的功劳归还给作者。

规则

• 对新增内容默认拒绝，但要妥善说明拒绝理由：给出与项目主张相关的理由，保留分支，绝不悄无声息地关闭（将拒绝记录为语料）。
• 保留作者署名。贡献者为其提交署名；维护者的每项修改都作为独立提交，并署维护者之名。
• 接受时批准，并在合并前完成——不要拖到发布后与关闭操作捆绑。批准是对贡献者代码的判定，而不是对可能失败的发布的收据。任何拥有评审权限的协作者或维护者都可以这样做，不限定某位评审者。
• 解释对作者所做的每一处改动，并以维护作者利益为出发点。对于作者未要求的重命名或重新界定，要说明原因。
• 不依赖特定评审者，并能在能力不足时降级执行：运行已安装的流水线技能（shower、re0-git、re0-release）；未安装时，则手动完成相应步骤。

验证

完成前：

1. 每项已合并的贡献都保留了作者署名，维护者的修改则作为单独的提交。
2. PR 在关闭前已获批准，并附上署名致谢评论后关闭。
3. 新技能已在所有名单页面上登记，检查均已通过。
4. 每项拒绝都说明了与论点相关的原因，并保留其分支。
5. 任何重命名或重新定位都已向作者说明。