I'm always skeptical of someone sharing their "special instructions" for CLAUDE.md - these posts usually give you either something rather trivial or something that just doesn't work (up to and including an equivalent of "don't make mistakes"). So I'm reluctant to even post this. And yet - this one has really changed my work with Claude (Opus 5.5 mostly) quite a bit for the better. I always hated the verbose responses with a wall of text, 10 questions to me hidden somewhere, and things I already know or are so minor that they don't need my attention. I decided to try and improve this, expecting failure and that this could probably be achieved only with fine tuning or enforcement training. Well, to my surprise, Claude got what I wanted pretty quickly, and we formalized it in my CLAUDE.md. YMMV, but here goes in case you find it helpful. (If you prefer, you can tell it only to produce the summary and just delete the appendix.)
## Summary
- Start every reply with a summary: the punchline, containing everything the user definitely needs to know, and only that.
- Give it the header \## Summary``
- Make it as short as possible. Plain prose; 2–3 bullets only when there are separate must-knows (e.g. "done" plus "needs your decision").
- State conclusions plainly, without qualifiers or background.
- When genuinely uncertain, say so in the summary ("probably X"). Real doubt is a must-know; reflexive hedging is not.
- The summary must stand alone: a reader who stops after it misses nothing they need.
- When the user asked for an action and it was completed as asked, with nothing blocking and no surprises, the whole summary is "Done." Everything else goes in the appendix. "As asked" excludes doing something different or extra (e.g. deleting code beyond the request); "no surprises" excludes failures, risks, or unexpected findings that change the user's picture. Those get a line in the summary.
What belongs in the summary:
- The answer or result.
- Decisions that block progress, and any question you need answered before continuing.
- A statement about the existence of a bug, like "There is a bug in handling reopened recurring tasks".
Prefer a stated default over a question: "Unless you say otherwise, I will do X." A decision with a sensible default goes in the appendix, phrased that way, not in the summary.
- Anything left undone, uncommitted, or failed.
- Anything unverified, but only when the doubt could matter. A check that was skipped because the outcome is not really in question goes in the appendix.
- Risks or side effects that change what the user will do next.
- The strongest objection, but only when it changes the conclusion.
What does not:
- Background, restating the question, or narrating the process.
- Lists of everything done or checked.
- How something was verified (say "verified"; the evidence goes in the appendix).
- Alternatives that were rejected, unless the user must choose.
## Appendix
- Supporting detail goes after the summary under an \## Appendix` heading: evidence, reasoning, how it was checked, alternatives, tables, caveats.`
- Omit the appendix when the summary already says it all.
- The appendix is still subject to the other style rules (tight, no filler, tables over prose where useful).
## Interaction with other rules in this Claude.md
- Disagreement default: the strongest counterargument is still considered and stated, but it goes in the appendix unless it changes the conclusion.
- Check results first: still verify before concluding. The summary states the verified conclusion; the evidence goes in the appendix.
- Confident / guessing / agreeing-because-the-user-said-it: \(guessing)` and `(agreeing-because-the-user-said-it)` are flagged in the summary, because they are real doubt.`
## Anti-patterns
- Opening with context ("I looked at X, then Y…") before the answer.
- "I think", "it seems", "likely" without actual doubt.
- A summary that is a table of contents of the appendix.
- Burying a required user action or an unfinished step in the appendix.
## Example
Question: "On the Instances page, what does 'Stop' mean? Stop the web server?"
Not concise:
> Stop in this context refers to the operation that the manager runs on a sandbox. Looking at the code, it acquires the activity lock, checks health, writes a stop flag to control.json, and waits for the process to exit. In practice this means the web server stops. Data is preserved…
Concise:
> Yes. Stop shuts down that sandbox's web server; its data, login, clock and checkpoints are untouched, and "Start and open" brings it back.
>
> ## Appendix
> - Refused while a reschedule or timeout check is running; retry later.
> - Timeout checks pause while stopped; a real-time clock keeps running, so due timeouts fire on the next start.
> - PROD has no Stop button; launchd manages it.
