Attention Span: ADHD-friendly output styles for Claude Code

The problem Attention Span targets: reading time, not coding ability

Claude Code answers correctly and at length. For a lot of people the second half is the problem. The README frames the project around attention as a limited resource and names its audience directly: "anyone whose attention is a limited resource. ADHD, tired, deep in flow, or just done with walls of text." The styles change delivery only. The README states the engineering ability underneath is the same, and the benchmark it points to is built to check that claim rather than assert it.

The before/after table in the README is the clearest statement of intent. The same question about PostgreSQL versus MongoDB produces 430 words by default and 94 words under Attention-kind, with the recommendation in the first line and the reasoning reduced to four arrow-marked points. Whether you agree with the database advice is beside the point; the comparison is about shape. The default answer buries the conclusion; the styled answer leads with it.

This is a narrow tool. It does not add tools, memory, or retrieval to Claude Code. It does not change the model. If your complaint about coding agents is that they get things wrong, this project has nothing for you, and the README says so explicitly: "We don't claim it produces better answers, that isn't what it's for."

How the styles work: markdown files that rewrite the delivery rules

Attention Span is not a wrapper or a proxy. It is a collection of output style files, and Claude Code's own output styles feature is the mechanism. The README links to the Claude Code output styles documentation and describes each style as "a single markdown file you drop in and switch on." The repository layout matches that description: there is an output-styles/ directory holding the style markdown, alongside commands/, skills/, and a .claude-plugin/ directory.

The rules inside a style are behavioural, not architectural. Attention-kind, the flagship, encodes: answer first with the conclusion in line one, say the least that fully answers, expand only on what matters so length itself signals importance, define rare technical terms once in about five words, use arrow markers and bold so the answer can be skimmed, and never restate a point. Two rules go beyond formatting. Long tasks get re-anchored, and the agent asks one question at a time. Code comments inherit the plain-English "explain the why" rule but not the chat formatting, which is a sensible split: you do not want arrow markers inside a function.

Spartan uses the same arrows and bold with the warmth removed: blunt, imperative, no transitions. Rundown produces TL;DR briefings. The three cover different registers rather than different capabilities, so the choice is about how much cushioning you want between you and the answer.

Installing Attention Span and switching on your first style

The README does not spell out an install command, so the reliable route is Claude Code's output styles mechanism plus the files in this repository. Clone the repository, then point Claude Code at the style file you want. The output-styles/ directory is where the markdown lives.

git clone https://github.com/alexgreensh/attention-span.git
ls attention-span/output-styles

You should see the style markdown files listed, including the Attention-kind, Spartan, and Rundown entries. The README also ships a plugin manifest under .claude-plugin/, which is the other supported route if you install it as a Claude Code plugin.

Once the style is available, switch to it from Claude Code's output style selector. The README's framing is "drop in and switch on," and the effect is per-session delivery, not a project setting that changes your code.

# in Claude Code, after installing the style
# open the output style selector and choose Attention-kind

To confirm it took effect, ask a question with an obvious answer and watch the first line. Under Attention-kind the conclusion should be in line one, marked with an arrow and bold, rather than after a paragraph of setup. If you still get a wind-up paragraph, the style is not active. The repository also carries commands/ and skills/ directories, so the project is not only styles; the README's own description, however, is about output styles first.

What the benchmark does and does not establish

The README reports a benchmark with a specific design choice: the work and the output are measured separately, and the headline numbers use no LLM judge. The work side is 12 coding tasks with hidden test suites, run with the style off and on. The README reports pass rates equal at 97% for both, described as within noise. That is the claim that matters most, because a style that shortens answers at the cost of correctness would be worthless.

The output side reports roughly 43% shorter output on average with a median of 41%, and 50 to 71% on verbose answers, with already-short answers barely changing. It also reports that the answer arrives in the first line 75% of the time versus 3% without the style, and that deliverables such as a requested message or commit come out clean 88% of the time versus 12%. The README is careful about one thing here: it says reading-grade scores do not apply, because they only measure word length and cannot see a wall of text. That is a fair criticism of a common shortcut.

The harness and the writeup are in the repository at benchmarks/results/2026-08-11-benchmark.md, and the README says every figure is reproducible from the repo. Reproducible is not the same as reproduced by you. The 88% deliverable figure is the softest of the set, since it depends on what counts as a clean deliverable, and the README does not show the grading rubric for that number in the excerpt available here.

Where Attention Span is the wrong tool

The styles change tone, so they are wrong whenever tone is the deliverable. If you are drafting user-facing copy, an apology email, or documentation meant to read warmly, a style that strips cushioning and compresses to arrows will fight you. Spartan is explicitly the wrong choice there; the README describes it as "terse, zero warmth" and "blunt and imperative, no cushioning, no transitions."

There is also a subtler failure mode. The README says length itself signals importance under Attention-kind. That only works if the model's judgement about importance matches yours. When it does not, the thing you needed gets one line and the thing you already knew gets four, and you have lost the redundancy that would have caught it. A long default answer is wasteful, but it is also harder to skim past a detail by accident.

Finally, the project is scoped to Claude Code output styles. The README's tagline mentions Codex and others, but the documented mechanism is Claude Code's output style feature, and the repository is organised around it. If you run a different agent, the markdown files may be portable as prompt text, but nothing in the README confirms that path, and the benchmark numbers were not produced that way.

Alternatives: prompt instructions versus a maintained style file

The obvious alternative is a line in your CLAUDE.md or system prompt telling the agent to be concise and lead with the answer. That costs nothing to try and requires no dependency. The difference is maintenance and specificity. A hand-written instruction tends to be one sentence, and models drift from it over a long session. Attention Span encodes a full rule set, including the parts people forget to write down: define rare terms once, never restate a point, re-anchor long tasks, ask one question at a time, and keep code comments plain without inheriting chat formatting. Those rules are the product.

The second alternative is a general prompt-library or agent-configuration tool that bundles many behaviours. Those tend to change what the agent does, adding tools or workflows. Attention Span deliberately does not. The README's claim that the work is untouched is the whole design, and it is why the benchmark separates work from output. If you want an agent that does more, this is not that. If you want the same agent that is easier to read, the scope is exactly right.

Maintenance, versioning and the AGPL-3.0 licence

The repository is not archived and the last push was on 2026-09-06. Releases have been frequent in the recent window: 0.6 on 2026-08-15, 0.7 on 2026-08-21, and 0.8 on 2026-09-06. That cadence suggests active work, but the README does not describe a support policy, a deprecation process, or how breaking changes to a style are communicated. A style file is easy to diff, so an upgrade is mostly a matter of reading the diff and deciding whether you prefer the new rules.

Upgrade cost is genuinely low for the styles themselves. The risk sits in the surrounding pieces: commands/, skills/, and the .claude-plugin/ manifest, which depend on Claude Code's plugin and skill interfaces. If those interfaces change, the styles keep working as plain markdown while the plugin packaging may need a version bump. The CHANGELOG.md at the repository root is the place to check before pulling.

The licence is AGPL-3.0. For individual use with Claude Code this is unremarkable. It matters if you plan to fold the style files into a hosted product or a modified distribution, because AGPL-3.0 carries source-availability obligations that permissive licences do not. This is a description of the licence, not legal advice; if you are shipping something commercial on top of these files, read the licence text in LICENSE and get your own answer.

Editorial conclusion

Adopt Attention Span if you use Claude Code and your bottleneck is reading its replies, not its code: the styles are single markdown files, the README reports equal pass rates on 12 hidden-test tasks with style off and on, and the benchmark harness is in the repository so you can rerun it. Do not adopt it if you need warm, conversational explanations, since Spartan deliberately strips that out, or if you work outside Claude Code, because the README only documents Claude Code output styles. Before trusting the numbers, open benchmarks/results/2026-08-11-benchmark.md and run the harness yourself; the README's claim that deliverables come out clean 88% of the time is the one to check first, because it is the figure most likely to shift with your own prompts.

Frequently asked questions

Official sources

1. alexgreensh/attention-span on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases