A Cursor rule for ultra-concise output
6 Jun 2026
Humans skim. “Be concise” does nothing — the agent already thinks it is. What works is hard numeric limits, negative constraints, and one bad/good example. The agent pattern-matches the example far more reliably than it interprets prose.
The rule
---
description: Force ultra-concise responses and documentation
alwaysApply: true
---
# Be ultra-concise
Humans skim. Default to the shortest output that fully answers.
## Chat responses
- Lead with the answer/result. No preamble ("Sure!", "Great question", "I'll help you...") and no closing summary unless asked.
- Prefer bullets over paragraphs. Max ~4 bullets or ~6 sentences for a normal answer.
- One concept per line. Cut adjectives, hedging, and restating the question.
- Show only changed/relevant code, not whole files. Skip "here's what I did" recaps after edits — the diff speaks for itself.
- Don't explain unless asked why. Report what changed in ≤2 sentences.
## Documentation output
- Lead with a one-line purpose, then a table or bullets. No "Introduction" / "Overview" filler.
- One idea per sentence. Prefer tables for anything with 3+ comparable items.
- No marketing tone, no repetition across sections, no restating headings in prose.
- Keep examples minimal and runnable; cut narrating comments.
## Bad vs good (chat)
❌ "Great question! I went ahead and updated the function. Here's a breakdown of everything I changed and why it matters for your use case..."
✅ "Updated `parseDate` to handle ISO strings. Edge case: empty input now returns `null`."Why each part matters
| Part | Why |
|---|---|
alwaysApply: true | Communication style is the rare legitimate always-on rule. Keep total always-on rules to 2–3. |
| Numeric caps (“max ~4 bullets”) | Enforceable. “Concise” is not. |
| Negative constraints (“no preamble”) | Hard boundaries beat soft preferences — the agent obeys “never X” more than “prefer Y”. |
| One bad/good example | Examples outperform prose. Show the filler you’re cutting. |
| Split chat vs docs | Different output channels need different shapes (sentences vs tables). |
Placement
- Global (Settings → Rules): applies to every project, chat only. Best for personal style.
- Project (
.cursor/rules/concise-output.mdc): shared via git, also governs generated docs/markdown. Best for team output. - Both: global for chat tone, project rule for documentation conventions.
What to skip
- Vague adjectives (“clean”, “professional”, “high-quality”) — unmeasurable, ignored.
- Long lists of synonyms for “short”. One cap per dimension is enough.
- Persuasion (“it’s strongly recommended that…”). The agent needs instructions, not convincing.