Four places context can land
Each of the four answers a different question, which is why using only one of them would not be enough.1
Session start
Everything standing that governs where the agent is about to work: what is due, open handoffs (lettered A to J), forks, the active projects, tasks and milestones, your saved notes, and whatever signals are worth knowing before the first prompt. What is due always sits on the first screen.
2
At the prompt
Whatever bears on the thing that was just asked for. base matches the text against your domain triggers, and the files this session has touched against your projects’ folders, and returns the rules, prior decisions and notes attached to the domains that matched, the best-fitting rules first.
3
Before a tool runs
The rules of the project that owns the file about to be touched, and the shape of that file (the entities inside it, what it imports, and what depends on it), placed before the agent reads a single line of it.
4
After it returns
What the result means in this codebase. For the exact lines just read, that means the call chain they sit in, delivered while it is still the thing being thought about.
How it decides what is relevant
What arrives is chosen by what is happening at that moment, which is what keeps it short. Opening a billing file returns the billing rules and the decision that governs them. It does not return the auth rules, the deployment notes, or a summary of the project. This matters for two reasons that pull in the same direction. Nobody is paying to send a model everything it might conceivably need. And a model given a briefing it did not ask for tends to hedge its way through the parts that do not apply. You can see exactly what a given piece of text would pull before you send it:domains.toml; the rules, decisions and notes attached to the domain live in the graph.
You can also just ask, and the answer comes out of the same place:
When it does not all fit
Claude Code delivers only so much of a hook’s text to the model, so base fits each hook to a budget: 10,000 bytes by default, the size measured to arrive whole, andbase doctor --measure re-measures it for your Claude Code. The most important text goes first. At the prompt that is the rules matched to this prompt or file, then their domain’s context, relay messages, your global rules and decisions, and the bracket rules last.
What does not fit is held back whole, never cut mid-sentence, and a line says what was held back and the command that prints it, base hooks show <block>. Rules that were held back still reach Claude as a short title each, with an instruction to read the rule before acting on anything it covers. Each session’s full output is kept under .base/hook-output/<session id>/, and base log matches shows what every prompt matched and why.
What base is holding
Four kinds of thing, all in one graph, all connected to each other. Your code. Every function, struct, class, import and call relationship, extracted by tree-sitter across more than thirty-five languages. “What calls this?” is a query rather than a search across files. Your work. Projects with their milestones and tasks. Decisions with the reasoning that produced them. Rules that fire when the context matches. This is the material that otherwise lives in somebody’s head, or in a wiki that was last accurate in March. Your documents. Markdown with frontmatter becomes connected nodes, and headings, links, wikilinks and tags all become edges. When an agent writes markdown, the hook teaches it the extraction contract at the moment of writing, so new documents are structured correctly as they are created rather than cleaned up afterwards. Your operations. Which domains are active, what changed since the last session, what has gone stale, what is still open. All of it is stored as plain-text NQuads files that live in your repository and diff in git. Queries run through SPARQL against an embedded Oxigraph instance loaded from disk per invocation, so nothing base needs is behind a network call.Sessions that carry over
Work does not usually finish inside one session, so base treats the seam between sessions as something to manage rather than something to survive. Four star commands cover it, typed straight into the chat:
Open handoffs resurface on their own at the next session start. Star commands are defined in
commands.toml and are fully customizable. Run base commands list to see what is currently loaded.
When several sessions are running at once, they coordinate through the relay. It gives each session a stable title, pings and task hand-offs between them, and a board showing who is alive and what is pending. A message arrives as one line on the receiving session’s next prompt, or at once through its inbox watcher (base relay arm prints how to start one), and it reads as information, never as an order that outranks you.
It learns from your corrections
When you correct the AI, base notices, from your wording, from what happened in the turn, or from a reply that starts withCORRECTED:, and asks Claude to file it as a rule proposal. Nothing changes until you approve it with base rule review, and base tune looks through recent sessions for the rule changes worth proposing. See Corrections and tuning.
When a hook fails
The hooks are designed to fail open. If base cannot answer, the turn proceeds without the injection rather than blocking on it. A session that loses its briefing is worse off than one that never had it; a session that cannot start at all is worse than both. To check the health of the graph itself, runbase doctor. It reports across both tiers and exits nonzero when something is wrong.