---
name: explainer-book
description: "1 本の速習資料では収まらない、章立ての学習資料（topic-book/01-quickstart.md, 02-….md …）を、読み手のペルソナに合わせて設計・執筆・検証する。章ごとの学習目標と理解度チェックの対応、概念を導入より前に使わない順序、章の読了時間の予算、「未完成なら落ち、答えなら通る」演習、book.json から生成する章の依存図を、verify-book.mjs で検査し、各章の出力・図・HTML は explainer の verify-doc.mjs で検査する。Use when the user asks for a book, a tutorial series, a course, \"学習資料\", \"チュートリアル\", \"ハンズオン\", \"本にまとめて\", \"章立てで\", \"01-quickstart から\", or when an explainer crash course would exceed ~20 minutes or needs exercises."
---

# explainer-book

`explainer` の本版。
1 本の速習資料（20 分以内・例 1 つずつ）で足りないとき、章に分けて、**手を動かして身につける**資料にする。

ペルソナ・図・検証の仕組みは `explainer` をそのまま使う。先に `../explainer/SKILL.md` を読むこと。
このスキルが足すのは、本全体の設計と検査。

スクリプトは、このスキルのディレクトリ（以下 `<skill>`）の `scripts/` にあります。
`verify-book.mjs` は、隣の `explainer` スキルの `scripts/verify-doc.mjs` を呼びます。2 つのスキルは同じ場所に入れてください。
依存の入れ方は `explainer` の「準備」と同じです。

## いつ本にするか

次のどれかに当てはまったら本にする。1 つも当てはまらなければ、`explainer` の 1 本で書く。

- 読了が 20 分を超える
- 読み手が手を動かす演習が要る（読むだけでは「判定できる」ようにならない）
- 概念に順序がある（A を知らないと B が読めない）

## 構成

```
<topic>-book/
  README.md            目次：想定読者、章ごとの「読み終えたらできること」、章の依存図、再現方法
  book.json            章の順序・学習目標・導入する概念・演習（references/book-json.md）
  01-quickstart.md     最初の章は必ず quickstart：理論の前に、動く結果に着く
  02-….md              concept：1 章 1 つの判定を身につける
  03-….md              practice：演習が中心
  checks.json          本文の出力と演習の答えを再生成するコマンド（explainer と同じ形式）
  examples/            章で使うコード・モデル。演習の出発点と答えを別ファイルにする
  figures/             book-map.*（生成）と各章の図
```

## 手順

```
1. ペルソナ     explainer と同じ。「怪しいところ」から、本全体の問いを 1 つ決める
2. 目標を並べる  問いに答えるために読み手ができるべき判定を 3〜6 個。1 章に 1〜2 個
3. 概念の順序   各判定に要る概念を書き出し、どの章で導入するかを決める（book.json introduces / requires）
4. 実物を先に   各章の例と演習を作り、走らせる。演習は「出発点で落ちる」「答えで通る」を両方確かめる
5. 章を書く     explainer の writing.md の型。章の冒頭に所要時間とゴール、末尾に理解度チェック
6. 検証         node <skill>/scripts/verify-book.mjs <book-dir> [--write]
7. 読ませる     first-reader で、少なくとも 01-quickstart と演習の章を、ペルソナ本人に読ませる（explainer の手順 8）
8. 渡す         dist/index.html と、各章の 1 行要約。未検証の点を明記
```

### 2. 学習目標

目標は「読み終えたら、何を判定できるか」で書く。「〜を理解する」は検査できないので書かない。

- 悪い例：「CTI を理解する」
- 良い例：「CTI が出たとき、条件が弱すぎるだけか、性質が本当に破れるかを TLC で判定できる」

各目標には、理解度チェックの問いを 1 つ以上付ける（`<!-- quiz: <目標id> -->`）。

### 3. 概念の順序

- ペルソナが既に知っている概念は `assumed` に書く。説明しない。
- それ以外の概念は、ちょうど 1 つの章が `introduces` する。その章より前の章の本文に出てきたら、検証が落ちる。
- 章が前提にする概念は `requires` に書く。依存図の矢印になる。

### 4. 演習

演習の答えも実行して確かめる。答えが間違った演習は、間違いを教える。

| kind | 例 | 検査 |
|---|---|---|
| `write` | 条件・関数・設定を書かせる | `starter`：出発点のまま実行すると**落ちる**ことを確かめる check。`answer`：答えで**通る**ことを確かめる check |
| `check` | 道具を回して判定させる | `answer`：判定の根拠になる出力を再生成する check |

- 答えは、演習と同じ節の `<details>` に入れる。
- 演習の前に `<!-- exercise: <id> -->` を置く。

### 5. 章を書く

`explainer` の文体に加えて、次を守る。

- 冒頭の引用ブロックに、所要時間・ゴール（その章の目標）・前提（前の章）を書く。
- 末尾で次の章へリンクする（`→ [02 …](02-….md)`）。HTML では前後の章と目次へのナビが付く。
- 前の章の結果を使うときは、章番号で参照する（「1 章の 3 つの check」）。同じ説明を繰り返さない。
- 手で推論した結果（「この状態には着けない」「この順序で起きる」）は、道具の出力に置き換える。推論は外れる。

### 6. 検証

```
node <skill>/scripts/verify-book.mjs <book-dir>           # 検査
node <skill>/scripts/verify-book.mjs <book-dir> --write   # 依存図と SVG を作り直す
```

本全体の検査：

| 検査 | 落ちる条件 |
|---|---|
| chapters | 章ファイルがない。`NN-` の番号が book.json の順と違う。1 章が quickstart でない |
| objectives | quiz が付いていない目標がある。quiz が他の章の目標を名指ししている |
| concepts | 概念を導入より前の章で使っている。`requires` が導入されていない。`introduces` と宣言したのに本文に出てこない |
| budget | 本文の推定読了時間（500 字/分 + コード 15 行/分）が `minutes` を超える |
| exercises | 印がない。答えが `<details>` にない。check が checks.json にない。`write` 演習に落ちる starter がない |
| map | `figures/book-map.*` が book.json と一致しない。README に図がない |

そのあと、README と全章を `verify-doc.mjs --pages` に渡す。出力の引用、図、ページ間リンク、各ページの vlmkit ゲートを検査する。

`book verdict: VERIFIED` になるまで直す。

## やってはいけないこと

- **章を増やして薄める。** 1 章に目標がない、または理解度チェックが目標を問わないなら、その章は要らない。
- **演習の答えを走らせない。**
- **前の章の説明を繰り返す。** 章番号で参照する。
- **検証を通すために言い換える。** 概念の検査に落ちたら、定義を前の章に移すか、章の順序を見直す。同義語に置き換えて逃げない。

## ファイル

| パス | 内容 |
|---|---|
| `references/book-json.md` | book.json の全フィールド |
| `scripts/verify-book.mjs` | 本全体の検査 → verify-doc.mjs |
| `../explainer/scripts/build-html.mjs` | 複数ページを HTML に（目次・前後の章へのナビつき） |