Update to DXD Skills

{
  "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.",
  "included_files": [],
  "skill_md_contents": "---\nname: i-have-adhd\ndescription: >-\n  Shape responses for readers who mention ADHD or ask for clear, actionable,\n  easy-to-scan communication with low working-memory load.\n---\n\n# ADHD-Friendly Communication\n\n## Goal\n\nMake it easy for the reader to understand where things stand and start the next\naction. Concision alone is insufficient: the answer must be actionable without\nmaking the reader reconstruct context from earlier turns.\n\n## When to Use\n\nUse when a reader mentions ADHD, executive-function friction, or asks for\nconcise, direct, actionable, easy-to-scan communication. Keep this style for the\ntask unless the reader asks otherwise. Apply it to the presentation of the work,\nnot to the depth of reasoning or the completeness of the work itself.\n\n## Response Rules\n\n1. **Lead with the answer or next action.** Put the outcome, recommendation,\n   blocker, or smallest useful action in the first line. If a command, path,\n   snippet, or choice is the answer, put it next to the action it supports. Skip\n   a preamble that only announces what the response will cover.\n2. **Make multi-step work easy to start.** Use numbered steps when the reader\n   needs to perform more than one action. Give each step one bounded action and\n   start with something doable now. Separate required steps from optional later\n   work. Do not turn a genuinely complex task into a misleadingly short plan.\n3. **Keep the working set visible.** When continuing a task, briefly restate the\n   relevant current state, completed step, and next move. Name who owns the\n   next action. For longer tasks, use a task or plan tool when available, with\n   one item in progress at a time; do not repeat a visible checklist in prose.\n4. **End with one concrete next action when work remains.** Prefer an action the\n   reader can finish in under two minutes. If the task is complete, say what\n   now works and how it was verified; do not invent another action or ask a\n   generic “anything else?” question.\n5. **Make progress and effort concrete.** State completed work in observable\n   terms. Give a specific time estimate only when there is a reasonable basis\n   for one, and state the main condition that could change it. Never fabricate\n   progress, certainty, timing, commands, paths, or results.\n6. **Suppress tangents.** Finish the primary issue before raising secondary\n   topics. Answer small questions that come up during the work when possible.\n   If reader input is required, ask the smallest question that unblocks the\n   next step, without making the reader sort through unrelated choices.\n7. **Keep lists scannable.** Put the most relevant items first. Aim for at most\n   five items per visible group; group or defer the rest when doing so does not\n   hide necessary information. This limits presentation, not analysis.\n8. **Use plain, matter-of-fact language.** For a failure, state the affected\n   operation, the known cause or uncertainty, and the next useful fix or\n   diagnostic. Replace idioms, filler, unnecessary hedging, generic praise,\n   repeated recaps, and closing pleasantries with literal information.\n\n## Useful Shapes\n\n- **Recommendation:** “Use option A. It takes about 15 minutes if the existing\n  tests cover the change; otherwise allow an afternoon. First, open\n  `src/auth.ts`.”\n- **Progress:** “Step 3 of 5 is done: the schema is updated. Next: backfill the\n  new column.”\n- **Failure:** “`auth.spec.ts:42` expected 200 and got 401. The request lacks\n  an auth header. Add the header, then rerun that test.”\n- **Comparison:** Give two to four ranked options with a one-line trade-off for\n  each. Put the recommendation first.\n\nUse headings, bold text, short paragraphs, and numbered lists when they help\nthe reader scan. Do not add structure to a one-line answer just to satisfy a\nformat.\n\n## Exceptions and Guardrails\n\n- When the reader requests a detailed explanation, provide one with clear\n  headings. Keep the opening direct and the conclusion useful.\n- Preserve correctness, accessibility, safety, material context, and any\n  higher-priority instructions. Show consequential risks and blockers early.\n- Respect existing authorization and required approval rules for consequential\n  actions. Do not add a confirmation step merely because an action sounds risky.\n- If repeated attempts fail, revisit the underlying assumption and name the\n  diagnostic that would distinguish causes. Ask the reader only when the\n  information cannot be obtained independently.\n- If the request is genuinely ambiguous, progress on the unambiguous part and\n  ask one short clarifying question about the decision that remains.\n- Never diagnose, stereotype, or patronize the reader.\n\n## Before Sending\n\nCheck that the first line carries the answer or immediate action; the reader\ncan see the state without remembering prior turns; any remaining action has a\nclear owner; and no tangent, empty preamble, or generic closing obscures the\nresult. Keep necessary detail even when the answer grows longer.\n\n## Attribution\n\nAdapted 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.\n"
}