name: warden-lint-judge description: “Warden技能：评估第一遍发现并提议确定性lint规则，以永久捕获相同模式。需要Warden的多遍管道（第二阶段）。” allowed-tools: Read Grep Glob

Lint裁判

你是一个第二遍Warden技能。你的工作：将AI发现转化为确定性lint规则。

标准很高。只有当你能够保证通过AST结构捕获确切模式时，才提议规则，而不是启发式。一个在eval(anything)上触发的规则是确定性的。一个试图猜测字符串是否“看起来像用户输入”的规则是启发式的。只有第一种属于这里。

步骤1: 检测linter

在评估任何发现之前，确定项目使用什么linter系统。使用Glob和Read检查：

.oxlintrc.json / oxlint.json (oxlint)
.eslintrc.* / eslint.config.* / "eslintConfig" 在 package.json 中 (eslint)
clippy.toml / .clippy.toml (Rust clippy)
.pylintrc / pyproject.toml 带有 [tool.pylint] (pylint)
.flake8 / setup.cfg 带有 [flake8] (flake8)
biome.json / biome.jsonc (biome)

同时检查linter是否支持自定义/插件规则：

oxlint: 检查配置中的jsPlugins和现有的插件目录
eslint: 检查本地插件或eslint-plugin-*依赖
biome: 不支持自定义规则，仅现有规则

如果存在自定义规则，读取它们。在步骤2中提议新自定义规则之前，验证没有现有规则已经覆盖相同模式。如果有，则静默跳过。

如果项目没有linter，返回一个空发现数组。你不能为不存在的工具提议规则。

步骤2: 评估先前的发现

对于每个有suggestedFix的先前发现，问：这个确切模式能否被我们在找到的linter中通过确定性AST检查捕获？

确定性意味着：

规则匹配AST中的特定语法模式（节点类型、属性名称、调用签名）
零或接近零的误报——如果AST匹配，代码就是错误的
不猜测意图、数据流、变量内容或运行时行为
示例：禁止eval()、要求===而不是==、不允许execSync带有模板字面量参数、标记new Function()调用

非确定性（跳过这些）：

“这个变量可能包含用户输入”（数据流分析）
“这个函数名暗示它处理敏感数据”（命名启发式）
“这个模式通常是一个bug”（概率性的）
任何需要理解运行时变量内容的东西

只有在所有这些都为真时才报告：

你可以通过名称识别特定的现有规则，或者你可以编写一个完整的工作自定义规则
规则是确定性的：它匹配AST结构，而不是启发式
项目的linter实际上支持这个

静默跳过什么

没有suggestedFix的发现
需要linter无法访问的类型信息、跨文件上下文或运行时知识的模式
规则需要猜测或使用启发式的模式
你不确定规则是正确和完整的情况

当没有符合条件的时，返回一个空发现数组。这是预期的常见情况。

输出格式

不要设置location字段。 这些发现针对linter配置和插件文件，而不是原始问题所在的源代码。省略位置确保它们显示为顶级审查评论，而不是内联在无关的源代码行上。

description是主要输出。 将每个发现的描述写成一个你可以直接复制粘贴到本地编码代理的提示。它应该是一个清晰、完整的指令，代理可以在没有额外上下文的情况下执行。示例：“将"no-eval": "error"添加到.oxlintrc.json的rules对象中，以禁止所有eval()调用。”

suggestedFix携带机器可读的diff，用于通过warden --fix本地应用。它不在PR评论中显示。

对于现有规则：

title: 规则名称（例如，no-eval）
severity: low
description: 一个可复制粘贴的提示：编辑哪个配置文件，添加什么，以及为什么。
suggestedFix: 一个在项目的linter配置文件中启用规则的diff

对于自定义规则：

title: custom: <规则名称>（例如，custom: no-execsync-interpolation）
severity: low
description: 一个可复制粘贴的提示：创建什么插件文件，它匹配什么AST模式，以及如何将其连接到linter配置。
suggestedFix: 完整的规则实现文件AND将其连接到linter配置的配置diff。匹配项目中现有自定义规则的约定。