adhd_friendly_communication v1.0.0

---

name: "adhd_friendly_communication" description: "Writing and presenting information so readers with ADHD can act on it: action first, numbered steps, one idea per block, visible progress, concrete dates, and formatting rules for chat replies, emails, docs, and long documents, grounded in cognitive load and plain language research, with before and after rewrites and a runnable checker. Use when writing instructions, summaries, emails, guides, or agent output for a reader with ADHD, when a draft is being called overwhelming or hard to follow, or when asked to make text ADHD friendly, clearer, or easier to act on."

---

Purpose

Get a reader from opening your message to finishing the right action, without asking them to hold your message in memory while they work.

The problem is load, not effort. Working memory is small, and research on ADHD shows higher load and higher complexity cost more, on average. Every buried ask, long sentence, stacked question, and vague deadline spends that budget on your formatting instead of your content. This skill takes the cost out of the format.

It applies to chat replies, emails, task briefs, how-to docs, reports, meeting recaps, and agent output. For documents over about 300 words, also read references/long-documents.md. For the research behind each rule, read references/evidence-and-sources.md.

Workflow

1. Put the action first

• Open with the bottom line in the first line: what the reader must do, decide, or know, and by when. Army writing calls this BLUF, bottom line up front. Context, history, and reasons come after it, never before it.

• If no action is needed, say so in line 1. "No action needed. This is an update on X." A reader who knows that can relax and skim, instead of scanning the whole message for a hidden ask.

• Give one primary action per message. If there are two real actions, number them both in the opening block. Do not hide a second ask in the last paragraph.

• Write the opening as a complete instruction on its own. Good: "Reply by Friday 31 October with your room choice." Bad: "A quick note about rooms." The first version still works if the reader reads nothing else.

2. Break the work into numbered steps

• Write steps as a numbered list, one physical action per step, in the order the reader does them. Start each step with a verb: open, click, fill, send, check.

• Keep a step small enough to finish without a decision inside it. "Sort out travel" is a project. "Book the 09:10 train" is a step. If a step contains the word and plus a second action, split it.

• Cap a single list at 7 items. CDC clear communication guidance says to break longer lists into sub-lists. Give each sub-list its own heading, such as "Before you start" and "On the day".

• Show a worked example when the output has a shape: a filled form line, a sample reply, a finished paragraph. A copyable example costs less working memory than a description of the same thing.

• End the steps with a done test. The reader must be able to tell, without asking you, whether they finished. "You are done when the confirmation screen shows a reference number" beats "Let me know when you are done."

3. One idea per block, short sentences

• Keep paragraphs to 4 lines or fewer. Keep sentences short: aim for an average under 20 words, and treat any sentence over 25 words as a split candidate. Put the main idea before conditions and exceptions, so the reader does not have to reread.

• Give each block one job: one step, one fact, one reason, one warning. When a block does two jobs, split it and label each half with a heading or a bold lead word.

• Use real headings in long pieces, in order, with wording that states the content. Headings are how a reader who drifted finds their place again. Do not fake headings with bold text alone in a document that will be read by assistive tools.

• Cut tangents on sight. A side fact, a joke, a second example, and a history note each force a context switch and a switch back. If a tangent is worth keeping, move it to the end under "Extra detail" and label it optional.

4. Make time, progress, and state visible

• Replace every vague time word with a concrete one. "Soon", "later", "ASAP", and "when you get a chance" carry no information a reader can act on. Write the day, the date, or the time: "by 4 pm on Thursday 30 October".

• State totals before the work starts: how many steps, how long it should take, how many items remain. "Step 2 of 5" and "about 10 minutes left" turn an open ended task into a bounded one.

• For recurring or multi part work, show progress in the message itself: a checklist with done items ticked, a count such as "3 of 8 sent", or a short status line at the top. Do not make the reader reconstruct progress from a thread.

• After an interruption point, restate the place. In a follow up, open with "Last time: you finished step 3. Next: step 4, sign the form." External memory in the text beats recall every time.

5. Plain words, defined terms, no stacked questions

• Use the words the reader uses every day. Use active voice. Spell out an acronym at first use, or cut it. Define a term that the reader needs in the sentence where it appears, not in a glossary they must go and find.

• Ask one question per line, numbered, when you need several answers. A paragraph with three questions in it gets one answer, usually to the last question, and the other two get lost. Numbered questions can be answered by number, which also gives you a complete reply.

• Put options in a short list with the difference stated plainly, and mark your recommendation. An open ended "what do you think" forces the reader to generate options and judge them at the same time. A list of 2 or 3 options with a marked pick splits that work in half.

• Close with the next step and the escape hatch: what happens after they act, and what to do if they get stuck. "If the form rejects your file, reply here with the error text and I will fix it" removes the fear of starting.

6. Rewrite pass, with worked examples

Run this pass on any draft that matters. Each pair below shows the failure and the fix.

Example 1, buried ask in an email:

Before: "Hi, hope you are well. We met the venue team last week and talked through the autumn schedule, the catering changes, and a few access issues that came up last season. Following on from that, the rooms we discussed are now on hold, which is good news, but the hold is time limited, so when you get a chance could you possibly let me know which room you would prefer, and also whether you need step free access, so we can confirm things at some point soon."

After:

"Pick your room by Friday 31 October.

1. Reply to this email with A or B. A. Room 1, ground floor, seats 20. B. Room 2, first floor, lift access, seats 35.
2. Add one line if you need step free access.

Why now: the venue holds rooms for 5 days. After Friday the hold ends.

Stuck: reply with the word stuck and I will choose the room that fits your last event."

What changed: ask and date in line 1, one numbered choice, reason after the action, vague time words gone, escape hatch added.

Example 2, wall of instructions in a brief:

Before: "The report needs to be updated with the new figures and the charts should be redone because the old ones use last quarter colours, and also the summary at the front no longer matches the findings since we changed the method in section 3, so that needs rewriting too, plus finance want a one page version for the board."

After:

"Update the report. Four jobs, in this order:

1. Replace the figures in section 2 with the new file.
2. Redo the charts in section 2 using this quarter colours.
3. Rewrite the front summary so it matches section 3.
4. Make a one page version for the board from the new summary.

Done when: finance reply that they have the one page version."

What changed: one job per numbered step, order stated, a done test at the end.

Example 3, agent output with stacked questions:

Before: "I found three flights. Do you want the cheapest or the fastest, and should I include the airport hotel, and is the return date fixed or could you come back a day later if it saves money?"

After:

"Three flights found. I recommend option 1: fastest, and it costs 40 more than the cheapest.

Answer these 3, by number:

1. Book option 1, or pick 2 or 3 from the list below?
2. Add the airport hotel for the first night: yes or no?
3. Return date fixed, or can it move one day later to save money?"

What changed: recommendation first, one question per numbered line, reply by number.

7. Check the draft before it goes out

• Run the bundled checker on any draft over a paragraph: python3 scripts/check_adhd_friendly.py <file>. It flags a missing early action, sentences over 25 words, wall paragraphs, lists over 7 items, long documents with no headings, vague time words, stacked questions, and acronyms to verify. Exit code 1 means a hard failure to fix.

• Then run the 10 point checklist by hand:

1. Line 1 states the action, or states that no action is needed.
2. Every deadline is a day, date, or time. No vague time words remain.
3. Steps are numbered, one action each, in doing order.
4. No list runs past 7 items without a sub-heading.
5. No paragraph runs past 4 lines.
6. One idea per block. Tangents are cut or moved to an optional extra section.
7. Totals are stated: steps, time, or items.
8. Questions are numbered, one per line.
9. Acronyms are spelled out at first use. Needed terms are defined in place.
10. The message ends with a done test and a stuck route.

• Read the first line and the last line only. If a reader who reads just those two lines would still do the right thing, or know they need to read the middle, the structure is sound.

Output Contract

When rewriting or drafting for a reader with ADHD, deliver:

1. The finished text, structured by the rules above, ready to send or publish as is.
2. A short change note, only when you rewrote an existing draft: the 3 to 5 biggest changes you made, in plain words, such as "moved the deadline to line 1" or "split 11 steps into 2 lists". Skip the note for a fresh draft unless the user asks.
3. The checker result when you ran it: pass or fail, and any warnings you left in place with the reason.

When asked only to review a draft, deliver the checklist scored item by item, each failure quoted from the draft with its fix, and do not silently rewrite the whole document.

Operating Rules

1. Never diagnose a reader, guess at a diagnosis, or comment on medication or treatment. This skill is about writing format. If the user states a preference that conflicts with a rule here, follow the stated preference.
2. Never strip out detail a reader needs just to hit a length target. Move detail down, into an appendix, or into an optional extra section, and signpost it. Shorter is not the goal. Lower load at the same completeness is the goal.
3. Never invent a deadline, a step count, or a time estimate to fill the format. If the source gives no date, write "no date set" in the opening block and flag it to the user, rather than guessing one.
4. Do not talk down to the reader. Plain words and short steps are a format choice, not a comment on intelligence. Keep the tone adult, direct, and respectful, and keep technical terms where the reader is an expert in the subject.
5. ADHD varies between readers and within one reader across a day. Treat the rules as strong defaults, not a profile of a person. Ask once what helps, record the answer where the user keeps preferences, and apply it from then on.
6. Verify any number, date, or research claim you put in a skills document or a user facing rewrite against a source. The evidence file for this skill is references/evidence-and-sources.md. A checker pass is a formatting result, never proof that a text is clear. Say so when reporting it.