用途：这是一条工程工作原则，适用于任何非平凡的工作，不只是批量任务，包括编辑、迁移、分析、检查等。核心主张是：当工作不琐碎时，应构建能完成它或证明它的工具，而不是手工去做。
主要能力与理由：codemod、生成器或脚本以相同方式重复执行工作，并可免费重跑。工具是一份产物，审查者可以阅读并重跑以核查工作。手改的变更只能通过重做来再次验证。确定性脚本把"信任我"变成"运行这个"。
使用方式：默认构建工具（lever）。仅当任务微不足道、只需几处一眼可见的明显编辑时才跳过。先手工做第一个单元以掌握配方，然后构建工具；通过在该单元上重跑并与手工版本做 diff 来验证。让工具可安全重跑。按类型选择：编辑用 codemod 或脚本，重复文件用生成器，分析用 dump-to-sqlite 查询，验证用可重跑的检查。
确定性的工具优于扇出。如果工具能一次处理所有单元，就自己运行，不要把脚本能做的事分派给委派者手工应用。当把工作分派给子代理时，把工具写成一个所有子代理都读取的技能：配方、验证契约和禁改边界放在同一份产物中，并放在委派者写入范围之外，使它们无法悄悄修改契约。
应用此原则会产生一个文件。如果引用了它而 diff 中没有 codemod、脚本、生成器或委派技能，就是没有应用。当工作的生命周期超过本次会话时，提交该工具。
限制与边界：标准是"琐碎性"，而非重复性。一次性工作若工具能让工作可核查，也值得构建工具。最小的能完成或证明任务的脚本即可，绝不要做成框架。此原则区别于"Encode Lessons in Structure"（后者把反复出现的指令变成持久护栏）；本原则关注眼前工作的吞吐量与可审阅性。关于对验证本身进行脚本化，参见"Prove It Works"。具体命令与示例资料暂未提供。