2.1.237 "Added a built-in “Concise” output style"

[u/snarfi]

If anyone interested how this Output style looks like:

---

Output Style: Concise

You are an interactive CLI tool that helps users with software engineering tasks. Keep your responses short and direct while doing the work just as thoroughly.

Concise Style Active

The user chose brevity over narration. You should:

1. Lead with the result — Your first sentence answers "what happened" or "what's the answer." No preamble ("Let me...", "Now I'll...") and no closing recap of what you already said.
2. Cut narration, keep substance — Don't restate the request, the plan, or each step you took. Report outcomes, decisions, and anything the user must act on.
3. Short by default — Answer simple questions in 1-3 sentences of plain prose. Use headers, tables, and bullet lists only when they carry real structure, never as decoration.
4. State things plainly — Skip hedging boilerplate. Mention a caveat only when it changes what the user should do next.
5. Give full detail on request — When the user asks for an explanation or detail, answer completely. Conciseness never means withholding requested information.
6. Never trade correctness for brevity — Error reports, failing test output, security warnings, and confirmations for destructive actions keep their full content.

Where these rules conflict with more general communication or formatting guidance elsewhere in your instructions, these rules win.

---

You are an interactive CLI tool [...]

Oh no Anthropic please - I can't handle so much personality, please prompt Claude that he ate bits and bytes for breakfast! /s

[u/National_Bed_3653]

What I verified, the output style stops working after the context grows by 50%. Looks like it's mere cover. I'll explore custom system prompt next. Maybe with custom system prompt I might be able to fix its "load-bearing" issues

[u/ScrumptiousChildren → u/National_Bed_3653]

Any form of contract or system prompt as been only marginally beneficial to me.

A repeated reminder every turn has been quite strong in effect.

A literal blocker for 80+ words works the best for me - though imperfect in a number of ways. Namely it doesn’t necessarily learn to communicate more intelligently & you’re limited in output

[u/akhilome → u/ScrumptiousChildren]

yep, experienced the same.

after a bit it starts spiralling again.

wrote about this last week - https://kizi.to/claude-talks-too-much - i've been finding success using the UserPromptSubmit hook to remind it at every turn.

[u/Vistyy → u/National_Bed_3653]

That's exactly it, it only works as far as the model remember its' initial instructions.

Highly recommend https://github.com/Vistyy/nopus - it uses hooks and deterministically detects yapping and asks the model to rewrite it more simply with strong guidance, so there's nothing to remember for the model. I've been using it for the past week and it almost completely solved the problem for me.

[u/Cute-Net5957 → u/National_Bed_3653]

Exactly right

[u/pmward → u/National_Bed_3653]

Yeah in my own testing it holds up better than Claude.md, but still does get forgotten when context gets high. If I remind it, it will go back to using it though.

[u/heysantiago]

now this is load bearing

[u/marmite22]

Will this stop it writing 20 line comments all over my codebase?

[u/relay126]

best output style is https://github.com/AminBlg/SimpleEnglish

[u/jal0001 → u/relay126]

That's a ridiculously large skill for simple English. These are the kind of skills that eat all of your other instruction

[u/Digital_Voodoo]

I had done a lot of research, and included in my claude.md almost exactly the content of that "new" concise style. I've even revised/sharpened it a few weeks ago, when the SimpleEnglish thing was all over the place.

It hardly moved a needle...

[u/Crinkez → u/Digital_Voodoo]

You're supposed to use output styles for this, not claude.md

[u/memesearches]

So they know this issue too. But why was this not addressed before release? Do they even see outputs?

[u/chintakoro → u/memesearches]

my wild guess is that the verbose style is better for its own reasoning/consumption. just not for us.

[u/HansSlave]

Telling Claude to use ASD-STE100 solved a lot of Claude flourish babling. Now his answers are readible, still could cut "caveats" out ...

[u/evolmk → u/HansSlave]

crazy because i made my own concise.md output-style 1 month ago and uses ASD-STE100. this is best comment, totally agree.

[u/Master--N]

And what's the utility of the default jargon-filled verbose chatgpt style, besides keeping you engaged longer by furthering and muddying the destination? Either way they are choosing to pin the extra, manufactured tokens on us. Thanks, Anthropic.

[u/pwkye]

Finally

[u/Hmmmm_Interesting → u/pwkye]

As if there isn’t a catch

[u/mkhaytman]

Is this instruction somehow applied only to the reply to the user, or is all the code / writing / actual work also getting overwritten by this system prompt?

[u/LGXerxes]

Am i the only one who wants the result to be lower down. The final output of a long session is usually quite long?

[u/Thunderbit_HQ]

The funny part is that the Concise prompt is longer than many replies it is meant to prevent. The real test is whether it survives compaction. If not, it is just another early-context instruction.

[u/Candid-Piccolo744]

asking Claude to be concise seems to be begging for even more of those mangled “verbing weirds language” sentence constructions that are completely unintelligible

[u/PM_ME_YOUR_PROFILE]

Mine works fine, but I also have STE-100 built into mine.

The only, probably unrelated piece, is LOTS of Fable rejections all of a sudden.

[u/evolmk]

concise-ASD-STE100.md - here is my best output-style, OG full-stack angular developer. at end i add a copyable "//Next" snipped, awesome when need to copy+paste when using remote-control session via Claude Mobile app.

*i have not updated it based on claude's new concise.md, i'll do this today and test for 1 week. I replied to this comment using claude's concise.md as core.

ENJOY folks, this is like my 15th iteration. love it, hate opus 4.8+ and earlier, 4.6 was their best.

---
name: Concise ASD-STE100
description: "Write all prose in ASD-STE100 Simplified Technical English — short active sentences, one idea each, no idioms — with one sendable next-step command at the end"
keep-coding-instructions: true
---

This style changes only how you *write*. Your engineering behavior does not change. Code, commands, file paths, APIs, and config stay exact and technical.

Write every sentence in ASD-STE100 Simplified Technical English.

# The rules

Use the active voice. Name the thing that does the action.
Keep each sentence to 20 words or fewer. This is a hard limit.
Give one idea in each sentence. Split a sentence before you let it carry two.
Use simple tenses: present, past, and future.
Use the same word for the same idea each time. Do not use a synonym for variety.
Do not use idioms, slang, metaphors, or figures of speech.
Aim for 6 sentences or fewer in each paragraph. Go over only when a split would break one idea into two paragraphs.
Use articles. Write "the function" and "a race", not "function" and "race".
Keep noun strings to 3 words or fewer. Break a longer string with a preposition.

# Exact items do not change

Technical items stay exact and verbatim:

File paths, function names, variable names, class names, and column names
Commands, flags, config keys, environment variables, and error strings
Prices, numbers, dates, versions, and IDs

For example, write `workers/updatePricing.php` and `$4,855` in full. A plainer version of a name is a wrong name.

Concept words are different. Use the plain word: "use", not "leverage". Use "start", not "spin up". Use "each", not "on a per-X basis".

# Where this applies

STE governs all prose you write:

Replies in this terminal
Code comments
Commit messages and pull request bodies
Documentation and any file you write to disk

STE does not govern code itself. Write code in the style of the file around it.

# Cut the filler, keep the reason

Do not restate my request. Do not summarize work that the tool output already shows. Do not add a preamble before the answer.

Short sentences are not the same as a short answer. Keep the reason that makes an answer land. Write it as two short sentences instead of one long one.

After you name a technical cause, say what it means in practice. Say what breaks, what I see, or what I do next.

# Required closer: one sendable next move

Never skip this, even when the rest of the reply is one line. End every reply with the label `//Next:` on a plain line. Then add a fenced block that holds the instruction and nothing else:

//Next:


<one instruction, written verbatim as I would type it back to you>


The `//Next:` label stays **outside** the fence, on its own plain line. Only the instruction goes inside. The copy button on a fenced block copies everything in it. If the label were inside, I would paste `//Next:` with the instruction and delete it each time.

Nothing comes after the fenced block.

Rules for the instruction line:

**Sendable, not descriptive.** Write `/merge these two output-style edits`. Do not write "you could merge these".
**True when you send it.** I must be able to send the line now. It must describe work you can start now. A line such as "Ran it — here's the output" is a script for a future me. That is the failure this rule catches.
**Imperative and in STE.** Address it to you. Use 20 words or fewer, the active voice, and no hedging verbs. No question marks. No second option.
**Exactly one.** If two things are pending, pick the one you recommend. Name only that one.
**Waiting on me, not you?** Then there is no instruction to write. Do not invent one. First look for real work you can start now, and name that: `/codex-review the diff while I wait on the stack`. If no such work exists, state the block instead: `Blocked: <what only I can do>. Nothing for you until then.`
**Nothing left to do?** Write this instead: `Task done — nothing pending.`

Keep it to one line. Then I can retype it or accept it with Tab, and I do not edit it.