CHAPTERS
- 0:02 – 0:33
What hooks are in Claude Code: deterministic automation
Explains that hooks run at specific lifecycle points in Claude Code and, unlike prompt instructions, they execute deterministically every time. Frames hooks as the reliable mechanism for enforcing behavior that must not be skipped.
- •Hooks run commands at defined lifecycle events in Claude Code
- •Primary distinction: hooks are deterministic and always run
- •Prompt instructions (e.g., in claude.md) can be followed inconsistently
- •Use hooks for actions that must happen with no exceptions
- 0:33 – 0:48
Practical use cases: formatting, compliance logging, safety blocks, notifications
Lists common scenarios where deterministic behavior matters, from code style enforcement to operational safety and auditability. Positions hooks as a way to guarantee team/process requirements rather than mere suggestions.
- •Auto-format after file edits
- •Log executed commands for compliance/audit purposes
- •Block dangerous operations (e.g., modifying production files)
- •Send notifications when Claude finishes a task
- 0:48 – 1:03
How hooks are configured: events, matchers, commands (settings.json)
Describes the core configuration model: choose a lifecycle event, optionally scope it with a matcher to certain tools, and define the command to run. Notes that hooks live in settings.json.
- •Hooks are configured in settings.json
- •Select an event that triggers the hook
- •Optional matcher limits which tools/actions trigger it
- •Provide a command to execute when triggered
- 1:03 – 1:18
Lifecycle events overview: prompt submit, pre/post tool use, notification, stop
Enumerates the available hook trigger points and what each represents in the Claude Code lifecycle. This section helps map desired automation to the correct event timing.
- •User prompt submit: runs after submitting a prompt, before processing
- •Pre tool use: runs before a tool call
- •Post tool use: runs after a tool call completes
- •Notification: runs when Claude sends a notification
- •Stop: runs when Claude finishes responding
- 1:18 – 1:33
Auto-formatting pattern: post-tool-use hook for edits
Walks through the most common hook setup—formatting after file modifications—using a post tool use hook scoped to edit operations. Emphasizes firing reliably whenever Claude changes files.
- •Use a post tool use hook for auto-formatting
- •Add a matcher for edit or multi-edit so it triggers on file changes
- •Hook fires whenever Claude modifies a file
- •Ideal for enforcing consistent code style automatically
- 1:33 – 1:48
Formatter selection by file type: Prettier, gofmt, Ruff, etc.
Explains how the formatting hook can inspect file extensions and call the appropriate formatter per language. Encourages aligning hook commands with the project’s existing toolchain.
- •Command checks file extension to pick the right formatter
- •Examples: Prettier for TypeScript, gofmt for Go, Ruff for Python
- •Works with whatever formatters the project uses
- •Keeps formatting consistent across edits
- 1:48 – 2:03
Blocking unsafe actions: pre-tool-use hooks with stdin JSON
Introduces pre tool use hooks as a mechanism to prevent certain tool calls from executing. Notes that the hook receives the tool name and input as JSON via stdin for inspection and policy checks.
- •Pre tool use hooks can block tool calls before execution
- •Hook receives tool name and tool input as JSON on stdin
- •Enables policy enforcement based on intended action
- •Useful for guarding against risky operations
- 2:03 – 2:13
Exit codes as control flow: proceed vs block with feedback to Claude
Details how exit codes determine whether an action is allowed, and how error messages can be fed back to Claude so it can adjust. Highlights exit code 2 as the hard-block mechanism.
- •Exit code 0 means proceed
- •Exit code 2 means block the action
- •stderr message is returned to Claude as feedback
- •Enables ‘hard rules’ rather than best-effort guidance
- 2:13 – 2:23
Examples of enforceable rules: production writes, rm -rf, main branch commits
Gives concrete policy examples that teams often want guaranteed: preventing production config changes, destructive shell commands, or restricted git operations. Reinforces hooks as compliance/safety tooling.
- •Block writes to production config directories
- •Block batch commands containing rm -rf
- •Block commits directly to main
- •Customize rules to team needs that must be guaranteed
- 2:23 – 2:33
Team-wide setup: project-level hooks in .claude/settings.json
Explains how placing hooks in the project configuration makes them shareable and consistent for everyone. Notes that these can be committed to the repository so the entire team inherits the same safeguards/automation.
- •Hooks in .claude/settings.json are project-level
- •Project hooks can be checked into the repo
- •Ensures consistent behavior across the team
- •Great for standardized formatting, logging, and safety rules
- 2:33
Robust scripting: use Claude project dir environment variable
Recommends using the Claude project directory environment variable to reference scripts stored in the repo. This ensures hook commands work regardless of Claude’s current working directory.
- •Reference project scripts via the Claude project dir environment variable
- •Avoids issues from varying current working directories
- •Improves portability and reliability of hook commands
- •Supports repo-contained hook tooling
Best-practice wrap-up: use hooks when it must happen every time
Summarizes where each hook type fits (post tool use for formatting/logging, pre tool use for blocking) and reiterates the core principle: deterministic requirements belong in hooks, not prompts. Encourages checking hooks into the repo for shared enforcement.
- •Hooks provide deterministic control over Claude Code behavior
- •Post tool use is ideal for auto-formatting and logging
- •Pre tool use is ideal for blocking dangerous operations
- •Configure in settings.json (and share via repo)
- •If it must never fail, use a hook—not a prompt
