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-adhd

Then 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-adhd

Invoke 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-always

The 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, 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.

After, 35 words

Run npm install jsonwebtoken@latest, then edit src/auth.ts:42.

  1. Open src/auth.ts
  2. Replace verifyToken (lines 42-58) with the snippet below
  3. Run npm test -- auth.spec.ts

Next: 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.

Side by side comparison of the same agent reply, with the answer buried between preamble, context, a tangent and a closer on the left, and the answer as the first line above three numbered steps on the right

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.

#RuleWhat it actually instructs
1Lead with the next actionThe first line is a command, path, or snippet. Prose comes after, if at all.
2Number multi-step tasksOne bounded action per step. No step holds “and then” twice. Fold trivial steps into the one before.
3End with one next actionName one thing doable in under two minutes. “Open the file” counts.
4Suppress tangentsFinish the first issue, then raise the second as a separate question.
5Restate state every turn“Step 3 of 5 done: schema updated. Next: backfill the new column.”
6Specific time estimates“About 15 minutes if tests already cover this. An afternoon if not.”
7Make wins visibleSay what now works and how to see it.
8Errors without dramaNo “Uh oh”. Give the failing location, the cause, and the fix.
9Cap lists at 5 itemsPast five, split into do now versus later, or must versus nice to have.
10No preamble, recap, or closersBanned 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.

OptionWhere it livesScopeCost to set up
Built-in output styles~/.claude/output-styles/Every session until you switchNone, already installed
i-have-adhd pluginFetched and updated by the harnessOne session, or all of them with the flag fileTwo commands
A CLAUDE.md blockOne repositoryEveryone who works in that repoEdit one file
A personal skill~/.claude/skills/Every project you touchWrite 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.

Horizontal bar chart of the project's eval rubric weights: correctness 35 percent, autonomy 25, actionability 20, safety 10, and concision 10 shown in orange as the joint smallest bar

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.

Decision diagram splitting a session into doing versus thinking, listing repetitive edits and long multi-turn work under invoke the skill, and debugging, design calls, code review and shared text under leave it off

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-adhd

Make 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-always

Drop 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.