3 build prompts · 4 checks · run them in order and your second brain gains its guardrails
Every prompt from the closing demo lives here, consolidated and cleaned up. Each one says what it is for and what your repo should look like when it lands. Open a terminal in your second brain repo, type claude, and paste them in order. Rephrasing in your own words works just as well; both roads end at the same repo. If a result does not match, ask Claude what it did differently, fix that step, and keep going.
A PreToolUse hook runs before a tool call executes, and an exit code of 2 blocks the call and hands Claude your message. This one screens every bash command for rm -rf (the delete command with every safety removed) and pushes to main. The block message suggests archiving because a good block redirects; a bare refusal just leaves Claude stuck.
create a PreToolUse hook that blocks any bash command containing rm -rf or a push to main. put the script in the scripts folder, make the block message suggest archiving instead of deleting, and register the hook in the settings file
What you should see: A script in the scripts folder and a new hooks block in .claude/settings.json registering it under PreToolUse with a Bash matcher. The settings entry is the on switch; a script sitting in a folder unregistered does nothing at all.
Matched to Write and Edit, so it inspects file content on its way to disk. Keys matching patterns like sk-ant or AKIA never reach a file, which matters because anything committed to a shared repo is on every teammate's machine within the hour.
add a second PreToolUse hook, matched to Write and Edit only, that scans file content for credential patterns like keys starting with sk-ant or AKIA and blocks the write
What you should see: A second script and a second PreToolUse entry in settings.json, this one matched to Write and Edit instead of Bash.
A PostToolUse hook with no matcher sees every tool call after it runs. It can block nothing; it writes history. When something odd turns up next month, this file answers the question what did Claude actually do, with timestamps.
last one: a PostToolUse hook with no matcher that appends every tool call to an audit log in the logs folder, with a timestamp on every line
What you should see: A third script and a PostToolUse entry with no matcher. From your next prompt onward, logs/audit.log grows one line per tool call.
Fresh matters because hook registrations load with the session. Close Claude Code, open it again inside your repo, and run these in order; the last one breaks a guardrail on purpose and then repairs it.
The prompt builds a throwaway folder first so nothing of yours is ever at risk, then walks straight into the blocked command.
make a throwaway folder called archive-old with a test file in it, then delete that folder with rm -rf
What you should see: The folder gets made, the delete gets blocked, and Claude proposes archiving instead of pushing back at you. That redirect is your block message doing its job.
The key is fake, built to match the pattern and nothing else.
save a test config file with the key sk-ant-test123 in it
What you should see: The write is blocked before the file exists. The fake key never touches disk, which is exactly the moment a real one would have been caught.
Guardrails also have to prove what they leave alone. An ordinary read should sail through, and the log should have been watching everything.
check the stakeholders file and tell me who our sponsor is
show me the audit log
What you should see: The file read runs untouched, which proves the matchers are scoped right and hooks stay out of ordinary work. Then the log shows everything so far, reads, writes, and both blocks, each line stamped with a time.
This is the audit rule from the demo, run with your own hands: check the settings file first, because it says which hooks run; then the scripts, because they say what hooks do.
remove the command blocker registration from the settings file, but keep the script. then try the rm -rf delete again
put the command blocker registration back
What you should see: With the registration gone and the script still sitting in its folder, the delete sails through. A script on disk protects nothing; only the registration makes it real. Then the second prompt restores the guardrail. Leave with it on.
Back to the Module 03 lesson, or straight to the quiz.