判断の分かれ目は「常時オンにするか、呼んだときだけ効かせるか」に尽きます。i-have-adhdは、Claude CodeやCodexといったコーディングエージェントの返答から前置き・要約・締めの挨拶を削り、最初の1行を「次にやる操作」にするためのAgent Skillです。インストールしただけでは何も変わらず、/i-have-adhdと打った瞬間からセッション終了まで効き続ける——この「既定オフ・明示オン」の設計を理解しているかどうかで、体験がまるごと変わります。
2026年9月18日時点で、リポジトリayghri/i-have-adhdのスター数はGitHub API上で47,468、フォーク2,765。公開は2026年5月13日、最終更新は2026年9月16日です。Trendshiftの集計によれば2026年9月8日にGitHub Trendingの首位に到達し、2026年第37週の「Repository Of The Week」1位も獲得しています。ライセンスはMIT、作者表記は「Ayoub G.」です。
先に答え:i-have-adhdは結局どういうスキルか

- 正体:10個の出力ルールを書いたMarkdown 1枚(
skills/i-have-adhd/SKILL.md)。プログラムではなく指示文です。 - 効果:「Great question!」「Hope this helps!」の類を禁止し、コマンド・ファイルパス・スニペットを先頭に出させる。手順は番号付き、進捗は毎ターン言い直し、リスト表示は5件までに抑える。
- 起動:Claude Codeは
/i-have-adhd、Codexは$i-have-adhd。フロントマターにdisable-model-invocation: trueがあるため、モデルが勝手に呼ぶことはありません。 - 解除:会話中に「stop adhd mode」または「normal mode」と伝えるだけ。
- 向き:複数ステップ作業の進捗報告とエラー報告。不向き:出力形式が決まっている作業(コードだけ返す、長文を書く)。リポジトリ同梱の評価データでも、この2種類はスコアが動きませんでした。
- 対応先:INSTALL.mdにはClaude Code・Codex・Grok・Gemini CLI・GitHub Copilot・Zed・Cursorなど15系統の手順が並んでいます。
出力はどう変わるのか

READMEに載っている対比例が、このスキルの主張をいちばん短く説明しています。素の状態では、認証フローの説明が延々と続いた末に「src/auth.tsの42〜58行目あたりが古いjsonwebtoken APIを使っているようです」という肝心の指摘が段落の中ほどに埋まり、最後は「Hope this helps! もっと掘り下げたければ言ってください」で終わります。読者は答えを探すために自分の目でスクロールし直すことになります。
スキルを効かせた側は、こうなります。
Run `npm install jsonwebtoken@latest`, then edit `src/auth.ts:42`.
1. Open `src/auth.ts`
2. Replace `verifyToken` (lines 42–58) with the snippet below
3. Run `npm test -- auth.spec.ts`
Next: paste the first failing line if any test fails.
情報量はほぼ同じで、並び順だけが違います。1行目が操作、中段が番号付き手順、最終行が「次の一手」。SKILL.mdの末尾には「送信前チェック」が置かれていて、読者が最初の1行と最後の1行だけを読んだとき、(a)次に何をするか (b)いま何が終わったか、が分かるかを確認してから返せ、と指示されています。この2点だけが合格条件です。
なお、日本語でAIの文章の癖そのものを矯正するアプローチとしては、航空整備の文書規格を持ち込んだ事例も出ています。考え方の比較にはASD-STE100とは?AIの文章癖を航空規格で直すAgent Skill解説が参考になります。
10のルールと、その裏にある5つの前提

ルールの前に、SKILL.mdは「ADHDの読者にとって読むこととはどういうことか」を5点に絞って書いています。①ワーキングメモリが小さく、画面に出ていない情報は消える ②答えを知ることと実行することは別で、その間で作業が死ぬ ③いちばん難しいのは着手 ④時間見積もりは粒度が潰れて「ちょっと」も「数時間」も同じに感じる ⑤ドーパミンが足りず、埋もれた成果は認識されない。10のルールはすべて、この5点から機械的に導かれています。
| # | ルール | 実際に何が禁止されるか |
|---|---|---|
| 1 | 次の行動から始める | 1行目に文脈・計画を置くこと。コマンド/パス/スニペットが先頭 |
| 2 | 複数ステップは番号付き | 「開いて、探して、入れ替えて、テストして」の一文詰め込み |
| 3 | 具体的な次の一手で終える | 「気軽に聞いてください」で終わること。2分以内に実行できる1つを指定 |
| 4 | 脱線を抑える | 「ところで依存関係も古いです」と本題の途中で別件を足すこと |
| 5 | 毎ターン状態を言い直す | 「完了しました。次に進みますか?」(何の何番目か不明) |
| 6 | 時間見積もりは具体単位 | 「少し作業が必要です」。「テストが揃っていれば15分」と書く |
| 7 | できたことを見える形に | 成果を長い振り返りの中に埋めること |
| 8 | エラーは淡々と | 「うわ、失敗しました」「問題があるようです」。位置・原因・修正を並べる |
| 9 | リストは5件まで | 関連項目をまとめず10件並べること(表示の話であり、分析を削る指示ではない) |
| 10 | 前置き・要約・締めなし | 「Great question」「Let me」「Sure!」「Hope this helps」 |
ルール9には但し書きがあり、「これは提示の形だけを縛るもので、分析・検索・ツール結果・候補生成・保持情報を制限してはならない」と明記されています。5件に切り詰めるのは画面に出す分だけで、内部では全部持っておけ、という設計です。ここを読み落とすと「調査が浅くなるスキル」と誤解しがちですが、原文はむしろ逆を要求しています。
ルールを破ってよい6つの例外
SKILL.mdには例外条項があり、これがスキルの実用性を決めています。①「説明して」「順を追って教えて」と頼まれたら本文は必要なだけ長く書く(前置きと締めは依然禁止、代わりに見出しを付ける) ②rm -rf・force push・スキーマ移行など破壊的操作の前は確認を優先 ③同じ不具合で3ターン連続「まだ直らない」なら、コードをいじるのをやめて疑わしい前提を名指しし、診断用の質問を1つする ④本当に曖昧なら短い確認質問を1つ ⑤ルールが答えそのものを消すなら課題が優先(「選択肢は?」には2〜4個をランク付きで返す) ⑥ハーネスの仕様が優先(システムプロンプトがツール呼び出しの宣言を求めるならそれに従う)。
Claude Codeへの導入は2コマンド

マーケットプレイスを登録してから、そこからプラグインを入れる二段構えです。
# マーケットプレイス登録 → インストール
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd
# 確認
claude plugin list
入れ終えたら、セッション内で/i-have-adhdと打ちます。プラグイン索引は起動時に読まれるため、補完候補に出ない場合はエージェントを再起動してください。更新はclaude plugin marketplace update i-have-adhd、削除はclaude plugin uninstall i-have-adhdとclaude plugin marketplace remove i-have-adhdの2本です。入れたまま止めたいだけならclaude plugin disable i-have-adhdで足ります。
プラグインという配布単位そのものが2026年に標準化されてきた経緯は、Agent Pluginsとは|Claude SkillsとMCPを統一する標準で整理しています。
中身は拍子抜けするほど素朴です。Claude Code側のマニフェスト(.claude-plugin/plugin.json)はバージョン0.3.0の数行で、実体は7KB程度のSKILL.mdと、後述するSessionStartフック1本だけ。そのSKILL.md冒頭のフロントマター(ファイル先頭と末尾をハイフン3つの区切り行で挟んだYAMLブロック)には、次のフィールドが並んでいます。
name: i-have-adhd
description: 'Shape output for a reader with ADHD: lead with the next action, ...'
disable-model-invocation: true
license: MIT
metadata:
tags: "ADHD, Output Style, Productivity, Formatting"
category: "productivity"
disable-model-invocationはClaude Code公式ドキュメントに記載された正規のフィールドで、trueにするとClaudeが自動でスキルを読み込まなくなり、ユーザーが/スキル名で呼んだときだけ有効になります。説明文すら常時コンテキストに載らないため、「入れておくだけならトークンを食わない」という性質はここから来ています。
常時オンにする2つの経路

毎回/i-have-adhdと打つのが面倒なら、経路は2つあります。
経路A:フラグファイル(Claude Code)
# 常時オンにする
touch ~/.claude/.i-have-adhd-always
# 設定ディレクトリを変えている場合
touch "$CLAUDE_CONFIG_DIR/.i-have-adhd-always"
# 都度呼び出しに戻す
rm ~/.claude/.i-have-adhd-always
仕組みはリポジトリのhooks/hooks.jsonを読むと分かります。SessionStartイベントにstartup|resume|clear|compactのマッチャで1本だけフックが登録されていて、Node製のalways-on.mjsを起動します。このスクリプトはまずフラグファイルの存在を確認し、無ければ即座に終了。あればSKILL.mdからフロントマターを剥がした本文を標準出力に流し込み、「ADHD MODE ACTIVE (always-on)」の1行を添えます。try/catchで囲まれていて、何が起きてもセッション開始を止めない作りです。つまりプラグインを入れただけでは挙動は1ミリも変わりません。
SessionStartをはじめとするフックの発火タイミングを整理しておくと、この種の常時オン設定を自作するときに応用が効きます。実例はClaude Code Hooks通知設定|macOS・Win・Slackにまとめています。
経路B:メモリファイルに10行貼る
フックを使わず、CodexやGrokなど他のランタイムでも同じことをするなら、INSTALL.mdが用意している短縮版ルールブロックを~/.codex/AGENTS.mdや~/.grok/AGENTS.mdに貼ります。10ルールを各1行に圧縮したもので、末尾に例外条項が1文だけ付きます。
## Output style
The reader has ADHD. Shape every response so it can be acted on:
1. Lead with the answer or next action: command, path, or snippet first.
2. Number multi-step work; one bounded action per step.
3. End with one next action doable in under two minutes.
4. Finish the current issue before raising a new one.
5. Restate progress each turn ("step 3 of 5 done").
6. Give time estimates in concrete units, never "a bit".
7. After a change, show what now works.
8. Errors: state location, cause, and fix. No drama.
9. Cap lists to 5 items.
10. No preamble, no recaps, no closers.
Exceptions: explain fully when asked to explain. Confirm before destructive
actions. After three failed fixes, stop and name the doubtful assumption.
If the request is ambiguous, ask one short question.
フルのSKILL.mdは7,200バイト強、この短縮版は1,000バイト程度。常時コンテキストに置く以上、後者のほうが負荷は軽い一方、例外条項の細かい条件(選択肢を聞かれたときの扱い、ハーネス優先の原則)は落ちます。
Codexとその他のランタイムでの効き方
INSTALL.mdのCodex手順は次の2コマンドです(Anthropicの公式ドキュメントではなく、リポジトリ側の記載に基づきます)。
codex plugin marketplace add ayghri/i-have-adhd --ref main
codex plugin add i-have-adhd@i-have-adhd
# 呼び出しは $ 記号
$i-have-adhd
Codexでも自動発動はしません。根拠はskills/i-have-adhd/agents/openai.yamlにあるpolicy.allow_implicit_invocation: falseで、Claude Code側のdisable-model-invocation: trueと同じ役割を果たしています。リポジトリはこの姿勢を「入れてあっても、あなたが点けていないなら消えている。中間はない」と表現しています。
その他の対応状況は、大きく3つに分かれます。
| 種別 | ランタイム | 導入形態 |
|---|---|---|
| プラグイン導入 | Claude Code / Codex / Grok / Antigravity | CLIのマーケットプレイス経由。明示呼び出しが前提 |
| 拡張・コマンド | Gemini CLI / OpenCode / Pi / Oh My Pi / Qwen Code / Kimi Code CLI / Zed | 拡張は常時オン、コマンドは都度呼び出しと二択の場合あり |
| SKILL.md直置き | Cursor / Amp / AstronClaw などagent-skills互換 | ~/.cursor/skills/等にフォルダごと配置 |
Grokだけは癖があり、grok plugin install ayghri/i-have-adhd --trustで信頼を付けたうえでgrok plugin enable i-have-adhdを実行しないと、フックもスキルも動きません。INSTALL.mdのトラブルシュートにも同じ注意が繰り返し書かれています。
公式の「Concise」出力スタイルと何が違うか
ここが選定の実質的な分岐点です。Claude Codeにはv2.1.237以降、組み込みの出力スタイルConciseがあり、公式ドキュメントは「結果から始め、前置きと実況を省き、既定では短く返す。ただしエンジニアリング作業の徹底度はDefaultと同じ」と説明しています。エラー報告・セキュリティ警告・破壊的操作の確認だけは必ず全文を保つとも書かれています。つまり「短くする」目的だけなら、何も入れずに/output-style conciseと打てば済みます。
| 観点 | 組み込みConcise | i-have-adhd | CLAUDE.mdに直書き |
|---|---|---|---|
| 導入コスト | ゼロ(コマンド1つ) | 2コマンド+再起動 | コピペのみ |
| 効く範囲 | 既定の指示そのものを差し替え | 呼んだセッション中だけ上乗せ | 常時、全プロジェクト |
| 状態の再提示(第3者が最も効く場面) | 規定なし | ルール5で毎ターン必須 | 書けば可 |
| 時間見積もりの粒度指定 | 規定なし | ルール6で具体単位を強制 | 書けば可 |
| 破壊的操作の扱い | 確認は全文保持 | 例外条項2で確認優先 | 自分で書く必要あり |
| 設定の保存先 | .claude/settings.local.json |
プラグイン+任意のフラグファイル | メモリファイル |
| 他ランタイムへの持ち出し | 不可(Claude Code専用) | 15系統に手順あり | 手で書き写す |
公平に言えば、Claude Codeしか使わず、目的が「短くしたい」だけなら組み込みConciseのほうが上です。追加の依存がなく、公式が保守し、エラー報告と安全確認の全文保持という安全弁が最初から入っています。i-have-adhdが優位に立つのは、(1) 進捗の言い直しと時間見積もりという、Conciseが規定していない2点が欲しいとき、(2) CodexやCursorなど複数のエージェントで同じ出力規約を揃えたいとき、(3) ルールを自分の好みに書き換えて配りたいとき(フォークしてSKILL.mdを編集し、自分のマーケットプレイスに差し替える手順がREADMEにあります)の3つです。
なお公式ドキュメントは機能の住み分けも明示しています。出力スタイルは「既定の指示を差し替えるもの」、CLAUDE.mdは「プロジェクトの規約を常に知らせるもの」、スキルは「呼ばれたとき・関連したときにタスク固有の指示を読み込むもの」。i-have-adhdはスキルの器を使って出力スタイル相当のことをしている、という位置づけになります。
リポジトリ自身の評価データが示す「効く場面・効かない場面」
このプロジェクトが他の人気スキルと違うのは、評価ハーネスと測定結果をリポジトリに同梱している点です。以下はevals/RESULTS.mdに公開されている数値で、筆者が実施した測定ではありません。条件は2026年8月2日、モデルclaude-opus-4-8固定、Claude Code 2.1.220、14ケース×3試行(条件あたり42行、計84行)、審査は同一モデルによるブラインド判定。報告コストは生成2.67ドル+判定0.92ドルです。
| 評価軸 | 重み | ベースライン | スキル適用 | 差 |
|---|---|---|---|---|
| 正確性 | 35% | 4.333 | 4.524 | +0.190 |
| 自律性 | 25% | 3.762 | 4.167 | +0.405 |
| 実行しやすさ | 20% | 3.905 | 4.619 | +0.714 |
| 安全性 | 10% | 4.643 | 4.667 | +0.024 |
| 簡潔さ | 10% | 3.429 | 4.571 | +1.143 |
| 加重合計 | — | 4.045 | 4.473 | +0.427 |
全5軸がプラスで、重大な問題として記録された件数は7件から3件に減っています。14ケース中10勝2分2敗。注目すべきは、ケース別に見ると差がどこに集中しているかです。
| ケース | 差 | 読み取れること |
|---|---|---|
| multi-step-progress(複数ステップの進捗) | +2.53 | 状態報告こそが本丸 |
| error-report(エラー報告) | +2.40 | 位置・原因・修正の定型化が効く |
| code-answer(コードで答える) | 0.00 | 出力契約がある場面では何も変わらない |
| long-form-request(長文要求) | 0.00 | 例外条項が正しく働き、短縮されない |
| agent-owned-edit(エージェント主導の編集) | −0.33 | 評価設計上そもそも合格不能なケース |
| partial-success(部分的成功の報告) | −0.63 | 唯一、追試の価値がある悪化 |
そして興味深いのは、この結果を公開している当人がリリース判定を「FAILED」と書いていることです。判定基準の第1条が「重大な問題がゼロであること」という絶対条件で、7件→3件に半減しても3件残る以上は不合格。しかもRESULTS.mdは「この条項は隣接する条項が相対比較なのに対して絶対条件になっており、どれだけ改善しても1件でも残れば永久に通らない。リリース時に発見するのではなく、意図的に決めておくべき性質の基準だ」と、自分の判定基準そのものに疑義を呈しています。数字を良く見せる方向の書き方ではありません。
悪化したpartial-successの分析も率直です。審査側のコメントは「証拠がないのに『認証ヘッダーの欠落』を確定原因として断言し、具体的な修正を処方している」。RESULTS.mdはこれをルール8(エラーは原因→修正の順で述べよ)の副作用である可能性が高いと推定しています。原因が特定できていない場面でも、形式が原因の明示を要求するために、モデルが断定に流れる——ルールが構造的に生む失敗として、いちばん警戒すべきパターンです。
読むときの留保も明記されています。3試行は少なく、ケース別の標準偏差は最大0.95に達するため、個別ケースの差が0.5未満なら信号として扱うべきではないこと。審査モデルが生成モデルと同じ系列であること。84応答のうち3件に、プレーンテキストとして書かれたツール呼び出し構文が残っていること。ベンチマークの読み方としてかなり誠実な部類です。
自分の環境で測り直したい場合、手順もリポジトリに入っています。
python3 scripts/run_evals.py validate
python3 scripts/run_evals.py run --runner claude --condition baseline \
--trials 3 --budget-usd 12.50 --output evals/results/responses.jsonl
python3 scripts/run_evals.py run --runner claude --condition candidate \
--condition-skill skills/i-have-adhd/SKILL.md \
--trials 3 --budget-usd 12.50 --output evals/results/responses.jsonl
python3 scripts/run_evals.py measure evals/results/responses.jsonl
公開されているスコア表に「出力が何%短くなったか」の数字は含まれていません。長さとトークン量は上のmeasureサブコマンドが別途集計する設計になっており、品質スコアと並べて読むべきものとされています。第三者の測定としては、Qiitaに3問・9試行で出力が1,884字→1,066字(−43%)になったという個人検証が公開されています。1モデル・少数試行の個人測定である点は割り引いて読む必要がありますが、方向性はリポジトリ側の簡潔さスコア(+1.143)と矛盾しません。
つまずきやすい点と回避策
❌ インストールしたのに出力が変わらない、と結論づける
⭕ 既定オフが仕様です。/i-have-adhdを打つか、touch ~/.claude/.i-have-adhd-alwaysでフラグを作ってから新しいセッションを開いてください。それでも補完に出ないときは再起動(プラグイン索引は起動時読み込み)、常時オンが効かないときはプラグインを更新してから再起動します。フックを同梱していないバージョンではフラグが無視されます。
❌ 効果を測るのに、フラグを立てたまま素の状態と比べる
⭕ これはリポジトリ自身が警告している落とし穴です。~/.claude/.i-have-adhd-alwaysが有効だと、比較対象のベースライン側にもルール全文が注入され、「スキルをスキル自身と比べる」ことになります。evals/README.mdは--setting-sources ""(Claude)や--ignore-user-config --ephemeral(Codex)でユーザー設定を切り離すことを必須としています。
❌ 原因が分かっていない不具合にも、原因→修正の型で答えさせる
⭕ 上で触れたpartial-successの回帰そのものです。証拠が原因を特定していないなら、例外条項3(3ターン失敗したら疑わしい前提を名指しし、診断質問を1つ)に寄せるほうが安全です。運用で補うなら「原因が確定していないときは断定せず、切り分け手順を1つ出す」という但し書きを自分のCLAUDE.md側に足しておくと噛み合います。
❌ 調査や設計レビューまで常時オンで走らせる
⭕ ルール9は表示件数の上限であって分析の上限ではない、と原文が明言していますが、実運用では「5件で足りる」と誤解した出力が出ることがあります。網羅性が要る作業では「stop adhd mode」で一旦外すか、例外条項1に沿って「順を追って説明して」と明示的に頼むのが確実です。
❌ フォークしたのに上流版が効き続ける
⭕ フォークと上流はプラグイン名・マーケットプレイス名が同じなので、先にclaude plugin uninstall i-have-adhdとclaude plugin marketplace remove i-have-adhdで上流を外してから、自分のリポジトリをmarketplace addし直します。
よくある質問
ADHDの診断がないと使ってはいけないのですか?
いいえ。READMEの副題は「ADHD-friendly outputs. No ADHD diagnosis needed!」で、診断の有無を前提にしていません。設計の出発点として認知特性を参照しているだけで、実体は出力フォーマットの規約です。元ネタはJ. Russell RamseyとAnthony L. Rostainの著書『The Adult ADHD Tool Kit』で、「人が1日をどう組み立てるか」ではなく「LLMがどう応答すべきか」に翻案した、とクレジットに書かれています。
オンにしたあと、どうやって戻しますか?
会話中に「stop adhd mode」または「normal mode」と伝えると、エージェントが1行で確認を返して既定の文体に戻ります。常時オン(フラグファイル)を使っている場合、この指示が効くのはそのセッションだけです。恒久的に外すにはrm ~/.claude/.i-have-adhd-alwaysを実行します。
トークンやコストはどのくらい増えますか?
都度呼び出しなら、呼ぶまではゼロです。disable-model-invocation: trueにより説明文すら常時コンテキストに載らないためです。呼び出し後はSKILL.md本文(約7KB)が入力に乗り続けます。常時オンにした場合はセッション開始時点から同じ本文が乗るため、短縮版の10行ブロック(約1KB)をメモリファイルに置くほうが軽くなります。出力側は簡潔さスコアが上がる方向なので、実効コストは作業内容次第です。
ライセンスと安全性は?
MITライセンスです。中身はMarkdown 1枚と、フラグファイルの有無を確認してSKILL.md本文を標準出力に流すだけのNodeスクリプト1本で、外部通信もファイル書き込みも行いません。フックの処理はtry/catchで囲まれ、失敗しても終了コード0でセッション開始を妨げない設計になっています。導入前にhooks/always-on.mjsを自分の目で読める分量です。
Claude Code以外でも同じ効果が出ますか?
公開されている評価はClaude Code 2.1.220上のclaude-opus-4-81モデルのみです。他ランタイムに手順が用意されていることと、同じ効果が測定されていることは別問題として扱ってください。なおClaude Codeのバージョン差で使える機能が変わる点は、Claude Code 2.1.245 新機能7選【2026年9月】も合わせて確認しておくと迷いません。
結論と次の一歩
i-have-adhdは、47,000スターという数字ほど大げさな仕掛けではありません。Markdown 1枚と条件分岐だけのフック1本、既定はオフ。それでもリポジトリ同梱の評価では加重スコアが4.045→4.473へ動き、伸びは「複数ステップの進捗報告」と「エラー報告」という2つの場面に集中していました。逆にコードだけ返す場面や長文要求では差がゼロ、部分的成功の報告では悪化しています。万能の改善ではなく、報告の型が決まっていない場面に型を与えるスキルと理解するのが実態に近いはずです。
選び方は冒頭の軸に戻ります。Claude Code単体で「短くしたい」だけなら、公式のConcise出力スタイルのほうが依存も保守負担も小さい。進捗の言い直しと時間見積もりが欲しい、あるいはCodexやCursorも含めて出力規約を統一したいなら、i-have-adhdの都度呼び出しから試すのが安全です。常時オンは、都度呼び出しで2〜3日使って「外したくない」と感じてからで遅くありません。
試す順序としては、まず/output-style conciseを1セッション試して物足りなさを言語化し、次にclaude plugin marketplace add ayghri/i-have-adhdから2コマンドで入れて/i-have-adhdを打つ。効果を数字で見たくなったら、--setting-sources ""で設定を切り離したうえでrun_evals.pyを自分のケースで回す。この3段階が、手戻りがいちばん少ない道筋です。
あわせて読みたい:
- Claude Code Hooks通知設定|macOS・Win・Slack — SessionStartを含むフックの発火条件と実装例
- Agent Pluginsとは|Claude SkillsとMCPを統一する標準 — スキル配布の器がどう標準化されたか
- ASD-STE100とは?AIの文章癖を航空規格で直すAgent Skill解説 — 出力の癖を規格で矯正する別アプローチ
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る(無料)
参考・出典
- ayghri/i-have-adhd — README — GitHub(参照日: 2026-09-18。スター数47,468・フォーク2,765はGitHub APIで同日取得)
- skills/i-have-adhd/SKILL.md — 10ルール・例外条項・送信前チェックの原文(参照日: 2026-09-18)
- INSTALL.md — 15ランタイムの導入手順・常時オン設定・トラブルシュート(参照日: 2026-09-18)
- evals/RESULTS.md — 2026-08-02実施の評価結果とリリース判定(参照日: 2026-09-18)
- Output styles — Claude Code Docs — 組み込みConciseスタイルと機能の住み分け(参照日: 2026-09-18)
- Agent Skills — Claude Code Docs —
disable-model-invocationの仕様(参照日: 2026-09-18) - ayghri/i-have-adhd — Trendshift — GitHub Trending首位到達日・週間ランキング(参照日: 2026-09-18)
- 3万スターの Claude Code スキルを入れたら、出力が43%短くなった — Qiita、第三者の個人検証(参照日: 2026-09-18)
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
著者:佐藤傑(さとう・すぐる)。株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。著書『AIエージェント仕事術』。
