powerpoint-slides

PowerPoint スライドのワークフロー

学術的な PowerPoint プレゼンテーションを作成するためのスキルです。全ライフサイクルに対応します： 作成 → コンパイル → レビュー → 仕上げ → 検証。

実行モデル：Claude が PptxGenJS（Node.js）スクリプトを作成 → 実行 → .pptx。 数式：OMML（ネイティブ数式、デフォルト）または LaTeX → PNG/SVG パイプライン（段落モードの代替手段）。

---

0. クイックリファレンス

タスク	コマンド	説明
論文から作成	create [topic]	フェーズ 0～5 の全パイプライン
JS スクリプトを実行	compile [file.js]	スクリプトを実行し、.pptx を生成
校正	review [file.pptx]	文法、誤字、整合性
ビジュアル監査	audit [file.pptx]	スライドごとのレイアウト検査
教育品質	pedagogy [file.pptx]	13 の教育パターン
全体レビュー	excellence [file.pptx]	5 つのエージェントによる並列レビュー
ビジュアルチェック	visual-check [file.pptx]	PDF→画像による体系的なチェック
指標を検証	validate [file.pptx] [duration]	スライド数、ファイルサイズ
図を抽出	extract-figures [file.pdf] [pages]	スライド用に論文の図を抽出

$ARGUMENTS を解析して、実行するアクションを決定します。アクションが指定されていない場合は、確認してください。

---

1. 厳守ルール（必須）

1. 形式化する前に動機を示す — すべての概念は「何を？」ではなく「なぜ？」から始めます。定義を文脈なしに提示してはいけません。
2. 2枚以内のスライドで具体例を示す — すべての定義について、導入から2枚以内のスライドで具体的な例を用いて解説します。
3. 電文調のスタイル — 完全文ではなくキーワード句を使います。スライドは原稿ではなく、話者向けのプロンプトです。例外として、文脈を示すための導入文を各スライドに1文だけ入れます。
4. すべてのスライドに役割を持たせる — 数式、図、表、定理、アルゴリズム、グラフのいずれかを少なくとも1つ含めます。短い箇条書きが3つあるだけで、それ以外に何もないスライドは、統合するか内容を充実させます。
5. 1枚あたりのアクセントカードは最大2つ — 多すぎると強調効果が薄れます。アクセントカードとは、色付きのボックス、吹き出し図形、強調表示された領域です。優先度の低い項目は通常のテキストにします。
6. 参考文献スライド — 最後から2枚目（「Thank You」の直前）に、主要な引用文献を列挙します。主要論文と、関連性の高い参考文献を3～5件含めます。
7. 色覚多様性に配慮したパレット — 青とオレンジの組み合わせを推奨します。二項対比に赤と緑は決して使いません。背景上のテキストは、WCAG AA のコントラスト比 4.5:1 以上を確保します。テーマ内で意味に応じた色を定義します。
8. フォントサイズの階層 — F 定数オブジェクトでデフォルトの基準値を定義します。表紙 48pt、セクション 36pt、タイトルバー 22pt、本文 15pt、小 12pt、キャプション 11pt、カードタイトル 18pt、表見出し 13pt、表セル 12pt。10pt 未満は使用しません。カードや領域の内容が少ない場合（テキストが使用可能領域の <50%）、QA 修正時にサイズを 2～4pt 大きくします。
9. 補足スライド — 「Thank You」の後に3～5枚配置し、付録の区切りスライドを間に入れます。想定される質問に備えて、詳細な証明、拡張比較、追加データを含めます。
10. 各タスクの後に検証する — JS → soffice → PDF → 画像検査を実行します。目視検証を行うまで、タスクは完了ではありません。
11. AI 特有のアクセント線を使わない — タイトルのすぐ下に装飾線を置いてはいけません。AI 生成スライドの典型的な兆候であり、プロらしく見えません。
12. レイアウトに変化をつける — 同じ種類のレイアウトを3枚以上連続して使ってはいけません。全幅、2段組み、数式中心、統計データ強調、アイコングリッド、タイムライン、表、グラフなどを交互に使います。
13. 数式の描画 — 表示数式とインライン数式には OMML（PowerPoint ネイティブの数式）をデフォルトで使用します。段落モードの数式には PNG@600DPI または SVG を代替として使用します。ぼやけた画像数式は認められません。
14. 16:9 レイアウト、余白 0.5" — LAYOUT_16x9（10" x 5.625"）を使用します。上下左右すべてに 0.5" の余白を確保します。コンテンツ領域：9" x 4.625"。
15. PptxGenJS のオプションオブジェクトを再利用しない — ライブラリはオブジェクトをその場で変更します（例：影の値を EMU に変換）。呼び出しごとに必ず新しいオブジェクトを作成します。ファクトリー関数を使用します：const makeShadow = () => ({...})。
16. 16進数カラーコードに # を付けない — "#FF0000" ではなく "FF0000" を使用します。# を付けると出力ファイルが警告なく破損します。
17. ビジュアルテーマの一貫性 — 選択したパレットをスライド背景、テキスト色、数式の前景色、グラフの色、アクセントカードの塗りつぶし色、区切り線に一貫して適用します。テーマにない色は使いません。
18. Unicode による数式の近似表記を使わない — カードやテキストボックス内の通常のテキストとして、Unicode の下付き文字（₀、₁）、上付き文字（ᵖᵉ）、特殊な数学記号（∑、∏、∈、∀、∝）を使ってはいけません。インライン数式、下付き文字付き変数、数式中のギリシャ文字を含むすべての数学表記は、OMML（推奨）または LaTeX 画像パイプライン（段落モード用）で描画する必要があります。テキストと数式が混在するカード本文では、個々の数式に OMML プレースホルダーを使うか、本文全体を1つの LaTeX 画像として描画します。例外は、単純なラテン文字1字（x、y、n）と演算子を含まない通常の数字のみです。
19. 縦方向のコンテンツ配分 — タイトルバーより下のコンテンツが、縦方向に CH の ≥75% を占めるようにします。すべての要素が上半分で終わる場合は、何かが間違っています。カードの高さを増やす、間隔を空ける、フォントを大きくする、または下部にまとめ・洞察カードを追加します。すべてのコンテンツスライドが「埋まって」見えるようにし、最後の要素の下に大きな空白を残しません。
20. コンテンツ密度の下限 — 短いテキストのみの箇条書きが3つ以下で、数式、図、表、カードのないスライドは内容が少なすぎます。隣接するスライドと統合するか、視覚要素を加えて充実させます。テキストのみのスライドは、デッキ全体の ≤20% にします。各カードには、内側の領域の ≥40% を満たすだけのテキストを含めます。足りない場合はフォントを 2～4pt 大きくするか、カードを統合します。
21. 境界の検証 — すべての要素について y + h ≤ SH - M（5.125"）を満たす必要があります。スクリプト生成時に、各要素の下端を必ず確認します。よくある落とし穴：表の描画後の高さを考慮せずに表の下にカードを重ねること、カード本文領域より高い数式画像を addCardFormula に渡すこと、2段のカードレイアウトで2段目がはみ出すこと。addCardFormula を使う場合、数式の高さパラメーター fH は cardH - 0.75（タイトル領域）以下にします。内容が収まらない場合は、カードの高さを減らす、数式の targetH を小さくする、または2枚のスライドに分けます。ビジュアル QA エージェントは、下端がスライドの境界で切れている要素を必ず検出します。
22. 参考文献スライドの書式 — 必ず1段組みレイアウトにします。CH を N 件の参考文献に均等配分し、各項目をその行の中央に縦方向で配置します。フォントは F.body.size（件数が多い場合は F.small.size）を使用します。区切り線や装飾要素は使わず、ページ全体に均等に配置したテキスト行だけにします。1ページあたり8件を超える場合は、2枚目の参考文献スライドに続けます。参考文献スライドは均等に埋まって見えるようにし、上下に大きな空白を残しません。
23. OMML の後処理とサイズ設定 — PptxGenJS で .pptx を生成した後、inject_omml.py を実行し、{{MATH:id}} プレースホルダーをネイティブの OMML 数式に置き換えます。出力に {{MATH: プレースホルダーが残っていないことを確認します。OMML 数式が LibreOffice で空白または歪んで表示されるのは想定どおりであり、バグではありません。ビジュアル QA では画像数式の鮮明さだけを確認します。重要な OMML サイズ設定ルール：OMML 数式はテキストボックスの高さ制約を無視し、テキストボックスのフォントサイズで描画されます。\sqrt{}、\frac{}{}、\sum、\prod などの背の高い構造は、テキストボックスから視覚的にはみ出します。重なりを防ぐため、（a）OMML 数式をカードや表のすぐ上または下に配置しないでください。階層の深さ（分数、根号、大きな演算子）ごとに、縦方向に ≥0.15" の余分な間隔を設けます。（b）根号、分数、または縦に積み重なる演算子を含む複雑な数式では、正確なピクセル寸法に収まる画像描画（formulas.json の "render": "image"）を優先します。（c）F.body.size（15pt）で addMathText を使う場合、単純な数式の描画高さは約 0.4"、\sqrt{} または \frac{}{} を含む数式では最大 0.7" になることを想定します。（d）OMML 数式を2つの要素の間に配置する場合は、数式の高さを targetH パラメーターの1.5～2倍として間隔を計算します。
24. 図のエンジン選択 — 構造図・フロー図（アーキテクチャ、依存関係、比較、ツリー）には Graphviz を使います。動作図・時間軸図（シーケンス、状態、ガント、ER）には Mermaid を使います。TikZ は、数学的に複雑な図、または論文に忠実な再現に限って使います。シーケンス図に Graphviz を使わず、複雑なノードレイアウトに Mermaid を使いません。
25. 図のテーマの一貫性 — 描画するすべての図に、現在のテーマの色を使用します。ノードの塗りつぶし色 = cardFill 相当、境界線 = ac.pos、テキスト = tx.pri。Graphviz／Mermaid のデフォルトカラー（青／黒）は最終出力に表示させません。render_diagrams.py に --theme を渡します。
26. テキストのはみ出し防止と余白 — PptxGenJS のテキストボックスは、はみ出したテキストをクリップしません。ボックスを超えたテキストは外側に描画され、下の要素と重なります。必須の対策は3つです。（a）すべてのテキストボックスに shrinkText: true を指定します（<a:normAutofit/> に対応）。autoFit: true は絶対に使わないでください。これは図形を拡張する <a:spAutoFit/> に対応します。（b）カードのテキストには const px = x + 0.25, pw = w - 0.4 を使用し、アクセントバーから 0.19"、右端から 0.15" の余白を確保します。タイトル：(px, y+0.1, pw, 0.4)、本文：(px, y+0.48, pw, h-0.62)、margin: [2, 0, 8, 0]。（c）縦方向の間隔を厳守する：ある要素の下に配置する要素はすべて、前の要素の下端から ≥0.1" 離して配置します。スクリプト生成時の確認には gap() ヘルパーを使用します。カード／数式の間に置く単独の addText 呼び出しは、重なりのバグの主な原因です。y 座標を概算せず、必ず直前の要素の確定した下端から計算します。コンテンツ量の上限：カード本文は、本文領域の高さ1インチあたり短い行を ≤4 行にします。さらにテキストが必要な場合は、カードの高さを増やすか、内容を分割します。
27. 図の出典表記 — 論文から抽出した図には、addFigure() のキャプションを使って出典表記（Source: Author et al., Year）を含める必要があります。幅が <800px の場合は、投影時にぼやける可能性があることをユーザーに警告します。表は決して抽出せず、PptxGenJS の addTable() で作り直します。
28. ビジュアル優先の計画 — 聴衆は箇条書きではなく、視覚的な手がかりを通じて構造を理解します。フェーズ2では、各スライドについて「テキストだけで、聴衆が10秒以内に内容を理解できるか？」と確認します。できない場合は、図、表、グラフ、図版などの視覚要素が必要です。複数段階のプロセス、構成要素間の関係、データの比較、階層、数値の推移などは、文章より視覚要素がほぼ常に適しています。フェーズ2のセルフチェック：各セクションに数式以外の視覚要素を ≥1 つ含めます。視覚要素がまったくないスライド（図、表、グラフ、図版のいずれもない）は、デッキ全体の ≤30% に抑えます。
29. 表セル内の数式 — 表セル内の数学表記（O(n)、ε、∑_{i} など）は、通常のテキストや Unicode の近似表記ではなく、OMML プレースホルダー（{{MATH:id}}）を使う必要があります。各セルの数式を "render": "omml" として formulas.json に追加します。OMML はセルのフォントサイズ（F.tblCell.size = 12pt）を自動的に継承します。セルの高さからはみ出す複雑な構造（分数、大きな演算子、縦に積み重なる式）には、targetH を rowH - 0.08 以下にした画像描画を使います。OMML セルには、セルオブジェクトを addTable に渡します：{text: "{{MATH:f42}}", options: {}}。
30. 長い表のページ分割 — スライドあたりの行数上限（データ行8～10行）を超える表は、複数のスライドに分割します。続きのスライドでは見出し行を繰り返し、addTableCont() を使ってスライドタイトルに " (cont'd)" を付けます。論理的な行グループの境界（例：アルゴリズム群、指標のカテゴリ、データセット群の間）で分割し、グループの途中で分割してはいけません。最終ページにはデータ行を ≥3 行含めます。それより少ない場合は前のページと統合します。各ページの小集団で異なる内容が示される場合は、そのページごとにキャプション／要点を付けます。
31. 図の縦横比に応じたレイアウト — 論文から抽出した図を埋め込む場合、マニフェストのメタデータまたは測定した寸法から図の幅／高さの比率を確認し、それに応じてレイアウトを選びます。比率 > 1.6（横長）→ addFigure() を使って中央揃えで全幅に配置します。比率 ≤ 1.6（通常または縦長）→ addFigureWithText() を使って左側に図、右側にテキストを配置します。図を引き伸ばしたり、切り抜いたりしてはいけません。必ず元の縦横比を保ちます。マニフェストから figRatio を計算します：width_px / height_px（PNG）または width_pt / height_pt（SVG）。左右に並べるレイアウトでは、説明の箇条書きを配置できるよう、図の幅を CW の60%以下にします。
32. 配置の一貫性 — 同じスライド上の同じ種類の要素（複数のカード、箇条書き、数式など）は、同じ x 座標と一貫した幅を使用します。許容差：≤0.05"。フェーズ5で実行する check_overlaps.py の配置チェックで、ずれを検出できます。よくある違反：カード列の x オフセットが少しずつ異なる、数式画像の中央軸が揃っていない、箇条書きの左余白が不揃い。cols2() または手動で列を配置する場合は、必ず同じ定数から x 座標を導出し、概算してはいけません。
33. 発表者ノート（任意） — ユーザーが発表者ノートを求めた場合、またはノートが役立つ発表（例：ジャーナルクラブ、学位審査）である場合は、addNotes(slide, text) を使ってスライドごとにノートを生成します。ノートは全文の原稿ではなく、電文調の要点（スライドあたり3～5項目）にします。重要なメッセージ、次のスライドへのつなぎ、聴衆から想定される質問を含めます。ノートは .pptx のノートペインに埋め込まれ、発表者ビューで表示されます。これは任意機能です。ユーザーが明示的に求めた場合、またはフェーズ1で尋ねられた場合にのみ生成します。

---

2. カラーテーマとビジュアルシステム

5 つのテーマ：Academic Light（デフォルト）、Midnight、Ocean、Forest、Sandwich。

完全なテーマ JSON ブロック、スライドマスターの定義、タイポグラフィの表、セマンティックカラー、スクリプトテンプレート、採点基準については、references/themes.md をお読みください。 これらはフェーズ 4（スクリプト生成）とフェーズ 5（品質保証の採点）で必要です。

主なポイント（常に把握しておくこと）：

• 各テーマに 4 つのスライドマスターがあります：TITLE_SLIDE、SECTION_SLIDE、CONTENT_SLIDE、THANK_YOU
• タイポグラフィ：Georgia（タイトル）＋ Calibri（本文）
• セマンティックカラー：positive=0173B2、negative=DE8F05、emphasis=029E73、neutral=8C8C8C
• Sandwich テーマには、明るい背景用と暗い背景用の 2 種類の数式カラーがあります

2.1 レイアウトタイプの一覧

レイアウト	用途
title	表紙スライド
section-divider	章の区切り
text-left-image-right	概念＋イラスト（55/45 分割）
two-column	比較／並列コンテンツ
formula-centered	数式が中心のスライド
formula-with-annotation	数式＋側面の注釈
stat-callout	大きな数値／重要な結論
icon-grid	色付き図形を使った複数のポイント
timeline	プロセス／歴史の流れ
table	データの比較
table-with-insight	表＋下部の重要な発見カード
table-continuation	長い表を「 (cont'd)」付きで次のページに分割
chart	チャート／グラフの表示
text-left-diagram-right	テキスト＋図を左右に配置（55/45 分割）
full-diagram	全幅の図
chart-centered	チャート＋キャプション
figure-with-text	抽出した図＋説明の箇条書き（アスペクト比を考慮）
full-image	全面画像＋オーバーレイ
references	参考文献
thank-you	クロージングスライド
backup	予備／付録スライド

---

3. アクション

3.1 create [topic] — フルパイプライン（フェーズ 0〜5）

共同作業で反復しながらプレゼンテーションを作成します。フェーズのゲートを厳守し、先に進んではいけません。

フェーズ 0：資料の分析

まず読み、質問は後からします。 意味のある質問をする前に、内容を理解する必要があります。

• 論文／資料全体を注意深く読む
• 中核となる貢献、主要な手法、主な定理、先行研究との比較を抽出する
• 記法の慣例を整理する
• 論理構造と、スライドに適したセクションを特定する
• 前提知識、自然なセクションの区切り、省略または掘り下げられる内容を確認する

分析結果を提示したり、質問したりせず、そのままフェーズ 1 に進んでください。

フェーズ 1：要件のヒアリング（必須）

AskUserQuestion を使って、コンテンツに基づくヒアリングを行います。質問はフェーズ 0 の分析に基づいて設定します。

必須の質問（必ず確認してください）：

1. 所要時間 — プレゼンテーションの時間はどのくらいですか？
2. 聴衆のレベル — 聴衆はどのような方々ですか？（専門家、大学院生、一般の研究者）
3. 前提知識 — フェーズ 0 で特定した具体的な技術的依存関係を列挙し、聴衆がどれを知っているかを尋ねます。
4. コンテンツの範囲 — 論文に実際に含まれる要素を選択肢として提示します。どの要素を強調し、省略し、または簡潔に触れますか？
5. 深さと広さのバランス — 論文に概要と詳細な構成の両方がある場合、どちらを優先するか尋ねます。
6. ビジュアルスタイル — どのテーマを選びますか？
   • A) アカデミックライト — 白／ライトグレーを基調とした、すっきりと正確なデザイン（デフォルト）
   • B) ミッドナイト — 全体をダークにした、テクノロジー感のある高級なデザイン
   • C) オーシャン — 青系の色調による、プロフェッショナルなアカデミックデザイン
   • D) フォレスト — 自然を感じさせる緑系の色調
   • E) サンドイッチ — タイトル／結論はダーク、本文はライト
7. 発表者ノート（任意）— 発表者ビューのペインに発表者ノートを表示しますか？ジャーナルクラブ、学位審査、リハーサルに役立ちます。希望する場合、各スライドのノートは要点を絞った箇条書き形式で作成します。

スライド枚数の目安（約 1.5～2 分につき 1 枚）：

所要時間	スライド総数	導入／動機	手法／背景	核となる内容	まとめ
5 分（ライトニングトーク）	5-7	1-2	0-1	2-3	1
10 分（短時間）	8-12	2	1-2	4-5	1
15 分（学会発表）	10-15	2-3	2-3	5-7	1-2
20 分（セミナー）	13-18	3	2-3	6-9	2
45 分（基調講演）	22-30	4-5	5-7	10-14	2-3
90 分（講義）	45-60	5-6	8-12	25-35	3-4

トークの種類ごとのヒント — 形式によって適切な戦略は異なります。形式を見誤ることが、質の低いプレゼンテーションの最大の原因です。

トークの種類	重視する点	よくある間違い
ライトニングトーク（5 分）	核となるメッセージを 1 つに絞り、背景説明は省く	5 分に通常のトーク全体を詰め込む
学会発表（10～20 分）	重要な結果を 1～2 点に絞り、手法の概要を手早く説明する	技術的な詳細に偏り、全体像を示さない
セミナー（45 分）	深く掘り下げてもよいが、視覚的な変化をつける	例を挟まず、数式ばかりのスライドが続く
学位審査／修士・博士論文発表	内容の熟知を示し、体系的に網羅する	動機を省き、結果の説明を急ぐ
ジャーナルクラブ	批判的に分析し、議論を促す	評価をせずに要約する
研究助成の提案	重要性 → 実現可能性 → インパクト	技術的すぎて、「なぜ重要なのか」の説明が足りない

ペース配分の原則：時間の 40～50% を核となる内容（結果／手法）に使います。具体例や視覚的な切り替えを挟まずに、理論中心のスライドを 3～4 枚以上続けないでください。形式的な説明が約 5 分間途切れずに続くと、聴衆の関心が薄れていきます。

フェーズ 2：構成案（承認ゲート — ユーザーの承認が必要）

セクションごとの詳細なアウトライン：

• セクションタイトル
• 割り当てるスライド枚数
• 各スライドの主要な内容（1～2 行）
• 各スライドのレイアウトタイプ（セクション 2.4 のレイアウト一覧から選択）
• 予定している図／グラフ（簡単な説明）
• 導入する記法

提示前にフェーズ 2 の自己チェックを行います：

• 各セクションに数式以外の視覚要素（図、表、グラフ、画像）が 1 つ以上ある
• 視覚要素がまったくないスライドは、全体の 30% 以下である（R29）
• 複数段階のプロセス、構成要素間の関係、データ比較のすべてについて、箇条書きだけでなく視覚的な表現を計画している

構成案を提示し、構成が適切か確認します。先に進むにはユーザーの承認が必要です。

フェーズ 3：数式の準備

1. フェーズ 2 の構成を確認し、すべての数式をリストにまとめます。表のセル内の数式も含めてください（R30）：計画したすべての表を確認し、添字、ギリシャ文字、演算子、複雑さの表記を含むセルを探します。それぞれを "render": "omml" を指定した個別の formulas.json エントリにします。
2. render フィールドを指定して formulas.json を作成します（"omml" | "image" | "auto"。デフォルトの "auto" は段落なら画像、それ以外なら omml です）：

   [
     {"id": "f01-entropy", "latex": "H(X) = -\\sum_{x} p(x) \\log p(x)", "mode": "display"},
     {"id": "p01-body", "latex": "\\begin{minipage}{8cm}...", "mode": "paragraph", "fg_color": "1A1A2E"}
   ]
   

3. レンダラーを実行します（画像エントリのみをレンダリングし、omml エントリにはマニフェストのメタデータのみを追加します）：

   python ~/.claude/skills/powerpoint-slides/scripts/render_latex.py formulas.json formulas/
   

4. formulas/manifest.json でエラーを確認します。LaTeX を修正するか、プレーンテキストに切り替えます。

サンドイッチテーマ：OMML 数式は自動的にテキストの色を継承するため、二重レンダリングは不要です。二種類のバリエーションが必要なのは画像としてレンダリングする数式（段落モード）のみです：

[
  {"id": "p01-light", "latex": "...", "fg_color": "2D3436", "mode": "paragraph"},
  {"id": "p01-dark",  "latex": "...", "fg_color": "FFFFFF", "mode": "paragraph"}
]

数式を多く含む段落（必須 — 厳格ルール 18）：フェーズ 2 で計画したカード本文とテキストボックスをすべて確認します。以下のいずれかが含まれている場合、そのテキストは必ず LaTeX 画像としてレンダリングしてください（Unicode による近似表記は不可）：

• 添字または上付き文字（x_i、e^{ax}、H_0）
• 数式内のギリシャ文字（α、β、Σ、∏）
• オペランドを伴う演算子（∈、⊆、∝、≥）
• 分数、総和、積分、積

単独の数式（ディスプレイ／インライン）には OMML を使用します（デフォルトの render:"auto" が処理します）。テキストと数式が混在するカード本文には、数式以外の語句に \text{} を使用し、段落全体を単一の LaTeX 画像としてレンダリングします。"mode": "paragraph" を指定して formulas.json に追加します（自動的に画像として処理されます）。フェーズ 4 では addFormula()／addCardFormula() を使用して埋め込みます。ヘルパーがマニフェストに基づいて自動的に処理方法を選択します。

エラーからの復旧：render_latex.py がマニフェスト内にエラー（"error": "..."）を報告した場合は、LaTeX ソースを修正して再実行します。代替策として、PptxGenJS でプレーンテキストとしてレンダリングします。

フェーズ 3～4 の反復：フェーズ 4 で追加の数式が必要だと判明した場合は、formulas.json に追加して差分実行します。

フェーズ 3.5：図の準備

1. フェーズ 2 の構成を確認し、レンダリングが必要な図や視覚要素を特定します。
2. それぞれを 5 層のパイプラインに分類します：
   • graphviz — アーキテクチャ図、フロー図、依存関係図、ニューラルネットワーク図、ツリー図、比較図（DOT 言語）
   • mermaid — シーケンス図、ガントチャート、円グラフ、状態図、ER 図
   • tikz — 数学を多用する図、幾何学的な作図、論文に忠実な再現図
   • shapes — シンプルな注釈、矢印、強調表示（PptxGenJS ネイティブ。ここではなくフェーズ 4 で処理）
   • extract — 論文 PDF からの図（extract-figures ワークフロー）
3. diagrams.json を作成します（スキーマについては diagram-rendering.md を参照）。
4. MCP による事前抽出（crop のない type: "extract" エントリが対象）： 該当する各エントリについて、一括レンダラーを実行する前に MCP による抽出を試します：

   mcp__pdf-mcp__pdf_extract_images(path=SOURCE_PDF, pages=PAGE, output_dir="diagrams")
   

   • 画像は PNG ファイルとして diagrams/ に直接保存されます（元の解像度、トークンコストなし）。
   • 返されたメタデータから、対象ページ内で最大の画像（width * height が最大のもの）を選びます。
   • 図の ID に合わせて名前を変更します：mv diagrams/page3_img0.png diagrams/<id>.png
   • MCP が画像を返さない、または失敗した場合 → render_diagrams.py による代替処理に任せます。
   • crop のあるエントリでは MCP を常にスキップします（ページ領域の抽出には pdftoppm が必要です）。
   • 一括レンダラーは、.png がすでにディスク上に存在する ID を自動的にスキップします。
5. レンダラーを実行します：

   python ~/.claude/skills/powerpoint-slides/scripts/render_diagrams.py diagrams.json diagrams/ --theme <theme_name>
   

6. diagrams/manifest.json でエラーを確認します。DOT／Mermaid の構文を修正するか、PptxGenJS の図形に置き換えます。

**DOT の記述ガイド：**ノードは最大約 15 個とし、横方向のフローには rankdir=LR、縦方向の階層には rankdir=TB、グループ化には subgraph cluster_* を使用します。

**Mermaid のガイド：**アクター／参加者は 6 人以下とし、対応しているタイプは sequenceDiagram、gantt、pie、stateDiagram-v2、erDiagram です。

5 層アーキテクチャの全ドキュメント、diagrams.json のスキーマ、テーマカラーのマッピング、トラブルシューティングについては、diagram-rendering.md を読んでください。

フェーズ 4：JS スクリプトの生成と実行

完全な PptxGenJS スクリプトを作成します。最初に依存関係をインストールしてください。

npm ls pptxgenjs 2>/dev/null || npm install pptxgenjs

references/themes.md →「Script Template」セクションを読み、テーマ定数（T）、タイポグラフィ定数（F）、レイアウト定数（SW／SH／M／CW／CY／CH）、スライドマスター、addFormula() ヘルパー、図表ヘルパー（addDiagram、addDiagramAt、addFigure）、グラフヘルパー（addChart）、セマンティックヘルパー（sTitle、sectionSlide、addBullets、addCard、addTable、addNumCard、addFlow、cols2）を含む、完全なスターターテンプレートを確認してください。また、pptxgenjs-reference.md →「Layout Code Patterns」で、そのまま使える9個のコードブロック（図表およびグラフのレイアウトを含む）を、数式描画パイプラインについてはformula-rendering.mdを、図表描画パイプラインについてはdiagram-rendering.mdを確認してください。

すべてのフォントサイズにFオブジェクトを使用し、2列レイアウトにはcols2()を使用してください。よく使うパターンにはヘルパー関数を使用します。フォントサイズをハードコードしてはいけません。常にF.body.size、F.title.sizeなどを参照してください。

ユーザー提供の画像（ロゴ、写真、スクリーンショット）：slide.addImage({ path: "image.png", ... })で直接埋め込みます。元の寸法からアスペクト比を計算してください。x: (SW - w) / 2で中央揃えにします。特別なパイプラインは不要です。ファイルが存在することだけを確認してください。

スクリプト生成の主なルール：

• シャドウ、塗りつぶし、その他のオプションオブジェクトには、必ずファクトリー関数を使用してください。
• 16進数カラーに#接頭辞を付けないでください。
• テキスト配列の各項目の間にはbreakLine: trueを使用してください。
• リスト項目にはbullet: trueを使用し、Unicodeの「•」は使用しないでください。
• 図形との正確な位置合わせが必要なテキストボックスには、margin: 0を設定してください。
• icon-gridレイアウトでは、視覚的なマーカーとして単純な色付きの四角形／円を使用してください（アイコン画像ではなく図形を使用）。

4a. 数学スライドのパターン

数式が多いスライドは、次の構造テンプレートのいずれかに従ってください。これらは、文脈なしに数式だけを並べてしまうというよくある落とし穴を防ぎます。

定義スライド：

[Framing sentence: why this definition matters]
[Formal definition — display formula or card]
[Key properties / immediate consequences — 2-3 bullet items]

構成／アルゴリズムスライド：

[One-line goal statement]
[Core equation / algorithm steps]
[Complexity or performance: prover cost, verifier cost, soundness]

比較スライド：

[Side-by-side table or two-column: prior work vs this work]
[1-2 lines highlighting the key difference]

定理→証明スライド（必ず2枚に分け、1枚にまとめない）：

Slide A: [Informal statement] → [Formal theorem in card] → [Why it matters]
Slide B: [Proof sketch — key steps only, ≤5 lines. Full proof in backup.]

洞察／注釈スライド：

[Observation the paper doesn't emphasize, or connection to related work]
[Why this matters / what it implies]

すべての数学スライドには、明確な要点が必要です。つまり、そのスライドから聴衆に覚えておいてほしいことを1つ示してください。

4b. コンテンツ密度の上限

下限はR4／R20を参照してください。認知的な過負荷を防ぐため、上限を設けています。情報が少なすぎるスライドよりも多すぎるスライドのほうが悪く、聴衆に何も残らなくなります。

• スライドあたりの箇条書きまたは項目は7個以下
• スライドあたりの数式表示は2つ以下（それ以上はスライドを分割）
• スライドあたりに導入する新しい記号は5個以下
• スライドあたりのアクセントカードは2個以下（R5ですでに規定）

各バッチの後に密度をセルフチェック：

• 数式／図表／テーブルがないスライドの数を数える → バッチの30%を超える場合は要注意
• 短い項目が3個以下で、数式もないスライドの数を数える → 統合候補
• 上限を超えるスライドの数を数える → 分割または再配分

4c. 表のベストプラクティス

レイアウトと配置：

• 列の配置：数値は右揃え、テキストは左揃え、短いラベルは中央揃えにします
• 列は最大6～7列、1枚あたりのデータ行は8～10行にします。それ以上になる場合は、スライドを分割する（R31）か、一部を抜粋して強調します
• 数値の精度：列内で小数点の位置を揃え、有効桁数を統一します（例：「XX.X%」または「X.XX」に統一）。桁区切りは任意ですが、使用する場合は一貫させます

セルの内容：

• セル内の数式には OMML（R30）を使用する必要があります。下付き文字、ギリシャ文字、演算子、計算量の表記がないか、すべてのセルを確認します。各数式を "render": "omml" とともに formulas.json に追加します。addTable には {text: "{{MATH:id}}", options: {}} を渡します
• テキストと数式が混在するセル（例：「achieves {{MATH:f12}} speedup」）では、数式部分を単一の OMML プレースホルダーで囲みます。混在するランは inject_omml.py が処理します
• セルの結合：グループ化されたヘッダー（例：「Time」列と「Space」列にまたがる「Complexity」）には、セルのオプションで colspan／rowspan を使用します。結合の階層は2段までにします。それより深い入れ子は読みやすさを損ないます

強調と強調表示：

• 重要なセルは太字または ac.pos の色で強調し、結果に目が向くようにします
• 比較表では、各行または各列の最良の結果を太字にします
• 5行を超える表では、読みやすさを高めるために縞模様の行（addTable ヘルパー経由）を使用します

長い表のページ分割（R31）：

• データ行が8～10行を超える表は、addTableCont() を使ってスライド間で分割します
• 続きの各スライドではヘッダー行全体を繰り返し、タイトルに「 (cont'd)」を付けます
• 論理的なグループの境界で分割し、最後のページにはデータ行を3行以上配置します
• 抜粋部分によって伝わる内容が異なる場合は、各ページにそれぞれのキャプションまたは要点を付けます

表と洞察の組み合わせ：

• 2セクションのレイアウトを優先します。上部60%に表、下部40%に洞察カードまたは重要な発見を示す箇条書きを配置します
• 要点のない表は使用しません。最低限、表の下に F.small.size のキャプション行を付けます
• 「論文の Table 1」を再現する場合は、まず忠実に表を再現し、その後、最も重要な2～3行またはセルを説明付きで強調する別の洞察スライドを作成します

4d. アルゴリズムとコードの表示

• 擬似コードは1枚あたり10行以下にします。それより長い場合は、「概要」と「主要なサブルーチン」のスライドに分割します
• 重要な行は ac.pos の背景色で強調します
• 入力／出力を上部に明記します
• 変数はイタリック体、関数は標準の太さにし、全体を通じて命名規則を統一します
• 実際のコード（擬似コードではないもの）には等幅フォントを使用し、関連する部分だけを表示します。ソースファイル全体をそのまま貼り付けてはいけません

バッチ処理：スライドが20枚を超える場合は、スクリプトを8～10枚ずつのバッチに分けて作成します。バッチごとに情報密度とレイアウトの多様性を自己チェックします。最終的なスクリプトは1つのファイルとし、1回だけ実行します。

導入の方針（いずれか1つを選択）：

• 聴衆がすぐには答えられない、挑発的な問いかけ
• 既成概念を覆す驚きの統計
• 実世界での失敗や問題から始め、「どうすれば解決できるか？」と問いかける
• 視覚的なデモンストレーション — 説明する前に現象を見せる

締めくくりの方針：

• 導入への回帰 — 冒頭の問いを振り返り、答えを示す
• 重要なポイントを3つ紹介 — 番号付き、簡潔な表現で、1枚にまとめる
• 今後の展望 — Q&A につながる自由回答形式の問いかけ
• 「Thank You」だけで終わらせないでください — 最後から2枚目の内容スライドが、聴衆に最も強い印象を残します

4e. スクリプトの自己レビュー（実行前）

完成した JS スクリプトを読み直し、node を実行する前に確認します。ここで問題を見つけておけば、QA のやり直しを避けられます。

構成：

• スライド枚数がフェーズ 2 の計画と一致している（許容範囲 ±2）
• 論理的な流れになっている：動機 → 背景 → 手法 → 結果 → まとめ
• 具体例または視覚的な区切りを挟まずに、数式の多いスライドが 4 枚以上連続していない
• 主要なセクション間にセクション区切りスライドがある

コンテンツの密度：

• 数式・図・表がなく、短い箇条書きが 3 項目以下のみのスライドがない
• 上限を超えるスライドがない（箇条書き 7 項目、数式 2 個、新しい記号 5 個、アクセントカード 2 個）
• テキストのみのスライドがデッキ全体の 20% 以下である

レイアウトと配置：

• すべての要素が y + h ≤ SH - M を満たしている（R21）
• 複数行のテキストボックスすべてに shrinkText: true が設定されている（R27）
• 同じレイアウトタイプのスライドが 3 枚以上連続していない（R12）
• すべてのフォントサイズに F 定数を使用し、数値を直接指定していない

表記法：

• すべてのスライドで同じ記号を一貫して使用している
• すべての記号が初めて使われる前に定義されている

フェーズ 5：QA ループ（必須）

┌─→ 5a. Execute JS script → .pptx
│   5b. soffice → PDF → pdftoppm → slide images
│   5c. Subagent visual inspection (per-slide)
│   5d. markitdown text extraction → content verification
│   5e. Score (apply rubric)
│   5f. Fix (edit JS and/or re-render formulas → re-execute)
└── score < 90 AND round < 3: loop back to 5a
    score ≥ 90 OR round = 3: report to user

5a. 実行＋OMML の挿入：

node generate_slides.js
# If manifest has any render:"omml" entries, inject OMML math:
python ~/.claude/skills/powerpoint-slides/scripts/inject_omml.py output.pptx formulas.json output.pptx

5b. 画像に変換：

python ~/.claude/skills/powerpoint-slides/scripts/soffice.py --headless --convert-to pdf --outdir . output.pptx
pdftoppm -png -r 200 output.pdf /tmp/slide

サムネイルのクイックグリッド（任意 — 詳細な確認の前に全体をすばやく把握するため）：

python ~/.claude/skills/powerpoint-slides/scripts/thumbnail.py output.pptx thumbnails --cols 4

5c. 目視確認（Agent サブエージェント経由）：

200 DPI のスライド画像はそれぞれ約 1～2MB です。画像を読み込むとコンテキストが蓄積されます。メインの会話または単一のエージェントで約 7 枚を超える画像を読み込むと、20MB の制限を超えます。スライド画像をメインの会話で直接読み込まないでください。

方針：Agent サブエージェントを並列で起動し、それぞれに 3～5 枚のスライドを割り当てます。各エージェントは担当するスライドを 1 枚ずつ読み込み、確認して、テキストのみのレポートを返します。メインの会話にはテキストのみが届くため、コンテキストをクリーンに保てます。

Total slides: N
Agents: ceil(N/5) agents, each reading up to 5 consecutive slide images
All agents run in parallel

各エージェントへのプロンプト：

「/tmp/slide-{NN}.png のスライド画像 [start]-[end] を読み込んでください。Read 呼び出し 1 回につき画像は 1 枚です。 各スライドについて、はみ出し、重なり、フォントの読みやすさ、数式の明瞭さ、コントラスト、 レイアウトの煩雑さ、コンテンツの密度、下端での切れを確認してください。

重要 — コンテンツ密度の測定：余白は、想定されるテキストボックスの境界ではなく、スライド画像にレンダリングされたピクセルを基準に判断してください。テキストボックスの高さが 3 インチでも、レンダリングされたテキストが 2 行で 0.5 インチしか占めない場合、視覚的な余白は 2.5 インチあります。実際のスライド画像を見て、表示コンテンツ（テキスト、図形、画像、数式）が縦方向のどこまであるか確認してください。そこからスライド下端までの間隔が、実際の余白です。タイトルバーの下の領域に対して、表示コンテンツが 75% 未満しか占めていない場合は指摘してください（R19）。

重要 — 下端でのはみ出し（R21）：カード、表、数式、テキストがスライドの下端で切れていないか確認してください。兆候：テキストが行の途中で切れている、カード下部の影が欠けている、表の行が表示されていない。これは最もよくあるレイアウトの不具合です。 また、カードのタイトルが本文と重なっていないか確認してください（タイトルの文字が下の本文に入り込んでいる状態。大きなフォントサイズでタイトルが長く、折り返される場合に起こりやすいです）。

図の確認：ラベルが読めること、線を見分けられること、ノードが重なっていないこと、色がスライドのテーマに合っていること（Graphviz のデフォルトの青／黒を使っていないこと）、図が切れずにコンテンツ領域内に収まっていること。抽出した図には出典キャプションがあります。

OMML に関する注意：LibreOffice／PDF プレビューでは、OMML 数式は空白として表示されます。これは既知の制限であり、不具合ではありません。画像化された数式の明瞭さのみを確認してください。

テキストのみのレポートを返してください。問題はスライド番号、説明、重大度とともに列挙してください。 問題がないスライドには「OK」と報告してください。」

すべてのエージェントのレポートを、単一の問題一覧にまとめます。

5a-post. XML 検証（OMML 挿入後）：{{MATH: のプレースホルダーが残っていないことを確認します。

python -c "
import zipfile, sys
with zipfile.ZipFile('output.pptx') as z:
    for n in z.namelist():
        if n.startswith('ppt/slides/') and n.endswith('.xml'):
            if b'{{MATH:' in z.read(n):
                print(f'RESIDUAL PLACEHOLDER in {n}'); sys.exit(1)
print('OK: no residual placeholders')
"

5a-post2. 重なりと境界の確認（OMML 挿入後）：

python ~/.claude/skills/powerpoint-slides/scripts/check_overlaps.py output.pptx

終了コードが 0 以外（重大／主要な問題が見つかった場合）のときは、JS スクリプトを修正して再実行します。 このチェッカーはカードを認識し、誤検出を避けるために、カード内部（コンテナーの矩形＋アクセントバー＋タイトル＋本文）をグループ化します。要素の重なり、下端でのはみ出し、間隔が狭すぎる箇所を検出します。

5d. コンテンツの検証：

pip install -q "markitdown[pptx]" 2>/dev/null
markitdown output.pptx > content.md

content.md を読み、テキストの内容、表記の一貫性、スペルを確認します。

5e. 品質スコアリング：references/themes.md →「品質スコアリング基準」のルーブリックを適用します。基準：90 以上なら納品、80～89 は警告、80 未満は修正が必要です。

5f. 修正：問題を修正するため、JS スクリプトを編集します。色／DPI に問題がある場合は、数式を再レンダリングします。再実行して再スコアリングします。最大 3 回までです。

作成後のチェックリスト（ユーザーへの報告前に行う最終確認）

[ ] JS script executes without errors, .pptx generated
[ ] OMML injection successful, zero residual {{MATH:}} placeholders
[ ] QA score ≥ 90
[ ] Every definition has motivation + worked example within 2 slides
[ ] No slide exceeds density upper bounds (7 bullets, 2 formulas, 5 symbols, 2 cards)
[ ] No sparse slides (all slides have substantive content)
[ ] Diagrams use theme colors (no default blue/black)
[ ] Tables fit within content area, key cells highlighted, cell math uses OMML (R30)
[ ] Long tables split with header repeat and "(cont'd)" marker (R31)
[ ] Notation consistent throughout — same symbol = same meaning
[ ] References slide present (second-to-last, before Thank You)
[ ] Slide images visually inspected (at least spot-check 3-5 slides via QA agents)

---

3.2 compile [file.js]

既存の PptxGenJS スクリプトを実行して .pptx を生成します。

npm ls pptxgenjs 2>/dev/null || npm install pptxgenjs
node FILE.js

コンパイル後の確認：

• 終了コードは 0 か？
• 出力 .pptx ファイルは存在するか？
• ファイルサイズは妥当か？（10KB 超ならコンテンツあり、50MB 未満なら妥当）
• 報告内容：出力パス、ファイルサイズ、成功／失敗

---

3.3 review [file.pptx]

読み取り専用の校正レポートです。ファイルは編集しません。

テキストを抽出します：

pip install -q "markitdown[pptx]" 2>/dev/null
markitdown FILE.pptx > content.md

4 つのチェックカテゴリ：

カテゴリ	チェック項目
文法	主語と動詞の一致、冠詞、前置詞、時制の一貫性
誤字	スペルミス、検索・置換の残骸、単語の重複、置換されていないプレースホルダー（[name]、[TODO]）
一貫性	スライド間での引用形式、表記法、用語、色の使い方
学術的品質	くだけた短縮形、裏付けのない主張、曖昧な略語

問題ごとのレポート形式：

### Issue N: [Brief description]
- **Location:** [slide number or title]
- **Current:** "[exact text]"
- **Proposed:** "[fix]"
- **Category / Severity:** [Category] / [High|Medium|Low]

---

3.4 audit [file.pptx]

画像変換による視覚的なレイアウト監査です。読み取り専用のレポートです。

python ~/.claude/skills/powerpoint-slides/scripts/soffice.py --headless --convert-to pdf --outdir /tmp FILE.pptx
pdftoppm -png -r 200 /tmp/FILE.pdf /tmp/audit-slide

スライドごとの視覚的チェックリスト：

• どの端でもテキストがはみ出していない
• 要素が重なっていない（テキスト同士、テキストと画像、図形同士）
• すべてのテキストが読みやすい（10pt相当以上）
• 表や数式がコンテンツ領域に収まっている
• 同種のスライド間でフォントサイズが一貫している
• テキストと背景のコントラストが適切である
• 視覚的に煩雑になっていない（競合する要素が多すぎない）
• アクセントカードが1スライドあたり2枚以下である
• レイアウトに変化がある（同じタイプが3枚以上連続しない）

Agent サブエージェントを使用する場合：並列エージェントを起動し、それぞれに3～5枚のスライドを割り当てます。各エージェントは Read ツールを使ってスライドを1枚ずつ読み取り、テキストのみのレポートを返します。メインの会話でスライド画像を読み取らないでください。画像がコンテキストに蓄積し、約7枚を超えると20MBの制限を超えてしまいます。

各問題について、スライド番号、説明、深刻度、修正の推奨事項を記載して報告します。

---

3.5 pedagogy [file.pptx]

教育的観点からのレビューです。読み取り専用のレポートです。

検証する13の指導パターン：

#	パターン	問題の兆候
1	形式化の前に動機付けを行う	文脈のない定義
2	記法を段階的に導入する	1枚のスライドに新しい記号が5個以上ある
3	定義の後に具体例を示す	例のない定義が2つ連続する
4	複雑さを段階的に高める	前提知識より先に高度な概念が登場する
5	段階的な表示（問題 → 解決策）	複雑な定理が一度にすべて表示される
6	転換点で道しるべとなるスライドを入れる	突然話題が飛び、移行がない
7	複雑な定理には2枚のスライドを使う	複雑な定理を1枚のスライドに詰め込んでいる
8	意味に基づいて色を使う	同じ色で二項対立を表現している
9	カード／ボックスの階層	コンテンツに合わないアクセントの種類
10	カード疲れを避ける	1枚のスライドにアクセントカードが3枚以上ある
11	ソクラテス式の問いかけを組み込む	スライド全体を通して質問が一切ない
12	複雑な概念ではビジュアルを優先する	視覚化より先に記法が提示される
13	並べて比較する	関連する定義が連続した別々のスライドにある

デッキ全体のチェック項目：

• 物語の流れ（動機付け → 展開 → クライマックス → まとめ）
• ペース配分（例や視覚的な休憩を挟まずに、理論中心のスライドが続くのは最大3～4枚まで）
• 視覚的なリズム（5～8枚ごとにセクション区切りを入れる）
• 全体を通した記法の一貫性
• 学生に求める前提知識が妥当である

---

3.6 excellence [file.pptx]

多次元にわたる包括的なレビューです。5 つの Agent 呼び出しを並列で実行します。

1. ビジュアル監査エージェント — Agent サブエージェントを並列でディスパッチし、それぞれに 3〜5 枚のスライドを割り当てます。各エージェントは Read ツールでスライド画像を 1 枚ずつ読み込み、重なり、フォントの一貫性、カード疲れ、余白の問題、レイアウトの多様性、コンテンツの密度を確認します。スライドごとに重大度を付記したテキストのみのレポートを返します。メインの会話でスライド画像を読み込まないでください。

2. 教育設計レビューエージェント — 「.pptx からテキストを抽出してください。13 の教育設計パターンとデッキ全体のチェック項目（物語の流れ、ペース配分、視覚的なリズム、表記の一貫性）を検証してください。パターンごとに報告してください。」

3. 校正エージェント — 「.pptx からテキストを抽出してください。文法、スペル、引用の一貫性、表記の一貫性、学術的な品質を確認してください。各問題について、位置と修正案を報告してください。」

4. 数式品質エージェント — Agent サブエージェントをディスパッチして数式スライドの画像を確認します（各エージェントに 3〜5 枚のスライドを割り当て、Read 呼び出し 1 回につき画像 1 枚）。確認項目：DPI が十分か（ぼやけていないか）、スライドのテーマに色が合っているか、配置が正しいか、サイズが一貫しているか。テキストのみのレポートを返します。

5. ドメインレビューエージェント（任意 — --domain フラグを指定した場合、または論文が数学・理論を中心とする場合に有効）— 「内容の正確性を検証してください。前提が明記されているか、導出が妥当か、引用が忠実か、主張が裏付けられているかを確認してください。各問題を重大度とともに報告してください。」

すべてのエージェントからの応答後、結果をまとめたレポートを作成します。

# Excellence Review: [Filename]

## Overall Quality: [EXCELLENT / GOOD / NEEDS WORK / POOR]

| Dimension | Critical | Major | Minor |
|-----------|----------|-------|-------|
| Visual/Layout | | | |
| Pedagogical | | | |
| Proofreading | | | |
| Formula Quality | | | |
| Domain (if run) | | | |

### Critical Issues (Immediate Action Required)
### Major Issues (Next Revision)
### Recommended Next Steps

品質スコアの対応：Excellent（重大な問題 0〜2 件、主要な問題 0〜5 件）、Good（重大な問題 3〜5 件、主要な問題 6〜15 件）、Needs Work（重大な問題 6〜10 件、主要な問題 16〜30 件）、Poor（重大な問題 11 件以上、主要な問題 31 件以上）。

---

3.7 visual-check [file.pptx]

PDF から画像に変換して行う、体系的なビジュアルレビューです。

ワークフロー：

1. 変換します：

   python ~/.claude/skills/powerpoint-slides/scripts/soffice.py --headless --convert-to pdf --outdir /tmp FILE.pptx
   pdftoppm -png -r 200 /tmp/FILE.pdf /tmp/vc-slide
   

2. ビジュアル検査のため、Agent サブエージェントを並列でディスパッチし、それぞれに 3〜5 枚のスライドを割り当てます。各エージェントは Read ツールで担当スライドを 1 枚ずつ読み込み、スライドごとのチェックリストを実行して、テキストのみのレポートを返します。メインの会話でスライド画像を読み込まないでください — 画像がコンテキストに蓄積され、約 7 枚で 20MB を超えます。体系的なスライドごとのチェックリスト：

   • どの端（上、下、左、右）でもテキストがはみ出していない
   • 要素が重なっていない
   • 発表を見る距離からでもすべてのテキストが読みやすい
   • 数式画像が鮮明である（ぼやけやピクセル化がない）
   • 表がスライド幅に収まり、セル内の数式が OMML として描画されている
   • 長い表の続きには、見出しが繰り返され、「(cont'd)」というタイトルが付いている
   • 類似するスライド間でフォントサイズが一貫している
   • テキストと背景のコントラストが十分である
   • 視覚的に煩雑でない
   • テーマカラーが一貫して適用されている
   • コンテンツの密度が十分である（テキストがカード／領域の面積の 50% を超えている）

3. 問題ごとに報告します：

   ### Slide N: [slide title]
   - **Issue:** [description]
   - **Severity:** Critical / Major / Minor
   - **Fix:** [specific recommendation]
   

---

3.8 extract-figures [file.pdf] [pages]

スライドで使用するために、論文の PDF から図を抽出します。まず MCP で抽出し、失敗した場合は pdftoppm にフォールバックします。

1. 対象の図を特定します — pdf_get_toc / pdf_read_pages を使って場所を確認します。不明な場合はユーザーに尋ねます。
2. MCP による抽出を試します（優先手段）：

   mcp__pdf-mcp__pdf_extract_images(path=PDF_PATH, pages=PAGES, output_dir="diagrams")
   

   • 画像を PNG ファイルとして diagrams/ に直接保存します（元の解像度、トークン消費なし）。
   • {page, index, width, height, format, file_path} を返します — file_path をそのまま使用します。
   • 対象ページごとに、最大の画像を選びます（複数ある場合はユーザーに選んでもらってもかまいません）。
   • 必要に応じて、わかりやすい名前に変更します：mv diagrams/page3_img0.png diagrams/<id>.png
3. pdftoppm にフォールバックします — MCP が画像を返さない場合、またはページの一部を切り抜く必要がある場合に使用します：
   • type: "extract" のエントリを含む diagrams.json を作成します（必要に応じて crop 座標も含めます）。
   • レンダラーを実行します：

     python ~/.claude/skills/powerpoint-slides/scripts/render_diagrams.py diagrams.json diagrams/
     

4. 抽出した画像のメタデータを使って、diagrams/manifest.json を更新または作成します。

ルール：

• ユーザー自身の論文でない限り、出典を明記する必要があります（Source: Author et al., Year）。
• 解像度を確認します：いずれかの寸法が 800px 未満の場合は、投影時にぼやけることをユーザーに警告します。
• 表は決して抽出しません — 鮮明に表示できるよう、addTable() で作り直します。
• 複数の図があるページ：MCP は図ごとに個別の画像オブジェクトを返す場合があります。1 枚の画像に結合されている場合は、pdftoppm と crop を使用します。

3.9 validate [file.pptx] [duration]

自動で定量的な検証を行います。測定可能なプロパティを確認します。

確認項目：

1. スライド枚数と発表時間（発表時間が指定されている場合）：

   python ~/.claude/skills/powerpoint-slides/scripts/soffice.py --headless --convert-to pdf --outdir /tmp FILE.pptx
   pdfinfo /tmp/FILE.pdf | grep "Pages:"
   

   時間配分表と比較します。範囲外の場合はフラグを立てます。

2. ファイルサイズ：

   • >50 MB：警告（共有に時間がかかります）
   • >100 MB：重大（画像が非圧縮の可能性があります）

3. コンテンツの抽出：

   markitdown FILE.pptx > content.md
   

   • テキストのないスライドの枚数を数えます → 空のスライドにフラグを立てます。
   • プレースホルダーテキスト（[TODO]、[XXX]）を確認します。

4. 数式画像（formulas/ ディレクトリがある場合）：

   • すべてのマニフェストエントリに、実在するファイルが指定されています。
   • "error" フィールドを含むマニフェストエントリがありません。
   • 画像の寸法が適切です（幅 > 100px）。

レポート形式：

# Validation Report: [Filename]

| Check | Result | Status |
|-------|--------|--------|
| Slide count | N slides / Xmin | OK / WARNING |
| File size | X.X MB | OK / WARNING |
| Empty slides | N found | OK / WARNING |
| Placeholder text | N found | OK / CRITICAL |
| Formula images | N/M valid | OK / WARNING |

Overall: PASS / PASS WITH WARNINGS / FAIL

---

4. 検証プロトコル

すべてのタスクは検証で終わります。 これは必須です。

[ ] JS script executes without errors (node exit code 0)
[ ] .pptx file generated and non-empty (>10KB)
[ ] soffice converts to PDF successfully
[ ] Slide images visually inspected (at least spot-check 3-5 slides)
[ ] Text content verified via markitdown (no garbled text, placeholders)
[ ] Score ≥ 90 (for create action) or issues documented (for review actions)

---

5. トラブルシューティング

問題	対処方法
Cannot find module 'pptxgenjs'	作業ディレクトリで npm install pptxgenjs を実行します
数式画像がない／マニフェストのエラー	formulas.json の LaTeX 構文を確認し（\\ を二重にエスケープします）、render_latex.py を再実行します。フォールバック：プレーンテキスト
soffice が停止する、または失敗する	pkill -f soffice を実行し、--headless フラグを付けて再試行します
.pptx の色が正しくない	16 進数カラーから # 接頭辞を削除します。6 文字の 16 進数のみ使用します。透明度は transparency プロパティで指定します
複数追加した後に図形の位置がずれる	ファクトリー関数を使います — PptxGenJS はオプションオブジェクトをインプレースで変更します
dot: command not found	brew install graphviz を実行します
図の色がデフォルトの青／黒になる	スライドのテーマに合わせて、render_diagrams.py に --theme フラグを渡します
抽出した図がぼやけている	元の PDF の解像度が低い可能性があります。より高い DPI を試すか、ベクター形式のソースを探します
pdfinfo: command not found	brew install poppler を実行します（pdfinfo、pdftoppm がインストールされます）

---

6. 依存関係

Node.js：npm install pptxgenjs Python：pip install Pillow lxml "markitdown[pptx]" システム：node、pandoc（OMML 変換）、xelatex、pdfcrop、pdftoppm（Poppler）、soffice（LibreOffice）、pdfinfo（Poppler）、dot（Graphviz — brew install graphviz）、mmdc（Mermaid CLI — npm install -g @mermaid-js/mermaid-cli、任意）