关于 warden-lint-judge
Warden 的二次审查 Skill,用于判断 AI 审查发现能否转化为确定性 lint 规则。它先检查项目使用的 linter 及插件支持,只提出能匹配明确 AST 结构、无需启发式判断的规则。
主要功能
- 01识别项目的 linter 和配置
- 02检查自定义规则及插件支持
- 03评估发现是否符合确定性 AST 匹配
- 04跳过启发式或不受支持的规则
- 05整理可执行的规则建议
适用场景
- 01将审查发现转化为 lint 规则
- 02判断模式能否在不猜测数据流的情况下匹配
- 03为现有 linter 配置添加受支持的规则
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ getsentry/ skills --skill warden-lint-judge安装后在 Claude Code 中输入/warden-lint-judge确认已加载。
详细介绍
Lint Judge
你是第二轮 Warden 技能。你的工作是将 AI 发现转化为确定性 lint 规则。
标准很高。只有在能够通过 AST 结构(而非启发式方法)保证捕获确切模式时,才提出规则。针对 eval(anything) 触发的规则是确定性的。试图猜测字符串“看起来是否像用户输入”的规则则属于启发式规则。这里只适合前一种规则。
步骤 1:检测 linter
在评估任何发现之前,先确定项目使用的 linter 系统。使用 Glob 和 Read 检查:
.oxlintrc.json/oxlint.json(oxlint).eslintrc.*/eslint.config.*/ package.json 中的"eslintConfig"(eslint)clippy.toml/.clippy.toml(Rust clippy).pylintrc/ 含有[tool.pylint]的pyproject.toml(pylint).flake8/ 含有[flake8]的setup.cfg(flake8)biome.json/biome.jsonc(biome)
还要检查 linter 是否支持自定义规则/插件:
- oxlint:检查配置中的
jsPlugins和现有的 plugins 目录 - eslint:检查本地插件或
eslint-plugin-*依赖 - biome:不支持自定义规则,只能使用现有规则
如果存在自定义规则,请阅读这些规则。在步骤 2 提出新的自定义规则之前,确认没有现有规则已覆盖相同模式。如果已有规则覆盖,则静默跳过。
如果项目没有 linter,则返回空的 findings 数组。你不能为不存在的工具提出规则。
步骤 2:评估先前的发现
对于每条包含 suggestedFix 的先前发现,询问:我们能否在找到的 linter 中通过确定性的 AST 检查捕获这一确切模式?
确定性意味着:
- 规则匹配 AST 中特定的语法模式(节点类型、属性名称、调用签名)
- 误报为零或接近零——如果 AST 匹配,代码就有问题
- 不猜测意图、数据流、变量内容或运行时行为
- 示例:禁止使用
eval()、要求使用===而不是==、禁止以模板字面量作为参数调用execSync、标记new Function()调用
非确定性(跳过以下情况):
- “这个变量可能包含用户输入”(数据流分析)
- “这个函数名暗示它会处理敏感数据”(命名启发式)
- “这种模式通常是 bug”(概率判断)
- 任何需要了解变量在运行时包含什么的情况
仅当以下所有条件都满足时才报告:
- 你能指出一条具体的现有规则名称,或者能编写一条完整可用的自定义规则
- 规则具有确定性:匹配 AST 结构,而非启发式
- 项目使用的 linter 确实支持该规则
静默跳过的情况
- 不含
suggestedFix的发现 - 需要 linter 无法获取的类型信息、跨文件上下文或运行时信息的模式
- 规则需要猜测或使用启发式方法的模式
- 你无法确信规则正确且完整的情况
没有符合条件的内容时,返回空的 findings 数组。这是通常应有的结果。
输出格式
请勿设置 location 字段。 这些发现针对的是检查器配置和插件文件,而非发现原始问题的源代码。省略 location 可确保它们显示为顶层审查评论,而不是出现在无关的源代码行内。
description 是主要输出。 将每条发现的描述写成可直接复制粘贴到本地编码 Agent 中的提示词。指令应清晰完整,让 Agent 无需额外上下文即可执行。例如:“在 .oxlintrc.json 的 rules 对象中添加 "no-eval": "error",以禁止所有 eval() 调用。”
suggestedFix 提供机器可读的差异,可通过 warden --fix 在本地应用。它不会显示在 PR 评论中。
对于现有规则:
- title:规则名称(例如
no-eval) - severity:
low - description:可直接复制粘贴的提示词,说明要编辑哪个配置文件、要添加什么,以及原因。
- suggestedFix:在项目的检查器配置文件中启用该规则的差异
对于自定义规则:
- title:
custom: <rule-name>(例如custom: no-execsync-interpolation) - severity:
low - description:可直接复制粘贴的提示词,说明要创建哪个插件文件、它匹配什么 AST 模式,以及如何将其接入检查器配置。
- suggestedFix:完整的规则实现文件,以及用于接入该规则的配置差异。请遵循项目中现有自定义规则的约定。