Concise Output

Concise Output

Overview

Signal over noise. Maximum information in minimum words. If a word doesn't add essential information, delete it.

Verbose output costs the reader attention and buries the one fact that matters under throat-clearing. Filler ("As we discussed earlier...", "It's important to note that...") signals nothing and trains the reader to skim. Brevity is not terseness for its own sake. It is respect for the reader's time and a forcing function for clear thinking. If you can't say it short, you don't yet understand it.

When to Use

Apply brevity by default, and especially for:

• READMEs, documentation, guides
• Commit messages, PR descriptions
• Implementation plans
• Status updates
• Most conversational responses

When NOT to use: brevity is not mandatory for error analysis requiring step-by-step reasoning, debugging complex issues, teaching a concept the user hasn't seen, or explaining trade-offs between multiple valid approaches. There, completeness beats compression, but cut filler even then.

Related: pairs with critical-peer (no-fluff communication) and answer-questions-directly (no preamble). When stating findings, confidence-levels keeps the percentage and gap concise rather than padded with hedging prose.

Critical Rules

| Rule | Enforcement | |------|-------------| | Maximum density | Pack information into minimum words | | No filler phrases | Cut "As we discussed", "It's important to note" | | Bullet lists over prose | Use bullets unless prose is clearer | | Active voice, present tense | "Run tests" not "You should run the tests" | | Get to the point | No preambles, no announcements |

Banned Phrases

| Banned | Why | |--------|-----| | "I'll help you with that" | Just help, don't announce | | "Let me explain..." | Just explain | | "It's important to note that" | Delete entirely | | "As we discussed earlier" | Unnecessary reference | | "In order to" | Use "to" | | "Additionally" / "Furthermore" | Usually deletable | | "Basically" / "Essentially" | Just say the thing | | "I think" / "I believe" | State it directly | | "As you can see" | They can see |

Examples

Conversational Output

WRONG: verbose response

It's important to note that before we begin the implementation,
we should take a moment to carefully consider the architectural
implications of our approach. Let me explain what I'm thinking...

CORRECT: concise response

Architectural concern: [specific issue]. Recommend [specific approach].

WRONG: meta-commentary

I notice that you've made some interesting changes to the authentication
system. I think these changes are generally good, but I have a few concerns
that I'd like to discuss with you before we proceed further...

CORRECT: direct feedback

Auth changes look solid. Three concerns:
1. [Concern]
2. [Concern]
3. [Concern]

Documentation

WRONG: verbose README

## Getting Started

Welcome to our project! We're excited that you're interested
in using this tool. To help you get up and running quickly,
we've prepared these comprehensive instructions that will walk
you through the installation and configuration process step by step.

### Prerequisites

Before you begin, please make sure you have the following installed:
- Node.js version 18 or higher
- npm or yarn package manager

CORRECT: concise README

## Quick Start

Requires Node.js 18+.

npm install
npm test
npm start

Commit Messages

WRONG: verbose

I've added a new validation system that will help us ensure data
integrity across the application. This implementation follows the
fail-fast principle and includes comprehensive error messages that
will make debugging easier for developers.

CORRECT: concise

Add fail-fast validation with explicit error messages

Prevents invalid data propagation at domain boundaries.

Implementation Plans

WRONG: verbose

Okay, so I've thought about this carefully and here's what I think
we should do. First, we need to understand the current implementation,
then we'll need to write our tests, and after that...

CORRECT: concise

Plan:
1. Trace current auth flow (src/auth/handler.ts)
2. Write failing test for OAuth integration
3. Implement OAuth handler
4. Refactor duplication in token validation

Density Techniques

| Technique | Example | |-----------|---------| | Cut introductions | "Here's the fix:" → [just show the fix] | | Use tables | Prose → structured comparison | | Inline context | "Run npm test to verify" vs explain then show | | Delete praise | "Great question!" → [just answer] | | Skip obvious | Don't explain what code clearly shows |

Common Rationalizations

| Rationalization | Reality | |---|---| | "A friendly preamble sounds more helpful" | The reader wants the answer, not the throat-clearing. The preamble delays the value. | | "I should explain my reasoning first" | Show the result, then justify only if non-obvious. Front-loading reasoning buries the conclusion. | | "More detail is safer" | More words dilute signal. The one load-bearing fact gets lost in the padding. | | "Bullets feel curt" | Bullets carry more information per line and let the reader scan. Prose hides structure. | | "I'll restate the question to confirm I understood" | Restating wastes a sentence. Answer directly; a wrong answer reveals a misread faster than a paraphrase. |

Red Flags

• Output opens with "I'll", "Let me", "I'm going to", or "Here's what I'll do"
• A paragraph of context before the actual point
• Praise ("Great question!", "Excellent!") before the answer
• Restating the user's question back to them
• "It's important to note", "Additionally", "Furthermore", "Basically"
• Prose where a table or list would be denser
• Explaining what the code already shows plainly

Self-Check

Before sending output, ask:

• [ ] Can I delete the first sentence?
• [ ] Can I delete the last sentence?
• [ ] Can I use a list or table instead of paragraphs?
• [ ] Did I announce what I'm about to do?
• [ ] Did I include any banned filler phrases?
• [ ] Is every sentence earning its place?

Summary

Ruthlessly eliminate words that don't carry information. Assume reader competence. Prefer structure over prose. Show rather than explain.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: jagreehal
• Source: jagreehal/jagreehal-claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.