/ironlint-init

name: ironlint-init
description: 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.
metadata:
  author: dynamik-dev
  version: 0.2.0
  category: workflow-automation
  tags: [linting, code-quality, config-generation, stack-detection]

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.