![\"i-have-adhd-plan\"](\"./logo.png\"){kind=logo}
\n\n \n
\n ADHD-friendly planning for agents and developers\n
\n\n ![\"License\"](\"https://img.shields.io/github/license/BnJam/i-have-adhd-plan?style=flat\")
\n 🇬🇧 ·\n 🇨🇳 ·\n 🇧🇷 ·\n 🇯🇵 ·\n 🇻🇳 ·\n 🇰🇷 ·\n 🇹🇭\n
\n\n\n## Install\n\nCopy/paste into your CLI prompt:\n\n```text\nInstall the `i-have-adhd-plan` skill/plugin from this repository: https://github.com/BnJam/i-have-adhd-plan. Refer to `AGENTS.md` for repository instructions.\n```\n\nOr 🔗 [check the installation instructions](INSTALL.md).\n\nIf Claude says `Marketplace 'i-have-adhd-plan' already on disk`, remove the stale\nmarketplace registration by its configured name, then add this repository:\n\n```bash\nclaude plugin marketplace remove i-have-adhd-plan\nclaude plugin marketplace add BnJam/i-have-adhd-plan\nclaude plugin install i-have-adhd-plan@i-have-adhd-plan\n```\n\nThis removes the marketplace entry only; it does not uninstall the original\n`i-have-adhd` plugin.\n\n## What it does\n\n`i-have-adhd-plan` is the planning-focused adaptation for agents and ADHD\ndevelopers. It helps an agent turn a request into a short, executable plan,\nkeep the current state visible, and maintain momentum during implementation.\n\nThis repository does not replace the original [`i-have-adhd` plugin or skill](https://github.com/ayghri/i-have-adhd).\nThat project provides the general ADHD-friendly response style. This project\nbuilds on the same principles for the planning mode of agents: define the\ngoal, break work into bounded actions, identify dependencies and verification,\nand stop at the next meaningful decision boundary.\n\nDuring authorized implementation, it also keeps a visible\n`Done / Current / Blocker / Next` checkpoint loop. No \"Hope this helps!\"\n\n## Who it is for\n\n- Developers who want agent plans that are easier to start and finish.\n- Agents that need compact, stateful planning and execution checkpoints.\n- Teams adapting ADHD-friendly interaction patterns to planning workflows.\n\nIt is an accessibility style, not a diagnosis or treatment claim. It can be\nused by anyone who benefits from lower-friction plans and visible progress.\n\n\n## What changes\n\nThe adaptation changes how an agent plans and carries work forward. It turns a\nlarge request into a bounded goal, keeps verification beside the relevant\nstep, and makes the next action explicit.\n\n\n| \n\n## Before: vague implementation guidance\n\n> Your auth change has several moving pieces: routes, middleware, token\n> verification, cookies, and tests. You could update the package and rewrite\n> the verification function, then run the tests. There may also be other\n> dependency updates to consider.\n\n | \n\n\n\n## After: an executable agent plan\n\n> Goal: Update token verification while keeping existing login behavior working.\n>\n> 1. Open `src/auth.ts`\n> 2. Inspect `verifyToken` and its callers; record the compatibility requirements.\n> 3. Update the implementation and add focused regression coverage.\n> 4. Run `npm test -- auth.spec.ts`; stop if the contract changes unexpectedly.\n>\n> Next: inspect `src/auth.ts` and identify the current token-verification contract.\n\n | \n