The Four-Layer Memory Pattern for Claude Code: Portable Identity Across Projects

You're working in three different repositories. Each one has different conventions, different patterns, different ways of doing things. Claude Code starts fresh in each project, asking the same questions, making the same mistakes.

Andrej Karpathy's LLM wiki pattern solved this for personal knowledge. The four-layer memory system extends that solution to code projects. It's not about vector databases or semantic search. It's about giving Claude Code a persistent identity that travels with you.

Table of Contents

1. Why Memory Layers Matter for Multi-Project Work
2. Layer One: CLAUDE.md (Project Identity)
3. Layer Two: Wiki Index (Permanent Knowledge)
4. Layer Three: Wiki Log (Session History)
5. Layer Four: Morning Briefing (Daily Context)
6. How the Layers Work Together
7. Setting Up Your Four-Layer System
8. What This Pattern Doesn't Solve

Why Memory Layers Matter for Multi-Project Work

Claude Code's default memory is context-bound. It remembers what happened in the current chat. When you switch projects or start a new session, that memory disappears.

This creates a specific problem for developers working across multiple repositories. You explain your testing conventions in Project A. You switch to Project B and explain the same conventions again. You come back to Project A three days later and explain them a third time.

The four-layer pattern solves this by separating memory into different time horizons. Each layer serves a different purpose.

Analogy: Think of it like a filing system. Project files stay in project folders (CLAUDE.md). Reference material goes in the central library (wiki index). Meeting notes stay in chronological logs (wiki log). Today's priorities go on a sticky note (morning briefing).

Layer One: CLAUDE.md (Project Identity)

This is the project-specific layer. One CLAUDE.md file per repository. It contains:

• Project conventions and style guides
• Architecture decisions
• Testing patterns
• Common commands and workflows
• Dependencies and setup notes

CLAUDE.md lives in the repository root. Claude Code reads it automatically when you start a session in that project.

What goes in CLAUDE.md:

CLAUDE.md should be 200-500 lines. Longer than that and you're documenting implementation details that belong in code comments. Shorter and you're missing critical conventions.

Layer Two: Wiki Index (Permanent Knowledge)

This layer is cross-project. One wiki/index.md file in a central location (home directory or Dropbox). It contains knowledge that applies across all your projects:

• Your personal coding preferences
• Tool configurations
• Patterns you use repeatedly
• Learning notes from past projects
• Technology decisions and rationale

The wiki index is append-only. You add to it, you rarely delete from it. It grows into a personal knowledge base.

Example wiki index structure:

## Testing Patterns
- Always mock external APIs in unit tests
- Use test containers for integration tests requiring databases
- Coverage targets: 80% for utils, 60% for UI components

## TypeScript Conventions
- Prefer type over interface for plain objects
- Use zod for runtime validation at API boundaries
- Avoid enum, use const objects with 'as const'

## Performance Rules
- Database queries: always add indexes for foreign keys
- Next.js: use dynamic imports for components over 100KB
- React: useMemo only after measuring, not by default

The wiki index should reference specific experiences. "After the outage in Project X, we learned..." not "It's good practice to..."

Layer Three: Wiki Log (Session History)

This layer captures what happened. One wiki/log.md file, also in your central location. It's a chronological record of significant sessions:

• What you built
• Problems you solved
• Decisions you made
• Things that didn't work

The wiki log is dated. Each entry starts with YYYY-MM-DD. It's not a journal, it's a history of significant work.

Log entry format:

### 2025-04-15 | Project A | Auth system

Added JWT refresh token rotation. Initial attempt used Redis for token storage but hit race conditions under load. Switched to database transactions with row-level locking. Performance is 50ms slower but correct under concurrency.

Key lesson: Redis pub/sub doesn't guarantee ordering across instances.

Files changed: auth/tokens.ts, auth/refresh.ts

Log entries should be 3-5 sentences. The goal is to recognize the situation if you encounter it again, not to document every detail.

Layer Four: Morning Briefing (Daily Context)

This layer is ephemeral. A morning-briefing.md file that you update each day. It contains:

• What you're working on today
• Blockers or constraints
• Specific context Claude Code needs right now

The morning briefing is temporary. You overwrite it daily or every few days. It's the shortest layer, usually 5-10 lines.

Example morning briefing:

# 2025-04-16

Working on: Payment processing integration in Project B
Blocker: Stripe webhook signatures failing in staging
Context: Production uses webhook secret from env var STRIPE_WEBHOOK_SECRET
Goal: Get webhook validation working in staging environment
Constraint: Can't modify production config until this is proven in staging

How the Layers Work Together

<!, Layer 2: Wiki Index, > Wiki Index Cross-project knowledge | Months to years

<!, Layer 3: Wiki Log, > Wiki Log Session history | Days to weeks

<!, Layer 4: Morning Briefing, > Morning Briefing Daily context | Hours to days

<!, Arrows, >

<!, Caption, > Four-layer memory stack: each layer serves a different time horizon

When you start a Claude Code session, it reads all four layers. The morning briefing tells it what you're doing today. The wiki log reminds it of recent work. The wiki index provides your general principles. CLAUDE.md gives project-specific context.

This creates portable identity. Your preferences and patterns travel with you. Claude Code doesn't forget your conventions when you switch projects.

Setting Up Your Four-Layer System

Step 1: Create the central wiki

mkdir -p ~/claude-wiki
touch ~/claude-wiki/index.md
touch ~/claude-wiki/log.md
touch ~/claude-wiki/morning-briefing.md

Step 2: Add CLAUDE.md to each project

In each repository root:

touch CLAUDE.md

Start with project structure, then add conventions as you encounter questions Claude Code asks repeatedly.

Step 3: Configure Claude Code to read the wiki

In Claude Code settings, add your wiki directory to the context paths. The exact method depends on your Claude Code setup (desktop app, CLI, or API integration).

Step 4: Build the habit

• Update morning-briefing.md at the start of each work session
• Add to wiki/log.md after significant sessions
• Add to wiki/index.md when you learn something reusable
• Update CLAUDE.md when you establish new project patterns

What This Pattern Doesn't Solve

This pattern gives Claude Code memory across sessions. It doesn't give it perfect recall. It won't remember every implementation detail from three months ago. It won't automatically extract patterns from your code.

The four-layer system requires manual curation. You decide what goes in each layer. That's both a limitation and a feature. You're not relying on vector search or semantic retrieval. You're building explicit knowledge.

Memory is not solved. But this pattern makes it manageable for developers working across multiple projects. You get portable identity without complex infrastructure.

Takeaway

The four-layer memory pattern separates context by time horizon. CLAUDE.md for project-specific conventions. Wiki index for permanent cross-project knowledge. Wiki log for session history. Morning briefing for daily context.

Each layer serves a different purpose. Together they give Claude Code a persistent identity that travels across your work. You explain your conventions once, not once per project.

Start with CLAUDE.md in your current project. Add the wiki layers as you see patterns worth preserving. The system scales with your needs, not against them.