用途：这是一条工程实践原则，用于处理反复出现的指令与纠正。核心主张是把重复的修复编码进机制（工具、代码、元数据、自动化），而不是写成文字说明。
主要能力与要点：
- 触发条件：当你发现自己第二次写下同一条指令，或注意到反复出现的纠正时适用。
- 处理模式：先问这条规则能否做成 lint 规则、元数据标记、运行时检查或脚本；能则编码并删除该指令；不能（需要判断）则让指令更醒目并补充失败模式示例。
- 选择最强机制：当多种机制都可行时，选情境允许的最强机制（无法编译的不可表示状态 > 使 CI 失败的 lint 或禁用 API > 规范辅助函数 > 运行时检查），因为智能体会模仿周围代码，较弱的防护会成为下一个模板。
- 推论：若修复是结构性的，就只用结构性修复，文字指令只是症状。
反馈闭环：捕获每次纠正，判断是一次性还是模式；路由到正确层级（一次性→brain note，反复修复→skill 或 lint 规则，系统性问题→principle）；闭环，不只是记录，要立即应用或建立具体待办。
反模式：只承认不记录；只记录不路由；只修个案不泛化。
限制：资料未提供具体安装命令、代码示例、平台或收费信息。