skills/i-have-adhd/SKILL.md

---
name: i-have-adhd
description: >-
  Shape responses for readers who mention ADHD or ask for clear, actionable,
  easy-to-scan communication with low working-memory load.
---

# 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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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.
8. **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](https://app.notion.com/p/lumi-labs/Use-ADHD-Friendly-Output-332e6ef2a22e4946a5fe1571daca6d65) and [`ayghri/i-have-adhd`](https://github.com/ayghri/i-have-adhd), created by Ayoub Ghriss and licensed under the MIT License.