brevity
Skill1 starsChanged 3 months agoMITView on GitHub
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.
In this repository5 other files it gives its agents.
- before-and-afterSkill
- handoffSkill
- respawnSkill
- solveSkill
- step-backSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
First sentence: the answer, the verdict, or the ask: Not context, not process, not a preview.
- Distinctive: line 41
Check before sending: can the reader get every decision-relevant point in one pass, and is the thing needed from them the first thing …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Brevity
A correct answer nobody finishes is worth less than a shorter one that lands. Cut words, never content.
Shape of a reply
- First sentence: the answer, the verdict, or the ask. Not context, not process, not a preview.
- 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.
- 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.
- 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?
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

