Your coding agent’s output is part of the interface
Coding agents are often judged by whether they can solve a task. That matters, but it leaves out a second question: can a person tell what to do next without reading through several paragraphs first?
For many developers, the answer changes the usefulness of an agent more than a marginally better explanation. When a response opens with caveats, explores three alternatives, and buries the command that unblocks the work near the bottom, the work has not become easier. The agent may be correct, but its output has created another interface to navigate.
The open-source i-have-adhd skill approaches this as an output-design problem. Its rules ask a coding agent to lead with the next action, number multi-step work, suppress tangents, make progress visible, and end with one concrete next step. Despite its name, the repository explicitly frames this as a response format, not an ADHD diagnosis or medical intervention.
Same prompt, two different interfaces
Here is the prompt given to both agents:
“Our login test started returning 401 after we upgraded jsonwebtoken. Fix it.”
Without the skill
The 401 response is likely related to a breaking change in the token-verification flow after the jsonwebtoken upgrade. I would first inspect the middleware, the token helper, and the test fixture to see whether the secret, algorithm, or payload shape changed.
Looking at this kind of issue, the most likely source is the verifyToken helper in src/auth.ts. You may need to update the jsonwebtoken call there and review the token creation code as well. After that, run the authentication tests and confirm whether the failure is still present. You should also consider reviewing the rest of your dependency versions.
This answer contains useful ideas. Its problem is that the developer still has to decide what to do first.
With the skill enabled
Run npm test -- auth.spec.ts.
- Open src/auth.ts.
- Find verifyToken at the failing line.
- Update only the jsonwebtoken call that no longer matches the upgraded API.
- Run npm test -- auth.spec.ts again.
If it still returns 401, compare the token payload in the test fixture with the value expected by verifyToken.
Next: paste the first failing assertion.
The second response does not claim to know the fix before seeing the failure. It gives the developer a small first action, a narrow scope, and a clear handoff if that action does not work.
Correct is not always actionable
A capable agent tends to explain its reasoning. That is valuable during design, review, or investigation. It can become counterproductive when the task is bounded and the user needs to begin immediately.
The difference is not simply fewer words. A short answer can still be vague. The useful property is that the response exposes the decision that unlocks progress.
For a bug fix, that might be a focused test. For a configuration change, it might be the file and setting to inspect. For a failing deployment, it might be the first log line that needs attention.
The useful rules are small
The repository’s approach is deliberately lightweight. It does not build a new agent, require a special model, or alter the codebase. It changes the contract for how the agent responds.
Three rules are especially useful in everyday engineering work:
- Lead with the next action. Put the command, file, or decision first when the task has an obvious starting point.
- Number multi-step work. A short ordered list makes dependencies and progress visible.
- Suppress tangents. Finish the requested fix before opening adjacent issues that are not blocking it.
The skill also asks for concrete time estimates, matter-of-fact error messages, and a single next step at the end of an unfinished task. These are not universal rules; exploratory research, architecture decisions, and code review often need more context. They are a good default when the goal is to reduce friction between “I understand” and “I have started.”
Use it as a mode, not a muzzle
An action-first style should not silence important uncertainty. If a database migration is destructive, a security boundary is unclear, or a product decision needs an owner, the agent should stop and surface that fact plainly. Compressing a risky choice into an imperative command is not helpful.
The better pattern is to make the response shape match the task:
- Use action-first output for known, bounded work such as reproducing a bug, editing a configuration file, or running a focused test.
- Ask one clear question when a missing decision changes the implementation.
- Expand into rationale when the developer asks for an explanation, trade-off analysis, or design review.
In other words, the skill is a way to control the agent’s interface, not to make the agent pretend that every task is simple.
Adopt the parts that help
The repository includes installation paths for several coding-agent environments and encourages users to tune the skill to their own workflow. You do not have to adopt every rule unchanged.
Try it with one repetitive workflow first: bug triage, failing CI checks, or a small maintenance task. Compare how often the first response gives you an immediate next action, how often you need to ask the agent to stop digressing, and whether the final handoff tells you exactly what remains.
If the answer becomes too terse for your team, keep the action-first opening and allow a short “why this is the next step” section below it. The goal is not fewer words at all costs. It is an output that makes the right work easier to begin.