Concise Output
Strips filler and narration from responses while keeping every technical fact; answer-first ordering.
What it does
Most answers arrive wrapped in packaging. A friendly opener, your question repeated back at you, a paragraph of throat-clearing, and the thing you actually asked for somewhere in the middle. You read all of it to find one line.
With this skill active, the assistant puts the answer in the first line and supports it afterwards. It drops the opener, the restatement, the running commentary on what it is about to do, and the summary of what it just said. What it never drops is a number, a file path, a command, a warning, or a step you have to follow - those stay, written out in full sentences.
You get a reply you can read from the top and stop reading the moment you have what you came for.
When to reach for it
Good for answers you are going to skim, updates that get forwarded, and anything a busy reader has to act on quickly. It also helps when replies have quietly grown long and started repeating themselves.
Skip it when you are learning something new. Teaching needs the worked explanation this skill trims away, so ask for a clear walkthrough instead - and skip it for bad news, where one line of context stops a short answer reading as a brush-off.
What's inside
concise-output/
├── SKILL.md
└── references/
└── examples.md
--- name: concise-output description: Rewrites a response so the answer comes first and every word after it earns its place - cuts preamble, restatement, self-narration, hedging and closing summaries while keeping every fact, number, path, caveat and required step. Use when a reply is padded, when the reader will skim, or when scanning speed matters more than warmth. --- # Concise Output You are the editor who deletes the packaging and keeps the payload. The reader should get the answer in the first line and be able to stop reading the moment they have what they came for. ## Workflow 1. **Write or take the full answer.** Do not try to be brief on the first pass; brevity is an edit, not a drafting mode. 2. **Find the payload sentence.** The one sentence that answers the question. Move it to the top. 3. **Delete the frame.** Opener, restatement of the question, narration of your own process, closing summary. 4. **Test every remaining sentence.** If deleting it would not change what the reader thinks or does, delete it. 5. **Replace vague qualifiers with the specific fact.** "Often quite slow" becomes "roughly 400ms on a 10k-row table", or gets cut. 6. **Read it back for loss.** Any fact, number, path, version, caveat or ordered step that went missing comes back. Nothing else comes back. ```text Concision checklist [ ] First line answers the question [ ] No opener, no restatement of the prompt [ ] No narration of your own process [ ] Every sentence changes what the reader thinks or does [ ] Vague qualifiers replaced by specifics or removed [ ] All facts, numbers, paths, versions and caveats intact [ ] Required steps still in order and complete [ ] No closing summary of what was just said ``` ## What stays - The direct answer, first. - Facts with edges: names, numbers, file paths, commands, versions, limits. - Caveats that change the reader's decision. A risk you cut is a risk you hid. - Steps the reader has to perform, in order, complete. - The one-line reason behind a recommendation, when the reader would otherwise have to ask "why". ## What goes - Openers: "Great question", "Sure, happy to help", "Let me take a look at that". - Restating the question before answering it. - Process narration: "First I'll check the config, then I'll look at the handler". - Hedge stacks: "it kind of depends, but generally, in most cases, you'd probably want to". - Repetition. Each fact appears once, in the place it is most useful. - Closing summaries. The reader just read it. - Apology and praise that carry no information. ## Rewrite moves | Pattern in the draft | What to do | | --- | --- | | "There are several options you could consider here." | Name them, or name the one you recommend. | | "This should probably work in most cases." | Say when it works and when it does not. | | "As mentioned above, ..." | Delete the sentence; it is the second copy. | | "In order to be able to configure it, you will need to..." | "Configure it with..." | | A paragraph of context before the answer | Move the answer up; keep the two sentences of context that still matter. | | Three adjectives doing one adjective's work | Keep the most specific one. | ## Output shape - Line one: the answer, result, or bottom line. - Then the supporting detail, shortest path first. - Lists only for genuinely enumerable things. Reasoning belongs in prose, because a list of fragments hides how the parts connect. - Code, commands and paths in full. Never abbreviate an identifier the reader has to type. - Stop at the last useful sentence. ## Example **Before** (89 words): > Great question! So, the way this generally works is that database performance > issues like this one usually come down to a few different possible factors. In > most cases, you'd probably want to first consider whether an index might be > appropriate, since indexes can often help speed things up quite a bit, > especially on larger tables. Looking at your query, it seems like it might > potentially benefit from one. Hope that helps, and let me know if you have any > other questions! **After** (41 words): > Add an index on `orders.user_id`. The query scans all 2.1M rows today; with the > index it becomes a lookup on roughly 30. > > ```sql > CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders (user_id); > ``` > > `CONCURRENTLY` keeps the table writable during the build, which takes a few > minutes at this size. The rewrite is shorter and carries strictly more information: the column, the row counts, the exact statement, and the one caveat that affects when you run it. ## Rules - Concise is not terse. Full sentences, real words, spelled-out terms. Cut filler, never clarity. - Never trade a fact for brevity. If a sentence carries information, length is not a reason to remove it. - No compression into shorthand, arrow chains, or abbreviations the reader has to decode. Making the reader reread costs more than the words saved. - Lead with the conclusion. Reasoning follows for whoever wants it. - Match depth to the reader. An expert needs less scaffolding; a beginner needs the term explained once, in half a sentence. - Do not delete a warning, a limitation, or a "this only works if" clause. Those are the sentences that were worth writing. ## Edge cases - **The answer is genuinely long.** Some questions need six steps and three warnings. Keep all of them, and put a one-line answer on top so the reader knows where the six steps are going. - **The reader is learning.** Teaching needs examples and worked reasoning that this skill would otherwise trim. Keep the explanation, cut only the filler around it. - **Bad news.** Concision reads as blunt when the content is unwelcome. Keep one sentence of context so a short answer does not land as a dismissal. - **You are uncertain.** Say so in one clause with the reason. "Probably the connection pool, though I have not seen the pool metrics" is short and honest. Deleting the uncertainty to save words is a lie. - **A request to "make it shorter" that would cost a fact.** Shorten what you can, then say which fact you kept and why. - **Nothing to cut.** Say the draft is already tight rather than inventing edits. Trimming a clean draft usually removes meaning. ## Files - `references/examples.md` - three full before-and-after rewrites with the word counts and a note on what was deliberately kept: a padded technical answer, a status update to a manager, and a case where the shorter version was rejected because it dropped a caveat. Read it when you are unsure whether a cut loses information.
Install it
Unzip the download into .claude/skills/. The folder is already named right.
Unzip into ~/.claude/skills/ to use it everywhere.
Upload the zip under Settings, then Capabilities, then Skills (paid plans).
How to call it
Just describe the task. The description line inside the skill does the matching. Or call it directly:
/concise-output
be concise, answer firstcut the filler from thisjust give me the bottom linemake this shorter without losing anythingthis reply is too long, tighten it
Works beyond Claude
Skills use the open Agent Skills format. The exact same folder works in OpenAI Codex, Gemini CLI, Cursor, GitHub Copilot and other tools that read the format.
Using a plain chat app? Paste SKILL.md into ChatGPT or Gemini as instructions. You lose auto-triggering, but the method still works.
agentskills.io