4.1 KiB
Constructing a Hook (with verification)
Given an event, matcher, target file, and desired behavior, follow this flow. Each step catches a different failure class — a hook that silently does nothing is worse than no hook.
-
Dedup check. Read the target file. If a hook already exists on the same event+matcher, show the existing command and ask: keep it, replace it, or add alongside.
-
Construct the command for THIS project — don't assume. The hook receives JSON on stdin. Build a command that:
- Extracts any needed payload safely — use
jq -rinto a quoted variable or{ read -r f; ... "$f"; }, NOT unquoted| xargs(splits on spaces) - Invokes the underlying tool the way this project runs it (npx/bunx/yarn/pnpm? Makefile target? globally-installed?)
- Skips inputs the tool doesn't handle (formatters often have
--ignore-unknown; if not, guard by extension) - Stays RAW for now — no
|| true, no stderr suppression. You'll wrap it after the pipe-test passes.
- Extracts any needed payload safely — use
-
Pipe-test the raw command. Synthesize the stdin payload the hook will receive and pipe it directly:
Pre|PostToolUseonWrite|Edit:echo '{"tool_name":"Edit","tool_input":{"file_path":"<a real file from this repo>"}}' | <cmd>Pre|PostToolUseonBash:echo '{"tool_name":"Bash","tool_input":{"command":"ls"}}' | <cmd>Stop/UserPromptSubmit/SessionStart: most commands don't read stdin, soecho '{}' | <cmd>suffices
Check exit code AND side effect (file actually formatted, test actually ran). If it fails you get a real error — fix (wrong package manager? tool not installed? jq path wrong?) and retest. Once it works, wrap with
2>/dev/null || true(unless the user wants a blocking check). -
Write the JSON. Merge into the target file (schema shape in the "Hook Structure" section above). If this creates
.claude/settings.local.jsonfor the first time, add it to .gitignore — the Write tool doesn't auto-gitignore it. -
Validate syntax + schema in one shot:
jq -e '.hooks.<event>[] | select(.matcher == "<matcher>") | .hooks[] | select(.type == "command") | .command' <target-file>Exit 0 + prints your command = correct. Exit 4 = matcher doesn't match. Exit 5 = malformed JSON or wrong nesting. A broken settings.json silently disables ALL settings from that file — fix any pre-existing malformation too.
-
Prove the hook fires — only for
Pre|PostToolUseon a matcher you can trigger in-turn (Write|Editvia Edit,Bashvia Bash).Stop/UserPromptSubmit/SessionStartfire outside this turn — skip to step 7.For a formatter on
PostToolUse/Write|Edit: introduce a detectable violation via Edit (two consecutive blank lines, bad indentation, missing semicolon — something this formatter corrects; NOT trailing whitespace, Edit strips that before writing), re-read, confirm the hook fixed it. For anything else: temporarily prefix the command in settings.json withecho "$(date) hook fired" >> /tmp/claude-hook-check.txt;, trigger the matching tool (Edit forWrite|Edit, a harmlesstrueforBash), read the sentinel file.Always clean up — revert the violation, strip the sentinel prefix — whether the proof passed or failed.
If proof fails but pipe-test passed and
jq -epassed: the settings watcher isn't watching.claude/— it only watches directories that had a settings file when this session started. The hook is written correctly. Tell the user to open/hooksonce (reloads config) or restart — you can't do this yourself;/hooksis a user UI menu and opening it ends this turn. -
Handoff. Tell the user the hook is live (or needs
/hooks/restart per the watcher caveat). Point them at/hooksto review, edit, or disable it later. The UI only shows "Ran N hooks" if a hook errors or is slow — silent success is invisible by design.