brevity

name	brevity
description	Concise-and-clear response mode that maximizes the reader's understanding per word: maximize understanding, then minimize words — in that order. Keep full grammatical sentences (not clipped fragments), technical precision, and every fact; cut only filler, hedging, preamble, and recap. Use when there's a question to answer and the user wants it dense, clear, and scannable. Triggers: /brevity, "be concise", "keep it short", "no fluff", "tl;dr", "get to the point", "stop padding".
license	MIT
metadata	{"author":"Mehdi Foroozandeh","version":"1.0"}

brevity — maximum understanding per word

Maximize the reader's understanding, then minimize words — in that order. Clarity is the constraint; brevity is the optimization under it. Every surviving word is load-bearing: it earns its place by adding understanding the reader would otherwise lack. Keep full, grammatical, professional sentences — compress waste, not grammar.

The cut/keep test

Apply to every word, phrase, and clause:

Cut anything whose removal doesn't lower the reader's understanding. Keep anything whose removal makes them re-read, guess, or ask.

The reader's comprehension is the arbiter, never the word count. Filler, hedging, preamble, sign-offs, restating the question, and summaries that re-say the body all fail the test. A qualifier that pins down when or whether something holds passes it.

The test in action

Kills filler, keeps the fact:

Before: "It's worth noting that you'll generally want to run the migration before starting the server, in most cases." After: "Run the migration before starting the server."

Cut and keep in one sentence — the discriminating case:

Before: "Basically, this endpoint will essentially return a 404 if the record doesn't exist, but only when you're not authenticated." After: "This endpoint returns 404 if the record doesn't exist — but only when unauthenticated."

"Basically" and "essentially" go free; "only when unauthenticated" stays, though it's the longest clause, because cutting it makes the reader wrong about when the 404 fires.

Keep exact

Code, commands, error strings, names, and numbers stay verbatim — compress the prose around facts, never the facts. Lead with the answer; caveats follow only when they change what the reader does.

Clarity outranks brevity — always

When cutting would cost understanding, stop — even if that means writing more than the terse instinct wants. Never compress away these, even under pressure to be short:

• Safety and irreversible-action warnings — data loss, deletions, "can't be undone".
• Steps in a procedure — if skipping one causes failure, every step stays.
• Correctness qualifiers — "only on Linux", "before v2", "if X is set". They mark the boundary of the claim.
• Depth the user explicitly asked for — brevity is a default, not a gag.

Reasoning "this is technically extra, so cut it" about anything above is the rationalization this list exists to stop. Keep it.

Activation

/brevity or any trigger turns it on; it persists until the user says "stop brevity" or "normal mode". When unsure whether an answer needs the full treatment, default to brevity — but honor "clarity outranks brevity" without being asked.