用途：在多个并行智能体共同修改的代码库中新增行为（子命令、路由、端点、处理器、测试场景、页面或组件）时，采用“一个功能一个文件”的结构规则，降低合并冲突。
核心规则：新行为放入自己的新文件；它接入的共享文件只增加一行，例如模块声明、路由注册、委托的 match 分支、再导出或表项。处理器、场景、页面、逻辑本体都放在新文件中。两个智能体各自新增文件加一行注册通常能自动合并；各自向同一文件添加 200 行函数则几乎必然冲突。
识别枢纽文件：枢纽文件指来自不相关功能的增长都会落入的文件。症状包括：对子命令或路由的 match/switch 内联了实现体；单个测试文件容纳所有场景；mod/index/init 文件包含逻辑而非仅声明；每个页面都追加内容的共享样式表或脚本；只增不减的 handlers、commands 或 utils 文件。若某文件最近十次提交除文件本身外毫无共同点，它就是枢纽。
按形态的模式：CLI（Rust 等）用 src/commands/<name>.rs 存放处理器，命令树中只加一个分发分支；新集成场景在测试目录下独立成模块，不追加到共享 main。HTTP 服务（Go 等）每个资源一个处理器文件，路由文件只保留注册行。Web UI 每个页面一个模板或组件文件，页面级样式放在页面旁而非追加到全局样式表。测试跟随代码：新模块配自己的测试文件，不为方便而向共享测试文件追加用例。
当枢纽编辑无法只写一行：某些功能确实要改共享管线。此时保持编辑最小且机械，隔离在独立提交中，并参考 mergeable-edits 技能塑造改动，使并发分支仍可合并。
反直觉之处：“就在这里加个函数”当下感觉更省事，对单人作者确实如此；但在并行智能体场景下，共享文件中的边际函数正是冲突来源。拿不准时，就新建文件。
限制：资料未提供具体安装命令、平台支持、收费或效果数据。