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. <確かめてほしいこと>

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

返答の型の行は、型のとおりの地の文で書く。「依頼文にあった：」などのラベルを太字にしない。箇条書きにもしない（「- 依頼文にあった:」の形にしない）。 本文も references/writing.md の「読みやすい日本語」に従う。チャットの返答では特に、太字は結論の 1 か所だけにし、変更前後の対比や理由のつながりは、箇条書きでなく表か文で書く。

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

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 が見るものは次の 4 つ。

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

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

8. 読ませる（first-reader）

verify-doc.mjs が保証するのは、主張が正しいことだけです。 読み手が最後まで読み、翌日も覚えているかは、同梱の first-reader スキルで確かめる。

項目	どうするか
sympathetic 役	personas/<id>.md の本人。「既に知っていること」を priors に、「読み方」を patience budget にする
skeptical 役	資料が届く場面（PR のレビュー、Slack のリンク）から配役する
intended gist	資料の「一枚で」の表と、ペルソナの問い（手順 2）
伝わっていない節	recall の答えが intended gist と食い違った節
構成の問題	skim gate を通らない、または前半で両者が離脱した。行単位の手直しより先に直す

first-reader は書き直さない。読み手の証言を受けて、どこをどう直すかは explainer が決める。 直したら verify-doc.mjs を再実行し、first-reader の again で同じ読み手に読ませ直す。 書き手は下書きを全部読んでいるので、読み手は必ず新しい subagent にする（first-reader の手順どおり）。 signals.py の信頼シグナルの数え方は英語向けで、日本語の資料ではほぼ 0 になる。日本語では trust ledger を自分の通読で判断する。 .first-reader/ は資料の隣に作られる。git 管理しない。

9. 渡す

• チャットでは、要約（3〜5 行）と dist/index.html を渡す。検証の結果（VERIFIED か、何が未検証か）も添える。
• PR では、差分の説明を同じ型で書き、図の SVG を添付する。理解度チェックは PR 本文の末尾に置く。

PR の説明に使うとき

問いは「この PR がマージされたら、何が変わるか」「何が壊れうるか」にする。 価値を先に、根拠は後に。 読み手（や利用者）にとって何が変わるかを、最初の 2 段落（2 節）までに書く。差分と仕組みは、その主張の根拠として後に置く。 差分はファイル順ではなく、説明の順に並べる（literate diff）。

実物は次の 2 つ。

• 変更地図：git diff --stat と import から事実シートを作り、触ったモジュールと依存を D2 か Mermaid で描く
• 変更前後で振る舞いが変わる最小の例（テストの追加・変更から選ぶ）

やってはいけないこと

• 出力を打ち直す。 貼る。検証スクリプトが照合する。
• 図を記憶から描く。 事実シートを先に作る。図が事実シートと食い違ったら、図が間違っている。
• 読み手の既知を説明する。 ペルソナの「知っている」にあるものは削る。
• 緑を過大に報告する。 「検査が通った」と書くときは、何の検査が、どの範囲で通ったかを書く。

ファイル

パス	内容
references/persona.md	ペルソナのテンプレートと、作り方
references/writing.md	資料の型、文体、理解度チェックの作り方
references/figures.md	問い → 図の種類の対応、事実シートの作り方、検査と目で見るループ
scripts/verify-doc.mjs	検証（checks / 図 / 引用 / HTML）
scripts/build-html.mjs	README.md → 自己完結 HTML（SVG をインラインで埋め込む）
scripts/figure-check.mjs	手で書いた SVG / HTML / D2 / Mermaid の図と Vega-Lite の spec を描画し、重なり・はみ出し・枠線や線と文字の交差・小さすぎる文字・豆腐（字形の無い文字）・輪郭になった文字・事実シートを検査し、目で見るシートを作る
scripts/figure-arrows.mjs	矢印の読みやすさ（2 本が重なって走る・箱を突き抜ける・交差・遠回り・逆向き）と、辺を 1 本ずつ強調したシート。figure-check が使う
scripts/figure-variants.mjs	D2 / Mermaid の配置の候補（TALA の seed・ELK・dagre、向き）を描き、点数つきで並べる
scripts/icons.mjs	Iconify のアイコンセット（lucide・logos）からアイコンを探し、候補を 1 枚に並べ、図の隣に置いて出典を ICONS.md に残す
scripts/tlc-to-mermaid.mjs	TLC の状態グラフと反例 → Mermaid の flowchart（反例の道を太枠）と事実シート