5 build prompts · 3 checks · run them in order and your second brain gains its foundation: the context layer
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.
This is the container everything else in the course lives in. The demo calls it client-project; name yours anything you like. The three folders give the rules you are about to write something to attach to, and the READMEs give a human teammate the same map Claude gets.
make a new folder called client-project and set it up as a git repo. this is the start of a new engagement. inside it, add three folders: research, deliverables, and data. then add a short README inside each folder that says what belongs in it
What you should see: A new client-project folder with git initialized, three folders inside, and a one or two line README in each. Nothing else yet.
The root CLAUDE.md is the team contract, loaded at the start of every session, so every line in it is a tax on every session. That is why the prompt says keep it short, and why the style rules move to their own file: the import keeps the root file small while the rules still load with it.
create a CLAUDE.md that explains this project and our working rules. keep it short. the rules: client facing docs follow our style guide, never change anything in data/raw, spell out abbreviations the first time you use them, and deliverables stay drafts until a partner reviews them. then put the writing style rules in their own STYLE.md file and link it from the CLAUDE.md
What you should see: Two new files at the repo root. CLAUDE.md holds a short project description, the working rules, and an import line pointing at STYLE.md. Read both files. If the root file came out long, tell Claude to cut it down; short is the discipline this module teaches.
Rules in a subdirectory CLAUDE.md load only when Claude works inside that folder. The naming rule belongs to deliverables/ and the read only rule belongs to data/ because that placement makes them free everywhere else in the repo. This is the lazy loading tier of the context layer.
in the deliverables folder, add a CLAUDE.md with rules just for that folder: files are named YYYY-MM-DD-topic.md and everything stays marked DRAFT until it has been reviewed. then do the same for the data folder with one rule: everything in data/raw is read only, we never edit source files
What you should see: deliverables/CLAUDE.md and data/CLAUDE.md, each a few lines long. Neither loads at session start; they wait for work in their folder, and the checks below prove it.
Preferences about you, like short answers and diffs before saves, have no place in the shared team file, because the committed CLAUDE.md speaks to every teammate's Claude. CLAUDE.local.md is your private layer, and the gitignore line keeps it off your teammates' machines.
now make a CLAUDE.local.md with my personal preferences: keep answers short, and show me a diff before saving changes. add it to gitignore so my teammates never get it
What you should see: CLAUDE.local.md at the root and a matching line inside .gitignore. Run git status: the overlay file should be invisible to git.
settings.json is the shared, committed configuration; settings.local.json is your personal one. The empty commands, skills, and agents folders are the sockets the next three modules plug into. And the deny rule is your first lock: a rule the harness enforces every time, whether or not anyone remembered to write it in prose.
inside a .claude folder i need: a settings.json for shared team settings, a settings.local.json for my personal settings, and empty folders named commands, skills, and agents. in the settings file, add a permission rule that blocks reading the secrets file in the data folder. then drop a dummy secrets file in the data folder so we can test the lock
What you should see: A .claude folder holding both settings files and three empty folders. Open settings.json: a permissions block with a deny entry naming the secrets file. And data/ now holds a dummy secrets file, waiting for the last check below.
Fresh matters because you are testing what loads at session start, with no help from this conversation's memory. Close Claude Code, open it again inside your repo, and run these.
No file is named and no hint is given. The answer has to come from what loaded at startup.
what are this project's conventions?
What you should see: Claude recites the rules from your root CLAUDE.md and the imported style file without opening anything first. That is the always loaded tier doing its job.
The naming and DRAFT rules live in the deliverables folder's own CLAUDE.md. You are about to find out whether the lazy tier loads itself.
draft a deliverable summarizing this week's findings
What you should see: A file lands in deliverables/ named in YYYY-MM-DD-topic form and marked DRAFT, and you mentioned neither rule. That silence is the proof: the folder file loaded on its own the moment work entered its folder.
The deny rule in settings.json is a lock, and locks only count if they hold when someone actually turns the handle.
read the secrets file in the data folder
What you should see: A refusal citing the permission rule. Asking nicely changes nothing, and that is the whole difference between a rule written in prose and a rule the harness enforces.
Back to the Module 01 lesson, or straight to the quiz.