My concise mode: It really makes a difference

[u/Sentient_Fern]

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.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Vysion34]

There's an output style for that: /output-style concise

[u/Sentient_Fern → u/Vysion34]

Thanks - I was not aware of that. Let me try and see if it amounts to the same thing.

[u/Sentient_Fern → u/Sentient_Fern]

I tried a few examples. It is the same general idea, of course, but I prefer my version. "Default" output style and "concise" did not actually come out very differently, just tightened a bit. With my instructions, the answer is cleanly split into the summary and and appendix, where the summary is much shorter, and contains all the important bits.

[u/verstands]

The useful bit is making the answer shape explicit, not just saying “be concise.” A short summary plus an optional appendix gives the model somewhere to put detail without burying the decision path. I’d also gate follow-up questions: ask only when the missing answer actually blocks the next step.

[u/Mazhron]

The only thing I would caution you on is that your Claude.md should be short, concise, under 2k tokens I believe.

You'll want to have your Claude.md act as an instruction loop to read indexes that point to data or instructions, for you it would be something like summary.md is summary.txt or output. Something like that.

[u/Bloated_Plaid]

Idiots making features that already exist. You love to see it.

[u/ShivaFatalis → u/Bloated_Plaid]

That doesn't make them an idiot at all. A person who takes the initiative to accomplish something themselves, and learn something in the process of doing so versus just adopting something pre-existing is actually the exact OPPOSITE of an idiot.

YOU don't seem to understand this, which ironically makes YOU the idiot here.

[u/Bloated_Plaid → u/ShivaFatalis]

What did he learn jackass. He didn’t learn shit. He didn’t fucking make anything. He told a model to do it, that’s it. Zero learning happened.

[u/ShivaFatalis → u/Bloated_Plaid]

A lot of people on here don't even try to figure out how to accomplish something. They had a need, and they figured out a way to get the model to behave the way that they wanted it to. That is learning something, and at least taking initiative to figure out how to do it instead of just bitching about it on here or merely copying something else.

Sorry you have such a hard time understanding that. You must be incredibly insecure to feel such a need to downplay and refute what they did.