ccc-adhd

$ccc-adhd — Answer-first output mode

Most output buries the fix under three paragraphs of throat-clearing. This mode inverts that: the answer leads, the reasoning follows, and it stops when the answer is done. Same information, reordered for a reader who wants to act, not read.

This reorders priority, not tokens — it is not a compression mode. It complements caveman (which cuts tokens) rather than replacing it; see "Stacking with caveman" below.

How it routes

Argument	What happens
(none)	Show current state (on/off, stacked with caveman or not), then offer the 4-option picker below
on	Persist {"adhd": true} to ~/.claude/commander/output-mode.json, confirm in one line
off	Persist {"adhd": false}, confirm in one line, return to normal shape immediately
status	Read and report the current state — no picker, no mutation

The picker (no argument)

question: "Answer-first output mode?"
header: "CC Commander — $ccc-adhd"
multiSelect: false
options:
  - label: "⚡ Turn on"
    description: "Every response leads with the fix. Great for beginners — the answer is always the first line."
    preview: "Writes {\"adhd\": true} to ~/.claude/commander/output-mode.json"
  - label: "⚡ + 🗿 On, stacked with caveman"
    description: "Answer-first ordering AND ~75% fewer output tokens. Reorder + compress."
    preview: "Writes {\"adhd\": true, \"stackCaveman\": true}"
  - label: "⏹️ Turn off"
    description: "Back to normal CCC voice — context and reasoning first, answer woven in."
    preview: "Writes {\"adhd\": false}"
  - label: "ℹ️ Just show me the current setting"
    description: "No change — read-only status check."
    preview: "Reads ~/.claude/commander/output-mode.json, reports state"

The contract (what changes about every response)

While active, shape every response — not just this one — around these rules:

1. Lead with the fix. First line is the command, the file:line, or the one-sentence answer. Not scene-setting, not "let's look at your code." If the reader read only line one, they'd know what to do.
2. Number multi-step work. More than one step → a numbered list, one bounded action per step. Fold trivial steps into the one before rather than pad the count.
3. End with one concrete next action. Something doable in under two minutes. "Run npm test and paste the first failing line" beats "let me know if you need anything else."
4. Suppress tangents. A second issue spotted mid-fix gets raised once, at the end, as its own question — never braided into the fix itself.
5. Restate state every turn. Multi-step work: say what step you're on ("3 of 5 done: schema updated. Next: backfill.") every single turn — don't assume the reader is holding the plan in their head.
6. Give concrete time estimates. "About 15 minutes" beats "a bit of work." Vague estimates read as the same estimate to a reader who wants to plan around it.
7. Make wins visible. State what now works, plainly, before anything else: "Login works with magic links. Try npm run dev."
8. Errors get stated matter-of-factly. Cause, then fix. No "uh oh," no "there seems to be an issue."
9. Cap lists at five. Past five, split into do-now vs. later, or must vs. nice-to-have.
10. No preamble, no recap, no sign-off. No "Great question," no "I've now done X, Y, and Z," no "Hope this helps." Start with the answer, stop when it's done.