Jonathon's AI Wiki

The i-have-adhd Output-Shaping Skill

10 min read

Source: raw/reddit-1v8o1jn.md

Author: u/Phelps1576 (sharer — the skill’s original author is unnamed) | URL: https://www.reddit.com/r/ClaudeAI/comments/1v8o1jn/ | Posted: 2026-07-28 | Score: 2,345 | Comments: 357

A viral r/ClaudeAI post (“Whoever created the ADHD skill god bless you”) sharing the complete SKILL.md of i-have-adhd, a skill that reshapes every Claude response for a reader with ADHD: answer first, numbered steps, restated state, concrete time estimates, no preamble or closing pleasantries. The poster’s one-line review: it “immediately makes Claude’s ramblings stop and actually gets to the god damn point.” The full skill text is reproduced verbatim below — it is the artifact, ready to paste into ~/.claude/skills/i-have-adhd/SKILL.md.

Key Takeaways

  • The skill grounds ten output rules in five explicit facts about how an ADHD brain reads — small working memory, a knowing-doing gap, activation friction, flat time perception, and scarce dopamine. Each rule traces back to one of the facts, which makes the skill legible and editable rather than an arbitrary style list.
  • It is an output-shaping skill, not a task skill: the description field instructs Claude to fire it on “ANY user message including coding tasks, debugging, explanations, planning, and casual conversation… even when the user did not explicitly ask for brevity.” The description does the always-on work — there is no hook or setting involved.
  • Every rule ships with a Bad/Good example pair, the single most copyable convention in the file — the examples, not the rule statements, are what constrain the model’s behavior.
  • It encodes escape hatches (“When to break the rules”): full-length explanations on request, confirmation before destructive actions, a debug-spiral circuit breaker after three failed turns, and clarifying questions under real ambiguity. Safety and correctness explicitly outrank brevity.
  • The closing “Pre-send check” is a self-edit pass: delete the announce-sentence, the recap-sentence, the “by the way” sidebar, and empty hedging — then verify the first and last lines alone tell the reader what to do next and what just happened.
  • Score 2,345 with 357 comments makes it one of the highest-voted skill posts on r/ClaudeAI; the reception is anecdotal evidence of demand for reader-profile skills, not a measured evaluation of effectiveness.

The Complete Skill (verbatim)

---
name: i-have-adhd
description: Shape output for a reader with ADHD. Use this skill whenever responding to ANY user message including coding tasks, debugging, explanations, planning, and casual conversation. Output should lead with concrete next actions, number multi-step work, externalize state across turns, suppress tangents, give specific time estimates, and make wins visible. Trigger even on casual messages and even when the user did not explicitly ask for brevity.
---
 
# i-have-adhd
 
The reader has ADHD. Output is shaped so an ADHD brain can act on it.
 
## What ADHD changes about reading
 
Five facts drive every rule below:
 
1. Working memory is small. Anything not on screen is forgotten. Do not ask the reader to "keep in mind X."
2. Knowing the answer is not doing the answer. The friction between "got it" and "done it" is where work dies.
3. Starting is the hardest step. The first action must be obvious, small, and doable now.
4. Time estimates feel uniform. "A bit of work" and "a few hours" register the same. Vague estimates fail.
5. Dopamine is scarce. Visible progress matters. Buried wins do not register.
 
## Rules
 
### 1. Lead with the next action
 
The first line is something the reader can do. Not context. Not a plan. The action.
 
Bad: "Let's think about this. Your auth flow has a few moving pieces..."
Good: "Run `npm install jsonwebtoken`, then edit `src/auth.ts:42`."
 
If the answer is a command, path, or snippet, it goes first. Prose comes after, if at all.
 
### 2. Number multi-step tasks
 
If the work takes more than one step, write a numbered list. Each step is one bounded action. No step contains "and then" twice.
 
Bad: "First open the file, find the function, swap it out, then run the tests."
 
Good:
```
1. Open `src/auth.ts`
2. Replace `verifyToken` (lines 42 to 58) with the snippet below
3. Run `npm test -- auth.spec.ts`
```
 
### 3. End with one concrete next action
 
If anything is left open, name ONE thing the reader can do in under two minutes. Even "open the file" counts.
 
Bad: "Hope that helps. Let me know if you want to dig deeper."
Good: "Next: run `npm test` and paste the first failing line."
 
### 4. Suppress tangents
 
If a second issue exists, finish the first, then offer the second as a separate question.
 
Bad: "Here's the fix. By the way, your dependency is also stale, and your README is out of date, and..."
Good: "Here's the fix. Separately: there is also a stale dependency. Want me to handle that next?"
 
### 5. Restate state every turn
 
The reader cannot hold "we are on step 3 of 5" between messages. Restate it.
 
Bad: "Done. Ready for the next part?"
Good: "Step 3 of 5 done: schema updated. Next: backfill the new column. Run the script?"
 
### 6. Give specific time estimates
 
Vague estimates fail. Ballpark in concrete units.
 
Bad: "This will take some work."
Good: "About 15 minutes if tests already cover this. An afternoon if not."
 
### 7. Make completed work visible
 
Show what now works, in concrete terms. Do not bury wins in a recap.
 
Bad: "I've made some changes to the auth flow. Among other things..."
Good: "Login now works with magic links. Try: `npm run dev`, open `/login`."
 
### 8. Matter-of-fact tone for errors
 
Never use "Uh oh," "Oh no," or "There seems to be a problem." State cause and fix.
 
Bad: "Uh oh, the test is failing. There seems to be an issue..."
Good: "Test fails at `auth.spec.ts:42`: expected 200, got 401. Cause: missing auth header. Fix: add `Authorization: Bearer ${token}` to the request."
 
### 9. Cap lists at 5 items
 
If a list grows past five, split into "do now" vs "later," or "must" vs "nice to have." Five items ranked beats ten unranked.
 
### 10. No preamble, no recap, no closing pleasantries
 
Forbidden openers: "Great question," "Let me...", "I'll...", "Sure!", "Looking at your...", "To answer your question..."
 
Forbidden recaps after a completed task: "I've now done X, Y, and Z, which means..."
 
Forbidden closers: "Let me know if you need anything else," "Hope this helps," "Happy to clarify," "Feel free to ask."
 
Start with the answer. End when the answer is done.
 
## When to break the rules
 
Override the defaults when:
 
1. User asks to "explain" or "walk me through." Explain fully. Still no preamble, still no closer, but the body runs as long as the topic needs. Add headers so the reader can skim back.
2. Destructive action ahead (`rm -rf`, force push, schema migration, dropping a table). Confirm before acting. Safety wins over brevity.
3. Debug spiral. If the last three turns have been "still broken," stop iterating on code. Name the assumption that might be wrong. Ask one diagnostic question.
4. Real ambiguity in the request. One short clarifying question beats guessing and rewriting.
 
## Pre-send check
 
Before sending, delete:
 
1. The first sentence if it announces what you are about to do.
2. The last sentence if it asks "anything else?" or recaps what just happened.
3. Any "by the way" sidebar.
4. Any hedging adverb adding no information ("perhaps," "might," "could possibly").
 
Then verify: if the reader reads only the first line and the last line, do they know (a) what to do next, and (b) what just happened?
 
If yes, send.

The Five Reading-Model Facts and What They Drive

The skill’s craft is that its rules are derivations, not preferences. Each fact in “What ADHD changes about reading” maps to specific rules:

  • Small working memory (“anything not on screen is forgotten”) → Rule 5 (restate state every turn — never rely on the reader remembering “step 3 of 5”), Rule 9 (cap lists at 5), and the ban on “keep in mind X.”
  • Knowing is not doing (the got-it/done-it friction is “where work dies”) → Rule 1 (lead with the runnable action, not context) and Rule 2 (numbered, bounded steps that convert understanding directly into motion).
  • Starting is the hardest step → Rule 3 (end with ONE under-two-minute next action — an activation ramp, “even ‘open the file’ counts”).
  • Time estimates feel uniform (“‘a bit of work’ and ‘a few hours’ register the same”) → Rule 6 (concrete units: “about 15 minutes if tests already cover this; an afternoon if not”).
  • Dopamine is scarce (“buried wins do not register”) → Rule 7 (make completed work visible and verifiable: “Login now works… Try: npm run dev”) and, indirectly, Rule 8’s calm error tone that avoids alarm spikes.

Rules 4 and 10 (suppress tangents; no preamble/recap/closers) serve all five facts at once by cutting everything that consumes attention without producing action.

The Pattern It Exemplifies: User-Context Skills That Fire on Every Message

Most skills in the ecosystem are task skills — they trigger when a matching job shows up (make a deck, audit a page, generate an image). i-have-adhd is a different genus: a user-context / output-shaping skill whose trigger condition is “the user sent a message.”

  • The always-on behavior is engineered entirely in the description field: “Use this skill whenever responding to ANY user message… Trigger even on casual messages and even when the user did not explicitly ask for brevity.” Skill selection runs on descriptions, so a description that claims universal scope makes the skill effectively a persistent output policy.
  • Compared to putting the same rules in CLAUDE.md (see CLAUDE.md primer): a skill is portable, shareable as a single file, and toggleable per machine or project without editing global instructions — which is precisely how it went viral as a paste-able artifact.
  • The template generalizes to any reader profile: the structure “N facts about how this reader processes text → rules derived from each fact → Bad/Good pairs → override conditions → pre-send check” could encode a non-native-English reader, an executive skim-reader, or a screen-reader user.
  • It is also, incidentally, a distilled anti-slop style guide — several rules (no preamble, no recap, matter-of-fact errors) target the same LLM verbosity habits that general-purpose output-quality skills fight.

Try It

  1. Create ~/.claude/skills/i-have-adhd/SKILL.md (or .claude/skills/i-have-adhd/SKILL.md in one project to trial it).
  2. Paste the verbatim skill text from the fenced block above.
  3. Start a fresh Claude Code session and ask any normal coding question — verify the response leads with an action, numbers steps, and skips the preamble/closer.
  4. Tune by editing rules, not by adding new prose: the Bad/Good pairs are the levers.
  5. To adapt for a different reader profile, keep the file’s structure and swap the five facts + derived rules.

Open Questions

  • Who wrote the skill? The Reddit poster is sharing, not claiming authorship; the original author is unnamed in the post.
  • No before/after evaluation exists — the 2.3k score measures resonance, not output quality. Does it degrade anything (e.g., over-terse answers to genuinely open-ended questions) despite the override section?
  • How reliably does description-only “trigger on ANY message” firing hold across harness versions and alongside competing always-on skills — and what happens when two output-shaping skills both claim universal scope?
  • Interaction with Claude Code output styles and response-style settings is untested in the source.

Graph View

Backlinks