Stats
Actions
Tags
'%20stop-opacity%3D'0.16'%2F%3E%3Cstop%20offset%3D'1'%20stop-color%3D'rgb(200%2C90%2C60)'%20stop-opacity%3D'0.03'%2F%3E%3C%2FlinearGradient%3E%3C%2Fdefs%3E%3Crect%20width%3D'320'%20height%3D'200'%20fill%3D'url(%23g)'%2F%3E%3Ccircle%20cx%3D'250'%20cy%3D'56'%20r%3D'92'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.06'%2F%3E%3Ccircle%20cx%3D'64'%20cy%3D'172'%20r%3D'58'%20fill%3D'rgb(200%2C90%2C60)'%20fill-opacity%3D'0.05'%2F%3E%3C%2Fsvg%3E)
From i-have-adhd
Interview the user about the current task before any work starts — convert every doubt into tappable structured-question rounds, echo the agreed spec, then begin. Use when the user says "interview me", asks for clarifying questions, wants a vague prompt refined into a spec, or when a request carries deliverable-changing ambiguity that the always-on style failed to catch.
How this skill is triggered — by the user, by Claude, or both
Slash command
/i-have-adhd:interviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The protocol lives in one place: `output-styles/i-have-adhd.md` at this plugin's root — relative to this SKILL.md file, `../../output-styles/i-have-adhd.md` — under rule 10, "Interview before guessing; end with the spec, not a question".
The protocol lives in one place: output-styles/i-have-adhd.md at this plugin's root — relative to this SKILL.md file, ../../output-styles/i-have-adhd.md — under rule 10, "Interview before guessing; end with the spec, not a question".
Read that rule now and run it as an explicit invocation on the current task (or on the topic passed as arguments, if any). Explicit invocation means the gate fires regardless of how clear the prompt looks, and cosmetic doubts are promoted into the rounds — the user has asked to make the small calls too. Do not paraphrase the protocol from memory — the file is the source of truth.
npx claudepluginhub caioniehues/i-have-adhd --plugin i-have-adhdGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Implements work from a spec or tickets using TDD at agreed seams, with regular typechecking and test runs, followed by code review.