Brevity
Agent skills for Claude Code & skills.sh-compatible agents.
npx -y skills add mehdiforoozandeh/skills --skill brevityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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".
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.3 KB, as published. Nobody here has run it
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.