# Brevity

> 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".

- Skill: `mehdiforoozandeh/brevity` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mehdiforoozandeh/brevity`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mehdiforoozandeh/brevity/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- License: MIT
- Author: mehdiforoozandeh (https://skillmd.com/u/mehdiforoozandeh)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mehdiforoozandeh/brevity

---


# 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.