Create-doc — スライド作成スキルに渡す構成案を作る

研究の記録（実行記録 md、結果 CSV、図、コード）を読み、1枚ずつ「何を言うか・どの型で見せるか・何を載せるか・何を話すか」が決まった構成案 を Markdown で書く。

渡す先は progress-report-deck スキル（同じ research-slides プラグインに入っていて、このスキルの隣のフォルダ ${CLAUDE_SKILL_DIR}/../progress-report-deck/ にある）。このスキルの出力は、progress-report-deck が「## 見出し1つ＝スライド1枚」として読み、テンプレートの型に流し込むことを前提に作る。作業を始める前に ${CLAUDE_SKILL_DIR}/../progress-report-deck/SKILL.md を読み、下の「スライド作成スキルとの約束」と食い違っていないか確認する（向こうのルールが変わっていたら、向こうに合わせる）。見つからなければ、この約束どおりに書けばよい。

利用者のプロフィール ~/.claude/yapi-skills/profile.md（氏名・研究分野・主な聞き手・独自ルール）があれば最初に読む。独自ルール（配色・最小の文字サイズなど）は下の約束より優先し、構成案の「この資料について」にも書き写す。

構成案の見本は references/template.md。書式に迷ったらこれに合わせる。

スライド作成スキルとの約束（progress-report-deck のルールから来ているもの）

構成案はこれを守って書く。守らないと、スライド化の段階で削られたり、作り直しになったりする。

項目	約束	理由（progress-report-deck 側のルール）
見出し	`##` 1つ＝スライド1枚。補足も含めて `##` はスライドにしか使わない。章の区切りには `#` を使う	下書きの `##` をスライドとして読む
骨格	タイトル → 今回行ったこと（目次） → 研究背景(1/2)(2/2) → 研究目的（今回の小目標） → 内容 → まとめ・課題 → ご清聴ありがとうございました、の順	テンプレートの固定骨格
研究背景	前回から変わらなければ「据え置き（ベースの資料のまま）」と書くだけで中身は書かない	研究背景は基本据え置き
今回の小目標	研究目的スライドに「今回の小目標」の文言を必ず書く（1〜2行）	向こうが毎回ユーザーに聞く項目。先に決めておく
枚数	最終の枚数で書く（向こうで統合・分割しなくて済むように）	向こうは `##` が多いと統合を提案してくる
型	内容スライドにはレイアウトの型を1つ指定する（下表）	箇条書きを流し込むと「下半分が空白」と指摘される
配色	色の意味は2つだけ: 青＝提案・対応・結論・主役の数値、オレンジ＝従来手法・問題・指摘・注意。手法ごとに3色目を割り当てない。表では主役の行を「淡青で強調」と書く	テーマの青 #156082 とオレンジ #E97132 の2色のみ
文字量	主張は全角30字以内（全幅18ptで1行に収まる量）。箇条書き1項目も30字前後まで。1パネル3行まで。長くなるなら図か表にするか、スライドを分ける	文字は16pt以上が必須で、縮めて詰め込めない
文字の大きさ	「小さく」「注釈は小さい字で」などの指示を書かない。脚注も16ptで入る長さ（1行）にする	16pt未満は禁止
数式	$...$ （LaTeX 記法）で書き、「数式（OMML）」と明記する	数式は OMML で組む
図	出力フォルダの `images/` にコピーした png を `images/<名前>.png` で指定する（pdf しか無ければ png に変換して入れる）。リポジトリ内のパスや `../` は書かない。縦横比が 4:3 のスライドに収まるかも意識する（横長の図2枚を縦に並べる、など）	pptx には png を貼る。スライドは 4:3。スライドは別のフォルダや別の端末で作ることがあり、フォルダの外は見えない
模式図	図ファイルが無く図式で見せたいもの（処理の流れ、タイムライン、従来→提案の対比）は、型名と描き方を具体的に書く	向こうが「図版の扱い」をユーザーに聞かずに済む
ノート	話す内容は「ノート」に書く。スライドには載せない	—
補足	質疑用の補足スライドは「ご清聴ありがとうございました」の後ろに置く	クロージングは本編の最後

指定できるレイアウトの型（progress-report-deck の assets/template.pptx にある実例）:

型	使いどころ	template.pptx の実例
チップ＋パネル（問題→対応）	「従来の問題 → 今回の対応」「指摘 → 対応」	p.7, p.11
番号バッジ＋パネル	①②③と番号が付く項目の列挙（利点、手順）	p.8-9
Before/After 模式図	従来手法と提案手法の対比（左＝オレンジ枠、右＝青枠、間に矢印）	p.10
タイムライン模式図	時間方向の処理の流れ（実線／破線ボックス＋コネクタ）	p.12
2カラムのチップ＋パネル＋下帯	2つの手法・設定を並べて比較、数式入り	p.13
表＋全幅の帯	結果の表と、その下に「読み取れること」の帯（主役の1本は濃紺塗り）	p.14
KPIタイル（2×2）	数値や結論4点を大きく見せる	p.15
チェックリスト（✓）	確認したこと・やったことの列挙	p.16
枠線ボックス2段	まとめ／今後の展望	p.17
図＋全幅の帯	既存の図を大きく貼り、下に読み取れることを帯で	（p.14 の表を図に置き換え）

目次（今回行ったこと）は型を付けない（箇条書きのまま、キーワードだけ太字。色は付けない）。

進め方

1. 要件を聞く（AskUserQuestion、1回にまとめる）

会話や依頼文から分かるものは聞かない。分からないものだけ聞く。

発表の種類と長さ: 進捗報告 / ゼミ / 学会。枚数の目安は内容スライド1枚≒1分（15分なら内容スライド10枚前後＋骨格の5〜6枚）
聞き手: 研究室メンバー / 学会 / 他分野の人。前提知識の量が変わる
含める周辺情報（複数選択）: 動機・経緯、比較実験、失敗分析、手法の変遷、バグ修正の影響など。候補は記録を読んで見つかったトピックから出す
研究背景を据え置きにするか: 前回の資料から変えるなら、変える内容

ユーザーが選択肢に無い自由記述で答えたら、それも要件として扱う（例:「きっかけに〇〇も入れて」）。

2. 材料を集める（読むだけ。実験の再実行はしない）

スライド作成スキル: ${CLAUDE_SKILL_DIR}/../progress-report-deck/SKILL.md（上の約束の確認）
記録: 実行記録_*.md、*結果*.md、README.md、方針書など。日付の新しいものから読む
数値: summary/*.csv、*.md の表。発表に載せる数値は必ずここから転記する
図: 既存の png を ls で探す。日本語ラベルの図があればそちらを優先する。使う図の元のパスを控えておく（手順4で images/ にコピーし、出典にも書く）
設定値: 補足スライドに載せるハイパーパラメータ・定数・モデル構成は、記録 md ではなくコードの実際の値（定数、argparse の既定値、実行時に保存された設定 json）から取る。記録とコードが食い違っていたらコードを正とし、ユーザーに伝える

3. 構成を決める

骨格（progress-report-deck のテンプレートに合わせる）:

タイトル
今回行ったこと（目次。内容スライドの見出しを短く並べる）
研究背景 (1/2)
研究背景 (2/2)
研究目的（目的＋今回の小目標）
〜内容スライド
まとめ・課題
ご清聴ありがとうございました
補足スライド（質疑用）

内容スライドはおおむねこの流れにする（枚数に合わせて足し引きする）:

動機・課題（なぜこれをやったか）→ チップ＋パネル
提案・変更の内容と利点 → Before/After 模式図か番号バッジ＋パネル
手法の詳細（処理の流れ）→ タイムライン模式図
正しさの担保・検証 → チェックリスト
パラメータの決め方 → KPIタイルか表＋帯
実験設定（データ、比較手法、評価指標）→ 2カラムか表＋帯
結果（主張1つにつき1枚）→ 表＋帯、図＋帯
コスト・制約 → 表＋帯か KPIタイル

補足スライド（質疑用）を必ず付ける。発表時間には含めない。

詳細設定（モデル・最適化・定数の表）
データ・シミュレーションの設定
比較手法の詳細（数式は OMML 指定）
評価指標の厳密な定義
パラメータ探索などの全結果表
想定質問と回答例（8問前後）: これだけはスライドにしない（# の章として構成案の末尾に置く、発表者の手元用）。「差が小さくないか」「1回の試行で言えるのか」「なぜこの比較対象なのか」「計算コストは」「未検証の主張の根拠は」など、弱点を突く質問を優先する

4. 書く（フォルダにまとめて出力する）

スライドは progress-report-deck で、別のフォルダや別の端末（PowerPoint のある PC など）で作ることがある。そのため、構成案と使う画像を1つのフォルダにまとめて出力し、そのフォルダだけ持っていけばスライドが作れるようにする。

スライド作成ドキュメント-<日付>/
├── スライド作成ドキュメント-<日付>.md   ← 構成案
└── images/
    ├── speed_sweep.png
    └── ...

フォルダ名と md のファイル名は スライド作成ドキュメント-<日付> に統一する（例: スライド作成ドキュメント-2026-10-15/）。日付は作成日を YYYY-MM-DD で書く。同じ日に別の発表用を作るなど名前がぶつかるときは、日付の後ろに短い識別子を足す（例: スライド作成ドキュメント-2026-10-15-ゼミ/）。既存のフォルダは上書きしない。プロジェクトのルート直下に作る
画像: 構成案で使う図をすべて images/ にコピーする（移動ではなくコピー。元のファイルは触らない）
- ファイル名は元の名前のまま。名前がぶつかるときや中身が分かりにくい名前（fig1.png など）のときは、内容が分かる英数字の名前に付け替える（例: velocity_field_f195.png）。空白は使わない
- pdf しか無い図は、png に変換して入れる（例: pdftoppm -png -r 200 -singlefile in.pdf images/name、または PyMuPDF で 200 dpi）
- 構成案の中では images/<名前>.png で参照する
- 元のパスは「出典」の章に「images/xxx.png ← 元のパス」の形で残す（あとで図を作り直すときに辿れるように）
模式図（図ファイルが無いもの）は画像を作らず、構成案に描き方を書く

冒頭の「この資料について」（# の章、スライドにしない）に、progress-report-deck への指示を書く:

発表の種類・長さ・枚数・聞き手
各スライドの書式（下記）
数値は改変・丸め直ししないこと
このフォルダを作業フォルダにして progress-report-deck を実行すること。図はこのフォルダの images/ に入っていて、images/<名前>.png で指定していること。新しい図は作らないこと（模式図は指定どおり描く）
手法名の表記ルール、配色の割り当て（青＝提案、オレンジ＝従来・比較手法）
研究背景を据え置きにするかどうか

各スライドの書式:

## スライドN — <タイトル>

- **型**: <レイアウトの型（上の表から1つ）>
- **主張**: <全角30字以内の1文。このスライドで一番言いたいこと>
- **本文**: <箇条書き。1項目30字前後、3〜4項目まで>
- **表** / **図**: <表は Markdown で、強調する行・列を書く。図は `相対パス.png`（何の図か）>
- **数式（OMML）**: <あれば $...$ で>
- **ノート**: <話す内容。スライドには載せない>

書くときの決まり:

主張は結論を書く。「結果①」「〇〇について」「〇〇を示す」ではなく「速度が上がるほど差が開く」。です・ますで終えない
評価語は数値で裏づける。「大幅に」「有効」「優れた」と書くなら、同じスライドに比較対象・指標・試行回数を置く。「同等」「保証」は言い過ぎになりやすい（「ほぼ同等」「確認した」）
生成した文章にありがちな語（非常に／画期的／〜することが可能／シームレスなど）は使わない。リストと置き換え例は ${CLAUDE_SKILL_DIR}/../progress-report-deck/references/ai-smell-lexicon.md
本文の箇条は1項目1文（「。」でつながる2文は分ける）
未検証のことは未検証と書く。期待される性質と、実験で示したことを混ぜない。該当スライドの本文か帯に1行入れ、まとめ・課題の「今後」にも載せる
公平な比較のための条件（収束させた設定を使った、など）は脚注1行で書く。経緯の長い説明は、ユーザーが含めると言った場合だけ書く
スライドに載せきれない詳しい説明はノートか補足スライドへ回す。本文を長くしない
最後に「出典」の表（内容 → ファイル）を # の章として付ける

5. 検証する（必ずやる）

数値の機械照合: 構成案に出てくる小数をすべて正規表現で抜き出し、出典の md / CSV（CSV は4桁・2桁に丸めた値）に含まれるか照合する。見つからないものは、自分で計算した差分か、転記ミスか、丸めの不統一かを1つずつ確かめて直す。照合スクリプトは scratchpad に置く
フォルダの自己完結: 構成案中の図の参照がすべて images/ 配下の png で、そのファイルが実在すること。../ や絶対パス、リポジトリ内のパスが残っていないこと。逆に images/ に参照されていない余計なファイルが無いこと。フォルダの合計サイズも報告する
図の中身: 図について何か言っている文（「〇〇で大きい」など）は、図を実際に開いて見て、合っているか確認する
約束の機械チェック: ## の数が想定のスライド枚数と一致する、全スライドに「型」がある（骨格スライドを除く）、3色目の配色指示が無い。主張の長さ（全角30字以内）・主張が結論になっているか・AI 臭のする語・表記ゆれは、スライド作成スキルの検査スクリプトで調べる:
```
python "${CLAUDE_SKILL_DIR}/../progress-report-deck/scripts/check_deck.py" --text "<構成案.md>" > check_doc.txt
```
出力を Read で読み、WARN を直す（研究上正しい言い方なら残してよい）。最後の行が DONE: … でなければ検査が落ちているので、0件と見なさない。スクリプトが見つからなければ、この項目は目で確かめる
枚数: 本編が要件の枚数に収まっているか数える

6. 報告する

1行目に想定した読み手（例:「想定読者: progress-report-deck スキル（その先に研究室ゼミの聞き手）」）
出力したフォルダのパスと中身（md 1つ＋画像の枚数・合計サイズ）
構成（各スライドを1行ずつ）と補足の中身
検証の結果（照合した数値の数、図の確認、約束のチェック）
発表前にユーザーが知っておくべき点: 未検証の主張、突っ込まれやすい数値とその理由、使った結果がいつの・どのコードのものか
次の一手: 「このフォルダで（別の端末ならフォルダごとコピーしてから）progress-report-deck を実行すればスライド化できる」と伝える。持ち運び方（USB、Box/OneDrive、zip にしてから送る等）はユーザーに任せる
コミットはしない（頼まれたらする）

スライド構成案作成スキル（create-doc）