A PostToolUse hook in .claude/settings.json runs eslint --fix automatically on every .ts, .tsx, .js, .jsx, .cjs, and .mjs file immediately after Claude writes or edits it, before the developer even sees the file.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "eslint --fix \"${file}\""
          }
        ]
      }
    ]
  }
}

This is local to each developer's Claude Code session via the project settings file. The principle here is catching errors at the earliest possible moment, the point of generation, rather than at review or CI. By the time a developer reads the file, it already conforms to the rules. There is nothing to fix and nothing to be distracted by.

A lint-staged pre-commit hook in package.json runs eslint --fix --max-warnings=0 alongside the Prettier step on staged files before every commit.

{
  "lint-staged": {
    "*.{ts,tsx,js,jsx,cjs,mjs}": [
      "prettier --write",
      "eslint --fix --max-warnings=0"
    ]
  }
}

The --max-warnings=0 flag is the key detail here. It means warnings block the commit, consistent with the CI lint gate. Without this, warnings accumulate silently, developers assume someone else will deal with them, and the codebase drifts. Matching the pre-commit gate to the CI gate means there are no surprises: if it commits, it will pass CI.

Critically, this layer enforces the rules for all contributors regardless of editor setup. Not everyone has the Claude Code hook. Not everyone has ESLint configured in their editor. The pre-commit hook is the safety net that makes the standard universal.

A dedicated eslint-auto-fix job in .github/workflows/npm-docker-build-image.yaml runs eslint --fix on PR-changed files only, commits any auto-fixed changes back to the PR branch, then re-runs ESLint to verify. If unfixable errors remain after that second pass, the build fails and a developer resolves them.

eslint-auto-fix:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
      with:
        ref: ${{ github.head_ref }}
        fetch-depth: 0

    - name: Get changed files
      id: changed
      run: |
        echo "files=$(git diff --name-only --diff-filter=ACMRT \
          origin/${{ github.base_ref }}...HEAD \
          | grep -E '\.(ts|tsx|js|jsx|cjs|mjs)$' \
          | tr '\n' ' ')" >> $GITHUB_OUTPUT

    - name: Run ESLint auto-fix
      run: npx eslint --fix ${{ steps.changed.outputs.files }}

    - name: Commit fixes
      uses: stefanzweifel/git-auto-commit-action@v5
      with:
        commit_message: "chore: eslint auto-fix"

    - name: Verify — fail if unfixable errors remain
      run: npx eslint --max-warnings=0 ${{ steps.changed.outputs.files }}

Scoping to changed files using a triple-dot merge-base diff is the critical design choice here. Running ESLint across the entire codebase on every PR would cause failures on pre-existing errors in files nobody touched, punishing contributors for problems they didn't introduce and creating a chilling effect on otherwise safe changes. Scoping to the diff means the bar is clear: the code you changed must pass. Everything else is a separate concern.