Context Isn’t a Ranking. It’s Two Axes.
The question comes up in every conversation about Claude Code, and it always arrives in the same
shape: what wins, CLAUDE.md or a skill? People are asking for a ranking. They want one
chain, something like CLAUDE.md > skills > data, so they can memorise it and move
on.
The chain does not exist. Worse, believing in it produces exactly the wrong instincts: you start
putting things in CLAUDE.md because it feels higher, and you end up with an always-on
layer so large it crowds out the material the agent actually needs to read.
"Context" gets used loosely for at least two different questions, and they have different answers. Split them apart and both become easy.
There is a one-page visual version of the argument below, with all five mechanisms plotted on both axes at once: Context in AI Coding Agents, Two Axes Not One Ranking →
Axis 1: scope and loading
The first question is when does this enter the window. There are five mechanisms, and they differ on scope (how long they stay relevant) and on what triggers the load.
CLAUDE.md is always loaded. It is layered by scope: enterprise, then project, then user. The user layer is effectively your personal profile, the preferences you carry from repo to repo.
Skills are loaded on demand. The model pulls one in when its description matches the task at hand. Lazy by design, which is why the description field is the part that matters most.
Commands are user-invoked prompt templates. You type /name, the
template is injected. Nothing loads until you ask.
Data is streamed in on the fly: files, tool results, whatever you paste.
Subagents are the odd one out, and the distinction is the whole reason they exist. They do not load into the current window at all. They run in their own context and hand back only a result.
That last point is the one worth internalising. Everything except the subagent shares one finite token budget. When people describe subagents as "a way to organise work", they are describing a side effect. The mechanism is that a subagent reads a hundred files and returns three paragraphs, and the ninety-seven files it discarded never touch your window.
Axis 2: precedence
The second question is entirely separate: what happens when two instructions conflict.
Here there genuinely is an order. System and enterprise instructions first, then your explicit
instruction in the moment, then CLAUDE.md, then skill guidance.
Notice what is missing from that list. Data does not appear, and it is not because data ranks last. Data is not a competing instruction at all. It is the material the instructions operate on. Asking whether a CSV outranks a skill is a category error, and the fact that the single-chain model forces you to answer it is the clearest sign the single chain is wrong.
Why it is built this way
Lazy loading is not a statement about importance. It is token economy. You keep the always-on layer small and pull in the rest only when it is needed, because the window is finite and every token spent on instructions that do not apply to this task is a token not spent on the task.
This reframes the design question. Instead of "how important is this guidance", ask "what is its
scope, and what should trigger it". Guidance that applies to every single turn in this repo belongs
in CLAUDE.md. Guidance that applies to one kind of task belongs in a skill, where a
good description does the triggering. A procedure you want to fire deliberately and never by
accident belongs in a command. And work whose intermediate steps you do not want to pay for belongs
in a subagent.
What it changes in practice
In this workspace the split shows up as a design rule rather than a theory. There are ten agent systems and twenty-five subagent definitions, and almost every one of those subagents exists because some piece of work has an expensive middle and a cheap answer. The collector that pulls a quarter of bank transactions, the checker that re-opens every cited file to confirm a quote is really there: both read far more than they report. Running them in the main window would work exactly once, on a small quarter, and then stop working.
The precedence axis shows up somewhere else entirely, in what happens when my own instruction
contradicts a file. If I tell an agent to skip a step that CLAUDE.md requires, my
instruction wins, which is correct and also the reason the genuinely non-negotiable guardrails in
this repo are not written as instructions at all. They are written as tool grants. An agent with no
send tool cannot be talked into sending, no matter where in the precedence chain the argument comes
from.
That is the practical payoff of separating the axes. Once you stop asking which layer outranks which, you start asking the two questions that actually have answers: when should this load, and what should happen if it conflicts. Getting that distinction right is what keeps agents predictable as the number of them grows.