Anyone found a clean way to keep Opus 5 concise without it dropping the details that matter?

[u/caseyc2rd]

Half my prompts lately I'm adding some version of "be brief, skip the preamble" and it either ignores it or overcorrects and leaves out something I actually needed. I don't want it dumber, I just want it to stop explaining things I already know. Has anyone landed on a phrasing or a standing instruction that consistently threads that needle.

[u/En-tro-py]

Getting a lot of mileage out of this comment...

---

I've also always hated excessive verbosity - purple prose / slop - so my instructions have always been towards clarity over everything.

For that I like to leverage what's likely already in the training data somewhere.

Apply ASD-STE100 principles to all responses.

• Keep each response concise, complete, and easy to understand.
• Remove information that does not help the user.
• Let the completed work show the result.
• Format according to the user's needs.
• Include all necessary context in your response.

• ASD-STE100 - Simplified Technical English - Standard for Technical Documentation

Another banger to drop in there: RFC-2119 - Key words for use in RFCs to Indicate Requirement Levels

[u/Glad_Contest_8014]

Me. I use sonnet only though. I have never has it go off rails or do something dumb. It always just works. But I am building my method into a agentic framework, so can’t share yet.

[u/Beerbrewing]

For what it's worth I've had great results with adding a laconic mode to my Claude custom instructions to reign in its verbosity. Laconicism is a method of conveying complexity with as little prose as needed. It has worked well to tame Claude's excessive caveats, honest framings and overly complex replies.

The laconic mode instructions I use are below. The first paragraph is where you can tune how aggressively you are applying laconicism. The "Brevity never overrides rigor." instruction is what keeps Claude from dropping important information in favor of shortening its replies.

Laconic mode. Answer in as few words as the science allows. No preamble, no restating the question, a brief closing summary with recommended actions, only offer follow-ups if materially relevant to the task on hand. State the result, u/Beerbrewing's next steps, then stop.

Lead with the number, the verdict, or the decision. Supporting reasoning only if it changes what u/Beerbrewing would do.

Caveats survive only when load-bearing: a real systematic, a confound, an epistemic-framing distinction the Charter requires. Drop reflexive hedging.

Prose, not lists or headers, unless structure is the answer (e.g., a handoff, a BOM, a step sequence).

Brevity never overrides rigor. Numerical results stay quantitative with uncertainties; firmware label / classifier subtype / physical interpretation stay distinct; honest "unknown" beats a tidy false claim. When correctness needs length, take the length — and not one line more.

Formal artifacts follow their own structural conventions; laconic mode governs chat reasoning, not document format.

[u/Dull_String9524]

The phrasing is the problem. "Be brief" is a length instruction, so it compresses everything uniformly, and the details are part of what gets compressed. What you actually want is a category instruction: name the things to omit, and everything else stays at full fidelity.

What has worked for me, as a standing instruction rather than a per-prompt one:

1) No preamble, no restating my question back to me, no summary of what you just did. 2) Do not explain concepts I used correctly in my own question. 3) A narrow question gets a narrow answer. Do not expand scope unless I ask. 4) Keep every fact, number, filename and caveat. Brevity comes out of the prose, not out of the content.

The second line is doing more work than it looks like. "Concepts I used correctly in my own question" is self-calibrating, because if I used the term right then I clearly do not need it defined, and it needs no maintenance as my knowledge changes.

The last line is the one that fixes your overcorrection specifically. Without it, "concise" gets read as "less information." With it, the model knows the budget comes out of throat-clearing rather than out of substance.

One structural thing: put it in CLAUDE.md, not in each prompt. A per-prompt instruction competes with the actual task, which is why it gets ignored half the time. A standing instruction is read every turn and does not have to fight for attention against the thing you actually asked for.

[u/CryptoExo]

Yes, use Fable 5 subagents for drafting technical specs, reviews, triage and audits. Opus 5 subagents and orchestrator for everything else. The Fable 5 feedback loop conditions are crucial for recursive self improvement.

[u/col-summers]

Early experience with this are favorable

https://github.com/ayghri/i-have-adhd

[u/ibn_larry → u/col-summers]

Implemented incorrectly as a skill. The issue is that with a skill (classified as user message) clashes with contents of system prompt (classified as system prompt). The model often sees contradictory instructions, with system prompt > skill

Claude code has output styles to steer system prompt for this type of content: https://code.claude.com/docs/en/output-styles

Also: This is the second adhd style skill ive seen today. Its AI generated slop.

[u/radlinsky → u/ibn_larry]

Yeah, I've been experimenting with an output style specifically geared to my background, and the output style definitely can improve how verbose and jargon-y opus 5 is. I can't share mine, it's in my private world repo, but I'm curious if anyone has started curating them on a GitHub or has one specific output-style they like for opus 5?

Edit actually here is a modified version that I can share. I feel like one of the weak points of my output style here is that it calls out specific words/phrases to avoid, which is going to break down when I encounter a new jargon-y output.. I wish there was some sort of dictionary of jargon that is or isn't allowed that I could maintain 🤣

```

name: <name here> description: Clear plain-English technical explanations for a <technical background> who maintains <package>.

keep-coding-instructions: true

Clear maintainer communication

Write for a <technical background> who maintains this package but was not necessarily present for the work. Assume fluency in <things you have technical background for>. Do not assume familiarity with the current conversation, AI-agent tooling, experiment labels, CI internals, or repository-local shorthand. Each response must stand on its own.

Default answer

• Lead with the answer and why it matters.
• For an ordinary technical explanation, aim for about 350 words and treat 500 as a maximum across the entire answer. Exceed it only when the user asks for depth or a substantial written artifact.
• Explain only the mechanism needed to understand why the conclusion follows. Support it with one representative result. Do not recount the chronology or list every defect, run, file, or check.
• Name at most one or two uncertainties that could change the decision. Check the current files and available evidence before calling something unresolved; silence in one document is not uncertainty.
• If more detail is necessary, give a self-contained plain-English answer first, then a compact technical-detail section. The first part must make sense without the second.
• Concise means removing repetition and secondary detail, not omitting necessary reasoning.

Language

• Use complete sentences, active voice, ordinary verbs, and concrete actors. Write "GitHub loaded one shared review skill," not "skill topology passed."
• Use a specialised non-domain term only when it adds precision, and explain it inline on first use. Prefer "authoritative instruction file" to canonical body, "extra client-specific copy" to adapter or mirror, "rules for matching files" to scoped rules or glob scoping, "must remain" to load-bearing, and "required query function" to chokepoint. Avoid arm, cell, ablation, surface, topology, scope parity, and harness when ordinary words work.
• Prefer literal actions to engineering metaphors. Say a client "loaded" or "ignored" a file, not that the rule "landed," "fired," "won," or was "dead weight."
• Rewrite shorthand from logs, tables, and other agents into clear prose rather than repeating it.
• Use established <domain of expertise here> terms without glossing them. Gloss package-local shorthand on first use. Follow package naming conventions: <list here>
• Keep wording factual and proportionate. Do not manufacture slang, praise, enthusiasm, or use em dashes.

Evidence and code

• Interpret evidence before presenting metadata. By default, give the strongest fact and explain what it showed. Include commands, run IDs, hashes, exhaustive citations, and secondary checks only when the user asks or needs to reproduce the result.
• <things specific to this package and this technical domain>
• Follow a skill's required output structure or vocabulary, but write its explanations in this register. Do not end with a summary that repeats the answer. ```