A brain made of plain markdown

Every Claude Code session starts with no memory of the last one. If I want it to know that I hate being asked permission for small things, or that the eBay quota resets at 07:00 UTC, or that a crawler took my sites down in October, something has to tell it. Every time.

So I keep a brain for it. It isn't a product or a vector database. It's markdown files in git, in four layers, and Claude reads most of it on its own and writes most of it too.

Layer one: how I work

One CLAUDE.md loads into every session in every project. It's a symlink into a small repo of my own, so it's versioned and comes back on a new machine with one install script.

It says how I like to work. Default to autonomy. Ask your questions once, up front, in one batch. Only two things are worth stopping for: a cloud bill going up more than $5 a month, or losing data that can't come back. "Done" means deployed and checked live, not "tests pass".

The part I'd steal is the rule for where a lesson goes when something breaks. The strongest mechanism that fits wins:

1. Test: catches the regression regardless of model or prompt.
2. Hook / lint rule: for hard rules that must never be broken.
3. Skill step: for procedure.
4. CLAUDE.md line: for project facts and gotchas. Always include the why,
   so a future model can judge when the rule applies.

A line in a prompt is the weakest place to put a lesson. A test is the strongest.

Layer two: what each project has learned

Claude Code keeps a memory folder per project. I've got 56 memory files across ten projects. Each one is one fact, with a why and a how-to-apply, and an index that loads at the start of every session.

Most of them were written by Claude itself, mid-session, when I corrected it or when something went wrong. A real one, lightly trimmed:

---
name: prefers big swings, less hand-holding
description: When user says "continue" or doesn't explicitly check in, they
  want Claude to keep moving through plans autonomously rather than pause for
  confirmation at each step
type: feedback
---
User prefers Claude to operate at "big swing" granularity, pushing through
entire phases of plans autonomously when given general authorization.

**Why:** Excessive check-ins defeat the purpose. Stated directly: "I WANT
CLAUDE TO BE RUNNING AGENTS ON MY BEHALF DAILY THAT DO SIGNIFICANT AND
SUBSTANTIVE WORK."

**How to apply:**
- When user says "continue" or "keep going", push through the entire next
  logical chunk, not just one task
- Stop and check in only at: phase boundaries, taste judgments, anything
  irreversible, or budget concerns worth flagging
- Don't ask "ready for the next task?" after every commit

Others are pure procedure. One records, step by step, how to drive Gemini in a browser tab to make product photos, including the check it runs before every send and how to keep the clipboard from carrying the wrong image. That took an afternoon to learn and now takes no time at all.

Layer three: decisions with dates

Each repo has its own CLAUDE.md and a decision log: date, decision, why, who. When a rule looks odd, the why is right there. My buyer's-guide sites are static files, and the rule says so in bold, followed by the reason: on October 6 a crawler walked every filter URL, blew through the hosting limits, and took everything down. A future model can weigh a rule it understands. It can only obey one it doesn't.

Layer four: shared research

My product factory hung its ideas off eight themes, each a file of research notes and linked ideas. The idea generator was meant to work the thinnest theme each time. It didn't: five themes never got real research notes, so it kept mining the same three, and said so in its run logs. It was right. A knowledge base compounds only where someone feeds it.

What's not built yet

Honestly, a fair amount.

• No cross-project memory. A lesson learned in one project stays there unless I promote it to the global file. I do that by hand, and sometimes I forget.
• A standards folder that's still empty. The plan is one file per topic, linked from the global rules. There's a README and nothing else.
• Crutch pruning, untested. Some rules only exist because a model got something wrong. I tag those inline, with the model and the date, so they can be deleted when a newer model doesn't need them. The benchmark that would prove it has no rows yet.

The next step is probably one searchable store across projects. For now, plain files in git have one big advantage: I can read every word of what my agents believe, and change it with a pull request.

Drafted with Claude from the files, repos and run logs it describes.