Reading through Claude Code's small official docs turned up three levers I was not using — agent teams, instructions for compaction, and a hidden MCP injection path
Introduction
Besides the large pages that gather a whole feature in one place, the official documentation contains a great many small pages of a few hundred to a few thousand characters. They are unremarkable files on their own, explaining a single setting or an edge case. It is tempting to skip them — but reading them right to the end, in batches of eight, turned up three findings that none of them would have yielded individually.
I imposed one condition on how I read. Every time I finished a batch, I mechanically searched my own existing records (design documents and past investigation logs) so as not to mistake something I already knew for a “new discovery”. Thanks to that condition, the third finding landed not as a “new discovery” but as a “record I had forgotten”.
The set of small official docs (batches of eight)
│
├─▶ Prior-record check (after each batch, mechanically search my own records)
│ └─ if it matches, land it as "already known" ── the return edge ──┐
│ │
├─▶ Finding 1: a lever for writing "what to preserve" into compaction │
│ └─ zero dedicated sections in the always-loaded discipline files ─▶ confirmed unused
│
├─▶ Finding 2: an external tool's description text gets added to the system prompt
│ └─ my own integration tool leaves it unset ──▶ third-party ones are invisible (limit of observation)
│
└─▶ Finding 3: the experimental feature for organising multiple AIs was already recorded a month ago
└─ the prior-record check fires ◀────────────────────────────────┘
(it fired four times in a row during this day's batch reading. Had I
written it up as a "new discovery", the same content would have been
recorded twice, costing extra time later to re-read and check for
a contradiction that was never there)
Finding 1: you can write “what to preserve” into the compaction process
Keep a conversation going long enough and, partway through, compression by summarisation kicks in (compaction: the recent exchanges stay, while older parts are replaced by a summary the AI writes itself). Information that is easy to overlook can disappear at that point — a premise confirmed at the very start of a long task, or a decision made along the way, dropping out of the conversation at the summary boundary.
The official documentation states explicitly that there is a lever for writing instructions into that summarisation process itself.
“The compactor reads your CLAUDE.md like any other context, so you can include a section telling it what to preserve when summarizing. The section header is free-form (not a magic string); the compactor matches on intent.”
It means the internal process that performs summarisation reads the always-loaded settings file just as it reads any other context, and that you can include in it a section saying what should be preserved when summarising. There is also a note that the wording of the heading is not fixed, and that matching is done on the intent of the content.
Checking the always-loaded discipline files in my own environment, dedicated sections of this kind numbered zero. That summarisation during a long session might dilute the procedures to check before starting work, or the discipline of taking a backup before a destructive operation, was something I had grasped — but I had not been using this lever as the countermeasure.
Finding 2: an external tool’s description text is added to the system prompt
The standard protocol for connecting external tools and data sources to an AI assistant (not a proprietary spec of my own, but an integration standard used in common across several AI assistants) allows an instructions field to be set. The official documentation states how that field is handled:
“instructions … Added to Claude’s system prompt.”
In other words, if the integration tool writes text into instructions, that text is added as it is to the foundational instruction the AI works from (the system prompt). This is not a mechanism specific to any one extension; it is a feature of the standard itself.
Checking the initialisation code of the personal integration tool I built (which I run for searching past records), it passes only the tool name and leaves instructions unset. So no writing into the system prompt is happening from a tool I wrote. On the other hand, whether integration tools published by others (one for browser operation, for instance) use the same field is not visible from here. There is a path whose breakdown does not remain in the conversation record, and no means of looking into it.
⚠️ I will write this limit down honestly. “Confirmed that nothing is being added” can be said only of my own tools; for third-party ones, the accurate state is “not visible”.
Finding 3: what should have been a “new discovery” was recorded by me a month ago
I read about an experimental feature for splitting roles across multiple AIs and running them in parallel. It is disabled by default and does not work unless a dedicated setting is set. Having finished reading, I was about to write it up as a “new discovery” when the prior-record check that runs at the end of each batch fired.
A mechanical search of my own records returned the following two entries.
~/.claude/teams/{team-name}/config.json(deleted when the session ends), mailboxinboxes/{agent}.json, task list~/.claude/tasks/{team-name}/(persistent, cleanupPeriodDays). team-name =session-+ the first 8 characters of the session ID. The config must not be hand-edited.
experimental, off by default:
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. … tokens scale linearly with the number of teammates, roughly 7x in plan mode.
Checking the dates, I had recorded almost exactly the same content about a month earlier. This close reading was no more than a re-confirmation of it. And the procedure itself — “search my records before calling something a new discovery” — fired four times in a row during that day’s batch reading. Had it not fired, I would have written the same content up again as a “new discovery”, and later cost myself time re-reading it to work out whether it contradicted the earlier entry or simply repeated it.
The more you read, the heavier the checking procedure has to be
What actually paid off in this sweep was not the contents of the official documentation so much as running, mechanically and after every batch, the procedure of searching my own records before calling anything I had read a new discovery. One of the three findings turned out not to need the official text as corroboration at all. The more you read, the more the outcome is decided by the procedure for reconciling what you read with what you already understand, rather than by the reading itself.
The three levers were not things I found by going out to look for them; they had been sitting there all along inside the small documents I kept putting off. The less material a document contains, the more readily it is treated as understandable without being read — and this time, that treatment amounted to three missed items.