用途：这是一条工作原则，主张对任何非琐碎的工作（编辑、迁移、分析、检查等），都应当构建能完成或证明该工作的工具，而不是手工去做。
主要能力与理由：构建工具带来两个收益。吞吐量方面，codemod、生成器或脚本每次都以相同方式完成工作并可免费重跑；可信度方面，工具是一份评审者可阅读、可重跑的产物，把“相信我”变成“运行它”，而手工改动只能靠重做来复核。
使用方式：先手工做第一个单元以摸清配方，然后构建工具，并通过在该单元上重跑工具、与手工版本做 diff 来验证。让工具可安全重跑。可选用 codemod 或脚本做编辑，生成器产出重复文件，dump-to-sqlite 查询做分析，可重跑检查做验证。确定性工具优于拆分委派：若工具能一次处理所有单元，就自己运行它，不要把这些单元分派给子智能体手工处理。当需要把工作分派给子智能体时，把工具写成它们都阅读的技能，将配方、验证契约和禁改边界放在同一产物中，并置于委派方的写权限范围之外，避免契约被悄然修改。若工作会超出本次会话，应提交该工具，让下次运行重跑而非重做。
适用场景：非琐碎工作，尤其是可重复、可验证的编辑、迁移、分析和检查。
限制：仅当任务确实琐碎（一眼可见的少量明显编辑）时才跳过构建工具。标准是“是否琐碎”，而非“是否重复”，一次性任务在工具能让工作可检查时同样值得构建。应构建能完成或证明任务的最小脚本，而非框架。该原则不同于将反复出现的指令固化为长期护栏的做法，也不同于对验证本身进行脚本化。