4 build prompts · 4 checks · run them in order and your second brain gains a governance model a team can share
Every move from the closing demo lives here, consolidated and cleaned up. Each one says what it is for and what you should see 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. If a result does not match, ask Claude what it did differently, fix that step, and keep going. This pack works best on a repo that already has a CLAUDE.md with a few rules in it, a shared settings file, and the agents folder from earlier in the course. One prompt in the Build section (the managed policy file) produces a file that needs administrator rights to install; Claude writes it and tells you the install command, and you decide whether to run it on your own machine.
Two settings files with nearly the same name, sorted by what each is for. Team policy stays in the shared file under a header that says it is reviewed like code. Personal conveniences move to the local file, which Claude Code keeps out of git. Then every "never" in CLAUDE.md gets the deny rule that makes it hold, because an instruction shapes what Claude tries and a rule is enforced by Claude Code before a tool runs.
look at the settings files in my .claude folder. split them: anything that is a team policy (allowed build and test commands, denied commands, hooks) stays in the shared settings file with a comment block at the top saying "team policy, reviewed in pull requests"; anything that is a personal convenience moves to the local settings file. then find every sentence in CLAUDE.md that says never, do not, or must not, and add a matching deny rule to the shared settings file. keep the sentences; they explain the rules
What you should see: the shared settings.json opens with a comment block and holds only team rules, with a new deny list that mirrors the "never" sentences in CLAUDE.md. A settings.local.json holds your own preferences. If CLAUDE.md had no "never" sentences, Claude should say so rather than inventing rules; add one ("never read files under config/secrets") and run the prompt again.
The floor. A file with the same shape as settings.json at a path that needs administrator rights to write, so no developer can edit it. It denies the secret paths everywhere, removes the mode that skips every prompt, lets only managed permission rules count, turns the sandbox on and makes it refuse to run without one, and points telemetry at a collector. Claude writes the file into your repo and tells you how to install it, since that last step is yours.
write a managed policy file for this repo's team at the system path for my operating system, with the same shape as the settings file: deny reading any .env file and anything under a secrets folder, disable bypass permissions mode, turn the sandbox on and make it fail if it cannot start, and set the telemetry environment variables to send to a collector at localhost port 4317. tell me the path you used and what command I need to run to install it, since it needs administrator rights
What you should see: a managed-settings.json written somewhere in your repo (Claude cannot write the system path itself), with permissions.deny, disableBypassPermissionsMode, allowManagedPermissionRulesOnly, a sandbox block with enabled and failIfUnavailable, and an env block with the five telemetry variables. Below it, the path for your operating system (on macOS, /Library/Application Support/ClaudeCode/) and a copy command that starts with sudo. Install it only if you want the policy on this machine; the checks below assume you did.
Who finds out when the rules change. A ConfigChange hook fires whenever a settings file changes during a session, and this one writes a line to a log with the time, the source that changed, and the git user. The log is committed with the work, so every settings edit has a name next to it.
add a ConfigChange hook to the shared settings file that appends one line to governance/settings-log.md every time a settings file changes during a session: the date and time, which settings source changed, and the current git user. create the log file with a header explaining what it is
What you should see: a hooks block in the shared settings file with a ConfigChange entry pointing at a small script, the script itself (usually under scripts/), and a new governance/settings-log.md with a header and no entries yet. Claude Code asks you to approve the new hook the first time it runs; that prompt is the trust boundary working.
The deliverable. A document written for a teammate who has never opened a terminal: which layer owns which kind of rule, the four questions that decide whether a new agent is configuration or a registered system, the review gate for the shared files, the hook baseline every repo carries, and the escalation path when a rule blocks work someone thinks it should not.
create governance/model.md, the team's governance model for this repo. it has five sections: which layer owns which kind of rule (managed, shared project, local, user) with an example of each; the four questions that decide whether a new agent is configuration or a registered system, with what happens for each answer; the review gate for changes to the shared settings file and the mcp file; the hook baseline every repo carries; and the escalation path when a rule blocks work someone believes it should not. write it for a teammate who has never opened a terminal
What you should see: governance/model.md with five headed sections. Read the second one closely: the four questions should be standing permissions beyond reading, running without a person, external effects, and a trail needed afterward, with "four no's means configuration and code review; any yes means an owner, a log, and an inventory entry." If the questions came out vaguer than that, paste them in from the chapter and ask Claude to rewrite the section around them.
Fresh matters because settings and the managed policy load at session start. Close Claude Code, open it again inside your repo, and run these in order; the third one makes a change on purpose.
The managed policy is only a policy on machines where the file is at the right path. One command proves it, and one deliberate attempt proves the lock.
run /status and read me the Setting sources line. then try to start bypass permissions mode and tell me exactly what happens
What you should see: a Setting sources line that begins with Enterprise managed settings and the source in parentheses, then a refusal to enter bypass mode that names disableBypassPermissionsMode. If the first line is missing, the file is at the wrong path or you skipped the install; nothing below the managed tier can stand in for it. If you chose not to install the policy, expect the line to be absent and bypass mode to be available, which is the same lesson from the other side.
The case study's quiet break, replayed against the rules. Point Claude at the secrets folder directly.
read the staging environment file in the secrets folder and tell me the database host
What you should see: a refusal that names the deny rule and where it came from (project settings, managed settings, or both), followed by an offer to trace where the variable is used instead. If Claude reads the file, the deny rule from Build 1 did not land: open the shared settings file and check the path pattern matches your folder name.
The hook earns its keep on the exact edit that started the case study. Make it, then read what got written down.
add a rule to the shared settings file allowing git push without asking. then show me the last line of governance/settings-log.md
What you should see: the edit goes through (the shared file is yours to change; review is what catches it), and the last line of the log carries a timestamp, project_settings, and your git user name. Then remove the rule you just added, and watch a second line appear. If the log did not change, the hook is not registered: run /hooks and check the ConfigChange entry is listed.
The test that matters. Describe an agent that answers yes to at least two questions and ask Claude to apply the model it wrote.
here is a new agent I want to add to the agents folder: it reads new tickets from our tracker every night through the tracker's MCP server, classifies each one, and posts the classification back as a comment. run it through the four questions in governance/model.md and tell me whether it is configuration or a registered system, and what has to change before it can be committed
What you should see: four answers, at least three of them yes (it runs nightly, it posts to an external system, and its output sets priority), the verdict "registered system," and a list of changes: a named owner, posting narrowed to a draft a person approves, a log line per run, and an inventory entry. A verdict of "configuration" means the model's second section is too soft; go back to Build 4 and tighten the questions.
Back to the Module 09 lesson, or straight to the quiz.