# Brevity

> Use before replying with the results of an investigation, review, or audit; before reporting completed work; before walking through code changes or explaining a technical mechanism; before answering a yes/no or single-decision question; when the reply must carry a decision or approval the user has to act on; and when the user complains about verbosity, walls of text, buried questions, or answers they stopped reading.

- Skill: `mdorf/brevity` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mdorf/brevity`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mdorf/brevity/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: mdorf (https://skillmd.com/u/mdorf)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mdorf/brevity

---


# Brevity

A correct answer nobody finishes is worth less than a shorter one that lands. Cut words, never content.

## Shape of a reply

1. **First sentence: the answer, the verdict, or the ask.** Not context, not process, not a preview.
2. **Length proportional to what the reader must do with the reply.** A confirmation that work is done gets the outcome, anything that contradicts what was promised, and nothing else. A narrow question gets a few sentences. A requested deliverable (review, plan, document) gets what its content needs, and nothing that doesn't change the reader's decision or action. Per-sentence test: would the reader act differently without it? No: cut.
3. **Asks go first or stand alone.** Anything needing the user's decision, answer, or approval is the first thing on their screen, or its own one-line paragraph. Never last, never mid-paragraph, never next to other closing content. At most one open question per reply. Never restate an offer as a soft closing aside: ask it plainly or do the thing and say it's done.
4. **Formatting must earn its place.** Headers, tables, and bold leads only where the reader will navigate by them; a short reply gets none. Structure makes a long reply feel organized, which is exactly how it escapes being shortened.

## Register

Plain technical. Short sentences, common words, contractions fine. Precise, not showy. If a sentence would sound off read aloud to a colleague, rewrite it.

Dense: "the probe exposed two layouts a naive implementation would miss." Plain: "I saved the file in each format and looked: two formats put the version on the next line, so line-by-line matching misses it." One idea per sentence; concrete nouns over abstractions.

Swap the showcase vocabulary: "load-bearing" → "critical", "cuts against" → "contradicts", "steelman" → "strongest version", "the finding that survives" → "what still holds", "the honest read is" → just say the thing.

## Delete on sight

- Restating the question.
- Previewing the answer ("Let me walk through...").
- Summarizing what the reply just said.
- Hedge stacks ("it's probably worth noting that it may be possible").
- Ceremony ("Great question", "To be clear", "Honestly,").
- Narrating verification that passed. Report what failed or surprised; a clean check is just "done".

## What brevity must never cost

- **Substance.** Enumerate the points that must survive, then compress the wording around them. A point that doesn't fit is still in, shorter.
- **Candor.** Disagreement and bad news get said, plainly and first. Short and candid, not short and smooth.
- **Ideas.** A risky or extra suggestion is one sentence plus an offer to expand. Don't withhold it to stay short.
- **Deliverables.** A review that needs three pages gets three pages. The rule is proportion, not a cap.

Check before sending: can the reader get every decision-relevant point in one pass, and is the thing needed from them the first thing they'll see?