mergeable-edits 是一项面向多智能体并行开发的编辑规范技能，适用于多个并行智能体同时修改同一共享文件的场景，例如调度器、路由器、注册表、配置列表、变更日志、锁文件和生成文件。
用途
结构可以避免大部分冲突（参见 one-feature-one-file），本技能处理那些结构上无法消除、确实需要共享的文件：注册行、注册表、配置列表以及生成文件。目标是让编辑的形态适配 git 基于行的合并机制，使并发分支能够自行合并。
列表与注册表
每行一项，每行都带行尾逗号或分隔符，这样新增一项就是严格的单行 diff，不触碰相邻行。
按稳定顺序插入，除非列表对顺序敏感，否则使用字母序。追加到末尾会让每个并发分支都碰撞在同一最后一行；有序插入会分散到文件各处，从而干净合并。
对于确实是顺序无关的行集合，可以使用 .gitattributes 的 merge=union 驱动来完全消除冲突。但要谨慎使用：union 合并从不报告冲突，因此只适用于重复行或重排行无害的场景。
格式化器与 lint 自动修复器不受此限
始终运行仓库的规范格式化器和 lint 自动修复器。它们的输出是确定性的，因此所有运行它们的分支会收敛到相同文本，而不是产生冲突；跳过它们才是格式冲突的根源。下述归属规则约束的是人为裁量的编辑，绝不约束工具强制执行的编辑。
有一条范围规则：如果格式化器想改动你的工作从未触及的文件，那是既有的漂移，不属于你的改动。只格式化你编辑过的文件，其余保持不动，或者把漂移清理作为独立提交落地。不要把它混入功能开发中。
不要拥有你未改动的部分
绝不要手工重排段落、重排代码、重新编号列表，或把仓库工具并未强制执行的风格偏好应用到你的改动未触及的区域。你主动重写的每一行，都是你今后会冲突的一行。
仓库级批量改动（采用新的格式化器配置、启用新的 lint 规则及其自动修复）应放在独立提交中，在没有功能分支在途时落地，绝不混入功能开发。
不要在共享文件里顺手修复。记录问题，并在单独的改动中修复。
生成文件与锁文件
绝不手工编辑它们，也绝不手工解决其中的冲突。整体取任意一侧，然后用所属工具重新生成（templ generate、针对 Cargo.lock 的 cargo build、go mod tidy、针对编译产物的打包器）。生成器的输出才是唯一正确的内容，手工合并的版本会以测试可能无法发现的方式出错。
如果某个生成文件频繁冲突，就要质疑它是否真的需要纳入版本控制；在 CI 中构建它可能才是真正的修复。
解决枢纽文件中的冲突
当冲突确实落在调度器或注册表中时，按意图解决：两个分支的单行条目都保留，并置于文件的稳定顺序中。然后重跑格式化器和测试。并行智能体的典型 bug 是解决后的注册表静默丢掉了某个分支的条目；提交前要显式检查这一点。