Claude Code forgets you every session. You explain your project again, you retype the same corrections, and you get the same mistakes back. The fix is a harness, and the Claude Code load order (the files Claude reads on startup, and their sequence) decides which of its rules reach the model.
A harness is Claude plus the files it reads on startup. Those files hold your rules, your skills, your tools and your saved state. You keep them in git, so they survive a new laptop or a new account.
Ahmed Besbes gives the same definition from the builder side: "The harness supplies context, manages tool execution and state, enforces boundaries, and checks results."
The model is rented. Mine is the same model you use. The harness is the part you own, and it is how you stop paying again every week for the same work.
Y Combinator says the same model weights score 30% or 95% on ARC-AGI, depending on the harness.
Fix the load order before you add one more rule. A file that never loaded is a set of rules that never ran.
TLDR
Five layers of files load before Claude answers, and you write three of them.
My own files cost 40,293 tokens, and only 28,069 of them load on every session.
Give each rule one home. A pasted copy drifts, and the model then picks a version at random.
Check what loaded with
/memory, because the model's own report proves nothing.A hook turns a rule into a gate that blocks a bad draft before you see it.
The Same Request Comes Back Wrong Without a Load Order
Take one prompt you have typed before: "Draft a short post about this week's release and save it with my other drafts." Run it in two setups with the same model.
Without a load order, here is what comes back:
The draft breaks the style rules you added last month, because the only copy it saw was an old paste.
The file lands at the repo root, because no project file names the drafts folder.
Claude says it followed your style guide, and nothing ran to check that claim.
Your next message repeats the corrections you typed last week.
With a load order, the global file loads one current copy of each rule. The project file names the drafts folder. A hook scores the file on save. Your next message is about the idea itself.
Watch out. If the wrong files loaded, throw the output away. No edit repairs a draft written under the wrong rules.
Claude Reads Five Layers of Files Before It Answers
Every session, Claude reads five layers before it answers you. Each layer has one job.
Jose Parreño Garcia maps the same stack: "Claude Code supports memory hierarchies: global, team, and project-level memory."
System prompt. Anthropic writes it. You cannot edit it, and it loads first.
Global CLAUDE.md. A CLAUDE.md is a plain Markdown file of instructions that Claude Code reads on startup. The global one sits at
~/.claude/CLAUDE.mdand loads in every folder.Project CLAUDE.md. Each project folder gets its own. It holds what only that project knows.
Skills. A skill is a folder with a
SKILL.mdfile inside. Claude reads one line per skill at startup and opens the full file only when a job matches.MCP tools and the environment. MCP (Model Context Protocol) is the standard way to plug an outside tool, such as Gmail, into Claude. The tool names, the working folder and the git status load last.
All five layers sit in the context window at once. The context window is the text a model reads before it answers. No layer wins every conflict, so when two layers disagree, the next run can pick the other one.
Skills are the cheap layer. Adding one more skill costs one line of startup text, because the full file stays closed until a job needs it.
Anthropic published its own guide to the skill format in this post.
My Harness Loads 40,300 Tokens Before I Type a Word
I measured my own stack on 2026-09-02. A token is about four characters of text. Nine files I wrote reach the model before my first word, and they add up to 40,293 tokens.
Every session: 28,069 tokens, whatever I ask for.
Writing prompt only: 12,224 tokens, added by a hook. A hook is a script that Claude Code runs on its own at a set event, such as a prompt or a file write.
Job match only: one full skill file, opened when a request matches its description.
Ask that same session about a Python bug and the writing rules never load. The layers that always load stay small, and the heavy rules arrive only for the job that needs them.
Each Rule Needs One Source Because Copies Drift Apart
The usual fix for an ignored rule is to paste it into a second file. Within weeks you edit one copy and forget the other. Both copies reach the model, and they now say different things.
The model sees both versions and picks one. Monday's draft follows the 20-word sentence cap, and Tuesday's draft breaks it. The model read a conflict you wrote.
Nate reports the same decay inside OpenAI, where the agent manual "turned into a graveyard of stale rules."
So give every rule one home:
Write the rule in one file.
Link to that file from everywhere else.
If a second place needs the full text, generate that copy with a script.
Add a check that compares each copy with its source and fails on any difference.
Rule of thumb. Every correction you repeat twice is a file you have not written yet.
One home per rule also means a new rule must reach every old file once. I built a skill called Corpus Rule Rollout for that job. It tests the rule on your best work first, then applies it across hundreds of files with a dry run before every write.
The Corpus Rule Rollout page shows one rollout across a real archive.
Step 1. Write Your Repeated Corrections Into One Global File
Create a folder named .claude in your home folder, and an empty CLAUDE.md inside it. Then write down the five corrections you gave an agent this week.
Write each correction as a short command, such as "Use American English."
Put each one in one file only.
A rule for every project goes in the global file.
Step 2. Move Project Facts Into a Project CLAUDE.md
Create a CLAUDE.md in the root of each project. Move every project fact out of the global file and into it. A project fact is anything only that project needs, such as its drafts folder or its test command.
Step 3. Add a Project Registry That Sends Claude to the Right Folder
One table in my global CLAUDE.md saves me the most retyping. It maps the words I say to a folder on disk and its GitHub repo.
I name a project and Claude works there from any session. Four rules travel with the table:
When two rows collide, such as "the docs", Claude asks which one I mean.
Claude runs
git statusbefore it edits, because some repos sit on feature branches.Claude names the target path in its reply when it writes to another repo.
A commit or a push still needs my yes.
To link a new project, add one row with the trigger words, the local path and the upstream repo.
Step 4. Run /memory Before You Trust the Output
Open a new session inside a project folder and run /memory. Claude Code itself lists the memory files it loaded. Fix any missing or extra file, then restart.
Tip. Trust the
/memorylist over anything the model says it read. The list comes from Claude Code, and the claim comes from the model.
Step 5. Write the Tie-Break Down Once You Pass Three Rule Files
Two layers stop working once you hold more than three rule files, because the files begin to collide. My voice file wants a long conditional sentence. My scoring script caps every sentence at 20 words. The scoring script is a Python program that counts the words and patterns I banned.
One file settles every collision. I call it the runtime contract. It names which files load, in what order, and which file wins each kind of disagreement:
A sample I paste into the session beats the voice profile.
The voice profile beats the skill.
A hard ban beats everything.
Step 6. Let a Script Print Which Files Loaded
Ask Claude which rules it followed and it answers with confidence. That answer is text the model generated. It can say a check passed when the check never ran, because a careful assistant reports success.
So a script renders a panel above every draft. The top half lists the files that loaded, which the script looks up itself. The bottom half runs each scoring script and prints the result:
A tick means the check passed.
A cross means it failed.
A dot means the check could not run, and a dot never reads as a pass.
When the panel and the model disagree, believe the panel.
Step 7. Block a Bad Draft With a Hook
A rule in a CLAUDE.md file is a request. The agent weighs it against everything else in context, and sometimes skips it. Rewriting the rule in capital letters only makes the request louder.
Hamza Farooq draws the same line: "a hook that blocks a tool call cannot be reasoned around."
A hook turns that request into a gate. Mine fire at three points.
On a writing prompt. The hook prints the file chain into context.
After every file write. It runs the scoring script, and on a critical finding it blocks the write and names the lines.
At the end of the session. It refuses to end while a draft it touched still fails.
Example. In one session, 21 LinkedIn comments failed the scoring script and never posted.
Boris Cherny, who leads Claude Code at Anthropic, runs a hook after every edit to format the code.
Step 8. Commit the Harness to Git Because a New Machine Needs the Same Order
Push three groups of files to a private repo:
Commit the global CLAUDE.md and every project CLAUDE.md.
Commit your skills and your hooks.
Commit a
.env.examplewith placeholder key names.
Never commit your .env keys or .credentials.json, which holds live login tokens. On a new machine, clone the repo into your .claude folder and copy each file back in place.
The full backup, restore and version control guide is in the 5 files that give Claude Code permanent memory.
Five Questions a Newcomer Asks About the Load Order
Does a longer CLAUDE.md make Claude follow it better? No. Every line in the global file loads on every session and competes with the rest. Move project facts into project files and job rules into skills.
Ilia Karelin sets the ceiling at 300 lines, because past it "Claude starts treating your instructions as background noise instead of rules."
Where does a rule go when it fits two projects? Put it in the global file. If only some projects need it, write it as a skill, because a skill loads only when a job matches.
How do I see which files Claude loaded? Run /memory inside the session. Claude Code lists the memory files itself, so the list does not depend on the model's answer.
Do I need hooks on day one? No. Start with two layers and the registry. Add a hook when one rule keeps breaking after you gave it one home.
What do I do with a draft written before the fix? Throw it away and run the prompt again. A draft built on the wrong rules carries those rules in every sentence.
The Appendix Holds Every Path and Command
The global and project files:
mkdir -p ~/.claude
touch ~/.claude/CLAUDE.md # global layer, loads in every folder
touch ./CLAUDE.md # project layer, run in the project rootRegistry rows to paste into the global file, one project per line:
notes, the vault -> ~/notes -> you/notes
my website, my site -> ~/code/my-site -> you/my-site
the docs -> ~/work/docs -> company/docsA hook that runs your own checker after every file write, in ~/.claude/settings.json:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [{ "type": "command", "command": "python ~/.claude/check.py" }]
}
]
}
}What to keep out of the backup repo, in .gitignore:
.env
.credentials.jsonSubscribe for the next piece of the harness, written from the files I run every day.
