Coding agents are increasingly capable of editing files, running tests and explaining unfamiliar codebases. But their usefulness can still be undermined by a simpler interface problem: making users scroll through reassurance, caveats and broad context before finding the command or file change they need.
An open-source project called [i-have-adhd](https://github.com/ayghri/i-have-adhd) packages a response style intended to address that problem. It is a skill or plugin for coding assistants, with a stated goal of producing “ADHD-friendly outputs” without requiring an ADHD diagnosis. The project is MIT-licensed and provides installation guidance for a CLI-based assistant workflow.
The intervention is formatting, not new model capability
The project does not claim to improve a model’s code reasoning or give it access to additional development tools. Instead, it supplies a set of ten behavioral rules for how the assistant should present work.
Those rules include leading with the next action, numbering multi-step tasks, suppressing tangents, using specific estimates in minutes, capping lists at five items and avoiding preambles, recaps and conversational closers. The skill also asks the assistant to restate the current state on each turn, make progress visible and report errors matter-of-factly.
The contrast in the project’s documentation is deliberate. Its “before” example resembles a familiar assistant response: an explanation of possible causes, several contextual observations and a generic offer to help further. The “after” version begins with a package-install command and a specific file location, follows with three numbered steps, then requests the first failing test line if the test does not pass.
For a developer in the middle of debugging, that shift can matter more than it sounds. The relevant question is frequently not “what are all the considerations?” but “what do I do now, and how will I know whether it worked?”
Why teams should care
Agent adoption is often framed as a model-quality or tool-integration decision. In practice, output design affects whether a tool fits into a developer’s working rhythm. Long, hedged answers can increase context switching, obscure an actionable recommendation and make it harder to recover after an interruption.
The project’s rules are also a useful prompt-design checklist for engineering organizations building internal agent experiences. Supportive prose, expansive explanations and repeated summaries may be appropriate in documentation or incident postmortems. They are less useful when an engineer needs to execute a narrow repair under time pressure.
For leaders, the broader lesson is that accessibility-oriented interaction patterns can be operational improvements for many users. Clear sequencing, bounded choices and visible completion criteria reduce ambiguity irrespective of whether someone identifies with the project’s ADHD-oriented framing.
There are trade-offs. A rigid preference for terse responses can hide important risk, particularly for production changes, security work or ambiguous requests. “Action first” should not become “act without validation.” Teams adopting such a skill should preserve escalation paths: a concise initial plan, explicit assumptions and a way to request rationale, alternatives or a deeper review.
Customization is part of the model
The repository explicitly supports forking and editing its `SKILL.md` rules, then installing the customized version. That is significant for organizations: the valuable artifact may not be the exact plugin, but a versioned house style for agent communication.
A platform team could adapt the same approach to require a rollback step for deploy-related requests, a test command for code changes, or a short risk callout when an agent touches authentication and permissions. Product teams could set different defaults for exploratory design work, where context and alternatives deserve more room.
What to watch next
The next test is whether coding-agent platforms make these response contracts easier to apply consistently across tools and teams. As agents move from chat answers to multi-step execution, presentation rules will become part of governance: they shape not only what an agent says, but whether humans can effectively supervise what it does.
The most durable takeaway is straightforward: teams should treat answer structure as a configurable product surface. Better agent output may begin not with a larger model, but with a clearer definition of the next action.
