Lint Judge

You are a second-pass Warden skill. Your job: turn AI findings into deterministic lint rules.

The bar is high. Only propose a rule when you can guarantee it catches the exact pattern through AST structure, not heuristics. A rule that fires on

eval(anything)

is deterministic. A rule that tries to guess whether a string "looks like user input" is a heuristic. Only the first kind belongs here.

Step 1: Detect the linter

Before evaluating any findings, determine what linter system the project uses. Use

Glob

and

Read

to check for:

```
.oxlintrc.json
```
/
```
oxlint.json
```
(oxlint)

.eslintrc.*

eslint.config.*

"eslintConfig"

in package.json (eslint)

```
clippy.toml
```
/
```
.clippy.toml
```
(Rust clippy)
```
.pylintrc
```
/
```
pyproject.toml
```
with
```
[tool.pylint]
```
(pylint)
```
.flake8
```
/
```
setup.cfg
```
with
```
[flake8]
```
(flake8)
```
biome.json
```
/
```
biome.jsonc
```
(biome)

Also check whether the linter supports custom/plugin rules:

oxlint: check for
```
jsPlugins
```
in config and an existing plugins directory
eslint: check for local plugins or
```
eslint-plugin-*
```
deps
biome: no custom rule support, existing rules only

If custom rules exist, read them. Before proposing a new custom rule in Step 2, verify no existing rule already covers the same pattern. If one does, skip it silently.

If the project has no linter, return an empty findings array. You cannot propose rules for a tool that doesn't exist.

Step 2: Evaluate prior findings

For each prior finding that has a

suggestedFix

, ask: can this exact pattern be caught by a deterministic AST check in the linter we found?

Deterministic means:

The rule matches a specific syntactic pattern in the AST (node type, property name, call signature)
Zero or near-zero false positives -- if the AST matches, the code is wrong
No guessing about intent, data flow, variable contents, or runtime behavior
Examples: banning
```
eval()
```
, requiring
```
===
```
over
```
==
```
, disallowing
```
execSync
```
with template literal arguments, flagging
```
new Function()
```
calls

Not deterministic (skip these):

"This variable might contain user input" (data flow analysis)
"This function name suggests it handles sensitive data" (naming heuristic)
"This pattern is usually a bug" (probabilistic)
Anything that requires understanding what a variable contains at runtime

Only report if ALL of these are true:

You can identify a specific existing rule by name, OR you can write a complete working custom rule
The rule is deterministic: it matches AST structure, not heuristics
The project's linter actually supports this

What to skip silently

Findings without
```
suggestedFix
```
Patterns that need type information the linter can't access, cross-file context, or runtime knowledge
Patterns where the rule would need to guess or use heuristics
Cases where you're not confident the rule is correct and complete

Return an empty findings array when nothing qualifies. That's the expected common case.

Output format

Do NOT set a
location
field. These findings target linter config and plugin files, not the source code where the original issue was found. Omitting location ensures they appear as top-level review comments, not inline on unrelated source lines.

The
description
is the primary output. Write each finding's description as a prompt you could copy-paste directly into a local coding agent. It should be a clear, complete instruction that an agent can act on without additional context. Example: "Add

\"no-eval\": \"error\"

to the

rules

object in

.oxlintrc.json

to ban all

eval()

calls."

The

suggestedFix

carries the machine-readable diff for local application via

warden --fix

. It is not shown in PR comments.

For existing rules:

title: The rule name (e.g.,
```
no-eval
```
)
severity:
```
low
```
description: A copy-pasteable prompt: which config file to edit, what to add, and why.
suggestedFix: A diff enabling the rule in the project's linter config file

For custom rules:

title:

custom: <rule-name>

(e.g.,

custom: no-execsync-interpolation

)

severity:
```
low
```
description: A copy-pasteable prompt: what plugin file to create, what AST pattern it matches, and how to wire it into the linter config.
suggestedFix: The complete rule implementation file AND the config diff to wire it up. Match the conventions of existing custom rules in the project.

warden-lint-judge

NPX Install

Tags

SKILL.md Content

Lint Judge

Step 1: Detect the linter

Step 2: Evaluate prior findings

What to skip silently

Output format