Claude Code automation

These three shell lines are the foundation of every automation: run Claude with a single prompt, get the answer, done. The magic flag is -p ("prompt") — it means "do this one thing and exit" instead of opening an interactive chat.

1. Line 1 — claude -p "Summarize what changed…" runs one prompt and prints the reply to the screen. The # one-shot comment just notes it does a single job.
2. Line 2 adds --output-format json, which makes Claude return structured JSON instead of prose. The > todos.json part redirects that output into a file a script can read later.
3. Line 3 shows the | (pipe): git diff produces your code changes, and the pipe feeds them in as context for the review prompt. Piping is how you hand Claude data to work on.

What the output means: Lines 1 and 3 print Claude's answer straight to the terminal; line 2 writes a JSON file (todos.json) with nothing shown on screen.

Try this: Run just line 1 in a real repo. Then try line 3 — the difference is that piping git diff gives Claude the actual code to look at, not just a request.

This JSON file teaches Claude Code to run your own commands automatically when certain things happen. A hook = an event name + a command to run when that event fires. Here we set two hooks so tests and an audit log happen every time, with no one remembering to trigger them.

1. "Stop" is the event for "Claude finished the task." Its command pytest -q runs your tests; || echo 'TESTS FAILED' means "if pytest fails, print that message" (|| = "or else").
2. "matcher": "*" means "match everything" — the Stop hook always fires. A matcher narrows which tools or events trigger the hook.
3. "PreToolUse" fires before a tool runs. Here "matcher": "Bash" limits it to Bash commands only, so it runs the echo right before any shell command Claude wants to run.
4. That echo appends a timestamped line (the date plus bash call) onto .claude/audit.log using >> (append to a file). That is your audit trail of every Bash command.

What the output means: Nothing runs now — this is configuration. But once saved, every task-completion runs your tests, and every Bash command adds a line to audit.log.

Try this: Change "Bash" to "Edit" and the audit hook would fire on file edits instead. The matcher is the dial that picks which events you care about.

This small Python program models the rule Claude Code uses internally to decide which hooks fire for an event. Modeling it makes hook behavior predictable — you can predict exactly what will run before it does.

1. def fire_hooks(event, tool, hooks): defines a function: given the event (e.g. "PreToolUse"), the tool in play (e.g. "Bash"), and the config, it returns the list of commands that should run.
2. hooks.get(event, []) looks up the hooks for that event, safely returning an empty list if none are configured. The for matcher, cmd in … loop then checks each one.
3. The if matcher == "*" or fnmatch.fnmatch(tool, matcher): line is the decision: a "*" matcher fires for anything, otherwise fnmatch does wildcard name-matching (so "Bash" matches the tool "Bash"). Matches get added to fired.
4. The three print(...) lines test it: a Bash call, an Edit call, and a Stop event — each shows which commands would fire.

What the output means: before Bash: ['audit.sh'], before Edit: ['format.sh'], on stop: ['pytest -q'] — each event fires only its matching commands, and the "*" Stop hook fires regardless of tool.

Try this: Add ("*", "log.sh") to the PreToolUse list and re-run — now both Bash and Edit fire log.sh too, because * matches every tool.

A slash command is just a saved prompt in a file under .claude/commands/. This one is named review.md, so typing /review in Claude Code expands into these exact instructions — a team-standard code review with no re-typing.

1. The first line is an HTML comment (<!-- … -->) noting the file's location. Everything after it is the prompt text Claude receives when you run /review.
2. The numbered list tells Claude exactly what to look for — correctness bugs, security issues, and missing tests. Being specific gives you a consistent review every time.
3. The last line, Group findings by severity. Cite file:line. Be concise — no praise., controls the format of the answer: organized, pinpointed to lines, and no filler.

Try this: Save this as .claude/commands/review.md, then type /review. Add a 4th rule (say "4. Performance concerns") and every future review includes it — that is the point of saving the prompt once.

This is a GitHub Actions workflow — a YAML file GitHub runs automatically. It makes Claude Code review every pull request and post its findings, so the obvious problems get caught before a human reviewer even looks.

1. on: [pull_request] is the trigger — this whole job runs each time someone opens or updates a PR. This is the "Trigger" box from the diagram.
2. runs-on: ubuntu-latest asks GitHub for a fresh Linux machine. The actions/checkout@v4 step downloads your code onto it; fetch-depth: 0 grabs the full history so git diff works.
3. ANTHROPIC_API_KEY: "${{ secrets.ANTHROPIC_API_KEY }}" passes your API key in from GitHub's encrypted secrets — the key is never written in the file.
4. The run: | block runs shell commands: save the PR's diff to a temp file, run claude -p headless to review it into review.md, then cat (print) it — or post it as a PR comment via the gh tool.

What the output means: On every PR, CI produces a Markdown review grouped by severity. Here it is just printed to the build log; in practice you would post it back onto the PR.

Try this: This ties the whole lesson together: the PR is the trigger, claude -p is headless mode, and review.md is the result feeding the pipeline.

When Claude runs unattended, some actions are too dangerous to ever do without a human saying yes. This function is a safety gate: it inspects a requested action and blocks the irreversible ones unless a human has approved. "Fail closed" means "when unsure, refuse."

1. HARD_DENY = {"git push", "deploy", "delete", "issue refund"} is a set of dangerous actions — the things that change prod, delete data, or spend money. These always need a human.
2. The if any(d in action for d in HARD_DENY) and not context.get("human_approved"): line checks two things at once: is this action one of the dangerous ones, and has no human approved it? If both are true, it refuses.
3. On refusal it returns (False, "…needs human approval…") — a False flag plus a reason. Otherwise it returns (True, "ok"), allowing the action.
4. The three print calls test it: a harmless run pytest is allowed; a git push with no approval is blocked; the same push with human_approved: True is allowed.

What the output means: (True, 'ok'), then (False, "…needs human approval…"), then (True, 'ok') — the identical push is blocked without approval and allowed with it. That approval flag is your human gate.

Try this: Add "drop table" to HARD_DENY and test allow_automated("drop table users", {}) — it now returns False. This is exactly how you keep an unattended agent from doing damage.