i-have-adhd — 機能を1つも足さないSkillが4.6万スターを集めた理由

何も機能を足さないSkillが、4.6万スターを集めている

Claude Code の Skill や Plugin と聞いて普通に想像するのは、新しいツールを生やすもの、外部サービスに繋ぐもの、独自のワークフローを回すものです。i-have-adhd はそのどれでもありません。ツールを足しません。MCPサーバも立てません。コマンドは実質1つだけです。 変えるのは応答の「形」だけです。

それでいて、2026年5月13日に公開されてから9月16日時点で 46,417スター・2,697フォーク。 リポジトリの説明文は1行だけで、こう書かれています。

A skill to stop your coding agent from burying the answer. ADHD-friendly output.

（コーディングエージェントが答えを埋もれさせるのをやめさせるSkill。ADHDに優しい出力。）

作者は「ADHDの読者のためのアクセシビリティ機能」として作ったと書いていますが、広まった理由はおそらくもっと単純です。「Great question!」から始まって「Hope this helps!」で終わる応答を、誰も読みたくないからです。 READMEの最後の一文も、そこを突いています —— 「Great question! を1回スクロールで飛ばさずに済んだなら、スターを」。

この記事では、このSkillを3つのレイヤーで読みます。①何が変わるのか（ルール）、②どう作られているのか（設計と実装）、③どう検証されているのか（評価ハーネス）。 特に③は、Skillというものを「なんとなく効いてる気がするプロンプト」から一歩進めたい人にとって、本体より価値があります。

何が変わるのか

READMEに載っているBefore/Afterがそのまま最良の説明なので、まず訳して並べます。同じ「auth.ts の verifyToken が古いAPIを使っている」という状況への応答です。

Before（素のエージェント）

いい質問ですね！ちょっと考えてみましょう。あなたの認証フローにはいくつか可動部があります —— ミドルウェア、トークン検証、そしてCookieの扱いです。src/auth.ts を見ると、verifyToken 関数（42〜58行目あたり）が古い jsonwebtoken のAPIを使っているようです。 ひとつのアプローチとしては、パッケージを更新してその関数を書き直すことが考えられます。変更後は認証テストを実行して壊れていないか確認するとよいでしょう。 ところで、依存パッケージのバージョン全体も見直したほうがいいかもしれません。お役に立てば幸いです！さらに深掘りしたい場合はお知らせください。

After（i-have-adhd 適用後）

npm install jsonwebtoken@latest を実行し、src/auth.ts:42 を編集してください。

1. src/auth.ts を開く
2. verifyToken（42〜58行目）を下のスニペットで置き換える
3. npm test -- auth.spec.ts を実行する

次: テストが落ちたら、最初の失敗行を貼ってください。

注目すべきは、情報が削られていないことです。パッケージ名も行番号もテストコマンドも全部残っています。 消えたのは、前置き（「いい質問ですね」）、態度の表明（「考えてみましょう」）、ヘッジ（「ようです」「かもしれません」）、 脱線（「ところで依存パッケージも」）、そして締めの挨拶です。短くしたのではなく、行動可能な順に並べ直した、というのがこのSkillの主張です。

10のルールと、その前提になっている5つの事実

SKILL.md は約1,200語。冒頭で「読者はADHDである。出力は単に短いのではない。ADHDの脳が行動に移せる形になっている」と宣言し、 ルールの前に「ADHDが読解に何をもたらすか」を5つの事実として置いています。ここが効いています。 ルールだけ渡すとモデルは字面を守って中身を壊しますが、理由が書いてあると判断ができるからです。

その上で、10のルールです。

設計として読む — 3つのポイント

ルールの中身以上に、Skillの「置き方」が参考になります。3点だけ取り上げます。

1. モデルに勝手に発動させない

フロントマターはこうなっています。

---
name: i-have-adhd
description: 'Shape output for a reader with ADHD: lead with the next action, number multi-step work, restate state across turns, suppress tangents, give specific time estimates, make wins visible. Invoke with /i-have-adhd; stays on until "stop adhd mode".'
disable-model-invocation: true
license: MIT
metadata:
  tags: "ADHD, Output Style, Productivity, Formatting"
  category: "productivity"
---

disable-model-invocation: true が肝です。 通常のSkillは description をモデルが読んで「この状況なら使うべきだ」と自律的に発動します。 しかし出力スタイルはタスクの性質ではなく、読み手の好みで決まるものです。 モデルが「この質問はADHD向けに整形したほうがよさそうだ」と判断するのは、明らかに越権です。 だからこのSkillはユーザーが /i-have-adhd と打った時だけ起動します。

2. 「持続する」ことを明文化している

ルール本体の前に、Persistence というセクションがあります。意訳するとこうです。

これらのルールは、このターンだけでなくセッションの残り全ての応答に適用される。 数ターンで期限切れにならないし、話題が変わっても失効しない。まだ適用されるか迷ったなら、適用される。

オフにするのは、読者が "stop adhd mode" または "normal mode" と言った時だけ。1行で確認を返し、デフォルトのスタイルに戻る。

「迷ったなら適用される（If you are unsure whether they still apply, they do.）」の一文が上手い。 スタイル指示は会話が長くなるとほぼ確実に薄まります。モデルは新しい文脈を「新しい依頼」と解釈して、デフォルトの饒舌さに戻る。 それに対して曖昧なケースの倒し方をあらかじめ指定しておくのは、プロンプト設計として素直で強い手です。 さらに、解除条件を自然言語の合言葉にして、解除時の応答（1行で確認）まで決めてあります。

3. ルールが答えを殺さないための例外条項

SKILL.md の後半は「When to break the rules（ルールを破るべき時）」に割かれています。6つあります。

最後の2つが特に重要です。「制約が勝ち、形は残る（the constraint wins, the shape stays）」という原則を立てて、 出力スタイルがタスクの成立条件を侵食しないようにしています。 「簡潔に」と指示した結果、選択肢を聞いているのに1案しか返ってこない —— あの失敗を、ルールの中で先回りして潰しています。

送信前チェックリスト

ルールの最後は、出力を出す前に実行する削除リストです。これは「守れ」ではなく「消せ」の形になっているので、モデルが実行しやすい。

そして最終確認 —— 「読者が最初の1行と最後の1行だけを読んだとして、(a) 次に何をすべきか、(b) いま何が起きたか、が分かるか？」。 分かるなら送信。この2問は、自分が書くドキュメントやPR説明にもそのまま流用できます。

常時ONの実装 — SessionStartフックとフラグファイル

毎回 /i-have-adhd と打ちたくない人のために、常時ONの仕組みがあります。 ただしインストールしただけでは何も起きない設計になっていて、有効化は明示的なオプトインです。

# インストール
claude plugin marketplace add ayghri/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd

# 常時ONにする（フラグファイルを置くだけ）
touch ~/.claude/.i-have-adhd-always

# カスタム設定ディレクトリを使っている場合
touch "$CLAUDE_CONFIG_DIR/.i-have-adhd-always"

# 常時ONをやめる
rm ~/.claude/.i-have-adhd-always

実体は SessionStart フックです。宣言はこれだけ。

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume|clear|compact",
        "hooks": [
          {
            "type": "command",
            "command": "node -e \"...(hooks/always-on.mjs を動的importする)...\"",
            "timeout": 30,
            "statusMessage": "Checking i-have-adhd always-on flag..."
          }
        ]
      }
    ]
  }
}

matcher に compact が入っているのが地味に効いています。 コンテキスト圧縮のたびにルール本文を再注入するので、長いセッションでスタイルが薄まる問題に構造で対処しています。resume と clear も同様です。

flowchart TD
    A["セッション開始<br/>startup / resume / clear / compact"] --> B{"フラグファイルはあるか<br/>~/.claude/.i-have-adhd-always"}
    B -->|"ない"| C["exit 0<br/>何も注入しない"]
    B -->|"ある"| D["SKILL.md を読む<br/>パスはスクリプト自身の位置から解決"]
    D --> E["YAMLフロントマターを除去"]
    E --> F["ADHD MODE ACTIVE の宣言 + ルール本文を<br/>stdout に出力 → コンテキストに注入"]
    F --> G["以降そのセッションの全応答に適用"]
    G --> H["'stop adhd mode' で<br/>そのセッションだけ解除"]
    X["例外が発生"] --> C

実装（hooks/always-on.mjs）で真似したい点が3つあります。

本当の読みどころ — 評価ハーネス

ここからが、このリポジトリを他の「プロンプト集」から分けている部分です。evals/ と scripts/ の下に、このSkillが実際に応答の質を上げるのかを測る仕組みが入っています。

測っているのは「短さ」ではない

採点表（evals/rubric.md）は5次元・加重。出力スタイルのSkillなのに、簡潔さの重みが最小の10%です。

内訳は、正確性35%（事実・技術的な正しさ、必要な詳細が保たれているか）、 自律性25%（エージェントが自分でやるべき仕事をやり、避けられる作業をユーザーに押し付けていないか）、 行動可能性20%、安全性10%、簡潔さ10%。 さらに「危険な指示」「重大な事実誤り」「明示された出力契約の違反」「タスク完了を妨げる自律性の後退」には blocker: true が付きます。

この設計は合理的です。出力スタイルの変更が怖いのは、短くなることではなく短くする過程で中身が落ちることだからです。 だから「落ちていないこと」を重く測り、「短いこと」は軽く測る。採点は条件名を伏せてA/B/Cのラベルでブラインド実施されます。

結果: 全次元で改善した

初回計測（2026年8月2日、claude-opus-4-8 ピン留め、Claude Code 2.1.220、14ケース×3試行＝1条件42行・計84行、生成$2.67＋採点$0.92）の結果です。 ベースラインは素のタスクプロンプト、候補は同じプロンプトに SKILL.md 本文をスタイル指示として注入したもの。

加重合計で 4.045 → 4.473（+0.427）。伸び幅は簡潔さ +1.143、行動可能性 +0.714、自律性 +0.405 の順。 注目すべきは、ルーブリックが最も重く見ている正確性が +0.190、安全性が +0.024 と、どちらも下がっていないことです。 RESULTS.md の表現を借りれば「このSkillは、正確さを対価にして簡潔さを買ってはいない」。 ブロッカーは7件→3件、14ケース中10勝2分2敗でした。

それでも「リリースゲート不合格」と書いてある

ここが、このリポジトリで一番好きな部分です。RESULTS.md の見出しはこうなっています —— 「Release gate: FAILED」。

リリース条件は4つ。①ブロッカーが1件もないこと、②正確性と安全性がベースラインから0.1以内または改善、③加重スコアがベースラインより高いこと、④公開する比較は同一の条件で測ること。 ②③④は満たしています。落ちたのは①だけです。

唯一の意味ある後退と、その仮説

候補が負けたケースは2つ。agent-owned-edit（上記の壊れたケース）と partial-success（−0.63）です。 後者について、レポートは原因の仮説まで書いています。

採点者のコメントは「証拠がないのに『認証ヘッダの欠落』を決定的な原因だと断定し、具体的な修正を処方している」。 そしてルール8（エラーは「原因→修正」の形で報告する）が、証拠が原因を特定していない時でもモデルに原因を名指しさせる圧力をかけている、という機序が示されています。 3試行では確証できないが、方向が一貫していて機序も説明できる唯一の結果だから、試行数を増やす価値があるのはここだ、と。

自分の施策に不利な結果を残し、原因を自分のルールに帰し、次に何を測るべきかまで書く。 これは評価レポートの書き方として、そのまま手本にできます。

条件汚染の話 — 一番実用的な教訓

evals/README.md に、LLM評価をやる人全員に効く警告があります。

# Claude ランナー: ユーザー設定を完全に切り離す
claude --setting-sources "" --model <ピン留めしたモデル> ...

# Codex ランナー
codex --ignore-user-config --ephemeral ...

理由が身も蓋もない。この分離をしないと、操作者のユーザーレベルのプラグイン・フック・メモリ・出力スタイルが全条件に漏れ込む。 そしてこのリポジトリにおける最も鋭い例が —— 自分自身の常時ONフラグ（~/.claude/.i-have-adhd-always）です。 フラグを立てたまま評価を回すと、ベースライン条件にも i-have-adhd のルールが注入され、Skillが自分自身と比較されることになります。

持ち帰り

i-have-adhd をインストールするかどうかは好みの問題です。実際、常時ONにすると窮屈に感じる場面は想像がつきます。 それより、このリポジトリから取れるものが3つあります。

個人的に一番刺さったのは、送信前チェックの最後の2問です ——「最初の1行と最後の1行だけを読んだとして、(a) 次に何をすべきか、(b) いま何が起きたか、が分かるか？」。 これはエージェントの応答に限らず、PR説明にも、Slackの報告にも、この記事にも効く問いです。