用途：当发现自己第二次写同一条指令，或察觉到反复出现的纠正时，用于判断该规则能否改由机制强制执行。核心观点是：每条错误、人工纠正和意外结果都是学习信号，应被捕获、分流并闭环；文字指令容易被漏掉，而结构机制无需配合即可生效。
主要能力：给出一个判断模式。先问这条重复指令能否变成 lint 规则、元数据标记、运行时检查或脚本；能则编码进去并删除原指令。若确实需要判断力、无法结构化，则把指令写得更醒目，并附上失败模式的例子。
机制选择：当多种机制都可行时，选情境允许的最强机制——依次为“不可表示、无法编译的状态”“会让 CI 失败的 lint 或被禁用的 API”“规范助手”“运行时检查”，因为智能体会复制周围代码的现有做法，较弱的防护会成为下一个模板。推论：若修复是结构性的，就只用结构修复，文字指令只是症状。
分流与闭环：当人工介入或测试失败时，判断是一次性问题还是模式。一次性问题记入 brain note；反复出现的修复升级为技能或 lint 规则；系统性问题升级为原则。闭环意味着不只有记录：要么立即应用，要么创建具体的待办事项。
反模式：只承认不记录（“我会记着”不会持久）；只记录不分流（把本该实现的 lint 规则写成笔记而不去实现，等于浪费）；只修复不泛化（修好单个实例却留下反复出现的模式）。
限制：资料未提供具体命令、安装方式、依赖、收费或平台支持信息。