Make Your Coding Agent Respect Formatter and Lint Rules

Make formatter compliance executable, not aspirational

“Follow the existing style” is a weak acceptance criterion. My preferred setup gives the agent three things: committed configuration, named commands, and a final check that fails loudly. The model writes the change; the repository decides whether its formatting and lint pass.

This walkthrough uses a disposable JavaScript project, npm, Node.js 22, and a POSIX shell. In an existing repository, inspect its scripts and configuration first. Keep the established toolchain rather than overwriting it with this example.

1. Install local tools and commit their versions

Run these commands separately, from your terminal: — mkdir agent-style-demo && cd agent-style-demo

git init && npm init -y — npm install --save-dev --save-exact prettier@3 eslint@9 @eslint/js@9 eslint-config-prettier@10

The major versions here deliberately select a compatible example stack, not “whatever is newest.” Exact dependency entries and the generated lockfile keep later installs consistent. Prettier specifically recommends a local, locked version because formatting can change between releases. ([prettier.io](https://prettier.io/docs/install/))

2. Give Prettier and ESLint separate jobs

Create formatting preferences and exclude generated output: — printf '%s\n' '{"singleQuote":true,"semi":true}' > .prettierrc.json

printf '%s\n' 'node_modules/' 'dist/' 'coverage/' > .prettierignore

printf '%s\n' 'node_modules/' 'dist/' 'coverage/' > .gitignore

Now create the flat ESLint configuration. Its standalone ignores object excludes generated directories; the recommended configuration supplies the initial lint rules. ([eslint.org](https://eslint.org/docs/latest/use/configure/configuration-files))

printf '%s\n' 'import js from "@eslint/js";' 'import prettier from "eslint-config-prettier";' 'export default [{ ignores: ["dist/**", "coverage/**"] }, js.configs.recommended, prettier];' > eslint.config.mjs

Keep the Prettier compatibility configuration last. It disables conflicting ESLint rules; it does not run Prettier. That distinction prevents the classic loop where formatting fixes one complaint and recreates another. ([github.com](https://github.com/prettier/eslint-config-prettier))

3. Name the repair loop and the acceptance gate

Add scripts the agent can invoke without inventing flags:

npm pkg set 'scripts.format=prettier . --write' 'scripts.format:check=prettier . --check' 'scripts.lint=eslint . --max-warnings=0' 'scripts.lint:fix=eslint . --fix --max-warnings=0' 'scripts.check=npm run format:check && npm run lint'

ESLint can fix some violations, but not every violation. The zero-warning threshold also makes warnings fail the lint command instead of quietly passing. ([eslint.org](https://eslint.org/docs/latest/use/command-line-interface))

Establish a clean baseline before involving the agent:

npm run format && npm run check

4. Put the commands in AGENTS.md

For Codex, commit an AGENTS.md file containing project instructions. Codex reads these instruction files, including applicable directory-level guidance. Keep the instructions concrete rather than duplicating every formatting option. ([developers.openai.com](https://developers.openai.com/codex/guides/agents-md))

printf '%s\n' '# Repository checks' 'Read package.json and existing configuration before editing.' 'After changes, run npm run lint:fix, then npm run format, then npm run check.' 'Fix remaining lint failures without disabling rules or expanding ignore patterns.' 'Do not change formatter configuration unless explicitly requested.' 'Report commands executed, their exit status, and any blocked checks.' > AGENTS.md

Run formatting again, then commit this baseline:

npm run format && npm run check

git add . && git commit -m 'Add agent formatting and lint contract'

5. Test whether the agent follows the contract

Give the agent this deliberately narrow task: “Create src/sum.js exporting a sum function. Follow AGENTS.md, run the repair loop, and report actual check results. Do not change configuration.”

Then inspect the result yourself: — npm run check && git diff --check && git diff --stat

• Reject configuration changes that merely hide the reported violations.
• Ask for the failing diagnostic when a repair stalls.
• Keep functional tests separate; clean lint does not prove correctness.

6. Keep the same checks when switching models

When comparing Claude Sonnet 5.5 with GPT-6 Astra through Fluxo, keep this repository contract unchanged. Fluxo provides one key and one base URL:

export FLUXO_BASE_URL='https://api.fluxorelay.com' — Fluxo works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK; configure your chosen client separately. Billing follows real tokens, including cache reads and writes, with no monthly fee. Users also earn a referral share when invited users pay.

If useful for your workflow, you can create a Fluxo account and try the same task with both models.

Finally, make npm ci followed by npm run check a required CI gate. Instructions guide the agent; executable checks enforce the result.