I can't stand reading long output.
Not "I mildly prefer brevity." I mean I hit a wall of text in my terminal and my brain refuses. I asked Claude to fix a nav dropdown, it fixed it, and then it wrote me eleven lines summarizing the fix I had just watched it make. Tool calls are visible. I saw the diff. I don't need the recap.
Sound familiar?
Telling it to be concise doesn't work. Not reliably. I had a memory saved that said "keep replies SHORT, she reacts strongly to long output," and it still handed me a status inventory with four headers.
So I went looking for what actually holds. Four options, ranked from weakest to strongest.
CLAUDE.md #
The obvious one. Put your rule in ./CLAUDE.md
for a project, or ~/.claude/CLAUDE.md
for every project on the machine.
This is where most people stop, and it's the weakest option. Not because it doesn't load, it does, every session. It's that your rule sits in a file competing with project context, tool definitions, and a conversation that grows all afternoon. By hour two it's noise.
One thing that genuinely helps: put the rule at the very top of the file, not buried at the bottom. Position matters more than I expected.
Use this if you want something scoped, visible, and easy to change. Don't expect it to hold under a long session.
Skills #
Skip this one. I went down this path first and it's a dead end for this problem.
Skills load when they're invoked. That's the whole design. A skill that says "write concisely" only helps if the model remembers to invoke it, which is the exact failure you're trying to fix. You'd be relying on the thing that's already unreliable.
Skills are great. They're just the wrong tool for always-on behavior.
Append a system prompt #
This is what I landed on.
Claude Code takes a --append-system-prompt-file
flag. Whatever is in that file gets appended to the system prompt every single turn. Not memory, not context, the actual system prompt.
Write your rules to a file:
~/.claude/concise.md
Then alias the command so you don't have to remember the flag:
alias claude='claude --append-system-prompt-file ~/.claude/concise.md'
Open a new terminal and you're done. Every session, every project, no flag to remember.
Two tradeoffs worth knowing. It applies everywhere, which I wanted but you might not. And it's invisible, so six months from now you may forget why your output looks different. Leave yourself a comment in the alias.
What goes in the file matters more than the mechanism. "Be concise" is useless. Ban specific behaviors:
- No recapping work the user just watched
- No status inventories unless asked
- No preamble ("Great", "You're right", "Let me")
- No closing summary paragraph
- No unsolicited next-step menus
- Answer first, context second
Specific prohibitions beat vague vibes. Every time.
A Stop hook #
This is the only option that actually forces anything.
Hooks are different from everything above. The harness runs them, not the model. A Stop
hook fires when Claude finishes a response, and it can block that response and send feedback, forcing a retry. You configure it in settings.json
alongside whatever else you're running.
That's real enforcement. Nothing else on this list is.
I passed on it for two reasons. A blocked response means a retry, and a retry means more tokens, which is a strange way to solve "you're wasting my tokens yapping." And any length check crude enough to write is crude enough to block an answer that genuinely needed the room.
If you want determinism and you accept the cost, this is your option. I wanted most of the benefit without the retry loop.
What I'd tell you to do #
Start with CLAUDE.md and append a system prompt. The alias is one line, it works everywhere, and you can delete it in five seconds.
Spend your effort on the rules file, not the mechanism. Ban behaviors by name. Vague instructions produce vague compliance.
And be honest with yourself about why you want this. Walls of text aren't a preference problem, they're a wall. Tuning your tools around how your brain actually works isn't precious. It's the whole point of having tools you can configure.
The model won't hold a rule you only mention once. Put it somewhere structural.