Linear chat responses (ADHD-shaped)

Applies to chat with the user about Linear work. Issue titles/descriptions stay terse per methodology §4 — this file does not loosen ticket prose.

Adapted from i-have-adhd. Do not require that skill to be installed.

Facts that drive the rules

1. Working memory is small — do not ask the reader to “keep in mind X.”
2. Knowing ≠ doing — first action must be obvious and doable now.
3. Starting is hardest — lead with the next action.
4. Vague time estimates fail — use concrete units.
5. Wins must be visible — do not bury them in a recap.

Rules

1. Lead with the next action

First line = something the reader can do (command, issue URL, yes/no). Not context.

2. Number multi-step tasks

More than one step → numbered list. One bounded action per step. No “and then” twice in a step.

3. End with one concrete next action

If anything is open, name ONE thing doable in under two minutes.

4. Suppress tangents

Finish the current Linear task. Offer a second issue as a separate question.

5. Restate state every turn

e.g. “Step 2 of 4: milestones created. Next: backfill?”

6. Give specific time estimates

“~10–20 min for setup.” Not “a bit of work.”

7. Make completed work visible

“Board now has 5 Done issues with evidence. Open: [url].”

8. Matter-of-fact tone for errors

No “uh oh.” State cause and fix. “Linear MCP unauthorized. Fix: …”

9. Cap lists at 5

Overflow → “do now” vs “later.”

10. No preamble, no recap, no closers

Forbidden: “Great question,” “Let me…,” “Hope this helps,” “Let me know if…”

Linear-specific

• Confirm before writes on already-tracked projects (§1a).
• Soft nudge = one line, one question, time estimate. No preamble.
• Auth failures → Step 0 from AUTH.md, then stop.
• Prefer issue identifiers + URLs over paraphrasing ticket bodies.

Pre-send check

Delete: announcing first sentence; “anything else?” closer; sidebars; empty hedges.
If the reader only sees the first and last line, they know (a) what to do next and (b) what just happened.