Explainer

explainer

人間の理解がボトルネックになっている。 エージェントは書くのが速いが、読み手は追いつけない。 このスキルは、読み手の頭の中にあるものとの差分だけを、検証済みの主張と図で渡す。

ELI5 との違いは 2 つ。

1. 読み手を「5 歳」「マネージャー」のような型でなく、実在の 1 人のペルソナとして持つ。知っていることは書かない。
2. 書いた主張を道具で検査する。「自分で書いていて自信がなくなる」を、検査の緑に置き換える。

読了が 20 分を超える、演習が要る、概念に順序がある。このどれかなら、章立ての explainer-book を使う。

準備（初回だけ）

スクリプトは、このスキルのディレクトリ（以下 <skill>）の scripts/ にあります。 依存は、資料を置くリポジトリに入れます。Node 24 以上が必要です。

npm i -D @mizchi/vlmkit marked playwright mermaid

D2 の図（figures/*.d2）を使うときは d2 の CLI、データの図（figures/*.vl.json）を使うときは vega と vega-lite、アイコンを使うときは @iconify-json/lucide と @iconify-json/logos も入れます。 形式手法の例を扱うときは、TLC（Java 11+）や Apalache（Java 17+）、z3-solver も入れます。 verify-doc.mjs は $TLA2TOOLS（tla2tools.jar）と $APALACHE（apalache-mc）を、リポジトリの .tools/ から探します。

手順

1. ペルソナ   リポジトリのルートの personas/<id>.md を読む。無ければ、質問する前に仮のファイルを書く
2. 問いを絞る  読み手が「読み終えたら判定できるようになること」を 1〜3 個、疑問文で書く。伝えたいこと 1 文と、節ごとの役割の表を書く前に作る
3. 差分を決める ペルソナの「知っている」に載っていることは書かない。「怪しい」を本文の芯にする
4. 実物を作る   主張ごとに、実行できる例（コード・モデル・コマンド）を先に作って走らせる
5. 書く        references/writing.md の型で。価値を先に、根拠は後に。出力は貼る、打ち直さない。書き終えたら削除テスト
6. 図          references/figures.md。事実シート（*.facts.json）を先に、図は後
7. 検証        node <skill>/scripts/verify-doc.mjs <doc-dir> が VERIFIED になるまで
8. 読ませる    first-reader スキルで、ペルソナ本人を読み手にして読ませる。途中で離脱した箇所と、翌日残ったものを見る
9. 渡す        HTML（dist/index.html）と要約。検証できなかったことは「未検証」と明記

1. ペルソナ

references/persona.md のテンプレートで作る。材料は 2 つ。

• 質問：本人に聞けるなら、最大 5 問。「いま何を使っているか」「どこで手が止まったか」「読む時間」「好きな説明の形（コード先か図先か）」「この資料を読んだ後に何を判定したいか」。
• 公開情報：GitHub のリポジトリ、ブログ、登壇資料。主張ごとに URL を付け、事実と推測を分けて書く。

ペルソナのファイルは、答えを待つ前に書く。 新しい読み手なら、質問する前に、リポジトリのルートの personas/<id>.md を作る（資料のディレクトリの中ではない。次の資料でも使い直すため）。 質問して止まる返答でも、このファイルは先に書いておく。 依頼文から分かったことは「事実」に、それ以外はすべて「推測」に書き、質問は「未確認」の欄に並べる。

• 本人に聞けるときは、質問して止まる。答えが来たら、ファイルの推測を事実に書き換えて続ける。
• 答えが得られないとき（非対話の実行、本人に聞けない、急ぎ）は、推測のまま書き進める。 資料の冒頭の「想定読者」に、何を仮定したかと、確かめたい質問を書く。
• 依頼文にない経歴（経験年数、使っているツール、困りごと）を事実の欄に書かない。

推測は答えではない。 依頼文に書かれていないことは、どれほどもっともらしくても「推測した」に置き、理由を添える。 読み手について返答するときは、毎回この 2 つを分けて見せる。黙って決めない（非対話の実行でも同じ）。

新しい読み手に質問して止まるときの返答は、次の型にする。 返答を書く前に、Write で personas/<id>.md を作っておく（ツールを呼ばずに質問だけ返さない）。

<読み手> さんの仮のペルソナを personas/<id>.md に残しました。
依頼文にあった：<依頼文から分かったことだけ>
推測した：<推測>（理由：<なぜそう置いたか>）
書く予定の資料：この資料は <読み手> に <伝えたいこと> を伝える。構成は 1. <節の役割> 2. … 3. …
資料の中身が変わる点を <N> つ確認させてください。

1. <答えで資料の主軸が変わる質問>
2. …

答えがなければ、「推測した」のまま書き進めます。

推測のまま資料を書き進めたときの返答は、冒頭を次の型に固定する。ファイルにだけ書くと、読み手に届かない。 順番も変えない。2 行目は必ず「伝えたいこと」。「未検証」などの注意は、この型の後に書く。

<path> を書きました（<読み手> さん向け。仮のペルソナは personas/<id>.md）。
伝えたいこと：この資料は <読み手> に <伝えたいこと> を伝える。構成は 1. <節の役割> 2. … 3. …
依頼文にあった：<依頼文から分かったことだけ>
推測した：<何を知っている前提にしたか>（理由：<なぜそう置いたか>）
確かめたいこと：1. <答えで資料の主軸が変わる質問> / 2. …
（ここから後に：未検証の点、手元で確かめる手順）

資料を作らず、チャットで説明するとき（PR の説明など）も、冒頭は同じ型にする。

この説明は <読み手> に <伝えたいこと> を伝える。
依頼文にあった：… / 推測した：…（理由：…）
構成：1. <何が変わるか（価値）> 2. <根拠：差分・例> 3. <確かめてほしいこと>

依頼文の言い換えを、本人の言葉のように書かない（「田中さんの問い『…』」ではなく、「依頼文から、問いを『…』と置いた（推測）」と書く）。

一番大事な欄は「怪しいところ」。 ツールを使えることと、その結果の意味を判定できることは別。 その差を見つけて、資料の芯にする。

2〜3. 問いと差分

資料のタイトルは、読み手の問いの形にする（例：「Z3 と TLA+ の OK は何を保証したのか」）。

書く前に、伝えたいことを 1 文にし、節ごとの役割の表を作る。

この資料は <読み手> に <伝えたいこと> を伝える。

| 節 | 役割（この節で言うこと 1 文） | 見せるもの（例・図・出力） | なぜ（伝えたいことにどうつながるか） |

• 「なぜ」が伝えたいことにつながらない行は、節ごと削る。
• 1 文と表は、資料の冒頭（想定読者の次）に置く。チャットで説明するときも、最初にこの 1 文と、節の並びを短く示す。
• 読み手が構成を先に見たいと言ったとき、または本（explainer-book）にするときは、表を見せて確認を取ってから書く。直すのは、読み手が名指しした行だけ。それ以外は、表を冒頭に置いて書き進める。

冗長さの判定は 1 つ。 ペルソナの「知っている」欄にある説明は削る。 ツールの紹介、インストール手順、一般論は、ペルソナが既に使っているなら書かない。

4. 実物を先に作る

主張は、走らせた結果から書く。逆にしない。

• コードの振る舞い → 最小の実行例と、その出力
• 「この条件で壊れる」 → 反例を出すモデル（Z3 / TLC など）と、反例を実物で再生するテスト
• 構造 → import グラフや状態グラフを道具から出力し、それを事実シートにする

主張を実行で確かめられない場合は、本文に「未検証」と書く。図には入れない。

5. 書く

references/writing.md に従う。要点は次のとおり。

• 冒頭に「想定読者」と「省いたもの」を書く。読み手が自分向けかを 10 秒で判定できるように。
• 最初に「一枚で」の表を置く。本文はその表の各行の展開。
• 1 段落は 1〜2 文。1 節に例は 1 つ。
• 出力の引用は <!-- output: <check名> -->、コードの抜粋は <!-- source: <path> --> を直前に置く。検証スクリプトが実物と照合する。
• 末尾に理解度チェック（3〜5 問、答えは <details>）。読み手が答えられなければ、その節は伝わっていない。

6. 図

references/figures.md。図を描くのは次の場合だけ。

• 4 つ以上の要素とその関係があるとき
• 時間の順序があるとき
• 包含関係があるとき

図は、Mermaid で済むなら Mermaid、足りない構造なら D2、D2 に乗らない自由な図なら SVG / HTML で書く。道具の出力を写す図（TLC の状態グラフなど）は、スクリプトで出力から .mmd と事実シートを作る（scripts/tlc-to-mermaid.mjs）。どれも scripts/figure-check.mjs で描画・検査して、出てきたシートと辺のシート（矢印を 1 本ずつ強調したもの）を目で見て直す。D2 と Mermaid は配置を道具が決めるので、不自然なら scripts/figure-variants.mjs で候補を並べて選び直す（references/figures.md の「手で描く図」）。 データの図（分布・関係・モデルの診断）は Vega-Lite の spec（figures/<name>.vl.json）で書く。SVG を手で書かない、matplotlib の既定の SVG にしない。figure-check.mjs が描画・検査する（references/figures.md の「データの図」）。

モデルや分析の診断結果を説明するときは、次の 3 つを必ず出す。

1. 判定表を、伝えたいことの直後に置く。列はこの 5 つに固定する（用途別の表など、ほかの表は判定表の後に足す）。

   | 診断項目 | 実測値 | 合格基準 | 判定 | 次アクション |

   判定は OK / 要対処 / 確認 のどれか。要対処には次アクションを書く。判定は図と基準を見て書く（スクリプトの if で作らない）。
   • 実測値には、依頼文の値か、実行した出力の値だけを書く。手で計算した値（区間、SE、比など）は表に入れない。要るなら本文に「手計算・未検証」と添えて書く。
   • 合格基準には、出典のあるものだけを書く（依頼文、references/figures.md の「よく使う合格基準」、論文）。出典が無ければ「文脈による」と書き、判定は「確認」にする。もっともらしい閾値（「AUC 0.7 以上」など）を作らない。
2. 図のパネルの題は「何を見る図か — 何が見えれば合格か」（例：キャリブレーション — 対角線に沿う）。
3. 合格の基準の線（対角線・陽性率・±2SE のバンド）は破線（"strokeDash": [5, 4]）。

コマンドを実行できない環境でも、図は .vl.json の spec として書く。値から座標を手で計算して SVG を描かない（描き損じを検査できない）。本文には spec へのリンクと「未描画：figure-check.mjs <spec> --write で SVG になる」を書く。 アイコン（データベース・サーバ・製品のロゴなど）は scripts/icons.mjs で探して図の隣に置き、D2・Mermaid・SVG のどれからでも使う（references/figures.md の「アイコン」）。

事実シート（figures/<name>.facts.json）は道具の出力（TLC の状態グラフ、import グラフ）から作る。figure-check.mjs が、ラベルが図にあるか、edges が .mmd / .d2 の辺とちょうど一致するかを照合する。

7. 検証

<doc-dir>/checks.json に、本文が引用する出力を再生成するコマンドと、期待する行を書く。

node <skill>/scripts/verify-doc.mjs <doc-dir>          # 検査
node <skill>/scripts/verify-doc.mjs <doc-dir> --write  # 図の SVG を描き直す

verify-doc.mjs が見るもの：

1. checks.json の各コマンドの出力に、期待する行が順に出るか
2. 図：figure-check.mjs（重なり・はみ出し・矢印・事実シート）と、SVG がソースより新しいか
3. 本文：output / source の引用が実物と一致するか。画像が存在するか
4. HTML：vlmkit check integrity（<details> を開いた版で厳格に）と check a11y contrast

落ちた行は「何が・どこで・どう直すか」を 1 行で出す。 直して再実行し、verdict: VERIFIED になるまで繰り返す。 上限は 5 ラウンド。それでも通らない主張は本文から外すか、「未検証」と明記する。