i-have-adhd Makes Agents Answer First

By Rogier Muller09.09.26

i-have-adhd is an MIT-licensed Claude skill by GitHub user ayghri that changes how a coding assistant answers: action first, numbered steps, no soft landing. It deals with the ordinary problem of coding agents burying the fix under explanation, caveats, and polite filler. The useful takeaway for ai coding for teams is not the project name; it is the output contract: say the next action before the reasoning, then make the result easy to test. As of September 8, 2026, the repository had 31,499 GitHub stars and had been pushed that day.

A skill is a packaged instruction set that teaches an AI assistant a reusable behavior for a specific kind of task. In this case, the task is not writing better Python or picking a smarter tool. It is making the assistant stop wandering before it tells you what to do. Devin Workshop is part of Harness Institute.

Read the release as an output contract

The project’s README makes the pitch with a before-and-after. Before, the agent gives a friendly paragraph about auth middleware, token verification, dependency versions, and tests. After, it starts with the command, the file, the line range, and the test to run.

That is a small change with a big workflow effect. A developer in Cursor, Anysphere’s AI code editor, can scan the answer while staying inside the editor, apply the first step, and push the agent to explain only when the plan looks risky.

The trap is thinking this is only about being concise. “Be concise” often produces shorter prose with the same buried structure. i-have-adhd is more specific: put the action first, number the steps, and end with the next handoff instead of a vague invitation.

The name also deserves care. Some developers liked the framing because it describes a real friction: long agent answers are hard to parse under pressure. Others were uncomfortable with people casually claiming ADHD as a prompt trick. That objection is fair. In a work repo, I would call the pattern “answer-first” unless a person chooses different language for themselves.

Notice what is clever, not just what is loud

The clever part is that i-have-adhd treats formatting as part of correctness. In AI software development, an answer can be technically accurate and still fail because the human cannot find the next action fast enough.

That matters for agentic coding because agents are chatty by default when they are uncertain. They summarize context, hedge, mention adjacent risks, and then finally say the edit. Sometimes that is useful. During a failing test or review pass, it is usually noise.

A good answer-first shape looks like this:

Do this now.
Here are the numbered steps.
Here is the file or command.
Here is the test.
If it fails, paste this exact thing back.

The trap is turning the skill into a personality transplant. You still want the assistant to explain tradeoffs when it changes an auth boundary, deletes data, rewrites migrations, or touches secrets. The skill should compress routine output, not hide risk.

Be honest about what is rough

A fair criticism from the discussion was size. Commenters counted roughly 8.7k lines across 59 files, while the core prompt appeared to live in a much smaller SKILL.md. That does not make the project bad, but it does make the project worth reading before you install it into a serious repo.

There is also a simpler workaround: ask the agent to explain again in a shorter, phone-readable way. Several developers already do that. For one-off ai pair programming, it works fine.

The difference is durability. A reusable skill saves you from asking the same style question over and over. It also gives reviewers something concrete to discuss: did the agent answer with an action, steps, a test, and a next handoff?

The trap is treating a skill as a substitute for review. Short answers can be wrong faster. If an agent tells you to run npm install jsonwebtoken@latest, you still need to check package impact, lockfile changes, and auth tests before merging.

Try it in Cursor on one small repo

The safest way to learn from i-have-adhd is to test the answer-first pattern on a small repo where mistakes are cheap. This is the practical bit for ai coding for teams: do not start with a grand process change. Start with one failing test, one branch, and one reviewable output shape.

Use Claude Code, Anthropic’s coding agent, if you want to try the project as a Claude skill. Use Cursor if your daily loop is agent-in-editor review. The same idea can live in a repo note, an AGENTS.md boundary, or a .mdc rule that tells the assistant how to answer in that workspace.

Here is a small Cursor rule stub you can adapt:

---
description: Keep coding-agent answers action-first and easy to test
alwaysApply: true
---

When answering implementation questions:
- Start with the next action or command.
- Use numbered steps for edits.
- Name the file, function, or test when known.
- Put explanation after the steps, not before.
- End with the exact test or log line the developer should paste back.

Do not compress security, data-loss, auth, billing, or migration risks.
For those, give the action first, then add a short risk note before code changes.

Pair that with a local AGENTS.md boundary in the repo root:

# Agent boundaries

Prefer answer-first replies for routine edits.

Before changing auth, payments, migrations, secrets, or permissions:
1. State the intended change.
2. Name the files you will touch.
3. Wait for confirmation.

After editing:
1. List changed files.
2. List tests run.
3. List the first failing line if any test failed.

This sits nicely beside the related training topic, but the point is smaller than training. You are checking whether answer shape improves review speed without making the agent careless. If the pain is tool choice rather than output shape, read How Coding Agents Choose Tools next.

Small experiment plan: answer-first, one repo

Copy this into an issue or PR description before you try the pattern.

## Answer-first agent experiment

Repo:
Branch:
Task:
Agent used:
Rule or skill used:

## What changed
- Files edited:
- Commands run:
- Tests run:
- First failing line, if any:

## What to check
- Did the first response start with the next action?
- Were steps numbered?
- Did it name the file, command, or test?
- Did it avoid filler?
- Did it preserve risk notes for auth, data, secrets, or migrations?

## Keep / change / remove
- Keep because:
- Change because:
- Remove because:

Run the same task twice if you can: once with the normal agent behavior, once with the answer-first instruction. Compare time to first useful action, number of clarification turns, and whether the reviewer could understand the change from the final note.

The trap is judging only tone. A pleasant short answer is not enough. The useful measure is whether the output made the edit easier to test and review.

Common questions

Is i-have-adhd only for people with ADHD?

No. The project’s README says no ADHD diagnosis is needed, and the behavior is broadly useful for developers who want scannable agent output. The naming may still feel uncomfortable to some people with ADHD, so a workplace-friendly version should describe the behavior as “answer-first” rather than asking people to borrow a diagnosis.

Why not just tell the agent to be concise?

You can, and it often works for a single reply. The advantage of a skill or repo rule is repeatability: the assistant keeps using the same structure across tasks. The important number from the public discussion is the core prompt scale: commenters found the main skill file was much smaller than the whole repository.

Does ai coding for teams need a skill like this?

It needs the behavior more than the exact package. Teams using coding agents benefit when answers begin with an action, include test commands, and leave a review trail. The caveat is that short output must not suppress material risk, especially around auth, data deletion, permissions, billing, or migrations.

Will answer-first replies make agents less careful?

They can if you over-compress everything. The safer pattern is action first, then a risk note when the task touches sensitive code. For routine test fixes, dependencies, and refactors, compression helps. For security boundaries and production data, require the agent to pause and name the files before editing.

Best ways to use this research

Best for: Developers who already like coding agents but lose time digging through long answers during implementation or review.
Best first artifact: A small .mdc rule or AGENTS.md note that asks for action-first output, numbered steps, named files, and tests run.
Best comparison angle: Compare normal AI code generation output against answer-first output on the same failing test, then review which one produced a clearer handoff.
Best caveat: Keep extra explanation for sensitive code paths. Brevity is useful only when it preserves the risk signal.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.