コードを書くAIに相談すると、こちらが知りたい結論より先に、前置きや気遣いが長く続いてしまうことがあります。GitHubに公開された i-have-adhd は、その“回りくどさ”を抑えて、答えを先に出すためのskill/pluginです。名前はかなり挑発的ですが、狙いはふざけたものではありません。読む人の集中を削らない出力に寄せよう、という提案です。AIコーディング支援が当たり前になった今だからこそ、こういう「出し方」の工夫が意外と効いてきます。
i-have-adhd がGitHubで提案していることこのリポジトリは、GitHub CopilotやClaude Codeのようなコーディング用エージェントに「答えを埋め込まず、先に出せ」と教えるためのskill/pluginとして公開されています。トップには「ADHD-friendly outputs. No ADHD diagnosis needed!」とあり、読む側が集中を切らさずに済む出力を目指す、という立て付けです。インストール方法も載っていて、CLIのプロンプトに Install the i-have-adhd skill/plugin from https://github.com/ayghri/i-have-adhd, refer to the repo's AGENTS.md for instructions. と貼り付けるか、インストール手順ページを参照するよう案内しています。
READMEの中核は、AIの返答をどう変えるかの比較です。Before の例では、AIが「Great question! Let me think about this.」のように話し始め、認証フローの説明を回り道しながら、最後に「Hope this helps! Let me know if you want to dig deeper.」と締めています。これに対して After では、最初に Run npm install jsonwebtoken@latest , then edit src/auth.ts:42 . と行動を示し、その後に Open src/auth.ts、Replace verifyToken (lines 42–58) with the snippet below、Run npm test -- auth.spec.ts と、次にやることを番号付きで並べています。もしテストが失敗したら「first failing line」を貼れ、と次の一手まで指定しています。
さらにREADMEには「The rules」として10個のルールが示されます。要点は、次の行動から始めること、複数手順は番号を振ること、最後に必ず具体的な次の一歩を置くこと、余談を抑えること、状態を毎ターン言い直すこと、時間見積もりは「a bit」ではなく分単位で書くこと、成果を見える化すること、エラーは淡々と伝えること、箇条書きは5項目までに抑えること、そして前置き・要約・締めの挨拶を入れないことです。要するに、AIが“親切そうに見える雑談”で重要な情報を隠さないようにする設計です。
このskillはそのまま使うだけでなく、skills/i-have-adhd/SKILL.md をフォークして編集し、自分の環境に差し替えられるとも書かれています。Claude Code向けには、既存のプラグインを外してから自分のforkを入れ直す手順も並んでいます。READMEの最後には、J. Russell RamsayとAnthony L. Rostainの『The Adult ADHD Tool Kit』をゆるく元にした、とありますが、これは人間の生活術をそのまま写したものではなく、LLMの応答設計に合わせて調整したものだと明言しています。
私は、このREADMEがかなり正直だと思いました。AIの出力は、丁寧さを足しすぎると逆に使いにくくなることがある。特にコード修正の場面では、最初の一文で「何をすればいいか」が見えないと、会話の流れを追うだけで疲れます。i-have-adhd が狙っているのは、まさにその疲れです。診断名を借りたタイトルは少し強いですが、実際に言っていることは「答えを隠すな」という単純で実務的な注文です。
ここで面白いのは、これは出力の見栄えを整える話ではないことです。文章をきれいにするのではなく、読む順番を変えています。先に行動、あとで理由。これは人がデバッグするときの思考順序にかなり近い。私は、AIの応答品質は“正しさ”だけでなく“発見しやすさ”で決まると思います。正しい修正案でも、最初に埋もれていたら意味が薄いからです。逆に、最初の一行で方向が見えれば、多少説明が粗くても前に進める。現場ではその差が大きい。
このプロジェクトで気になったのは、「No preamble」「No recap」「No closers」という徹底ぶりです。普通なら冷たく見えるかもしれません。でもコード作業の文脈では、むしろ会話の無駄を減らすための配慮に近い。AIは、ともすれば毎回「Great question!」から始めてしまうし、ユーザーが知りたい一言を後ろに回しがちです。そこを強制的に矯正するのがこのskillの役目でしょう。
ただし、ここには少し注意も必要です。すべての場面で前置きが悪いわけではありません。設計の意図を説明したり、危険な操作を止めたりするときは、前置きが安全装置になることもある。だから私は、このルールセットを万能薬とは見ません。むしろ、反復的な開発作業や軽い修正で効く“作法”に近い。AIに必要なのは常に短文ではなく、状況に応じて説明密度を切り替える柔軟さだと思います。このリポジトリは、そのうちの一つの極をはっきり示している点で価値があります。
GitHubにあるこのリポジトリは、単なるユニークなネタではなく、今後のAI支援の競争軸をよく表しています。モデルの性能だけで差をつけにくくなると、次に効いてくるのは「どう返すか」です。どんな順序で情報を出すか、どこまで一度に言うか、何を省くか。コード生成そのものより、実務ではその周辺の体験が生産性を左右します。i-have-adhd は、そのレイヤーを人間が明示的に調整できることを示しています。
私は、これはかなり大事な流れだと思います。なぜなら、AIを使う現場は一枚岩ではないからです。長文で丁寧に説明してほしい人もいれば、先にコマンドだけ欲しい人もいる。そうした好みの違いを「モデルの性格」として押しつけず、skillとして差し替え可能にしていく方向は、かなり実用的です。しかもGitHub上のREADMEだけでなく、AGENTS.md や各種 plugin 設定、テストまで含めて配布している点がいい。単なるポエムではなく、行動に落とし込める形になっているからです。
タイトルに ADHD が入っているので、特定の当事者向けのツールに見えるかもしれません。けれど実際には、もっと広く「集中が切れやすい場面の出力」を整える道具です。長い説明を追うのが苦手な人、急いでいる人、複数のタスクを往復しながら作業する人には、かなり相性がいいはずです。言い換えると、これはアクセシビリティの話でもあります。
その意味で、私はこのプロジェクトの名前の強さも含めて、わりと良い賭けだと思いました。目を引くし、何を直したいのかが一瞬で伝わる。しかも中身は意外と地味で、やっていることは「順番を守れ」「一度に詰め込みすぎるな」「次の一手を見せろ」というルール化です。派手なAI機能ではないけれど、こういう地味な改善の積み重ねが、結局は使いやすさを決めるのではないでしょうか。モデルが賢いだけでは足りない。賢さを、こちらが読める形に整える層が要る。i-have-adhd はその必要をかなり分かりやすく示しています。