I once told Claude, about a sentence it had just written for me: “I started reading that and it made me feel stupid, so I stopped.” That one line taught me more than any careful answer could have, because it marked the exact spot where the writing lost me.
It also pointed at something I had missed for a long time. Talk to Claude for a while and it starts to sound like you. Write formally and it answers formally. Crack a joke and it loosens up. Language models pick up the register and style of the person in front of them, and that mirroring is usually a nice property. But the way I talk is not the way I best take in information. Those are two different systems, and the mirroring only serves the first one. When Claude explains something new to me in my own comfortable style, it optimises for how I sound, not for what stays in my head.
So I stopped guessing and ran some tests on myself.
The mistake I was making
If you had asked me whether analogies help me, I would have given you a flat answer. It would have been wrong, because the honest answer has a condition on it, and I had never separated the two cases.
When I am learning a new concept and I ask for it to be explained, an analogy helps. It gives me a handle on something I have nothing to attach to yet. But when I am in the middle of work and Claude just tells me what it did, the same analogy is dead weight. I have to decode it for no reason, and it costs me the attention I wanted on the actual task.
So the rule is not “analogies, yes” or “analogies, no”. It is “analogies when I’m learning, not when I’m working”. I only found that condition because I tested the two situations separately instead of asking myself one flat question. That is the point of this post. You are probably wrong about how you best process information, and often the wrong is that you flattened a rule that needed a condition on it.
What I built instead
I wrote a communication protocol. It is a file my agent loads at the start of every session, and it tells Claude how to explain things to me specifically. Not “be concise”. Actual rules, each one backed by a small test of what I retained.
A few of the rules that came out of it:
Explain in short sentences linked by cause and effect, not bullet points. Loose facts in a list do not encode for me. A causal chain does. Same facts, very different retention.
Bold the key terms and values. I re-read. I always re-read. Instead of fighting that, the design makes re-reading cheap, so my eye finds the important word without parsing the whole sentence again.
Tie any explanation to a consequence for me before explaining it. This was the big one, and I would not have guessed it. When a topic did not connect to something I cared about, no amount of formatting saved it. I just did not retain it. Framed as a decision with a consequence for me, the same content stuck on the first try.
That last rule is the thing the exercise taught me that I value most, and it only showed up because a test forced it out. Interest is not a nice-to-have for my memory. It is a gate the information has to pass before formatting even matters.
None of these are aesthetic preferences. Each one earned its place by beating the alternative in a retention check.
The same explanation, two ways
To make this concrete, here is one short technical explanation written twice. Same facts, a debounced search input. The first version is how an assistant explains it by default. The second applies my rules. Neither is wrong, and the first is perfectly competent. The second is just tuned to how I read.
Default:
Debounce is a technique for limiting how often a function runs in response to a rapid stream of events. On a search input, the naive approach wires the request directly to the input’s change event, so every keystroke fires its own request. Type “laptop” and you’ve sent six requests, “l”, “la”, “lap”, and so on, most of which are already stale by the time they come back. That wastes bandwidth, hammers your backend, and can cause race conditions where an earlier response arrives after a later one and overwrites the correct results.
Tuned to my rules:
Without debounce, every key the user presses in a search field fires its own request. Typing “laptop” sends six requests: “l”, “la”, “lap”, and so on. Most of those requests are already stale by the time they come back. Stale requests waste bandwidth, hammer the backend, and cause race conditions: an earlier response arrives after a later response and overwrites the correct results.
Debounce is a technique that limits how often a function runs in response to a rapid stream of events. Instead of firing the request on each keystroke, debounce starts a timer set to a short delay, for example 300ms. If another keystroke arrives before the timer expires, debounce cancels the timer and starts a fresh one. Only when the user stops typing for the full delay does the timer complete and a single request go out. The backend only sees the queries the user actually paused on, requests drop, load drops, and the race conditions from intermediate keystrokes disappear.
The difference is not quality. The default version opens with the abstract definition and runs it as one long descriptive paragraph. My version opens with what breaks first, bolds the identifiers so a re-read is cheap, and moves in short cause-and-effect steps. For me, the second one stays in my head. For you, a different set of edits would.
It’s not about saving tokens
One thing to be clear about before you run this. The goal is not to make Claude cheaper or its answers shorter. Token cost is not the point. The point is my own mental capacity. Every message I have to re-read, decode, or push through spends attention I wanted for the actual work. A protocol tuned to me lowers that cost. It cuts the review fatigue of going over the same answers again and again. The tool ends up working in my favour, instead of me working to parse the tool.
That only pays off if you are honest while you build it. Honesty beats polish here by a wide margin. If a question bores you, say so. If you start reading a sentence and give up halfway, say that too. If you skimmed instead of reading, admit it. None of that is a failure to hide. All of it is the signal. An honest “this bored me” or “I gave up on that sentence halfway” beats any careful answer, because it marks the exact point where the writing lost you. That is what the line I opened with did. You are not there to impress Claude. You are there to show it where you drop off.
Build your own
You do not need my file. You need your own, because your constraints are not mine. Claude can run the whole thing on you. Paste this into a fresh conversation and give it twenty to thirty minutes.
I want you to build me a personal communication protocol: a set of rules for how you should
explain things to me, calibrated to how I actually process information, not how I think I do.
Work in four phases. Do them in order and don't skip the testing.
PHASE 1: INTERVIEW
Ask me about how I take in information. One question at a time, wait for my answer. Cover at
least: whether I re-read things and where; whether long nested sentences cost me; how I feel
about analogies, acronyms, tangents, parentheticals; whether I retain loose facts or need
cause-and-effect; whether I prefer tables, prose, or bullets; and what my attention does when a
topic doesn't interest me.
Also ask me two things you'll need for the tests: what topics I genuinely care about (a hobby,
a game's lore, a field I follow on my own time), and what field I actually work in. Write both
down, because Phase 2 uses them to check whether interest and domain change what I retain.
If I mention a formal assessment (cognitive profile, ADHD/dyslexia eval, learning profile), ask
me to paste the relevant parts, since measured beats self-reported.
Before you start, tell me that honesty matters more than good answers here: if a question bores
me, if I start a sentence and trail off, or if I skimmed instead of reading it, I should say so,
because that is the signal you need most. I'm not here to impress you.
PHASE 2: TEST
Don't trust my self-report. Design a handful of small retention checks based on what the interview
surfaced. The mechanic stays the same each time: explain the same content two ways, then check
which version I actually followed and could repeat back a few minutes later. What you vary between
the two versions is yours to choose.
The following are only examples of what you might vary, NOT a fixed menu to work through: bullets
vs. linked causal prose; with an analogy vs. without; a topic I care about vs. a neutral one; a
fact from my field vs. a generic one; dense vs. spread out; conclusion first vs. mechanism first;
a table vs. a paragraph. Pick the variables most likely to matter for me, and invent your own if
the interview points at something I didn't name. Don't limit yourself to the examples above.
Run at least one check on a dimension I did NOT mention myself, since I may be blind to what
actually helps me. Run at least four checks total. Tell me what each one is testing before you run it.
PHASE 3: DERIVE
From the interview and the tests, write the rules. One rule per constraint. Each rule states the
instruction AND the one-line reason behind it, so I don't later delete a rule whose purpose I
forgot. Prioritize rules the TESTS supported over rules I merely claimed.
PHASE 4: WRITE THE FILE
Output a finished protocol file I can save as CLAUDE.md (or paste into custom instructions). Include:
- a header saying this is evidence-based, not aesthetic preference
- a short profile: which mental operations are cheap for me, which are expensive
- the numbered rules with their reasons
- a one-line "reading signal" you print at the start of every session so I know the file loaded
- an adaptation section: how to detect when I'm low on capacity and switch to a stripped-down format
Start with Phase 1, first question only.Save the output as CLAUDE.md if you use Claude Code, or paste it into the custom-instructions field of whatever tool you use. It loads every session from then on. This is not specific to Claude either. The same file helps other assistants and agents. In my experience the best results come in Claude Code, where far fewer system prompts compete with your instructions, so your rules carry more weight. The web version has more of that background noise, but the protocol still helps a lot there.
What makes the test sharp
The test is only as good as the material you feed it. Give Claude a topic you genuinely care about, a real passion: a hobby, a game’s lore, a field you follow on your own time. The gap between how much you retain on that versus a neutral topic is often the single biggest finding of the whole exercise. For me it was decisive. Then have it test you with real material from the field you work in, your stack, your jargon, a system you own, so the result matches how you actually read at work.
Why bother
The default assistant is tuned for the average reader. On every axis you are not the average reader, and neither is anyone else. The gap between “generically clear” and “clear to you” is real, and you pay it on every message until you close it.
Closing it once, with evidence, pays back on every session after.
If you run the exercise, I would like to hear two numbers: your interest-versus-neutral retention gap, and whether domain facts helped. If the pattern holds across people, that tells us something. If it is wildly personal, that tells us something too. Either way you end up with an agent that finally speaks to you.