diff --git a/AGENTS.md b/AGENTS.md
index 61f3369..a4f1b0c 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -64,6 +64,7 @@ ai-plugins/
| [docs/plugin-development-guide.md](docs/plugin-development-guide.md) | プラグイン開発ガイド（構造、plugin.json、バージョン管理、検証） |
| [docs/ndf-plugin-reference.md](docs/ndf-plugin-reference.md) | NDFプラグイン詳細リファレンス |
| [docs/specifications/](docs/specifications/) | 完了済みplan/issue由来の確定仕様 |
+| [docs/presentations/](docs/presentations/) | 勉強会などで使うスライド資料（Marp形式）とビルド手順 |
| [docs/claude-code-skills-survey.md](docs/claude-code-skills-survey.md) | Claude Code Skills調査レポート |
| [docs/development-history/](docs/development-history/) | 開発履歴と知見 |
| [plugins/ndf-claude/README.md](plugins/ndf-claude/README.md) | Claude Code版NDFプラグイン |
diff --git a/docs/.nojekyll b/docs/.nojekyll
new file mode 100644
index 0000000..e69de29
diff --git a/docs/index.html b/docs/index.html
new file mode 100644
index 0000000..8d7ab9d
--- /dev/null
+++ b/docs/index.html
@@ -0,0 +1,12 @@
+
+
+
+
+
+ai-plugins
+
+
+公開しているのはプレゼンテーション資料です。プレゼンテーション資料へ移動します。
+リポジトリ: devbasex/ai-plugins
+
+
diff --git a/docs/presentations/2026-08-06-ai-plugins-intro.html b/docs/presentations/2026-08-06-ai-plugins-intro.html
new file mode 100644
index 0000000..3f72904
--- /dev/null
+++ b/docs/presentations/2026-08-06-ai-plugins-intro.html
@@ -0,0 +1,1490 @@
+ai-plugins
【0:00-0:35】
+NDFが何なのかは前回話したので、今日は「で、結局どのスキルに何が書いてあるのか」をやります。
+スキルは手順書じゃなくて、判断基準が書いてあるものだと思ってください。何をやるかより、何を重視するかが本体です。
+持ち帰ってほしいのは、PRを1本出す流れがスキルを繋ぐだけで終わる、という感覚ひとつです。
【0:35-1:25】
+構成はシンプルです。スキルの本体は ndf-shared の1か所。ここを直すと、Claude用・Codex用・Kiro用の配布物がビルドで生成されます。
+なので「Claudeでは直ってるけどCodexでは古い」が起きない。地味ですがこれが一番効いてます。
+数が違うのは、ランタイムごとに意味のないスキルを外しているからです。Claudeは29、Codexは30、Kiroは28。
+MCPプラグインが10個。今日は時間の都合で名前だけにします。
【1:25-2:10】
+インストールはこれだけです。marketplace add は初回だけ、あとは install。
+入るものは3種類。スラッシュで呼ぶスキル、裏で働くサブエージェント、それとフック。
+Stopフックは作業が終わったらSlackに要約を投げてくれます。長時間タスクを回してる人はこれだけでも入れる価値があります。
+では本題、スキルの中身に行きます。
【2:10-2:55】
+これが今日の地図です。左から、作る前にプランを書き、PRを出し、レビューを回し、最後に仕様書として残す。矢印1本がスキル1個です。
+下の3つは順番のどこかに入るものじゃなくて、全工程にかかるルールです。文章を書くとき、調べるとき、バグを直すときに常に効いてくる。
+ここからスキルを1個ずつ開けていきます。それぞれ「何が書いてあるか」と「何を重視しているか」の2点で見てください。
【2:55-4:00】
+1つめ。implementation-plan は issues/ 配下に実装プランを置くスキルです。
+左が中身。プランの雛形が決まっていて、概要・背景・修正対象・タスク分解・影響範囲・テスト計画。埋めるだけです。全部の変更に要るわけじゃなくて、判断基準もスライドの通り書いてあります。
+右が思想。重視しているのは「なぜ」を残すこと。コードを見れば「何をやったか」は分かるけど「なぜやったか」は消えるので、そこだけ残す。
+なのでプランとPR本文で役割を分けていて、同じ内容をコピーするなと明記されています。
+下のブロックが実用上ありがたくて、プランを書かずに実装しちゃっても、PRを作る瞬間に会話履歴とgit logとdiffから逆算して生成してくれます。「あとで書く」が実際にあとで書かれる。
【4:00-5:05】
+2つめ、pr。commitしてpushしてPRを作るまで一括です。
+引数の解釈が賢くて、--draftならドラフト、ブランチ名っぽい文字列ならベース指定、それ以外はコミットメッセージ。覚えなくても適当に打てば通ります。
+既にPRがある状態で叩くと、新しく作らずに本文を今の差分に合わせて書き直します。実装が変わったのに説明文が古いまま、が無くなる。
+で、このスキルが一番重視しているのは事故防止です。mainで直接コミットしようとすると止まる。これは何度か救われてます。
+もうひとつが下のブロック。qa や staging に feature ブランチから直接PRを出すと、そのブランチをマージしたときに環境固有のコードが main に流れ込む。これを止めて、cherry-pick方式に誘導します。ブランチ運用の事故って気づいたときには手遅れなので、コマンドの側で止めてくれるのはかなり効きます。
【5:05-6:15】
+3つめ、review。第二引数でレビュアーをcodexやgeminiに差し替えられます。自分が書いたコードを自分でレビューしても甘くなるので、別のAIに渡すと普通に知らない指摘が出てきます。
+中身で面白いのは、観点に優先順位が付いていることです。「いい感じにレビューして」だと指摘が散らかるので、言語慣用性から順に見ろと明示してある。
+チェックポイントも具体的で、関数50行・ファイル300行という数字まで書いてあります。ただし「プロジェクトの慣例が優先」と但し書きが付いていて、数字を機械的に当てはめないようになっています。
+個人的に効くと思っているのが下の2つ。重複コードはPRの範囲外でもまとめろと書いてある。あとマジックナンバーを見つけたときに、定数にすればいいという話にしないで、DBのマスタやyamlに出せないか考えろと。定数化って一見きれいですが、運用で変わる値を定数にすると次はデプロイが必要になるんですよね。
【6:15-7:20】
+同じくreviewですが、こっちは指摘の書式の話です。
+先頭に重要度とカテゴリを付ける。これは見やすさのためだけじゃなくて、この重要度が後段の自動修正の判断に直結しています。criticalとmajorは必ず直す、nitは直さないで最後に人間に見せる。つまりラベルが処理の分岐になっている。
+なので「過剰なnit量産は避けろ」とも書いてあります。AIにレビューさせると、どうでもいい指摘を大量に出して仕事した感を出しがちなので、そこを抑えにいっています。
+もうひとつ、指摘は必ずコード行に紐付けろというルール。総評に「〇〇が気になります」って書かれても、どこの話か探すところから始まるので。総評に書いていいのは設計レベルの話だけです。
【7:20-8:05】
+4つめ、cross-review。codexとgeminiの両方にPRレビューを投げて、両者がAPPROVEを返すまでレビューと修正を自動で回し続けます。
+片方がAPPROVEでも、もう片方が指摘を出していれば止まらない。
+デフォルトは最大12ラウンド、8ラウンドで収束しなければPRをローテーションします。修正はサブエージェントに投げるので、メインの会話ログは汚れません。
+このスキルで一番よくできているのが次のページです。
【8:05-9:15】
+cross-reviewの本体はここだと思っています。
+PRの変更ファイルを全件取って中身で分類し、その種類に効く観点だけを両方のAIに渡します。ドキュメントだけのPRにN+1の話をされても困るし、マイグレーションを含むPRでロールバック手順を聞かれないのも困る。それを自動で切り替えている。
+表に出したのは一部で、全部で15分類あります。マイグレーションならbackfillとロールバック、認証まわりならsecretとPIIとCSRF、という具合です。
+これに加えて --focus で今回だけの観点を足せます。長いチェックリストを渡したいときはファイルでも渡せる。
+重い処理なので、単発の第二意見が欲しいだけなら前のページの /ndf:review でいいです。そこは使い分けてください。
【9:15-10:25】
+5つめ。実装が終わったプランを仕様書に変換します。
+ポイントは移動じゃなくて書き直しだということ。プランには「まずAをやってからBをやる」みたいな作業順とか、途中でやめた案とか、AI向けの作業指示が入っていて、それは仕様じゃないので全部落とします。
+面白いのが語尾の変換ルールまで書いてあることで、「実装する」は「提供する」に、「修正対象」は「構成」に直す。プランは未来形で書かれていて、仕様書は現在形であるべきなので。細かいですが、これがないと「実装する」が残ったまま仕様書として置かれて、読んだ人が「これまだ実装されてないのか」と誤解します。
+最後に実コードと照合する手順まで入っています。書いた設定名やファイルパスが本当に存在するか、逆に実装にある重要な挙動が抜けていないか。仕様書が嘘をつかないようにする工程ですね。
【10:25-11:40】
+6つめ、markdown-writing。v4.20で体裁ルールから可読性ルールに拡張されたやつです。
+一番効くのは1番。説明文にテーブル名やカラム名をそのまま書かせない。例を見てください。上は書いた本人には完璧に伝わるけど、読む側には何ひとつ伝わらない。書いた側が説明した気になるのが厄介なところです。
+2番3番は、AIに書かせると必ず出るやつです。「案Aを採用しました」とか「指摘を受けて修正しました」とか。それは文書じゃなくてgitとPRに置け、と。文書には「今何が正しいか」だけ書く。
+4番は次のページで詳しくやります。
+7番は分量ルールですが、単純な行数制限じゃなくて「分割すると理解が落ちるなら分けるな」と例外が書いてあります。
+あと、書き終わったあとに走らせるgrepまで用意されています。案Aとか、以前は、みたいな語を機械的に拾う。人力チェックリストで終わらせてないのが良いところです。
【11:40-12:50】
+7つめ。この2つはセットです。
+左のinvestigation-rules。「無い」と書くなら実行結果を貼れというルール。AIはコードを読んだだけで「該当なし」と自信満々に断言するので、それを止めるためのものです。実例として、外部テーブルの一部のカラムだけ見て「該当カラムなし」と結論づけたけど、実は別名のカラムにデータがあった、という失敗がスキルの中に書いてあります。
+下の一文が個人的に好きで、エビデンスなしで残課題の優先度を「低」にするのは誤判断の典型、と名指しされている。優先度を下げるのって実質「やらない」なので、そこにこそ根拠が要る。
+右のproblem-solving。データがおかしいときに、そのデータだけ直して終わりにするな、と。なぜ入ったかを遡って、入口にバリデーションを足してから直す。あとコードの修正とデータの修復を別コミットにしろと。混ぜるとRevertできなくなるので。
【12:50-13:40】
+CodexとKiroです。ここは「同じものが使える」ということだけ持って帰ってください。
+Codexはマーケットプレイス方式で、Claudeとほぼ同じ2コマンド。セッションに入るとndfコロン付きでスキルが並びます。実際に叩いて30個読み込まれているのを確認済みです。
+Kiroだけ方式が違って、リポジトリをcloneしてinstall.shを叩きます。.kiro/skills/ 以下にスキルが並んで、エージェント定義も一緒に作られます。何度実行しても壊れないので、更新したら叩き直せばいいです。
【13:40-14:30】
+まとめです。
+今日いろいろ見てきましたが、共通しているのは、どのスキルにも「何をやるか」の前に「何を重視するか」が書いてあることです。レビューなら観点の優先順位、文章なら誰に向けて書くか、調査なら何を根拠とするか。
+そこって人によってブレるところで、しかも指摘しづらいところなんですよね。それをスキルに落として揃えているのが、このプラグインの一番の中身だと思っています。
+まずは次のPRで pr と review を叩いてみてください。質問あればどうぞ。
+
+編集するのは `plugins/ndf-shared/` の **1か所だけ**。そこから3ランタイム分の配布物が生成されます。
+ほかに MCP プラグインが **10個**（Serena / BigQuery / Playwright / Chrome DevTools / Redash など）。
+
+
+
+
+
+---
+
+# インストールは2コマンド（Claude Code）
+
+```bash
+# 1. マーケットプレイスを登録（初回だけ）
+/plugin marketplace add https://github.com/devbasex/ai-plugins
+
+# 2. NDFを入れる
+/plugin install ndf@ai-plugins
+```
+
+入れると使えるようになるもの:
+
+| | |
+|---|---|
+| **スキル 29個** | `/ndf:pr`, `/ndf:review` … スラッシュで直接呼べる |
+| **エージェント 8個** | director / corder / qa / debugger / devops-engineer など |
+| **フック 2種** | SessionStart（transcript保持を90日に維持）/ Stop（AI要約+Slack通知） |
+
+
+
+---
+
+# 今日の地図: PRを1本出すまで
+
+
+
+この4つに加えて、**全工程に効く「書き方・調べ方」のルール**が3つあります。
+
+| スキル | 何を揃えるか |
+|---|---|
+| `/ndf:markdown-writing` | 会話も検討過程も知らない第三者に伝わる書き方 |
+| `/ndf:investigation-rules` | 「無い」と書くならエビデンスを添える |
+| `/ndf:problem-solving` | つじつま合わせをせず、上流で直す |
+
+
+
+---
+
+# ① `/ndf:implementation-plan` — 作る前に書く
+
+
+
+
+### 書いてあること
+
+`issues/` に置くプランの**雛形**。
+概要 / 問題・背景 / 修正対象 /
+タスク分解 / 影響範囲 / テスト計画。
+
+**作るケース**
+複数ファイル・新機能・
+既存ロジックの大幅変更・DBマイグレーション
+
+**作らないケース**
+typo / 設定値だけ / 1ファイルの軽微な修正
+
+
+
+
+### 重視していること
+
+**「なぜ」を残すこと。**
+後任か将来の自分が変更意図を追える状態にする。
+
+プランとPR本文の役割を分けています。
+
+| | 役割 |
+|---|---|
+| プラン | 「なぜ」「どう分解するか」の永続記録 |
+| PR本文 | 「何をやったか」のレビュー用サマリ |
+
+
+
+
+
+### 書いてあること
+
+引数の解釈ルール（`--draft` / ブランチ名 /
+それ以外はコミットメッセージ）、
+PR本文の組み立て方、
+既存PRがある場合の**本文更新**手順。
+
+
+
+
+### 重視していること
+
+**事故を止めること。**
+デフォルトブランチへの直接コミットを拒否。
+`qa/*` などへの直接PRも止めて
+`/ndf:cherry-pick-pr` に誘導します。
+
+
+
+
+最大12ラウンド。8ラウンドで未収束ならPRをローテーション。修正はサブエージェントに投げるのでメインの会話は汚れません。
+
+
+
+
+
+---
+
+# ④ `/ndf:cross-review` — 観点はPRの中身で切り替わる
+
+変更ファイルを全件取得して分類し、**該当する観点テンプレートだけ**を両AIに渡します。
+
+
+
+
+| 分類 | 渡される観点 |
+|---|---|
+| `docs_only` | 説明の妥当性、コード・設定との整合 |
+| `db_migration` | 型、NULL/default/制約/index、backfill、ロールバック |
+| `api_contract` | 互換性、schema、エラー形式、認可 |
+| `auth_security` | secret/PII、CSRF/CORS/JWT/OAuth |
+| `performance` | N+1、I/O、ロック、cache、冪等性 |
+
+
+
+
+ほかに `code` / `test` / `dependency` /
+`config_ci` / `frontend` /
+`deletion_rename` / `generated` /
+`i18n` / `infra` の全**15分類**。
+
+```bash
+/ndf:cross-review 123 \
+ --focus "ドキュメントとコードの整合性"
+```
+
+今回だけの観点は `--focus` で追加。
+長いチェックリストはファイルで渡せます
+（`--extra-instructions-file`）。
+どちらも自動テンプレートの後ろに乗ります。
+
+
+
+
+
+### 書いてあること
+
+`docs/` 配下の標準章立て。
+概要 / 背景 / 対象範囲 / 仕様 /
+データ・設定 / 外部連携 / エラー処理 /
+セキュリティ / 運用 / テスト観点 / 関連リンク
+
+**消すもの**
+実装タスクのチェックリスト、PR分割計画、
+作業担当、破棄された方針、調査メモ、
+AIエージェント向けの作業指示
+
+
+
+
+### 重視していること
+
+**移動ではなく書き直し。**
+プランは作業中の意思決定記録なので、
+完了後は「今のコードと一致する記述」だけを残す。
+
+語尾まで変換ルールがあります。
+
+| プラン | 仕様書 |
+|---|---|
+| 実装する | 提供する / 保持する |
+| 修正対象 | 構成 / 関連ファイル |
+| テスト計画 | テスト観点 / 検証方法 |
+
+
+
✅ 利用者の契約プランを変更 |
+| 2 | 検討過程の痕跡を残さない | 「案A」「壁打ちの結果」「先ほど決めた」 |
+| 3 | 変更履歴を本文に残さない | 「以前はXだったが指摘を受けてYに変更した」 |
+| 4 | 否定的な結論にはエビデンスを添える | 未確認は「残リスク」として明示。省くと確認済みと読まれる |
+| 5 | 個人情報・機密情報を書かない | コミットメッセージは後から消しにくい |
+| 6 | 図はインラインで書く | mermaid / math。plantUML・HTML・`