Context Is Everything!¶

For much of 2025 this was my experience of agentic gen/AI coding:

Start a task, Claude Code takes a while to warm up until it hits a sweet spot where it reliably produces consistent, good work for many turns, and then, blammo!, context collapse. At which point my only options are /clear or /compact. Arg!

Context Collapse¶

We know from the NoLiMa paper that longer contexts become diffuse which result in the haystack problem: earlier signals that lack lexicographical matching get buried in the mass of tokens. At some point the agent starts to go haywire — often when we're near the context window limit. This is super frustrating because it comes without warning and interrupts flow. Once this happens, I find that /clear is the only workable option. I wanted a better option than to simply start over.

Introducing Context-Curator¶

https://github.com/0x6a77/context-curator

Context-curator is a set of Claude Code slash commands that allow you to manage context in a task-oriented way. (You can read below how context-curator came to exist.) The general idea is that context, which includes the CLAUDE.md files, really should be task-specific so that Claude Code laser focuses on just what's needed for the task.

Now I can warm up a context and save it as part of a task, and when I encounter context collapse, I just reload the warmed-up context. Or when I return to a task, I get the warmed-up context. (If we reload a context within the cache window, we'll save tokens. This will usually be true for /resume after a collapsed context.)

Task and Context¶

Context-Curator has two major constructs:

• Task: focuses Claude Code on a specific task. We @include a task-specific CLAUDE.md file.
• Context: Stores a named version of the session context in the task area. You can manage and reload these contexts.

Commands¶

Context-Curator introduces the following commands:

The task commands manage your tasks and the context commands manage contexts within those tasks. So now I can have an api-refactor task that has one or more named contexts. These can be personal (stored in ~/.claude) or project-based (stored in ./.claude). The project-based contexts, known as "golden contexts" are available to the entire project team.

Example Usage¶

Task Resume¶

If you already created the api-refactor task, the following command reloads that task. (Notice that the user has to manually enter the /resume command to reload the session context — Claude Code does not expose any automated way to manage context.)

❯ /task:task api-refactor
⏺ Bash([ -f /Users/jeffw/git/karrots-appserver/.claude/tasks/default/CLAUDE.md ] && echo "initialized" || echo "not-initialized")
  ⎿  initialized
⏺ Bash(node ~/.claude/context-curator/dist/scripts/task-check.js "api-refactor")
  ⎿  exists:personal
⏺ Bash(node ~/.claude/context-curator/dist/scripts/context-list.js "api-refactor")
  ⎿  Project: /Users/jeffw/git/karrots-appserver
     Task:    api-refactor

  ✓ Task: api-refactor
  ✓ Context: fresh start

  Run: /resume 70cd2adc-37e7-489a-9dfb-8ddf1475135c

  Your focus:
    Refactor the gRPC service layer to use consistent patterns across all service implementations.

❯ /resume 70cd2adc-37e7-489a-9dfb-8ddf1475135c 

How We Got Here¶

I never understood why Claude Code didn't allow me to manage the context and have long wanted to fix this. I should be able to save, name, and reload a warmed-up context — especially given how critical they are to task success, as NoLiMa shows. (In December 2025 there was partial progress with /rename.)

Context Management¶

The problem is that Claude Code doesn't expose the context or provide any way to load it, so there is no easy way to solve this problem without the source code. I spent weeks simulating workflows with Claude Chat to test ideas before implementing them to see if there was some workable hack, but it just seemed impossible. Even if I succeeded, there is no way to load context through automation without the user taking manual action. I even tried reverse engineering the Node.js to see if I could locate the memory location of the current context objects.

I kept coming back to /resume because that is the only way a normal user can affect Claude Code's context. What if we let the user manage their contexts by name and then ask them to manually reload them when they were ready? While this is not a great user experience, it does work. To make this less terrible we give users a list of /resume commands they can copy-paste into the prompt. This minor irritant works reliably and gets us a huge capability!

Tasks¶

Over several weeks I iterated on different ideas and behaviors, always first simulating workflows with Claude Chat. As the first rudimentary capability emerged, I started to realize once I could easily manage contexts, what I really wanted was task-specific contexts! Once I had this, I realized that tasks as a first-order concept make a lot of sense! That led to the idea of a task-specific CLAUDE.md file. This led to an idea of a dual-CLAUDE.md model where one is part of the git project and the other git-ignored. In the git-ignored CLAUDE.md, the task command could insert an @import statement to load the CLAUDE.md to import task-specific context from the task sub-directory. The fact that I'm working with a task doesn't affect other members of the project.

User vs Project Tasks and Contexts¶

Then I realized that we might want to share these tasks and contexts with the team, so I introduced two kinds: user, stored in ~/.claude, and project (aka golden) stored in ./.claude. The task's home directory is either ~/.claude/projects/<PROJECT>/tasks/<TASK> (user tasks) or ./.claude/tasks/<TASK> (project tasks).

A Work in Progress¶

Context-Curator is a work in progress, and is a bit of a hack due to the lack of first-class context management in Claude Code. There are many glitches and rough spots that I continue to work out, but I wanted to get it out there in case it is useful to others. I will continue to fiddle with the user experience as I get more experience with using it. Another problem is how dang slow it is. Slash commands don't run like pure shell scripts — they invoke the model which is part of why it's slow, but it's also possible my implementation is sub-optimal. I continue to work on this. (Tho' it has gotten about 5x faster than the early versions!)

Development Ideas¶

Beyond stability and user experience, I'm also thinking about other ways to manage and focus context for large, legacy codebases. E.g. can we limit Claude Code to a specific sub-directory to prevent drive-by refactoring in areas we don't want touched? (Perhaps an @include in the user CLAUDE.md file can tell the model to only look in a specific set of sub-directories?) Another idea is to generate per-directory CLAUDE.md files?

There is some tension between the caching window and a saved context's size. What is the ideal size of a warmed-up context? That will be an interesting thing to measure.

Steal this Project!¶

Ideally the Claude Code team will steal this idea so I can retire this project! I've tried to adopt a design that's in line with how the Claude Code creators use the product themselves so that it's a natural extension to existing workflows. But if you do steal it, please make sure to expose context as a first-class service so that we can extend and enhance it. Especially for large, brownfield projects where laser-focused context is critical to success.