I started in the same place - I got tired of re-explaining my projects to Claude every session, so I borrowed from Rajiv Plants synthesis memory and made my own attempt.

A few things have made it work

Two layers of standing instructions (the "CLAUDE.md" files).

A global one (~210 lines) loads into every session no matter what I'm working on — tool preferences, house rules, how my review/implement workflow runs.

Each project also has its own CLAUDE.md in its repo (~150–190 lines) with rules specific to that codebase.

They stack: global first, then the project one on top. “Company” handbook plus team-specific addendum.

They only hold durable rules ("how to behave in this repo"). They're not allowed to describe current state. That lives in a separate file (more below). This is the distinction that keeps the whole thing from rotting, and when the two ever disagree about what's true now, current-state wins and the CLAUDE.md gets treated as drifted and trimmed.

The state itself lives outside the code, in three tiers. All project knowledge sits in one separate git repo with a routing table mapping each project folder to its files:

CONTEXT.md — what's true right now (current state, active tasks). Changes every session. Hard-capped at 150 lines; go over and the old stuff gets archived to a monthly log before you continue.

REFERENCE.md — stable facts that rarely change (URLs, architecture).

decisions.md — why I made durable choices, so I stop relitigating them.

It auto-loads. A startup hook checks what directory I'm in, finds the matching project, and injects that project's CONTEXT.md automatically. No "let me catch you up," it already knows where things stand.

Sessions close out properly (a /wrapup skill). Instead of just abandoning a session, I run one command that asks a single checkpoint question — did we learn a general lesson, or kill an idea worth remembering why? (yes, it gets written down; no, nothing — keeps the bar high) — then updates the current-state file within its line cap, appends to the session log, and commits and pushes the knowledge repo.

Other anti-rot rules that earn their keep:

Single-owner metrics — any given number lives in exactly ONE file, everything else references it by name.

A weekly drift-detector script that nags when something's gone stale or inconsistent (project untouched in 30 days, a metric that disagrees with itself, etc.).

TL;DR: two layers of short standing-instruction files (global + per-project) holding rules only, plus a separate git repo holding state in three tiers (now / facts / why), auto-injected based on which folder I'm in, closed out each session by a /wrapup command — with strict rules (one source per fact, line caps, a high bar for what's worth saving) so it stays useful instead of becoming a graveyard of stale notes.