当现成 lint 规则无法覆盖某条代码评审规则时…

把一条没有现成 linter 规则可匹配的文字规则，合成为自定义 lint 规则，并用独立意图测试做信任门禁，不健全就退回文字规则。

适用场景

解决思路

1. 检测语言与工具链：读取仓库确定主要语言、正在使用的 linter（ESLint、Ruff、Pylint、Clippy、RuboCop、Stylelint 等）、测试框架和已有自定义规则（以匹配约定）；若无法确定（多语言仓库、无 linter 配置、多个候选），先询问用户再生成任何内容。
2. 先复用再合成（ADOPT > REUSE > SYNTHESIZE）：合成是最后手段。先检查已有插件/内置规则（参考插件表和 no-restricted-* 系列）；再尝试内置构造规则（ESLint 的 no-restricted-syntax / no-restricted-imports、Ruff/Pylint 的 select、RuboCop 的 cop 等）；只有当规则需要 AST 分析、自动修复或现成规则不提供的选项时才合成。若现成规则适用，启用它（一行配置）并跳到第 6 步，不要合成。
3. 按语言选择参考文档：JavaScript/TypeScript 用 ESLint（../../../skills/linter-docs/eslint.md）；Python 用 Ruff（../../../skills/linter-docs/ruff.md）或 Pylint（../../../skills/linter-docs/pylint.md）；Ruby 用 RuboCop（../../../skills/linter-docs/rubocop.md）；Rust 用 Clippy（../../../skills/linter-docs/clippy.md）；CSS 用 Stylelint（../../../skills/linter-docs/stylelint.md）。Go 则生成 golang.org/x/tools/go/analysis 分析器并用 analysistest 测试；其他语言用最地道的 lint 方案并附测试用例和集成说明。
4. 明确意图再读代码库：确定确切违规（如“无硬编码密钥”不只是名为 password 的变量，还包括 apiKey、token、无环境变量的字面量；“API 调用要包重试”需要真实调用签名和包装器签名）；确定修复形式（在本代码库中合规写法具体长什么样，读真实文件确认 helper 的导入路径和调用形状）；确定干净的相似物（看起来像违规但其实不是：字符串、注释、JSDoc @example 中的模式；别名/命名空间形式）。若有歧义（如“API 调用包重试”通常有歧义），询问用户而不是猜测。
5. 合成规则与独立意图测试两个产物：规则优先用 AST/关键字分析而非文本/子串扫描（文本扫描会在散文中的模式上误报，基于名称的检查器会漏掉同义词）；遵循参考文档的结构、fix/suggest 和注册指南。测试必须编码意图而非检查器的捷径，并加入能击破朴素合成的对抗用例：valid（不得标记）包括字符串字面量、行注释、JSDoc/docstring @example 中的模式，仅包含关键字的 camelCase 标识符（如 consoleLog），看起来接近的合规调用；invalid（必须标记）包括违规的所有真实形式——同义词（apiKey/token，不只是 password）、别名/命名空间形式（window.console.log）、以不同方式包装的情况。不要让测试迁就检查器走的捷径。
6. 信任门禁：精确率和召回率都必须为 1.0。用第 4 步的测试运行合成检查器（ESLint RuleTester、pytest、analysistest 等）。通过（每个 invalid 都被标记、每个 valid 都干净）则规则 KEPT，可安全强制执行，继续第 6 步；泄漏（任何误报或漏报）则规则 ABSTAINED，不要接入，如实报告泄漏原因（如“匹配到注释中的模式”“漏掉 apiKey”），要么把规则退回为文字，要么修复检查器后重跑门禁，但绝不发布未通过门禁的检查器。参考门禁在 rule-enforcer/gate.js（两阶段：自测 + 盲对抗金标集），典型对抗用例在 rule-enforcer/gold/gold.json，可运行端到端演示（cd rule-enforcer && npm run demo，观察它保留健全规则并放弃两个泄漏规则）；阅读它们了解用例形态和放弃纪律，然后照搬，不要重新发明门禁。
7. 把 KEPT 规则接入指令文件：仅对通过门禁的规则（或第 2 步复用的现成规则）执行。v2 规格（仓库有 CLAUDE.md.spec.ts）：添加 enforce() 行并重新编译——"<rule-id>": enforce("<linter>/<rule-name>", "<why>")，然后运行 npx vigiles compile。v1（手写 CLAUDE.md）：追加 ### <规则标题——祈使句、简洁>，**Enforced by:** `<linter>/<rule-name>`，**Why:** <一句话——架构原因>。
8. 如实呈现结果：对保留的规则，展示生成的文件、门禁证据（通过的对抗用例）、集成步骤、spec/CLAUDE.md 块以及验证方式（运行 linter，看它捕获真实违规）；对被放弃的规则，说明是哪条规则、为什么泄漏、它保持为文字——拒绝一个检查器是正确结果，不是要隐藏的失败。在写任何文件或编辑 spec/CLAUDE.md 之前先询问用户，不要自动为用户写入任何内容。

适用边界 · 注意事项

• 当现成 linter 规则或插件已经能覆盖该规则时——应直接启用现成规则（strengthen 结果），不要合成。
• 当规则意图含糊且用户无法澄清时——基于猜测意图的规则最终也过不了门禁，应先询问。
• 当检查器无法通过信任门禁（精确率或召回率不为 1.0）时——不要接入，退回为文字规则。