Ironlint review
Skill ironlint/ironlint/adapters/claude-code/skills/ironlint-review
Agentic-native linting tool to enforce deterministic quality gates
npx -y skills add ironlint/ironlint --skill ironlint-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 16 stars16 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Reviews ironlint check health from the telemetry log. Use when the user says "review my ironlint checks", "check health", "which ironlint checks are noisy", "find dead ironlint checks", "ironlint review", or asks for an audit of .ironlint.yml.
SKILL.md
3.7 KB, as published. Nobody here has run it
IronLint Review
Audit the check set against telemetry. Surface candidates for removal, scope adjustment, or a source fix.
Source of truth
.ironlint/log.jsonl — one record per check invocation, with a per-check
breakdown. Each line:
{
"type": "check",
"ts": "2026-06-15T00:00:00Z",
"file": "src/foo.rs",
"status": "block",
"elapsed_ms": 42,
"checks": [
{"check": "no-debug", "status": "block", "elapsed_ms": 30},
{"check": "no-todo", "status": "pass", "elapsed_ms": 12}
]
}
- The top-level
statusis the most severe of the checks that ran (block>internal_error>pass). There is nowarntier. checks[]attributes the outcome to each check by id, so you can recommend on specific checks, not just files.checksis empty when no check matched the file.- A check with
status: "internal_error"carries areason(timeout, not_found, …) — it couldn't run, which is a broken check, not a finding.
Process
- Read
.ironlint/log.jsonl. - Aggregate over the last N entries (default last 1000, or all if fewer),
grouping by
checks[].check(and cross-referencingfile). - Surface concerning patterns per check:
- High block rate (>50% of the files a check ran on): the check may be too strict, or the code it covers genuinely needs fixing at the source.
- Zero blocks across many runs: the check may be dead — its
filesscope never matches anything dirty, or it never fires. Confirm it still earns its keep. - Recurring
internal_error: the check is broken (read itsreason) — fix or remove it; a check that can't run protects nothing. - Slow checks (high
elapsed_ms): flag for optimization or a narrower scope.
Recommendations
For each concerning check, propose ONE of:
- Investigate source: a high block rate may be a real codebase problem to fix in code, not in the check.
- Tighten the
filesscope: narrow the glob so a noisy check fires only where it should. - Remove the check: a check that never blocks (and isn't meant as a tripwire) is noise in the config.
- Fix a broken check: for recurring
internal_error, repair theruncommand or the tool it shells out to.
Never apply recommendations silently. Present each one and ask the user. To
re-confirm what a check does on a file, run ironlint check --file <path> --check <id> --format json and read the verdict.
Output format
Reviewed N entries from .ironlint/log.jsonl (date range A → B).
Per-check health:
| Check | Runs | pass | block | error | Note / recommendation |
|-----------------|------|------|-------|-------|--------------------------------------------------------|
| no-debug | 31 | 24 | 7 | 0 | High block rate (23%) — investigate src/api or tighten |
| no-todo | 84 | 84 | 0 | 0 | No blocks — confirm it still earns its keep |
| eslint-check | 12 | 9 | 0 | 3 | Broken (reason: not_found) — eslint missing on PATH |
To re-confirm a check on a file:
ironlint check --file <path> --check <id> --format json
Notes
- Records are per check invocation with a per-check breakdown; group by
checks[].checkto attribute outcomes to a specific check. - Statuses are
pass,block, andinternal_error— there is nowarn.