Wire a PostToolUse hook that auto-formats every edit instead of nagging in review

Write a Claude Code PostToolUse hook that runs npx biome check --write automatically after every matching edit, and feeds back only what the formatter actually changed, rather than silently reformatting with no signal or blocking nothing while a style violation quietly ships. PostToolUse runs after the tool call has already executed and cannot prevent it — this hook is a feedback and auto-correction mechanism, not a guardrail, and the prompt and the script must both be built around that distinction rather than treated as a delayed PreToolUse check.

WHICH TOOL CALLS THIS HOOK MATCHES
Edit and Write calls only, not Bash or Read.

FILE PATTERNS THIS APPLIES TO
*.ts and *.tsx files only, skipping markdown and JSON files this formatter is not configured for.

HOW MUCH DETAIL TO FEED BACK
A short diff of just the lines the formatter touched, not the full file content.

WHAT HAPPENS IF THE FORMATTER ITSELF FAILS
Report the formatter’s error output distinctly, labeled as a formatter failure, not folded into the normal "formatting applied" message.

PRODUCE
1. The settings.json fragment: a PostToolUse hooks entry matched to Edit and Write calls only, not Bash or Read. and scoped by *.ts and *.tsx files only, skipping markdown and JSON files this formatter is not configured for. so this does not fire on every tool call, only ones that actually touched a file this formatter applies to.
2. The hook script, which reads the tool input and result from stdin, identifies the exact file that was just edited, runs npx biome check --write against that specific file only, and compares the file's content before and after the formatter ran.
3. If the formatter changed anything, the script must report back to Claude, per A short diff of just the lines the formatter touched, not the full file content., specifically what changed — not the entire reformatted file, which would waste context repeating content that did not need to change, and not a bare 'formatting was applied' with no detail, which gives Claude nothing to actually learn from for its next edit in this same file.
4. If the formatter made no changes, the script should exit cleanly with no output — a hook that reports 'no changes needed' on every single edit adds noise to every turn for information that only matters the one time it is not true.

EXIT CODE AND FEEDBACK MECHANICS
Use exit code 2 with the diff on stderr when there is something for Claude to see, since that is what surfaces as additional context back to Claude in a PostToolUse hook, distinct from the blocking exit code a PreToolUse hook uses — a PostToolUse hook exiting with a blocking-style code does not undo the edit that already happened, it can only add noise without preventing anything, so confirm the exit code chosen actually does what this hook intends rather than assuming the same code means the same thing across both hook types.

FAILURE HANDLING
Per Report the formatter’s error output distinctly, labeled as a formatter failure, not folded into the normal "formatting applied" message., if the formatter command itself errors, such as on a syntax error the edit just introduced, report that distinctly from a normal formatting change — a formatter crash is different information than a style correction and conflating the two in the same feedback channel hides a possible real bug behind what looks like routine auto-formatting noise.

OUTPUT
The settings.json fragment and the hook script, followed by one example of the feedback Claude would actually see after an edit that needed reformatting, and one showing the silent case where nothing was needed.