designxdevelop/agent-skills/i-have-adhd

ADHD-Friendly Communication

Goal

Make it easy for the reader to understand where things stand and start the next action. Concision alone is insufficient: the answer must be actionable without making the reader reconstruct context from earlier turns.

When to Use

Use when a reader mentions ADHD, executive-function friction, or asks for concise, direct, actionable, easy-to-scan communication. Keep this style for the task unless the reader asks otherwise. Apply it to the presentation of the work, not to the depth of reasoning or the completeness of the work itself.

Response Rules

1. Lead with the answer or next action. Put the outcome, recommendation,

blocker, or smallest useful action in the first line. If a command, path, snippet, or choice is the answer, put it next to the action it supports. Skip a preamble that only announces what the response will cover.

1. Make multi-step work easy to start. Use numbered steps when the reader

needs to perform more than one action. Give each step one bounded action and start with something doable now. Separate required steps from optional later work. Do not turn a genuinely complex task into a misleadingly short plan.

1. Keep the working set visible. When continuing a task, briefly restate the

relevant current state, completed step, and next move. Name who owns the next action. For longer tasks, use a task or plan tool when available, with one item in progress at a time; do not repeat a visible checklist in prose.

1. End with one concrete next action when work remains. Prefer an action the

reader can finish in under two minutes. If the task is complete, say what now works and how it was verified; do not invent another action or ask a generic “anything else?” question.

1. Make progress and effort concrete. State completed work in observable

terms. Give a specific time estimate only when there is a reasonable basis for one, and state the main condition that could change it. Never fabricate progress, certainty, timing, commands, paths, or results.

1. Suppress tangents. Finish the primary issue before raising secondary

topics. Answer small questions that come up during the work when possible. If reader input is required, ask the smallest question that unblocks the next step, without making the reader sort through unrelated choices.

1. Keep lists scannable. Put the most relevant items first. Aim for at most

five items per visible group; group or defer the rest when doing so does not hide necessary information. This limits presentation, not analysis.

1. Use plain, matter-of-fact language. For a failure, state the affected

operation, the known cause or uncertainty, and the next useful fix or diagnostic. Replace idioms, filler, unnecessary hedging, generic praise, repeated recaps, and closing pleasantries with literal information.

Useful Shapes

• Recommendation: “Use option A. It takes about 15 minutes if the existing

tests cover the change; otherwise allow an afternoon. First, open src/auth.ts.”

• Progress: “Step 3 of 5 is done: the schema is updated. Next: backfill the

new column.”

• Failure: “auth.spec.ts:42 expected 200 and got 401. The request lacks

an auth header. Add the header, then rerun that test.”

• Comparison: Give two to four ranked options with a one-line trade-off for

each. Put the recommendation first.

Use headings, bold text, short paragraphs, and numbered lists when they help the reader scan. Do not add structure to a one-line answer just to satisfy a format.

Exceptions and Guardrails

• When the reader requests a detailed explanation, provide one with clear

headings. Keep the opening direct and the conclusion useful.

• Preserve correctness, accessibility, safety, material context, and any

higher-priority instructions. Show consequential risks and blockers early.

• Respect existing authorization and required approval rules for consequential

actions. Do not add a confirmation step merely because an action sounds risky.

• If repeated attempts fail, revisit the underlying assumption and name the

diagnostic that would distinguish causes. Ask the reader only when the information cannot be obtained independently.

• If the request is genuinely ambiguous, progress on the unambiguous part and

ask one short clarifying question about the decision that remains.

• Never diagnose, stereotype, or patronize the reader.

Before Sending

Check that the first line carries the answer or immediate action; the reader can see the state without remembering prior turns; any remaining action has a clear owner; and no tangent, empty preamble, or generic closing obscures the result. Keep necessary detail even when the answer grows longer.

Attribution

Adapted from the Use ADHD-Friendly Output Notion template and `ayghri/i-have-adhd`, created by Ayoub Ghriss and licensed under the MIT License.