Claude Code Doesn't Remember. Here's How I Fixed That.

Claude Code is remarkably capable. It can read codebases, write code, run tests, create pull requests. But it struggles with continuity. You can resume a conversation with claude -r, but as conversations grow longer, auto-compaction drops earlier context, token costs rise, and response quality degrades. Finding an old conversation is surprisingly hard, too, since Claude Code's conversation management is minimal. The result: complex tasks that span multiple sessions tend to lose their thread.

Over the past several months, I've built two patterns that changed how I work with Claude Code. The first turns multi-step tasks into structured execution plans that survive across sessions. The second gives Claude persistent knowledge about any codebase, even repos you don't own. They're simple to set up, and they compound over time.

Plans that survive across sessions

Real work rarely fits in a single conversation. A feature might span several files, require multiple commits, and take days. Claude Code starts fresh every session, so you lose the thread. You end up re-explaining what you've already done, what's left, and what decisions were made along the way.

I solved this with GitHub issues as execution plans, managed by a set of custom Claude Code skills (I've published simplified versions at claude-plan-skills).

The workflow has four stages:

1. Create a plan (/gh-create-plan): I describe the work to Claude, and it creates a structured GitHub issue with a description, steps as checkboxes, and relevant links. The issue becomes the single source of truth for the task.

2. Implement the plan (/gh-implement-plan): Claude reads the issue, presents the steps, and works through them in order. After each step, it commits the changes and checks off the checkbox on the issue. If something is unclear, it stops and asks rather than guessing.

3. Update the plan (/gh-update-plan): As work progresses, decisions change, or new information surfaces, the plan issue is updated with session notes. A new conversation can pick up exactly where the last one left off.

4. Close the plan (/gh-close-plan): When the work is done, the issue gets a summary and is closed. It then serves as documentation: what was built, why, and what decisions were made along the way.

Here's what a plan issue looks like in practice:

## Description
### What
Add a new `validate` subcommand that checks config files for syntax errors before deployment.

### Why
Users currently discover config errors only at deploy time, which wastes CI minutes and blocks releases.

## Steps
- [x] Add CLI argument parsing for `validate` subcommand
- [x] Implement config file parser with error reporting
- [ ] Add unit tests for valid and invalid configs
- [ ] Update help text and README

The checked boxes show where a previous session left off. When I start a new conversation and run /gh-implement-plan, Claude reads the issue, sees that two steps are done, and picks up at "Add unit tests." No re-explaining needed.

The plan issues also include diagrams, generated as Mermaid blocks. When I describe the work, Claude produces both the issue structure and a diagram to visualize the flow. Because Mermaid is plain text, the diagrams live inside the issue body, are version-controlled like everything else, and render natively on GitHub:

This is text in the issue, not an uploaded image. Anyone reading the issue sees the rendered diagram. Anyone editing the issue sees the source. Claude can update it as the plan evolves.

Personal context for every project

The plan cycle solves the "losing the thread" problem. But there's a second kind of context loss that's more subtle.

Claude Code reads CLAUDE.md files for project context, and you can generate one with /init. But CLAUDE.md is a shared, committed file. It's the team's context. I often need personal context on top of that: my custom test commands, the modules I specialize in, details about my expert areas that are too specific for the shared file. And for open-source projects where I'm a contributor but not a maintainer, I can't commit a CLAUDE.md at all.

Claude Code also reads a file called CLAUDE.local.md from the project directory. It works just like CLAUDE.md, but it's meant for personal context that you don't commit. This is the key to the pattern.

I keep a private repo called ai-memory that holds CLAUDE.local.md files for every project I work with:

ai-memory/
  claude/
    some-oss-project/
      CLAUDE.local.md
    my-teams-service/
      CLAUDE.local.md
    infra-tools/
      CLAUDE.local.md

Each file contains what I need Claude to know beyond what's in the shared CLAUDE.md: how I run tests, which modules I own, architecture details relevant to my work, conventions I've learned from code review. Here's a simplified example:

# CLAUDE.local.md

## My test commands
Run the integration tests I usually work with:
`mvn test -Dtest=ClassName#methodName -Pintegration`

## Areas I work on
- The config parser module (src/main/java/config/)
- The validation pipeline (src/main/java/validate/)

## Conventions I've learned
- Commit messages: conventional commits (feat:, fix:, chore:)
- PRs must reference an issue number
- No wildcard imports

I symlink these files into each project's checkout:

~/git/some-oss-project/CLAUDE.local.md
  → ~/git/ai-memory/claude/some-oss-project/CLAUDE.local.md

Now when I open Claude Code in any project, it picks up my personal context automatically alongside the project's shared CLAUDE.md. No re-explaining. The ai-memory repo is private and version-controlled, so the knowledge accumulates. When I learn something new about a project, a test quirk, a build flag, a convention I picked up from code review, I add it to the file. Every future session benefits.

Beyond these two patterns

These two patterns are the foundation, but they're not the whole setup. I also use a granular permission model that controls what Claude can do without asking, an instruction that prevents it from speculating about code it hasn't read, and skills that handle the back-and-forth of GitHub PR reviews, some of which I'll cover in a future post.

The edge is judgment, not config

Everything I've described here is simple to set up. A private repo with markdown files. GitHub issues with checkboxes. A few custom skills. None of it is technically impressive.

The value isn't in the mechanism. It's in knowing what to put in a CLAUDE.md file, how to break a task into steps that Claude can execute reliably, and when to let Claude work autonomously vs. when to stop and redirect. That judgment comes from using these patterns daily and refining them based on what actually works.

If you try these patterns, you'll develop your own version of that judgment. The config files are the starting point, not the destination.