Ironlint init

Skill ironlint/ironlint/adapters/claude-code/skills/ironlint-init

Agentic-native linting tool to enforce deterministic quality gates

Install

npx -y skills add ironlint/ironlint --skill ironlint-init

Assembled 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

Bootstraps a project's .ironlint.yml with IronLint's generic baseline, then helps the user deliberately add checks for their stack and existing linters. Use when user says "init ironlint", "set up ironlint", "bootstrap ironlint config", "create ironlint checks", "ironlint init", or asks to create or generate an ironlint configuration.

SKILL.md

3.1 KB, as published. Nobody here has run it

IronLint Init

Start with IronLint's generic baseline, then help the user choose checks for their stack and installed linters. A check is two fields — files (a glob or list) and run (a shell command that exits nonzero to block); there are no engines or severities.

This skill is user-driven. Do not silently install tools or add checks. Every step below is a proposal the user accepts or declines.

Step 1: Run `ironlint init`

ironlint init writes a small, stack-agnostic starter .ironlint.yml and trusts it for you. It does not inspect manifest files or wrap linters:

ironlint init

This creates .ironlint.yml with generic starter checks (and, outside this Claude session, can also wire hooks into other agents — not needed here, the PreToolUse hook is already running). Review the generated checks.

Step 2: Wrap the project's linters as checks

For each linter the user has installed (ruff, biome, eslint, tsc, phpstan, clippy, …) that runs per file, propose a check that feeds the proposed content on stdin; any nonzero exit blocks:

checks:
  ruff-check:
    files: ["**/*.py"]
    run: "ruff check --quiet --stdin-filename \"$IRONLINT_FILE\" -"

Test each candidate against a sample file before adding it (see /ironlint-config for the fixture loop). Only add checks that pass on clean input and block on dirty input. Skip repo-wide tools that aren't per-file (e.g. cargo clippy) — they don't map to a per-file check; suggest running them as a pre-push step instead.

Step 3: Trust the config

ironlint init already trusted the config it scaffolded. If you hand-edit .ironlint.yml (Step 2), re-bless it:

ironlint trust

This records a sha256 of the config (and any files it extends:/.ironlint/scripts/) in the out-of-repo trust store at ~/.config/ironlint/trust.json — it does not write into .ironlint.yml. Any later edit invalidates the fingerprint, and ironlint check refuses to run until you re-trust.

Step 4: Verify

Edit any in-scope file. The PreToolUse hook runs ironlint and either passes (clean) or blocks (with the check's message). See the ironlint skill for how to read a block verdict.

Notes

If .ironlint.yml already exists, do not overwrite it — ironlint init leaves an existing config untouched. Propose edits via /ironlint-config instead.
There is no migration from older formats; ironlint rejects a pre-0.3 config (schema_version:/rules:) outright. Write checks fresh.
Telemetry lands at .ironlint/log.jsonl, with a per-check breakdown in each record. The /ironlint-review skill consumes it.