Claude Code や Codex などの AI コーディングエージェントを日常的に使っていると、「Great question!」「Let me think about this...」といった前置きから始まり、背景説明が長々と続いた末に、ようやく実行するべきコマンドが出てくる、という応答に疲れを感じたことはないでしょうか。作業の勢いを保ったまま次の一歩を踏み出したいのに、応答の冒頭を読み飛ばして「結論はどこにあるのか」を探す時間が積み重なっていきます。
こうした「回答を埋めてしまう」出力の癖は、モデル側のデフォルト応答スタイルに起因する部分が大きく、プロンプト側で毎回細かく指示するのは現実的ではありません。プロジェクトごとに「短く」「番号付きで」「次のアクションから始めて」と書き足すのは手間ですし、複数のエージェントを併用していると、それぞれで異なる指示を維持することになります。
そこで注目されているのが、Ayoub G. 氏が公開している OSS「i-have-adhd」です。名称に「ADHD」を冠しているものの、これは医学的診断を持つ人向けのツールではなく、「冗長な AI 応答が苦手なすべての読み手」を対象に、応答形式そのものを「行動優先」へ整形するための Skill/Plugin として設計されています。
本記事では公式ドキュメント（README・SKILL.md・INSTALL.md）と GitHub API から取得した公開メタデータに基づき、i-have-adhd の設計思想と 10 のルール、Claude Code / Codex / Zed / Gemini / Hermes への導入手順、公式 output-style や類似 OSS との違い、そしてどのようなプロジェクトで採用が適しているかまでを整理します。動作検証やスクリーンショット取得は行わず、あくまで公開情報に基づく解説である旨をあらかじめお断りしておきます。
i-have-adhdとは
i-have-adhd は、Claude Code などの AI コーディングエージェントが「回答を埋めてしまう（bury the answer）」ことを止めるための Skill/Plugin OSS です。作者は Ayoub G. 氏で、リポジトリは ayghri/i-have-adhd で公開されています。ライセンスは MIT、GitHub 上のスター数は 14,326、フォーク数は 764、最終更新は 2026 年 7 月 31 日と、執筆時点でアクティブに開発が続いているリポジトリです（GitHub API /repos/ayghri/i-have-adhd のレスポンスに基づく。以下、リポジトリメタ値は同一時点の値）。属性としてはアーカイブ済み（archived）でも他リポジトリのフォーク（fork）でもなく、archived=false / fork=false の独立したプロジェクトです。
README では「A skill for your coding assistant that stops it from burying the answer. Action first. Steps numbered. No 'Hope this helps!'」と説明されており、「最初にアクション」「複数手順は番号付き」「『お役に立てば幸いです』のような締め語なし」の 3 点が全体を貫くコンセプトです。ADHD という名称は「短期記憶が小さく、開始摩擦に弱く、達成の可視化を必要とする読み手」の認知特性を出力設計に反映していることを示しており、README でも「診断を持っているかどうかは問わない」ことが明示されています。
対応する開発環境は Claude Code だけにとどまらず、Codex、Zed、Gemini、Hermes、Cursor、そして Anthropic 社が展開している Agent 系ツールに向けた配布ファイルまでを同一リポジトリに同梱しています。単一のプロンプト定義（SKILL.md）を中核に据え、各ホストの規約に合わせて配布形式を分けている構成のため、同じ「行動優先」の応答スタイルを複数のエージェントに揃えて適用できるのが大きな特徴です。
Before / After で見る出力の変化
i-have-adhd を適用する前と後で、AI コーディングエージェントの応答がどう変わるのかは、README の冒頭に対比例として示されています（出典: README.md）。
適用前の応答は、典型的には「Great question!」や「Let me think about this...」のような前置きから始まり、続いて背景や設計判断に関する説明、いくつかの仮定の提示、そして最後に「Hope this helps!」で締める、という構成になりがちです。読み手が実際にキーボードに手を戻して作業を再開するまでには、応答の 3〜4 割を読み飛ばして「実行するべき手順」を探す必要があります。
適用後の応答は、これが反転します。最初の 1 行が、読み手が今すぐ実行できるコマンドやスニペット、または「これを 1 行目に貼り付けてください」といった具体的な指示になります。複数手順は必ず番号付きリストで、各ステップが「1 つの境界のある行動」として書かれ、末尾には「次に 2 分以内にできる 1 つのアクション」が示されます。読み手は応答を上から順に実行するだけで作業が進み、途中で「結論はどこか」を探す認知コストが発生しません。
このスタイル変換を明文化しているのが、次の章で紹介する「10 のルール」です。
10のルールと背後の設計思想
i-have-adhd の中核は、リポジトリ内の skills/i-have-adhd/SKILL.md に定義された 10 のルールです。ただし、ルールそのものを丸暗記するのが目的ではなく、その背後にある「なぜ冗長な応答が読み手を止めてしまうのか」という認知モデルを理解することが、採用判断や自分向けのカスタマイズを行ううえで重要です。
なお、以下ではルールを SKILL.md 原文の番号（1〜10） のまま提示します。読みやすさのために「体験を変える 5 つ」「送信前に自動で削る 5 つ」の 2 群に分けていますが、各項目に付した番号は原文と一致しており、公式ドキュメントと突き合わせながら読み進められます。番号の連番性より、原文との対応の正確さを優先しています。
前提となる読み手モデル
SKILL.md の冒頭「What ADHD changes about reading」節では、応答を書く側が想定するべき読み手モデルが整理されています。要点は次の 5 つです。
- 短期記憶が小さいため、画面外に流れた内容は忘れる前提で書く
- 「理解できた」と「実行できた」の間には摩擦があり、この摩擦が最大の敵となる
- 開始が最も難しいため、最初の一歩は明確・小さく・今すぐ可能な形にする
- 「少し」「数時間」のような曖昧な時間感覚は記憶に登録されにくい
- ドーパミンが希少なため、完了と成果の可視化が動機維持に必須である
ここで示されている「読み手」は必ずしも医学的な ADHD 診断を持つ人ではなく、「同時に複数の課題を抱え、集中力が奪われがちな現代の開発者」全般を含む広い定義です。この前提を踏まえたうえで、10 のルールを 2 群に分けて眺めると、設計者の意図がつかみやすくなります。
体験を大きく変える 5 つのルール
- 1. Lead with the next action — 最初の 1 行は、読み手が今すぐ実行できる行動・コマンド・スニペットにする
- 2. Number multi-step tasks — 複数手順は番号付きリストで、各ステップは「1 つの境界のある行動」に絞る
- 3. End with one concrete next action — 完了しない場合でも、末尾に「2 分以内でできる 1 つの次の行動」を置く
- 5. Restate state every turn — 「今 5 ステップ中 3 完了」など、現在の状態を毎ターン再宣言する
- 6. Give specific time estimates — 「少し」「数時間」ではなく、分・時間単位の具体値で見積もる
この 5 つは応答の「骨組み」に関わり、適用の前後で読み手の体感が最も変わるルールです。
送信前に自動で削るべき 5 つのルール
- 4. Suppress tangents — 派生的な別課題は、現在の課題を終わらせてから別途出す
- 7. Make completed work visible — 何が今動くようになったのかを具体的に示す
- 8. Matter-of-fact tone for errors — "Uh oh" のような感情表現を避け、エラー箇所・原因・修正手順を淡々と提示する
- 9. Cap lists at 5 items — リストは 5 項目までとし、超える場合は「今やる / 後で」「必須 / 推奨」で分割する
- 10. No preamble, no recap, no closing pleasantries — "Great question" "Let me..." "Hope this helps" のような前置き・要約・締め語はすべて禁止
SKILL.md には送信前チェックリスト（Pre-send check）が明文で定義されており、「冒頭『これから何をするか』を告げる文の削除」「末尾『他に何かありますか？』の質問文と直前の作業サマリの削除」「『ところで』で始まる余談の削除」「情報量のないヘッジ表現（perhaps / might など）の削除」「circle back などの慣用句を文字通りの行動表現に置換」といった具体的な削除操作が並びます。
ルールを破ってよい 6 つの例外
すべての応答から前置きと締め語を機械的に削るだけでは、読み手にとって逆に不親切になる場面があります。SKILL.md はその点を織り込んでおり、以下の 6 つの状況では上記ルールを部分的に破ることを認めています。
- 「説明して」「walk me through」と依頼された場合: 十分に長く説明してよい（ただし前置き・締め語は禁止）
- 破壊的操作（
rm -rf、force push、schema migration など）: 実行前に確認を挟む - デバッグスパイラル（3 回連続で失敗）: 前提を疑い、1 つの診断質問を返す
- 依頼が曖昧な場合: 1 つだけ短い確認質問を返す
- ルールに従うと答えそのものが消える場合: タスクを優先しつつ形式は維持する
- Agent harness 側の制約: システムプロンプトの指示が優先される
「学習にも壊滅的ではない」設計になっている点は、後述の採用判断の章で改めて触れます。
導入手順（Claude Code / Codex / Zed / Gemini / Hermes）
i-have-adhd のインストール手順は、対応ホストごとに INSTALL.md にまとめられています。本節では代表的な 5 環境について、公式ドキュメントの手順をそのまま引用します（コマンドはいずれも INSTALL.md からの抜粋で、改変はしていません。出典 URL は各サブセクションに明記します）。Cursor、Antigravity 向けの配布ファイルもリポジトリに同梱されており、詳細は同ドキュメントを参照してください。
Claude Code へのインストール
Claude Code では、標準の plugin marketplace 経由でインストールし、/i-have-adhd で呼び出します。
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd
（出典: INSTALL.md）
/i-have-adhd はセッションごとに手動で起動する使い方で、常に有効化しておきたい場合は、後述の常時 ON 化の章で扱うフラグファイル方式を利用します。
Codex へのインストール
Codex 版は plugin marketplace への追加時に --ref main の指定が必要で、呼び出しは $i-have-adhd になります。
codex plugin marketplace add ayghri/i-have-adhd --ref main
codex plugin add i-have-adhd@i-have-adhd
（出典: INSTALL.md）
Zed へのインストール
Zed の場合はコマンドラインではなく、Agent Panel の Skills manager から SKILL.md の URL を貼り付ける方式が推奨されています。ローカルの ~/.config/zed/skills/ 配下に SKILL.md を配置する方法も利用できます。詳細な UI 上の手順は INSTALL.md の Zed 節を参照してください。
Gemini CLI へのインストール
Gemini CLI にはプラグインマーケットプレイスの仕組みがないため、INSTALL.md では 2 通りのネイティブルートが併記されています。「常にルールを効かせたい」ケースと「セッションごとに opt-in で呼び出したい」ケースで使い分ける想定です。
拡張機能ルート（常時適用・主推奨）
リポジトリ直下の GEMINI.md が SKILL.md 全体をインポートする構成になっており、拡張機能としてインストールするとメッセージ 1 通目からルールが有効化されます。事前に git コマンドが利用できる環境が必要です。
gemini extensions install https://github.com/ayghri/i-have-adhd
コマンドルート（セッション限定・opt-in）
呼び出さない限り作動しない、SKILL の標準的な挙動に合わせた導入方法です。~/.gemini/commands/i-have-adhd.toml を取得したうえで、セッション内で /i-have-adhd と入力するとそのセッションのみルールが適用されます。
mkdir -p ~/.gemini/commands
curl -fsSL https://raw.githubusercontent.com/ayghri/i-have-adhd/main/skills/i-have-adhd/agents/gemini.toml \
-o ~/.gemini/commands/i-have-adhd.toml
（出典: INSTALL.md）
Hermes へのインストール
Hermes ではワンライナーの CLI コマンドで導入できます。
hermes skills install ayghri/i-have-adhd/skills/i-have-adhd
（出典: INSTALL.md）
常時ON化とカスタマイズの安全性
Claude Code で /i-have-adhd を毎回打つのが煩わしい場合、リポジトリ同梱の hooks/always-on.sh を使って、セッション開始時に自動で SKILL.md を注入する仕組みを利用できます。「常時 ON」と聞くと暴発の心配がありますが、実装を見るとむしろ「安全に無効化できる」ことを最優先した設計になっていることが分かります。
フラグファイル方式の常時 ON 化
有効化には、Claude の設定ディレクトリ配下にフラグファイルを 1 つ作成するだけです。
touch ~/.claude/.i-have-adhd-always
（出典: INSTALL.md）
hooks/always-on.sh は SessionStart フック（startup / resume / clear / compact のいずれか）で起動し、$CLAUDE_CONFIG_DIR/.i-have-adhd-always（デフォルトでは ~/.claude 配下）が存在する場合のみ SKILL.md 本文を注入します。フックの実装は Pure POSIX sh で書かれており、Node 等の別ランタイムに依存しません。YAML frontmatter は除去したうえで本文だけを流し込む処理になっており、フラグファイルが存在しなければ何もせず exit 0 で終了するため、セッション起動を止める副作用がありません。
無効化の手順
常時 ON を外したいときは、フラグファイルを削除するか、セッション内で「stop adhd mode」と指示するか、または Claude Code のプラグイン管理コマンドで plugin 自体を無効化するかのいずれかを選べます。フラグファイル方式が最もライトで、rm ~/.claude/.i-have-adhd-always を実行するだけで次のセッションから元の応答スタイルに戻ります。
フォークして自分用にチューニングする
「10 のルールは大枠として気に入っているが、社内プロジェクトでは番号付きリストの見出しを変えたい」「送信前チェックリストに独自項目を加えたい」といったチューニング要求がある場合、README の "Tune it" セクションでは「フォークして SKILL.md を書き換える」運用が推奨されています。フォーク先のリポジトリを marketplace に追加すれば、そのままチーム内配布に使えます。ライセンスが MIT のため、社内向けフォークや改変版の配布に法的な障害は少ないと考えられますが、実際の利用にあたっては各社の OSS 利用ポリシーに従って判断してください。
類似OSS・公式output-styleとの違い
「Claude Code の応答スタイルを変える」という目的の OSS は他にも存在します。採用判断のために、代表的な 2 つの選択肢と i-have-adhd を並べて眺めておきます。
Anthropic 公式の output-style プラグイン
Anthropic 社は Claude Code 本体のリポジトリ内で、公式の output-style プラグインをいくつか公開しています（anthropics/claude-code/plugins）。代表的なものに learning-output-style（ユーザーが要所でコードを書く「学習モード」）と explanatory-output-style（実装選択に関する教育的な補足を出す「解説モード」）があります。
これらは i-have-adhd と目的が正反対で、「時間をかけて理解を深める」ことを支援するスタイルです。分量としては詳細な説明を促す方向であり、対応ホストも Claude Code 公式にとどまります。学習フェーズ・研修フェーズでは公式 output-style が有効で、実行フェーズでは i-have-adhd が有効、という使い分けが自然な選択になります。
hesreallyhim/awesome-claude-code-output-styles キュレーション集
コミュニティ発のキュレーション集として、awesome-claude-code-output-styles-that-i-really-like があり、Zen Master / Tabloid Journalist / Haiku Helper / Existentialist Poet / Vim Salesman といった「キャラクター変換系」のスタイルが多数収録されています。minimal スタイルもこのキュレーション経由で紹介されています。
これらの多くは「エンタメ・トーン変更」を主目的としており、生産性向上を主目的とする i-have-adhd とは焦点が異なります。実装形態も単一の output-style 定義がベースで、i-have-adhd のような「Skill + フック + 評価ケース + マルチホスト対応」を 1 つのプラグイン一式として提供する形にはなっていません。
立ち位置の整理
Claude Code 本体はデフォルトでも「conciseness（簡潔さ）」を重視する設計方針を持っていますが、実際の応答では前置きや締め語が残ることが多く、i-have-adhd はその上位ラッパーとして「行動優先」まで押し込む立ち位置にあります。単一のスタイル切り替えではなく、常時 ON 化のフックや評価ケースまでを含めた一体型プロジェクトである点が、他の類似 OSS との最大の差分と言えます。
採用判断（どのようなプロジェクト・チームで使うと効果的か）
前節までの整理を踏まえて、「自分のプロジェクトで採用すべきか」を判断するための切り口をいくつか示します。
- 一人開発 / 個人プロジェクト: 効果を感じやすい代表ケース。Claude Code に「実装 → 修正 → 実行」を繰り返し依頼する使い方では、応答冒頭の前置きが積み重なると集中力を削がれます。常時 ON 化しておくと、応答スタイルを毎回指示する認知コストが不要になります。
- チーム開発 / 社内プロジェクト: SKILL.md の内容がプロジェクトメンバー間で共有されるため、応答スタイルの均質化に役立ちます。ただし、コードレビューや設計議論の場面では、公式の explanatory-output-style や独自の解説向けプロファイルとの併用が現実的です。
- 学習・教育コンテンツ制作: 向きません。i-have-adhd は削ることを是とする設計のため、教材制作や学習ノートの生成に使うと必要な文脈まで削られる恐れがあります。この用途では公式 learning-output-style や無適用の状態が適切です。
- マルチエージェント環境（Claude Code + Codex + Zed の併用など）: 対応ホストの広さが効いてきます。同一の SKILL.md をベースに複数エージェントの応答スタイルを揃えられるため、ツールを切り替えるたびに応答傾向が変わって集中を削がれる、という状況を減らせます。
i-have-adhd 側にも「ルールを破ってよい 6 つの例外」が組み込まれており、「説明してほしい」と明示的に依頼すれば十分に長く説明が返り、破壊的操作の前には確認を挟む、といった安全弁が用意されています。評価ケース（evals/）にも "explanation" や "safety" のカテゴリが用意され、これらの例外挙動が回帰しないように検証されている点は、学習寄りの使い方でも「壊滅的ではない」設計を担保しています。
メンテナンス状況・ライセンス・健全性
OSS を採用するときに最も気になるのは「メンテナンスが止まっていないか」「ライセンス上の制約はどうか」「品質検証は行われているか」の 3 点です。i-have-adhd について、公開データで確認できる情報を整理します。
- スター数: 14,326（GitHub API
/repos/ayghri/i-have-adhdレスポンスに基づく） - フォーク数: 764（同上）
- ライセンス: MIT（同上）
- 最終更新（
pushed_at）: 2026 年 7 月 31 日（同上、執筆時点） - 属性:
archived=false/fork=false/disabled=false/visibility=public（同上） - 主要言語（GitHub 判定）: Python（同上。ただしリポジトリ内のファイル構成は Markdown と Shell が中心で、Python は評価ケースのランナーで用いられています）
さらに、リポジトリ直下の evals/ には評価用の rubric（evals/rubric.md）と cases.jsonl が同梱されており、単なるプロンプト集ではなく、応答品質を継続的に検証する仕組みが備わっている点は健全性シグナルとして評価できます。rubric は Correctness（35%）/ Autonomy（25%）/ Actionability（20%）/ Safety（10%）/ Concision（10%）の 5 次元で構成され、リリース基準として「blocking findings ゼロ」「Correctness と Safety がベースライン ±0.1 以内」「総合重み付けスコアがベースラインより高い」「競合クレームは同じケース・モデル・試行回数・rubric で比較する」の 4 条件が明文化されています。
参考として、2026 年 5 月に作成された比較的新しいリポジトリでありながら、2026 年 7 月 22 日に GitHub Trending で #3 に達しており（trendshift.io/repositories/30905）、日本語圏でも Zenn や個人ブログでのレビュー記事が確認できるなど、コミュニティでの採用が広がりつつある段階です。ライセンス（MIT）とアクティブな更新頻度、そして評価フレームワークの同梱を合わせて考えると、社内での試験導入から始めるうえでのリスクは比較的低いと判断できます。
まとめ
i-have-adhd は、Claude Code などの AI コーディングエージェントの応答から前置き・要約・締め語を削り、「行動優先」の応答スタイルへ整形する MIT ライセンスの Skill/Plugin OSS です。核となる 10 のルールは、短期記憶・開始摩擦・時間感覚・ドーパミンといった読み手側の認知モデルに紐付いており、単なる文体変換ではなく設計思想として一貫しています。
対応ホストは Claude Code / Codex / Zed / Gemini / Hermes / Cursor など複数にまたがり、Pure POSIX sh 実装の SessionStart フックによってフラグファイル 1 つで常時 ON 化・無効化を切り替えられます。評価用の rubric と cases.jsonl が同梱されているため、応答品質の継続検証にも配慮されています。
診断の有無を問わず「冗長な AI 応答が苦手な人」全般に有効で、実行フェーズ中心のプロジェクトでは体感的な効果が大きい一方、学習・教材制作用途では公式 output-style や無適用の状態のほうが適しています。用途に応じて公式 learning-output-style / explanatory-output-style と使い分ける、あるいはフォークして SKILL.md を自分向けにチューニングするといった選択肢を含めて、公式リポジトリの README・SKILL.md・INSTALL.md を確認したうえで、自プロジェクトに合う使い方を検討してみてください。
なお、Claude Code で利用できるスキルを「用途別に横断的に見比べたい」「i-have-adhd 以外にもチームで使えるスキルの候補を知りたい」といった場合には、当ブログの Claude Codeスキルおすすめ厳選 が参考になります。本記事が i-have-adhd という単一スキルの深掘りであるのに対し、同記事は用途別のスキル選定を横断的にガイドする内容で、記事タイプが異なる補完関係にあります。
