A small collection of output styles for Claude Code that change how it talks to you, not how it codes. Answer-first, plain English, easy to skim. Each one is a single markdown file you drop in and switch on.
The concise-by-default rules are kind to your attention first. Trimming Claude's output is a welcome side effect, not the point.
Three so far: Attention-kind (the flagship), Spartan (terse, zero warmth), and Rundown (TL;DR briefings). Each has its own section below.
Attention-kind
An ADHD-friendly style. Claude answers first, keeps it short, drops the jargon, and expands only on what's actually worth your attention. Every point is spaced out and marked with a →, and the important words are bold, so you can skim just the bold and still get the whole answer.
Same engineering ability underneath. Only the delivery changes.
Who it's for: anyone whose attention is a limited resource. ADHD, tired, deep in flow, or just done with walls of text.
Before / after
The question: "Which database should I use for a new social app, PostgreSQL or MongoDB?" Same answer, before and after the style.
For a new social app, start with PostgreSQL, and the bar for choosing MongoDB instead is high. Social apps are relationship-heavy by nature: users follow users, posts belong to users, comments belong to posts, likes connect users to posts. That's a web of connections, exactly what a relational database is built for. In MongoDB you either cram related data into one record and fight size limits, or split it out and end up stitching it back together in your app code anyway. The feed problem makes this worse: timelines, "posts from people you follow," and mutual-friend lookups all lean on the kind of cross-referencing Postgres does in a single query. You also get consistency for free, since follow counts and "did I already like this" checks want real transactions… [and it keeps going like this]
→ Use PostgreSQL. A social app is all relationships (friends, follows, likes), and Postgres handles those natively. Right for ~90% of new social apps.
→ You keep flexibility. Its JSONB column stores schema-less data inside the same database, so you get MongoDB's looseness without leaving Postgres.
→ Pick MongoDB only if your data is self-contained documents with no links, and you need massive write volume on day one.
→ The early trap with MongoDB: six months in, five different shapes of "user" and no clean fix. Postgres forces the structure.
→ Next: start on managed Postgres (Supabase, Neon, RDS).
Same information. One of them you can read at a glance.
Does it actually help? (measured, and reproducible)
The benchmark measures the work and the output separately, and the headline numbers use no LLM judge. Every figure is reproducible from this repo. Full writeup and runnable harness.
- The work is untouched. 12 coding tasks with hidden test suites, style off vs on: pass rates are equal (both 97%, within noise). No judge, just tests passing.
- ~43% shorter output on average (median 41%), and 50-71% on verbose answers where it matters; already-short answers barely change.
- You reach the point in ~6 words instead of ~40. The answer is in the first line 75% of the time vs 3%. (Reading-grade scores don't apply, they only measure word length and can't see a wall of text.)
- Deliverables come out clean 88% of the time vs 12% with no style, ask for a message or commit and you get just that, no wrapper.
It's shorter, clearer, and easy to grasp at a glance, with the work untouched. We don't claim it produces better answers, that isn't what it's for.
What changes
- Answer first. Conclusion in line one. No wind-up.
- Short by default. Says the least that fully answers, then stops.
- Expands only on what's vital, so length itself signals importance.
- Plain English. Rare technical terms get a five-word definition, once.
- Built to scan.
→ markers, heavy bold, real spacing between points.
- No repetition. Each point makes one distinct argument, never restated or re-argued.
- Re-anchors long tasks and asks one question at a time, so you never lose the thread.
- Comments too. Code comments inherit the plain-English "explain the why" rule, but never the chat formatting.
Spartan
Terse mode with the warmth stripped out. Same arrows and bold as Attention-kind, but blunt and imperative, no cushioning, no transitions, maximum compression. For heads-down work when you want signal, not conversation.
The question: "Three priorities this week, room for two, how do I decide what to cut?" Both real Opus 5 eval outputs.
Cut the one that fails the cheapest test: if it slipped a week, who actually feels it, and how much? Run all three through four quick filters and the loser usually falls out on its own. Consequence of delay: two of your three probably have soft deadlines you invented and one has a real one, a person waiting, a dependency downstream, a window that closes. Cut from the self-imposed pile, never the someone-is-blocked-on-me pile. Reversibility: some things get harder the longer they wait, others are exactly as easy next week, so cut the one whose cost curve is flat. Who owns it besides you: if a priority can be delegated or done at 80% by someone else, it is a better cut than one only you can do… [and it keeps going like this]
→ Rank by cost of NOT doing it, not by effort or interest. Ask each: what breaks if this slips a week? The one with the softest consequence gets cut.
→ Kill the reversible one. If a task can wait, be delegated, or restarted later with no penalty, cut it. Protect anything with a hard deadline or a dependency where others are blocked on you.
→ Run the regret test. Friday night, which un-done task stings most? Keep that one. The one you'd shrug at is your cut.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
