Ten i-have-adhd rules that stop your AI from rambling

i-have-adhd is a 142 line Markdown file that tells your coding agent to lead with the action and cut the filler. It spread fast because verbose agent output annoys nearly everyone, and this was the first fix small enough to install on impulse.
Key Takeaways
- One Markdown file tells your coding agent to lead with the action.
- Its reach says more about agent filler than it does about ADHD.
- Rules 1 and 10 do most of the work, and rule 5 pays off in long sessions.
- Terse output hurts when the reasoning is the thing you asked for.
- Writing your own house style file takes about ten minutes.
What does the i-have-adhd skill actually do?
It is a plugin for coding assistants, published by ayghri
under an MIT license and created on 13 May 2026. The whole thing is one file, skills/i-have-adhd/SKILL.md, 142 lines and about 1,186 words, with no tool, server, or dependency behind it.
What changes is the shape of every reply for the rest of the session. On Claude Code :
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhdThen type /i-have-adhd. There is no local clone, since Claude Code fetches the repo and keeps it updated.
On Codex :
codex plugin marketplace add ayghri/i-have-adhd --ref main
codex plugin add i-have-adhd@i-have-adhdInvoke it with $i-have-adhd. Saying “stop adhd mode” or “normal mode” switches it off again.
Always-on is Claude Code only: the plugin ships a SessionStart hook that loads the rules when it finds a flag file.
touch ~/.claude/.i-have-adhd-alwaysThe file does nothing by itself, and on a plugin version without hooks/hooks.json it does nothing at all. Other harnesses have no hook, so always-on there means pasting the rules into your agent’s persistent context.
Here is the project’s own before and after , both answering the same question.
Before, 94 words
Great question! Let me think about this. Your auth flow has a few moving pieces: the middleware, the token verification, and the cookie handling. Looking at
src/auth.ts, theverifyTokenfunction (around lines 42-58) seems to be using an olderjsonwebtokenAPI. One approach would be to update the package and rewrite that function. After making the change, you’d want to run the auth tests to confirm nothing breaks. By the way, you might also want to look at your dependency versions overall. Hope this helps! Let me know if you want to dig deeper.
After, 35 words
Run
npm install jsonwebtoken@latest, then editsrc/auth.ts:42.
- Open
src/auth.ts- Replace
verifyToken(lines 42-58) with the snippet below- Run
npm test -- auth.spec.tsNext: paste the first failing line if any test fails.
A 63 percent cut with no information lost. The answer moved to the first line, and the wrapper around it is gone.
The name invites confusion, but the README says plainly that no ADHD diagnosis is needed. The credits call the rules loosely based on The Adult ADHD Tool Kit by J. Russell Ramsay and Anthony L. Rostain, adapted for how a model should reply rather than how a person should plan a day. It is an output style.
The 10 i-have-adhd rules, and the three that carry the weight
The ten headline rules are the part that gets quoted, but the SKILL.md file opens with five stated premises about reading, and every rule traces back to one of them: working memory is small, so nothing off screen survives; knowing an answer is not the same as doing it; starting is the hardest step; vague time estimates all read alike; and buried wins go unnoticed.
| # | Rule | What it actually instructs |
|---|---|---|
| 1 | Lead with the next action | The first line is a command, path, or snippet. Prose comes after, if at all. |
| 2 | Number multi-step tasks | One bounded action per step. No step holds “and then” twice. Fold trivial steps into the one before. |
| 3 | End with one next action | Name one thing doable in under two minutes. “Open the file” counts. |
| 4 | Suppress tangents | Finish the first issue, then raise the second as a separate question. |
| 5 | Restate state every turn | “Step 3 of 5 done: schema updated. Next: backfill the new column.” |
| 6 | Specific time estimates | “About 15 minutes if tests already cover this. An afternoon if not.” |
| 7 | Make wins visible | Say what now works and how to see it. |
| 8 | Errors without drama | No “Uh oh”. Give the failing location, the cause, and the fix. |
| 9 | Cap lists at 5 items | Past five, split into do now versus later, or must versus nice to have. |
| 10 | No preamble, recap, or closers | Banned outright: “Great question”, “Let me…”, “Sure!”, “Hope this helps”. |
Rules 1 and 10 carry the change you see in the before and after above. Rule 5 only pays off across a long multi-turn session. The rest are polish, and most users wouldn’t notice if they vanished.
The under-discussed part is the pre-send check at the bottom of the file. Before replying, the model deletes five things: openers that announce intent, closers that ask “anything else”, “by the way” sidebars, soft words like “probably” and “fairly” that carry no information, and idioms it can state literally. Then it verifies one thing. Reading only the first line and the last line, does the reader know what to do next and what just happened?
That clause is the one place the file argues against itself, and the limit it draws is the right one. A “probably” that carries real doubt stays. Delete it and the model sounds certain when it is not.
Why a single prompt file caught on
The repo sat quiet from May onward, then found a large audience in a matter of weeks. Since it holds no code, the reasons sit in the packaging.
Installing it takes two commands and adds no runtime or config file, so trying it costs almost nothing. The annoyance it fixes is common too, because every coding agent user has scrolled past a cheerful opener to find a one line answer buried underneath. Claude Opus 5 made that complaint loud, and this trick became the top-voted cure for Opus 5’s rambling problem .
The docs reach well past one tool. INSTALL.md runs to 588 lines and covers nine harnesses. Claude Code, Codex, Zed, Hermes, Pi, Gemini CLI, GitHub Copilot, and Antigravity each get their own section. A catch-all covers Cursor, OpenCode, Amp, and anything else that reads agent skills. The README also ships in Chinese, Japanese, Korean, and Vietnamese
, so the audience was never English-only.
Forking is the documented way to customize it, and the fork count runs unusually high for a repo with no code in it. Those are people bending the file to their own taste rather than taking it as shipped.
The repo also ships an eval harness with 14 test cases and a scoring rubric. A release gate blocks any change that drops correctness or safety. Regression tests on a prompt file are rare, and they suggest the author treats this as software.
A rush of installs still says nothing about how many people had the skill enabled a month later.
What Claude Code already gives you for free
Claude Code already ships output styles
as a built-in feature, covering much of the same ground. Run /config, pick Output style, and you can switch between Default, Proactive, Explanatory, and Learning, or drop your own Markdown file into ~/.claude/output-styles/. The old /output-style command was removed in v2.1.91, so use /config or set outputStyle in a settings file. Pairing a style with a hook is what finally keeps Opus 5 brief
, since the style alone drifts back to long answers on a big model.
| Option | Where it lives | Scope | Cost to set up |
|---|---|---|---|
| Built-in output styles | ~/.claude/output-styles/ | Every session until you switch | None, already installed |
| i-have-adhd plugin | Fetched and updated by the harness | One session, or all of them with the flag file | Two commands |
A CLAUDE.md block | One repository | Everyone who works in that repo | Edit one file |
| A personal skill | ~/.claude/skills/ | Every project you touch | Write one file |
Conflicts have a documented tiebreak: override 6 states that inside an agent harness the system prompt outranks the skill file. So a project CLAUDE.md with its own response style wins wherever the two disagree. The skill keeps its shape everywhere else.
When terse output is the wrong choice
The author knows compression is a trade. A “when to break the rules” section lists six cases where the model must stop compressing: an explicit ask to explain, genuine ambiguity, a debug spiral where the last three turns were “still broken”, a dangerous command such as rm -rf or a schema migration, a rule that would delete the answer, and a harness instruction that contradicts the file. Override 5
settles that fight in one direction: when a rule would cut the answer itself, the task wins and only the formatting gives way.
The project’s own scoring rubric makes the same point in numbers. Correctness gets 35 percent of the weight, autonomy 25, actionability 20, safety 10. Concision is worth only 10 percent, the joint smallest slice.
Still, the overrides don’t cover everything. Five kinds of work suffer under an always-on terse style:
- Debugging, where the reasoning is the deliverable. A three line fix with no stated hypothesis gives you nothing to check, and you can’t tell a correct diagnosis from a confident guess.
- Design and architecture, where the trade-offs live in the qualifications. A ranked list with one line each hides the conditions under which the ranking flips.
- Code review and unfamiliar code. Rule 4 defers the second bug to a question at the end, and deferred questions get skipped.
- Learning something new. The pre-send check strips words like “probably” and “I think”, which are how a model tells you it is unsure, so you lose the cue to check before you paste.
- Output you hand to someone else. Terse replies assume the reader holds your context, which stops being true the moment the text becomes a commit message or a ticket.
The repo leaves one question open. The file claims the rules persist for the whole session and survive context compaction. All 14 eval cases are single prompts, though, so that claim is asserted rather than measured.
So keep it session scoped. Invoke /i-have-adhd for execution work and skip it for the sessions where you are thinking rather than doing. The always-on flag is the setting you are most likely to regret.
How to write your own output style skill
I keep a written response style in a CLAUDE.md for my own repositories, covering structure, banned constructions, and a hard ban on em dashes. Two things surprised me. Banning a specific phrase works, while describing a tone does not, because “be concise” is a judgment call the model makes differently every turn. The rules that survive a long session are the ones with a checkable output, like the dash ban. The model drops the softer ones once the context gets busy.
If I started that file again today, I would write the pre-send deletion list first and the style rules second. The deletion list does the real work.
Write your own output style skill for Claude Code
Collect the phrasings you hate
Spend one working session copying every agent reply that annoyed you into a scratch file, including the preamble, the recaps, the “Hope this helps” closers and the unrequested tangents. This list becomes your rules.
Fork the upstream skill as a starting shape
Fork ayghri/i-have-adhd
and open skills/i-have-adhd/SKILL.md. Keep the structure of named rules with a bad example and a good example under each.
Rewrite the rules in your own voice
Replace the rule bodies with your list from step 1. Write each rule as an instruction plus one banned phrasing and one accepted rewrite.
Add a when-to-break-the-rules block
List the cases where the style must yield: explanation requests, destructive commands, debug spirals, real ambiguity. Without this block the skill will compress answers that needed room.
Add a pre-send check
End the file with a short list of things the model must delete before replying, plus one verification question it must answer yes to. This is the part that catches filler.
Install your copy
Fork and upstream share a name, so remove the upstream copy first if you have it:
claude plugin uninstall i-have-adhd
claude plugin marketplace remove i-have-adhd
claude plugin marketplace add <your-username>/i-have-adhd
claude plugin install i-have-adhd@i-have-adhdMake it always on, or keep it manual
Keep the upstream hooks/hooks.json in your fork, then set the flag so the SessionStart hook loads your rules every session:
touch ~/.claude/.i-have-adhd-alwaysDrop the hook file and the flag stops working. Or skip both and invoke /i-have-adhd per session.
Test it against your own bad examples
Restart Claude Code, paste three prompts from step 1, and confirm the replies open with an action and end without a closer. If one slips through, add the offending phrase to the banned list verbatim.
Pick by how much tuning you want. Install i-have-adhd as it ships if you want the change today and don’t care about editing it. Fork it if you have two or three phrasings of your own to ban. Write your own file if you already know exactly what your agent does that annoys you.
Botmonster Tech