Botmonster TechTen 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, and the ADHD framing is not the reason. 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.
- The rules that pull their weight: action first, restate progress, drop the closers.
- 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
you run two commands, claude plugin marketplace add ayghri/i-have-adhd and claude plugin install i-have-adhd@i-have-adhd, then type /i-have-adhd. There is no local clone, since Claude Code fetches the repo and keeps it updated.
The Codex
path uses codex plugin marketplace add ayghri/i-have-adhd --ref main followed by codex plugin add i-have-adhd@i-have-adhd, invoked with $i-have-adhd. On either harness, touch ~/.claude/.i-have-adhd-always turns it on for every session. Saying “stop adhd mode” or “normal mode” switches it off again.
The project’s before example is the reply pattern the whole thing exists to delete:
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, the verifyToken function (around lines 42-58)
seems to be using an older jsonwebtoken API. 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.The after version answers the same question in 35 words instead of 94, a 63 percent cut with no information lost. It opens with Run npm install jsonwebtoken@latest, then edit src/auth.ts:42, then gives three numbered steps. The closing line is one instruction: paste the first failing line if a test fails.
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, nothing more.
The 10 i-have-adhd rules, and the three that carry the weight
Most write-ups stop at the ten headlines. The SKILL.md file opens with five stated premises about reading. Working memory is small, so nothing off screen survives. Knowing an answer is not doing it, and starting is the hardest step. Vague time estimates all register the same. Buried wins do not register at all. Every rule traces back to one of those five.
| # | 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”. |
Rule 2 in the skill file explains why the skill cuts steps rather than listing them all: a short path someone finishes beats a complete path they abandon.
Three of the ten do most of the visible work. Rule 1 moves where the answer sits and rule 10 deletes the wrapper around it. Rule 5 only shows its value across a long multi-turn session. Rules 6, 7, and 9 are polish. 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, hedging adverbs 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 hedging clause is the one place the file argues against itself, and the qualification is a good sign. A hedge carrying real uncertainty stays, because cutting it manufactures confidence the model does not have.
Why a single prompt file caught on
The repo sat quiet from May onward, then found a large audience in a matter of weeks. Nothing in the code explains that, because there is no code.
Three things did the work. The install cost is close to zero: two commands, no runtime, no config file. That removes the usual gap between “this looks nice” and “I tried it”. The complaint is also universal, since every coding agent user has scrolled past a cheerful opener to find a one line answer buried underneath. Claude Opus 5 gave that complaint its biggest stage yet, and this exact trick became the top-voted cure for Opus 5’s rambling problem .
Distribution did the rest. 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.
Attention is not retention, though. A rush of installs says nothing about how many people still 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.
| 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. The file carries a “when to break the rules” section with six overrides. Three cover the request itself: an explicit ask to explain, genuine ambiguity, and a debug spiral where the last three turns were “still broken”. One covers danger, such as rm -rf or a schema migration. The last two cover the rules fighting themselves, either by deleting the answer or by contradicting the harness. 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. 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. 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. In practice, deferred questions get skipped.
- Learning something new. The pre-send check deletes weak hedges, and hedges are how a model signals doubt. Lose them and you lose the cue to verify before you paste.
- Output you hand to someone else. Terse replies assume the reader holds the context. That breaks 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. Preamble, recaps, “Hope this helps”, 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
Run claude plugin uninstall i-have-adhd and claude plugin marketplace remove i-have-adhd first if the upstream copy is present, since fork and upstream share a name. Then run claude plugin marketplace add <your-username>/i-have-adhd and claude plugin install i-have-adhd@i-have-adhd.
Make it always on, or keep it manual
Run touch ~/.claude/.i-have-adhd-always to apply it to every session, or leave it off 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.