ultimate-ppt-master

保真改 PPT Skill（Ultimate PPT Master）

機能の段階（v7.0.0-beta.1）： Preserve Edit ＝ RC；upm make による Editable Deck ＝ Beta（図形編集可能な DrawingML であり、ネイティブの a:tbl／グラフデータオブジェクトではありません）；upm make --format web-deck ＝ Experimental SVG HTML Preview（雑誌風の GA ではありません）；Kimi エクスポート ＝ 実験的／正式版ではありません。自動修正は、はみ出しを抑える限定的なフォント縮小と修復プランの作成に限られ、2 ラウンドの実行処理全体には対応しません。正式モードでは、プレースホルダーやソースなしでの納品を拒否します。品質ゲートには bin/upm を優先してください。CLI の終了コード 0 は、必須のゲートに合格したことを意味します。

PowerPoint の編集は、保全を最優先します。ユーザーが指定したスライド／オブジェクトだけを変更し、それ以外はバイト単位でそのまま維持して、WPS／PowerPoint で問題なく開ける編集可能な .pptx を納品します。ソース資料から新しい編集可能な PPTX や雑誌風のウェブデッキを生成することも引き続き可能ですが、あくまで副次的な機能です。修正／修復の依頼を、一からの再生成にすり替えないでください。

主モード — 既存の PPTX を保全しながら編集：修復プランを読む → 指定されたスライド／オブジェクトだけに触れる → 編集前後をレンダリングする → 編集可能な .pptx と安全性レポートを書き戻す（下記の 既存 PPTX の修復モード を参照）。

副次モード — ソースから生成：入力 → ストーリーボード → デザインと生成 → 改良と納品。

ステップ 0 — 環境の確認（スクリプトを実行する前に行ってください）

スクリプトを実行する前に、実行環境を一度確認してください（短時間で完了します。保全編集自体は Python 標準ライブラリのみで動作しますが、生成ルートには追加の依存関係が必要です）。

python3 --version        # needs 3.10+; picks python3.13/3.12/3.11/3.10/python3 on PATH

• ${SKILL_DIR}/.venv がある場合は、すべての処理で ${SKILL_DIR}/.venv/bin/python を優先してください。
• 存在しない場合は、軽量な Python 依存関係を一度インストールしてください。

  bash ${SKILL_DIR}/scripts/bootstrap.sh --profile core
  

  （--profile core では requirements-core.txt のみがインストールされ、Chromium と npm は含まれません。タスクでソース変換、画像生成、Playwright によるレンダリングが必要な場合は、--profile all または visual-review を使用してください。）
• スクリプトが ModuleNotFoundError で失敗した場合、不足しているパッケージはそのルートで任意に必要となる依存関係です。${SKILL_DIR}/.venv 内に pip install <package> でインストールしてください（該当するルートは requirements.txt のセクション見出しを確認してください）。その手順を黙って省略しないでください。

運用モデル

この Skill は、PowerPoint のネイティブエディターの代替ではなく、PowerPoint を使った作業を支えるローカルの品質・ワークフローレイヤーとして扱ってください。ユーザー向けの標準的な手順は次のとおりです。

1. 入力 — 1 行のタスク、ファイル、URL、または既存の PPTX を受け付け、技術設定を最初に提示するのではなく推測します。
2. ストーリーボード — 重要な質問は最大 3 つまでにし、その後、スライドごとの役割、根拠との紐付け、明示的な不足事項を提示します。
3. デザインと生成 — 表紙／本文／データの扱い方を含む、完成度の高いビジュアル案を 3 つ提示し、まず決定論的な構造ドラフトを作成します。その後、選択されたスライド、または監査で不合格となったスライドだけを改良します。
4. 改良と納品 — 安定した slideId を基準に作業します。編集可能な PowerPoint オブジェクトを維持し、正式な編集は PowerPoint で完了させます。

Bridge、プロバイダー、DeckIR、スクリプト、JSON コントラクトは、プロフェッショナル／診断モードでも引き続き利用できます。project-brief.json、storyboard.json、asset_plan.json、quality-report.json と既存の Bridge ハンドオフ互換性を維持してください。DeckSession がある場合は、すべての成果物でそのフェーズ（intake / outline / generating / review / delivered）と安定した slideId の値を維持してください。

既存の PPTX がビジュアルまたはブランドの参考資料として提供された場合は、次を実行してください。

python3 ${SKILL_DIR}/scripts/pptx_template_import.py <reference.pptx> --manifest-only --reference-style-mode style-only

生成された reference-style.json を使って、プライベートなコンテンツをコピーせずに、マスター／レイアウトのリズム、テーマのフォントと色、プレースホルダー、グラフの表現、共通のページ役割を再利用してください。

既存の PPTX の修復モード

引き継ぎ資料に attachments/pptlint-repair-plan.json が含まれている場合、ソース PPTX は新しいデッキの素材ではなく、修復対象の納品物として扱います。

• 手動を優先する高速な修復経路を使います。ストーリーボードの生成、ビジュアルディレクションの検討、画像の取得、要素キットの生成、指定されたオブジェクトを直接変更しないデッキ全体の制作工程は省略します。
• 計画を立てる前に選択された修復タスクを確認し、指定されたスライドだけを編集します。
• ユーザーが明示的に変更を許可しない限り、表示されるすべての文字、数値、データ、結論、スライド数、スライド順、未選択のスライドを変更しません。
• ローカル修復のために、Artifact Tool、SVG、その他の再構築パイプラインを使ってソースデッキ全体を読み込み、再エクスポートしてはいけません。これらの方法では、マスター、透明度、プレースホルダー、グループ化されたオブジェクト、リンク、未編集のスライドが再解釈される可能性があります。
• パッケージを保持するネイティブなオブジェクト編集方法として、エディター scripts/preserve_edit_pptx.py を使用します。すべてのパッケージパーツをそのままコピーし、指定されたスライド（および、そのスライドのチャート操作が対象とするチャートパーツ）のみを再シリアライズします。そのため、未編集のスライド、ロゴ、マスター、レイアウト、テーマ、メディア、リンクはバイト単位で同一のままです。 まず確認してから編集します。

  python3 ${SKILL_DIR}/scripts/preserve_edit_pptx.py --list <source.pptx>
  python3 ${SKILL_DIR}/scripts/preserve_edit_pptx.py <source.pptx> <repaired.pptx> \
      --slide <N> --replace "旧文本=新文本" --report <fidelity-report.json>
  

  対応しているネイティブ操作（デッキ全体の再生成より優先してください）。
  • テキスト：--replace OLD=NEW または op replace_text
  • スタイル：op style_text — フォント／サイズ／太字／色（任意の一致条件）
  • 表：op replace_table_cell — 行／列、またはテキスト検索で指定
  • 図形：op set_shape_geometry — ポイント単位で移動／サイズ変更（インデックス／名前／テキストで照合）
  • チャート：ops replace_chart_text、set_chart_value（リンクされたチャートパーツのみを書き換えます） 複数スライド／複合操作を一度に行う場合：

  python3 ${SKILL_DIR}/scripts/preserve_edit_pptx.py <source.pptx> <repaired.pptx> \
      --edits edits.json --report <fidelity-report.json>
  # edits.json: [{"slide":1,"replacements":{"Q2":"Q3"}},{"slide":4,"operations":[{"op":"replace_table_cell","row":2,"col":1,"text":"128"}]}]
  

  または、1 枚のスライドに型付き操作を 1 つ適用する場合：--op '{"op":"style_text","size":24,"bold":true}'。一致する対象がない場合、指定されたスライドもバイト単位で同一のままです。
• 忠実度レポートは必須の判定基準です。safe が true でなければなりません。変更できるのは対象のスライド／チャートパーツのみで、パーツの追加や削除は認められません。予期しないパーツの変更、追加、削除があった場合は重大な失敗として扱い、処理を中止して報告し、納品しません。
• エディターがネイティブにまだ対応していない変更（スライドの追加／削除、新しい画像の挿入、表構造の再構築、自由形式の再デザインなど）については、デッキ全体を読み込み、再エクスポートしてはいけません。代わりに、該当するオブジェクトだけを対象とした簡潔な PowerPoint／WPS の手順を提示します。
• 現在の環境でエディターを使用できない場合、修復済み PPTX を生成してはいけません。通常のデッキ制作パイプラインを開始するのではなく、直ちに簡潔な PowerPoint／WPS の手順を提示します。
• 選択された問題を、ロックを破らずに改善できない場合は元のページを維持し、ユーザーが判断すべき内容を正確に報告します。
• ネイティブ編集を実施した後は、PowerPoint、WPS、または LibreOffice で変更したスライドをレンダリングし、全画面表示で編集前後を確認します。表示オブジェクトの欠落、黒または変化した背景、ロゴの破損、リンクの変更、意図しない移動は重大な失敗として扱います。
• 修復済み PPTX は別ファイルとして保存し、pptlint proof を実行します。そのスコア／ルール判定は補助的な証拠としてのみ扱います。レンダリング画像による目視確認をせず、テキスト／ルールのチェックだけを根拠に成功を主張したり、Verified 認証を発行したりしてはいけません。

このモードは、対象を絞った改訂のための経路です。修復依頼を新しいストーリーボードの作成に黙って置き換えたり、ストーリーを変更したり、影響を受けないページを再生成したり、小規模なローカル修正にデッキ全体の生成時間を費やしたりしてはいけません。

品質パイプラインの追加要件：ステークホルダー向けのデッキは、「ビジュアルディレクション → ページ役割コントラクト → ビジュアル完成度監査」にも合格する必要があります。

最良の効果を得るためのブリーフ強化

生成されるワークフローポリシー

このセクションは contracts/ から生成されます。手動で編集せず、python3 scripts/generate_contracts.py を実行してください。

信頼できる情報源

• プライマリーワークフロー：SKILL.md
• デザインコントラクト：DESIGN.md
• 機械可読ポリシー：contracts/workflow-policy.yaml、contracts/route-policy.yaml、contracts/visual-defaults.yaml、contracts/quality-modes/

Best-Effect ブリーフの強化

ルートの選択やファイルの生成を行う前に、ユーザーの短い指示を bestEffectBrief に書き換えます。プロンプトの品質、自動補完した対象者／シナリオ／メッセージ／ページ数／スタイル／ソース／アセットに関する前提、推奨ルート、ユーザーとエージェントのどちらが各判断を行ったかを記録します。

ルーティング

• ポリシーに従って自動でルーティングします。リクエストを分類できる場合は、生成前に PPTX と Web のどちらにするかをユーザーに選ばせないでください。
• 事実、ソース、ブランド／IP、コンプライアンス、ルートの選択によって納品物が大きく変わる場合に限り、要点を絞った質問を最大 3 つまで行います。
• 既存の PPTX の編集（改PPT / 保真修改 / edit this pptx）→ preserve-edit（Preserve Edit Engine）。
• フォーマル／編集可能／政府／金融／研修／レポート／.pptx のシグナル → 品質モード standard で editable-deck。
• HTML／Web PPT／マガジン／エディトリアル／電子ペーパー／スイススタイル／横方向スワイプ／基調講演／ショーケース／デモデー／ブラウザー優先のシグナル → web-deck（明示的にリクエストされた場合のみ有効）。
• フォーマルまたは Web のシグナルがない、極端に情報の少ないトピックのみのプロンプトには、編集可能なデッキをフォールバックとして適用します → Editable Deck、スタイル 正式商务 PPTX / 微软雅黑 / 可编辑正文、6 ページ、カバー面 light-or-warm-paper。

極端に情報の少ないプロンプトに対するフォールバックのページ構成

1. 明るい、または温かみのある紙面の表紙。印象的なタイトル、最小限のサブタイトル、柔らかな輪郭のビジュアル／エビデンスパネルを 1 つ配置
2. 問題、トレンド、または背景を説明するページ
3. ソースに基づく主張を含むエビデンス／データページ
4. 比較またはプロセスのページ
5. リスクまたはアクションのページ
6. 要点と次のステップを示す、明るい雰囲気のまとめページ

ビジュアルのデフォルト

• デフォルトの表紙面：light-or-warm-paper（明るい色／温かみのある紙面／オフホワイト）。
• 暗い表紙を使用できるのは、ユーザーの要望、ブランドシステム、明示的なアートディレクション、画像主導のローンチの場合に限ります。
• ユーザー、ブランド、または明示的なアートディレクションで求められない限り、ページ全体を黒くした表紙は使用しないでください。
• インクは主にテキスト色として使用し、ページ全体の背景色としては使用しないでください。

ソースのインポート

• デフォルトのインポートモード：copy（--copy）。
• --move／アーカイブして元ファイルを削除する操作は、明示的に選択する上級者向けオプションであり、デフォルトではありません。
• リポジトリ内部で生成された調査成果物は、誤ってコミットされるのを防ぐために、引き続き移動してもかまいません。

エビデンスの状態

使用可能な値：unmapped、candidate、grounded、conflicted、missing。 ソースが存在するという理由だけで作成された下書きスライドは、grounded ではなく、必ず unmapped から開始してください。 grounded とするには、主張単位でソースを紐付ける必要があります。

品質モード

デフォルトモード：standard。 使用可能なモード：quick、standard、audit。

モード	用途	主なゲート
quick	下書き、社内での議論、コンテンツの検証	構成／ファイルの妥当性に問題があれば失敗。ビジュアルエビデンスは警告
standard	ほとんどのフォーマルなレポート、デフォルトの制作ルート	フォーマルな納品に問題があれば失敗。ビジュアルエビデンスを推奨
audit	取締役会資料、政府、金融コンプライアンス、外部公開	プレビュー PNG／デザインレポートの欠如、または空白ページのリスクがあれば失敗

セマンティックアサーション：

• defaultCoverSurface=light
• extremeThinAutoRoutes=True
• extremeThinDefaultFormat=editable-deck
• formalSignalDefaultFormat=editable-pptx
• mustAskBeforeGenerate=False

ルートの選択または制作の前に、ユーザーの未加工のリクエストを bestEffectBrief に変換してください。多くのユーザーは短いトピックや「帮我做个 PPT」としか入力しないため、Agent を直接使用する場合は必須です。

bestEffectBrief には、次の内容を記録する必要があります。

• ユーザーの元のリクエストの要約。
• プロンプトの品質：complete、thin、extreme-thin のいずれか。
• 自動補完したブリーフ：対象者、シナリオ、中心となるメッセージ、ページ数、ストーリー展開、出力ルート、スタイルの方向性、ソースの範囲、アセット／IPのポリシー、前提。
• 推奨ルート：guizang-web-fixed-style、formal-editable-pptx、dual-delivery のいずれか。
• 固定フォールバックの判断と、その選択理由。
• ユーザーに由来する内容と、Agent が推論した内容の区別。

ルートの決定順序

デフォルトの配信ルートを選ぶ前に、次の決定順序を使用します。最初に一致した項目が適用されます。正式な用途や編集可能性を示すキーワードは、プロンプトの情報量より優先されます。

順序	判定キー	条件	結果
1	explicit-formal-signal	pptx、.pptx、PowerPoint、可编辑、汇报、报告、政府、金融、培训、审计、コンサルティング／ビジネスレポート、またはステークホルダーによる修正が加えられたファイル	formal-editable-pptx
2	explicit-web-signal	杂志风、网页PPT、HTML、横滑、Swiss/瑞士风、エディトリアル／電子ペーパー、ブラウザー優先、キーノート／ショーケース／デモデー	magazine-web-deck
3	extreme-thin-fallback	トピックのみ、または25文字／語以下で、対象者、シナリオ、ソース、ページ数、スタイル、主要メッセージを示す情報がない	guizang-web-fixed-style
4	thin-guided-intake	トピックに加えて上記の情報が少なくとも1つあるものの、ソースまたは主要コンテンツがない	段階的な質問
5	complete-source-first	ソースと制作コンテキストが十分	ソースを起点に進める

判断に迷う場合は、フィクスチャに基づく分類器を実行します。

python3 ${SKILL_DIR}/scripts/best_effect_router.py "<raw user request>"

極端に情報量の少ないプロンプトへのフォールバック

ユーザーがトピックのみ、1行の依頼、またはごくわずかなソース資料しか提示していない場合、最初に完璧なプロンプトを書くよう求めないでください。ユーザーが正式用途／編集可能／政府／金融／研修用のPPTXを明示的に依頼している場合を除き、次の安定したデフォルトを使用します。

• ルート：Guizang-like Magazine Web Deck fixed style；
• モード：Mode 2: Magazine Web Deck；
• スタイル：Style A · 電子雑誌 × 電子ペーパー；
• ページ数：ユーザーから別の指定がない限り8ページ；
• ページ構成：
  1. 明るい色調または温かみのある紙のような表紙。印象的なタイトル、最小限のサブタイトル、柔らかな縁のビジュアル／エビデンスパネルを1つ配置します；
  2. 課題、トレンド、または背景を示す明るいコンテキストページ；
  3. 緊張感や機会を示す、画像とテキストの構成、または抑制の効いたシグナルを配置したページ；
  4. 3つの要素で構成するフレームワーク、道筋、または手法を示す明るい構成ページ；
  5. 大きなメッセージを掲げるセクション区切りページ；
  6. エビデンス／シーン／事例のページ；
  7. 最終的な判断または問いを示す視点のページ。ユーザー、参考資料、または選択された方向性で指定されている場合に限り、ダークな色調を使用します；
  8. 行動、要点、または締めくくりの一文を示す明るいクロージングページ。

このフォールバックは「安定した高品質の出力」を実現するためのルートです。事実の不足、ブランド／IPの使用許可、コンプライアンス上の境界、またはソースの信頼性がデッキを大きく左右する場合に限り、エージェントは焦点を絞った質問を1つだけ行えます。通常のスタイルに関する不足は、固定スタイルで補います。

ユーザーが正式用途で編集可能なデッキ、政府／金融／研修／レポート用の資料、または.pptxを明示的に依頼した場合は、formal-editable-pptxに切り替えます。Microsoft YaHei、明るい色調／ほぼ白のデフォルト表紙、柔らかな縁の大きなヒーローパネル、正式なビジネス品質ゲート、ソースの信頼度、公式素材／IP素材の計画、同じbestEffectBriefレコードを含む、8～12ページの編集可能なPPTXブリーフを作成します。ユーザーまたはブランドの方向性で明示的に求められていない限り、ページ全体が黒い表紙は使用しないでください。

簡潔なブリーフの確認ゲート

制作に入る前に、依頼がビジュアル Web ブリーフ経由か、Codex との直接の会話経由かを判断します。

• Web Visual Brief Builder：project-brief.json.visualBrief、guidedBrief、expectationFitを確認します。Web のタグは装飾ではなく、ユーザーの意図を示すものです。タグの既定値と矛盾する場合は、貼り付けられた背景情報や特別な要件を優先します。
• Codex Guided Intake：Codex への直接の依頼で詳細が不足している場合は、いきなり最終品質の PPT 制作に進まず、制作の枠組みが明確になるまで段階的に質問します。
• ソース優先：信頼できるソースファイルと対象の文脈がすでに揃っている場合は、前提を記録して先に進みます。
• 前提付きドラフト：ユーザーがドラフト、初稿、または「まずは既定の内容で一版作ってください」と明示的に依頼した場合に限り、これを使用します。

Agent を直接使用する場合は、ガイド付きヒアリングの前に Best-Effect Brief Enhancer を実行します。bestEffectBriefから安全に制作方針を推定できない場合にのみ、段階的に質問します。

ガイド付きヒアリングでは次の項目を確認できますが、ストーリーボードを提示する前にユーザー向けの質問を3つ以内にします。リスクのない技術的な選択は推定し、残る詳細は編集可能な前提として明示します。

1. 使用シナリオと対象読者。
2. 読者に期待する行動や判断。
3. ソース資料と、内容の基準となる範囲。
4. 中心メッセージと必須項目。
5. ページ数、章立て、発表者ノートの要否。
6. ビジュアルスタイルと情報密度。
7. ブランド、公式素材／IP 素材、AI 画像の使用許可、避けるべき事項。
8. 出力形式。既定では編集可能な PPTX とします。

ユーザーの回答後、簡潔な確認用ブリーフを作成します。expectationFit.readyForProduction = trueになった場合、またはユーザーが記録された前提付きのドラフトを明示的に承諾した場合にのみ、作業を進めます。

既定の納品ルート

このスキルは、実際のオフィスで使う PPT の納品に最適化されています。ルートの判断はシンプルにします。

• 一般的ながら内容があり、十分な正式な背景情報を含むビジネス依頼では、既定でモード1：編集可能な PPTXを選択し、bestEffectBriefの作成後に作業を進めます。
• 「AI に関する PPT を作ってください」「PPT を作ってください」「スライドを作って」などの極端に情報の少ない依頼や、正式な形式／編集可能なファイルを求めていることが示されていない、テーマのみの依頼では、Guizang風マガジン Web デッキ固定スタイルを使用するモード2：マガジン Web デッキを既定とします。
• ユーザーが PowerPoint、.pptx、編集可能なファイル、ビジネスレポート、コンサルティング資料、研修資料、政府／金融関連資料、または他の人が修正する可能性のあるものを求めている場合は、モード1：編集可能な PPTXを選択します。
• ユーザーが雑誌風、Web PPT、HTML スライド、横スワイプ式デッキ、エディトリアル／電子ペーパー、スイス・スタイル、基調講演／ショーケース／デモデイ形式、ブラウザー優先の納品を明示的に求めている場合、または「極端に情報の少ないプロンプトへのフォールバック」が有効な場合は、モード2：マガジン Web デッキを選択します。
• ユーザーが両方を求めている場合は、プロジェクトフォルダーを分けて個別に納品します。
• 依頼のルートが実際に曖昧で、シナリオから判断できない場合に限り、ユーザーに選択を求めます。簡潔な質問を1つしてから作業を続けます。

一般的な依頼には、平易な言葉で次のように説明します。

短い指示を最適な効果が得られるブリーフに自動で広げてから進めます。テーマや一文だけの指示で、正式な編集可能 PPTX の明確な指定がない場合は、既定で Guizang風マガジン Web PPT を選び、まず安定した高品質の初稿を作成します。正式な報告資料や編集可能なファイルが必要な場合は、PPTX に切り替えます。

正式なビジネス納品ゲート

まず品質モードを選択します。ドラフトにはquick、ほとんどの正式なレポートには既定のstandard、取締役会／政府／金融／外部公開向けにはaudit／formal-auditを使用します。ビジネス／レポート／コンサルティング／研修／政府／金融関連のデッキ、および実際の関係者に渡すことを想定した納品物では、既定でqualityGate.level = "formal-business"にします。ユーザーが簡易ドラフトを明示的に求めている場合を除き、これを既定の品質基準とします。 最終的な PPTX または Web Deck ファイルを生成する前に、以下の項目を design_spec.md、spec_lock.md、design-quality-report.md に確定してください。

• templates/visual-directions/ から選んだビジュアルの方向性、または適切な方向性がない場合は、文書化した custom ベンチマーク。
• ページの役割とレシピの契約：各ページについて、design_spec.md／spec_lock.md に page_role、visual_weight、layout_family、page_recipe_id、asset_requirement、visual_layer、raster_policy、anti_patterns を記載します。
• ブランドアセット、または文書化した代替策。
• ソースまたはユーザーが言及する、企業ロゴ、キャンペーンロゴ、観光関連IP、製品マーク、QRコード、印章、パートナーマークなど、確定的なマークの公式／IPアセット計画。まず公式または認可済みのソースを検索してください。ロゴ風の偽物のプレースホルダーは決して描かないでください。
• 追跡可能な証拠ソースとデータ解釈の境界。
• カスタムビジュアル用の既定のビジュアルアセット生成エンジンとして、Codex ネイティブの GPT 画像生成（利用可能な場合は image2）を使用します。これは「ChatGPT/OpenAI を主要なビジュアルアセットエンジンとして使用する」ための Codex 実行パスです。プロンプト、ファイル名、対象スライド、手動編集を asset-plan.md または images/image_prompts.md に記録します。
• 有用な場合は、再利用可能な小型要素のアセット計画：セクション区切り、指標バッジ、プロセスノード、コネクター、アイコンのアクセント、テクスチャ、コールアウトステッカー。
• scripts/generate_visual_element_kit.py によるローカル要素生成の状態：assets/generated/element-manifest.json、images/image_prompts.json、images/image_prompts.md。
• 証拠、公式リファレンス、ブランドの境界に関する公開アセット検索計画、または検索しない理由の明示。選定した各公開アセットについて、ソース URL、発行元、ライセンス／使用上の注記、挿入先を記録します。
• デッキに表示する各確定的な IP マークについて、spec_lock.md brand_assets および asset-plan.md／images/image_sources.json に記録します。各エントリには official-source、user-provided、text-lockup-fallback、needs-authorized-replacement のいずれかを記載してください。
• 画像、チャート、インフォグラフィックの計画、または画像を使用しない方針の明示。
• ページのリズム、レイアウトの多様性、各スライドの役割。
• spec_lock.md aesthetic_checks に、本文フォントの基準、タイトルと本文のサイズ比、カード数、カードのパディング、余白の目標、ロゴの扱い、レイアウト反復のリスクを記載します。
• 4.0 のハイブリッド編集可能ビジュアル戦略：生成ビジュアルはテキストを含まないレイヤーとしてページを補助し、正式な本文ページは編集可能な状態を保ちます。
• ビジュアルの完成状況：スクリーンショット／PNG をレンダリングし、レイアウト反復のリスクを確認し、プレースホルダーアセットにラベルを付け、design-quality-report を作成します。
• 編集可能な PPTX オブジェクトと Web Deck のビジュアル全体のレンダリングに関する成果物チェック。 正式納品のルール：
• タイトルとカードを繰り返すページだけで、デッキ全体を構成しないでください。
• デザイン仕様書に意図的な理由が記録されている場合を除き、3ページ連続で同じレイアウトファミリーを使用しないでください。
• デザイン仕様書に意図的な理由が記録されている場合を除き、3ページ連続で同じページレシピを使用しないでください。
• 正式なPPTXの本文ページに、ページ全体を覆う生成画像を使用しないでください。ページ全体を覆うラスター画像の使用は、表紙、セクションページ／最終ページ、ポスター／KVページ、Webショーケースページ、またはraster_policyに記録されたユーザーの明示的な許可がある場合に限ります。
• デッキがドラフトであることを明確に示し、ユーザーがその制約を承諾している場合を除き、スライドタイトルだけの状態で作業を進めないでください。
• デッキの文脈に合うビジュアルディレクションパックがある場合は、汎用的な「フリーデザイン」風の見た目を使用しないでください。まずディレクションパックを選び、その後に調整してください。
• ビジュアルによってデッキを改善できる場合は、CodexネイティブのGPT画像生成（利用可能な場合はimage2）を主要なビジュアルアセット生成エンジンとして扱ってください。最終的なスライドの組み立て前に、構成済みの補助ビジュアルと、小さく再利用可能なマイクロアセットを生成してください。
• ランダムなストック画像や、要素をただ積み重ねる手法に頼らないでください。各AIビジュアルには、背景の雰囲気、エビデンスのイラスト、プロセスのアクセント、概念的なメタファー、製品／文脈を示すシーン、テキストを含まないビジュアルレイヤーのいずれかとして、シーン／構成上の役割を持たせてください。
• 有用な場合は、一貫性のあるエレメントキットを生成して再利用してください。小さなセクション区切り、指標バッジ、プロセスノード、コネクター、アイコンのアクセント、控えめなパターン、コールアウトステッカーなどが含まれます。
• マイクロアセットを繰り返し使用する正式なデッキでは、最終的なスライドの組み立て前にpython3 scripts/generate_visual_element_kit.py <project_path>を実行してください。画像バックエンド／キーもホストネイティブの画像ツールも利用できない場合は、images/image_prompts.mdにNeeds-Manualプロンプトを記録して作業を続けてください。デッキ全体の作業を中断しないでください。
• 公開／公式／再利用可能なアセットの検索は、主に事実を裏付ける資料、公式参照資料、ブランド使用上の境界を確認するために行ってください。挿入前に、出典と使用上の境界を記録してください。
• ソースに固定のIP名が含まれる場合は、生成前に公式ソースを検索してください。例：交通银行、好客山东、文旅大戏、製品／カード名、提携組織、都市／観光ブランド、アプリ／ミニプログラムのロゴ、イベントのロゴ。公式ウェブサイト、プレスリリース、メディアキット、政府／公共サービスのポータル、またはユーザー提供ファイルを優先してください。第三者のロゴダウンロードサイトは、検索の手がかりとしてのみ使用でき、最終的な出典資料としては使用できません。
• 固有のIPアセットは装飾的なアイコンではありません。公式に入手した、またはユーザーから提供された場合は、実際のアセットを挿入してください。それ以外の場合は、置き換えに関する注記を目に見える形で記載し、クリーンなテキストロックアップを使用してください。偽のシンボル、汎用バッジ、「似ている」マークを作成しないでください。
• Codex／GPT／OpenAIが生成したアセットはassets/generated/またはプロジェクトの画像フォルダーに保存し、実際のアセットとして挿入してください。
• 非公開のソース資料、内部スクリーンショット、顧客データ、APIキーは、ユーザーがアップロードを明示的に承認しない限り、ローカルに保管してください。
• PPTXの出力には、編集可能なテキスト、図形、グラフ、画像、ノートを使用してください。スライドをページ全体のスクリーンショットに統合しないでください。
• ロゴやブランドマークには、実際のアセット、適切に処理されたベクター、または記録されたテキストによる代替表現を使用してください。ロゴをb／cのようなテキストの断片に劣化させないでください。
• 既知のロゴやキャンペーンのIPマークを、任意の図形、頭文字、アイコンバッジ、生成による近似物に置き換えないでください。公式アセットを安全に入手できない場合は、design-quality-report.mdで外部公開をブロックし、needs-authorized-replacementを記録してください。
• Webデッキでは、デスクトップ／モバイルでの視覚的な完全性、メディアの描画、レイアウトの多様性を確認してください。
• Design Doctorは、デフォルトでレポートのみを出力します。ユーザーから自動修復を明示的に依頼された場合を除き、SVGを自動修復しないでください。

デリバリーデザインのデフォルト設定

ユーザー、ブランドガイド、または選択したテンプレートで明示的に上書きされない限り、以下のデフォルト設定を使用してください。

• フォントファミリー：既定の CJK フォントおよび本文フォントには "Microsoft YaHei"（微软雅黑）を使用し、プレビュー時のフォールバックとしてのみ "PingFang SC"、ラテン文字のフォールバックとして Arial を使用します。これにより、PowerPoint への引き継ぎを実用的にし、Web フォントの著作権やインストールに関するリスクを避けます。
• タイトルと本文の関係：ほとんどのフォーマルなスライドでは全体を通して Microsoft YaHei を使い、フォントを増やすのではなくウェイトのコントラストで変化をつけます。エディトリアル、アカデミック、基調講演のようなトーンが必要で、フォントがプリインストール済み、または明確に記載されている場合に限り、セリフ体やディスプレイ体とのコントラストを使います。
• テーマのアートディレクション：ソースを読み、ビジュアルの方向性を選んだら、生成前にテーマに合った具体的なアートコンセプトをひとつ決めます。表紙や最終ページ、スライド全体で繰り返す任意のモチーフを導ける程度に具体的なものにします。たとえば、文化・観光をテーマにしたスライドでは、海岸線、山のシルエット、旅行スタンプのリズム、温かみのある市場の灯り、抑制された銀行ブランドの構成といった要素を含む 山海交汇 烟火同行 を使えます。ソースにより豊かなテーマがあるのに、「ビジネスブルー」で済ませないでください。
• タイトルのアート表現：業務報告書、政府・金融分野の厳格なコンプライアンス文書、または表現豊かなタイトルが不適切なその他の文脈を除き、メインタイトルには独自の構成を通じてテーマのアートディレクションを反映させます。たとえば、テキストを重ねたロックアップ、図形で描いた筆文字風の線、画像マスクのアクセント、大きなネガティブスペース、モチーフと一体化したタイトル枠などです。本文には引き続き Microsoft YaHei を使います。ディスプレイフォントは、インストール済みでライセンスがあるものを使うか、描画・ベクター表現で置き換えます。
• 16:9 PPT のフォントサイズ：表紙タイトルは 60-92px、セクションタイトルは 44-60px、ページタイトルは 30-40px、サブタイトルは 22-28px、本文は 18-24px、グラフのラベル・キャプションは 12-16px にします。情報量の多いコンサルティング資料では、通常、本文を 18-20px にします。研修資料や基調講演では 22-24px にします。
• スケールと余裕：「小さな PPT」症候群を避けます。テキストグループが 3-5 個あるページでは、フォーマルな本文は通常 20-22px にします。情報量の多いレポートでも 18px を下限とします。テキストを 18px 未満にする必要がある場合は、スライドを分割する、文章を表やプロセス図に変換する、または詳細をノートに移します。ページタイトルは本文の約 1.6-2.0 倍、カードタイトルは本文の 1.15-1.35 倍のサイズにして、明確に目立たせます。脚注は視覚的に控えめにします。
• 余白とグリッド：16:9 のセーフマージンは 48-64px、タイトル帯は 72-96px、フッターは 28-40px とし、主要コンテンツ領域は 12 カラムのグリッド、または意図的な非対称分割に沿って配置します。テキストをキャンバスの端、グラフの軸、装飾レイヤーに接触させないでください。
• 1 スライドあたりのコンテンツ量：1 ページで伝える主な判断はひとつにします。本文ページには通常、中心となるビジュアルシステムひとつと補足ポイント 2-4 個を配置するか、明確な要点を示すタイトルを付けた情報量の多い表やグラフを配置します。
• レイアウトの多様性：本文ページでは、グラフ＋要点、画像とテキストの分割、プロセスフロー、根拠を示す表、ネガティブスペースを活かしたメッセージ、マトリクス、タイムライン、FAQ／リスクの積み上げなど、ページの種類を交互に使います。タイトル＋カード 3 枚の構成を定番として繰り返さないでください。
• 要素の扱い：フラットな図形、明瞭な区切り線、控えめな塗り、抑制された影を使います。カードは項目をグループ化するために使い、段落ごとに設けないでください。アイコンは内容をすばやく把握する助けにしますが、内容の代わりにはなりません。
• 画像の扱い：生成ビジュアルは、表紙、セクション区切り、ポスター／ショーケース、または意図的に画像を中心とした Web Deck ページを除き、テキストを含まない補助レイヤーとして使います。フォーマルな本文 PPTX は編集可能な状態を保ちます。
• 仕上げの規律：極端に狭いガター、角張ったボックスの羅列、丸みが強すぎるカード、どこも同じ強さのボックス、弱いタイトル階層、コントラストの低いグレーの文字、孤立したラベル、窮屈なロゴ、無作為な装飾線、公式に見える未ライセンスのマークを避けます。コンテナが必要な場合、編集可能な PPTX では控えめな 8-14 pt の角丸を基本とし（Web では 12-20 px）、表紙のヒーローまたは根拠を示すパネルひとつに限り 18-24 pt／24-32 px を使えます。グラフ、罫線、表の内部構造は直線にします。装飾を加える前に、余白、スケール、配置、そして明確な主役を活用します。

プロジェクトの成果物が存在する場合は、正式な監査を実行してください：

python3 scripts/audit_formal_delivery.py <project_path_or_artifact>
python3 scripts/audit_design_completion.py <project_path_or_artifact>
python3 scripts/audit_visual_recipes.py <project_path_or_artifact>
python3 scripts/audit_pptx_native_objects.py <final.pptx> --expect text,shape

監査に失敗した場合は、具体的な問題を報告し、既知のリスクを承知で出荷することをユーザーが明示的に選択しない限り、最終納品前にデッキを修正してください。

注意

🚨 全体的な実行規律（必須）

このワークフローは、厳密な逐次パイプラインです。以下のルールは最優先事項です。いずれかに違反すると、実行失敗となります。

1. 簡潔な逐次実行 — ステップは順番に実行しますが、不必要な待機を増やしてはいけません。前提条件がそろったら、ユーザーに「続けて」と言ってもらうことなく、ブロックされないステップを進めてください。
2. ガイド付きヒアリングの前にベストエフォートの概要を作成 — ユーザーが Codex で直接依頼しており、本格的な PPT を作るのに十分な詳細が提示されていない場合は、まず bestEffectBrief を作成してください。プロンプトの情報が単に不足している場合は、成果物を大きく左右する事実、情報源、ブランド／IP、コンプライアンス、またはルートの選択についてのみ、段階的に質問してください。プロンプトが extreme-thin で、ユーザーが編集可能な正式な PPTX を明示的に依頼していない場合は、Extreme Thin Prompt Fallback を使用し、Guizang のようなマガジン Web デッキの固定スタイルで作成してください。
3. ヒアリング後は、実際の障害がある場合にのみ停止 — ブリーフが十分に明確になった後は、必須の情報源、ルートの選択、法的／ブランド上の許可、または不足している手動アセットが、作業を進めるうえでリスクとなる場合にのみ停止してください。それ以外の場合は、妥当な前提を置いて記録し、作業を続けてください。
4. ヒアリング後に納品ブリーフを1つ作成 — 依頼が曖昧な場合、ガイド付きヒアリングは複数回の短いやり取りにわたることがあります。その後は、さらに複数回の確認を行うのではなく、簡潔な納品ブリーフを1つ作成してください。ストラテジストは引き続きキャンバス、ページ数、対象者、スタイル、色、アイコン、タイポグラフィ、画像を決定しますが、ユーザー向けの確認を連続して行うのではなく、1つの制作仕様として記録してください。
5. 開始前のゲート確認 — 各ステップの冒頭には、前提条件（🚧 GATE）が記載されています。そのステップを始める前に、これらを必ず確認してください。
6. 推測による先行実行は禁止 — 後続のステップの内容を「事前準備」することは禁止です（例：ストラテジストのフェーズで SVG コードを書くこと）。
7. サブエージェントによる SVG 生成は禁止 — エグゼキューターのステップ 6 での SVG 生成はコンテキストに依存するため、現在のメインエージェントが最初から最後まで完了させる必要があります。ページ SVG 生成をサブエージェントに委任することは禁止です。
8. ページは逐次生成のみ — エグゼキューターのステップ 6 では、全体のデザインコンテキストを確定した後、1回の連続した作業で、SVG ページを1ページずつ順番に生成する必要があります。ページをまとめて生成するバッチ処理（例：一度に5ページ）は禁止です。
9. ページごとに SPEC_LOCK を再読み込み — SVG ページを生成する前に、エグゼキューターは read_file <project_path>/spec_lock.md を実行する必要があります。すべての色／フォント／アイコン／画像はこのファイルに基づく必要があり、記憶に頼ったり、その場で値を作り出したりしてはいけません。また、エグゼキューターは現在のページの page_rhythm タグを確認し、対応するレイアウト規律（anchor ／ dense ／ breathing — executor-base.md §2.1 を参照）を適用する必要があります。このルールは、長いデッキでコンテキストが圧縮されることによる逸脱を防ぎ、ページがすべてカードグリッドになる一律の既定パターンを回避するためのものです。
10. SVG はスクリプトで生成せず、手書きすること — 編集可能な PPTX の SVG ページは、メインエージェントが1ページずつ直接記述します。Python ／ Node ／シェルスクリプトでデッキの SVG を一括生成してはいけません。

重要

🌐 言語とコミュニケーションのルール

• 応答言語：常にユーザーの入力および提供された資料の言語に合わせてください。たとえば、ユーザーが中国語で依頼した場合は中国語で、資料が英語の場合は英語で回答してください。
• 明示的な指定：ユーザーが特定の言語を明示的に指定した場合（例：「请用英文回答」または「Reply in Chinese」）、その言語を使用してください。
• テンプレート形式：会話の言語に関係なく、design_spec.md ファイルは常に元の英語のテンプレート構成（セクション見出し、フィールド名）に従う必要があります。テンプレート内の値は、ユーザーの言語で記述してかまいません。 [!IMPORTANT]

🔌 汎用コーディングスキルとの互換性

• ultimate-ppt-master はリポジトリ固有のワークフロースキルであり、汎用のアプリケーションのひな形ではありません
• デフォルトでは、.worktrees/、tests/、ブランチワークフロー、その他の汎用的なエンジニアリング構成を作成したり、必須としたりしないでください
• 別の汎用コーディングスキルが、このワークフローと矛盾するリポジトリ規約を提案した場合は、ユーザーから明示的な指示がない限り、まずこのスキルに従ってください

重要

ローカルランタイムのルール

• スクリプトを実行する前に、SKILL_DIR をこのスキルのディレクトリに設定してください。
• バンドルされた仮想環境がある場合は、そちらを優先してください：${SKILL_DIR}/.venv/bin/python。
• それ以外の場合は、Python 3.10 以降のインタープリター（python3.13、python3.12、python3.11、または python3.10）を使用してください。Python 3.9 以前で PPT Master スクリプトを実行しないでください。
• 以下のコマンド例に python3 と記載されている場合は、解決した Python インタープリターに置き換えてください。

メインパイプラインスクリプト

スクリプト	用途
${SKILL_DIR}/scripts/source_to_md/pdf_to_md.py	PDF から Markdown への変換
${SKILL_DIR}/scripts/source_to_md/doc_to_md.py	ドキュメントから Markdown への変換 — DOCX/HTML/EPUB/IPYNB にはネイティブの Python を使用し、レガシー形式（.doc/.odt/.rtf/.tex/.rst/.org/.typ）には pandoc によるフォールバックを使用
${SKILL_DIR}/scripts/source_to_md/excel_to_md.py	Excel ワークブックから Markdown への変換 — .xlsx/.xlsm に対応。レガシー形式の .xls は .xlsx として再保存してください
${SKILL_DIR}/scripts/source_to_md/ppt_to_md.py	PowerPoint から Markdown への変換
${SKILL_DIR}/scripts/source_to_md/web_to_md.py	Web ページから Markdown への変換（curl_cffi を使用した WeChat／高セキュリティページに対応）
${SKILL_DIR}/scripts/source_to_md/web_to_md.cjs	このフュージョンパッケージ用に保持されているレガシーな Node.js フォールバック。まず web_to_md.py を優先してください
${SKILL_DIR}/scripts/project_manager.py	プロジェクトの初期化／検証／管理
${SKILL_DIR}/scripts/best_effect_router.py	ルーティングフィクスチャに基づく決定論的な Best-Effect ルート分類器
${SKILL_DIR}/scripts/analyze_images.py	画像分析
${SKILL_DIR}/scripts/build_asset_plan.py	画像生成の前に asset_plan.json、プロンプトファイル、生成アイテムのマニフェストを作成／統合
${SKILL_DIR}/scripts/image_gen.py	AI 画像生成（複数のプロバイダーに対応）
${SKILL_DIR}/scripts/image_search.py	PPTX 用画像取得のための Web 画像検索ヘルパー
${SKILL_DIR}/scripts/svg_quality_checker.py	SVG の品質チェック
${SKILL_DIR}/scripts/spec_lock_slice.py	spec_lock.md の行数上限を適用し、ページごとのロックスライスを返す
${SKILL_DIR}/scripts/execution_budget.py	ページ数がしきい値を超えるデッキに resume-execute の分割モードを必須にする
${SKILL_DIR}/scripts/total_md_split.py	スピーカーノートの分割
${SKILL_DIR}/scripts/finalize_svg.py	SVG の後処理（統合エントリーポイント）
${SKILL_DIR}/scripts/svg_to_pptx.py	PPTX にエクスポート
${SKILL_DIR}/scripts/validate-magazine-deck.mjs	Style A のマガジンデッキの静的検証：プレースホルダー、クラス、リズム、画像参照
${SKILL_DIR}/scripts/validate-swiss-deck.mjs	references/magazine-web/swiss-layout-registry.json を使用した Style B の Swiss デッキの静的検証
${SKILL_DIR}/scripts/animation_config.py	オプションのオブジェクトレベル PPTX アニメーション用サイドカーの足場作成
${SKILL_DIR}/scripts/notes_to_audio.py	オプションの録音ナレーション音声の生成
${SKILL_DIR}/scripts/update_spec.py	spec_lock.md の color／font_family の変更を、生成済みのすべての SVG に反映
${SKILL_DIR}/scripts/visual_review.py	生成された SVG ページのオプションのルーブリックベースのビジュアルレビュー
${SKILL_DIR}/scripts/audit_design_completion.py	ページの役割、レイアウトの反復、アセット、ノート、引き渡し準備状況のビジュアル完成度監査
${SKILL_DIR}/scripts/generate_visual_layers.py	ハイブリッド編集可能なデッキ向けに、テキストなしのページビジュアルレイヤープロンプト／マニフェストを準備
${SKILL_DIR}/scripts/audit_visual_recipes.py	4.0 のハイブリッド編集可能なデッキ向けに、ページレシピ、ビジュアルレイヤー、ラスター方針を監査

ツールの全ドキュメントについては、${SKILL_DIR}/scripts/README.md を参照してください。

テンプレート一覧

Index	Path	Purpose
レイアウトテンプレート	${SKILL_DIR}/templates/layouts/layouts_index.json	利用可能なページレイアウトテンプレートを照会します
シナリオプリセットの指示	${SKILL_DIR}/templates/presets/preset-directions.json	一般的なデッキ構成、ソース要件、テンプレート候補、QA チェックを用意します
ビジュアルディレクションパック	${SKILL_DIR}/templates/visual-directions/index.json	Strategist が design_spec.md を作成する前に、コンテキストに応じた美的ガイドラインを選択します
ページレシピ	${SKILL_DIR}/templates/page-recipes/index.json	PPTX／Web ページを生成する前に、ページごとの構造レシピを選択します
ブランドプリセット	${SKILL_DIR}/templates/brands/brands_index.json	利用可能なブランドアイデンティティのプリセット（色／タイポグラフィ／ロゴ／トーン）を照会します
ビジュアライゼーションテンプレート	${SKILL_DIR}/templates/charts/charts_index.json	利用可能なビジュアライゼーション SVG テンプレート（チャート、インフォグラフィック、図、フレームワーク）を照会します
アイコンライブラリ	${SKILL_DIR}/templates/icons/	${SKILL_DIR}/templates/icons/README.md を参照してください。ls templates/icons/<library>/ | grep <keyword> で必要に応じてアイコンを検索できます
マガジン Web スタイル A テンプレート	${SKILL_DIR}/assets/magazine-web/template.html	単一ファイルのエディトリアル／電子ペーパー風 Web デッキの雛形
マガジン Web スタイル B テンプレート	${SKILL_DIR}/assets/magazine-web/template-swiss.html	単一ファイルのスイススタイル Web デッキの雛形
マガジン Web のリファレンス	${SKILL_DIR}/references/magazine-web/	テーマ、レイアウト、コンポーネント、画像プロンプト、スクリーンショットのフレーミング、QA チェックリスト

単独ワークフロー

Workflow	Path	Purpose
topic-research	workflows/topic-research.md	ユーザーがソースファイルを提供せず、トピックのみを提示した場合のパイプライン前調査
create-template	workflows/create-template.md	単独のテンプレート作成ワークフロー
create-brand	workflows/create-brand.md	ブランド専用テンプレートを単独で作成するワークフロー
resume-execute	workflows/resume-execute.md	ステップ 1～5 の後、新しいチャットで SVG の実行を再開します
verify-charts	workflows/verify-charts.md	エクスポート前のチャート座標の調整
customize-animations	workflows/customize-animations.md	オプションのオブジェクト単位の PPTX アニメーションカスタマイズ
generate-audio	workflows/generate-audio.md	オプションの録音ナレーション／音声ワークフロー
live-preview	workflows/live-preview.md	ブラウザーでのライブプレビューと注釈付けワークフロー
visual-review	workflows/visual-review.md	SVG の生成後、後処理の前に行うオプションのページごとのビジュアルレビュー

---

モード 2：マガジン Web デッキのワークフロー

このワークフローは、Default Delivery Route でマガジンスタイルの Web デッキが選択された場合にのみ使用します。

Web ステップ 1：デッキの概要を確認する

テンプレートをコピーする前に、ビジュアルのサブスタイルを 1 つ選択します。

Style	Use when	Template	References
A · 電子雑誌 × 電子ペーパー (デフォルト)	ユーザーがマガジン、エディトリアル、電子ペーパー、Monocle風、人間味のある表現、ナラティブを指定した場合、またはサブスタイルを指定していない場合	assets/magazine-web/template.html	themes.md、layouts.md、components.md
B · スイス国際主義／スイススタイル	ユーザーがスイススタイル、瑞士風、Helvetica、グリッド、情報デザイン、データ主導、製品／エンジニアリング／KPI のデッキを指定した場合	assets/magazine-web/template-swiss.html	themes-swiss.md、layouts-swiss.md、swiss-layout-lock.md

ユーザーがこれらの詳細をまだ提示していない場合は、サブスタイル A／B、対象者／シナリオ、発表時間または目標ページ数、ソース資料、画像の利用可否／スクリーンショットの扱い、テーマの希望、厳守すべき制約について、簡潔な質問を一度に 1 つずつ行います。十分な情報がある場合は、前提を明示して進めます。元のマガジン／電子ペーパーの美的表現を維持するため、デフォルトはスタイル A とします。

構成についてユーザーの支援が必要な場合は、次のナラティブアークを提案します。

Hook → Context → Core → Shift → Takeaway

Web Step 2：HTML デッキフォルダーを作成する

Web デッキ用のフォルダーを作成します。通常は <project_name>/ppt/ とし、隣接して images/ ディレクトリを用意します。シードテンプレートをコピーします。

mkdir -p "<project_path>/ppt/images" "<project_path>/ppt/assets"
cp "${SKILL_DIR}/assets/magazine-web/motion.min.js" "<project_path>/ppt/assets/motion.min.js"

スタイル A · エディトリアル／電子ペーパー：

cp "${SKILL_DIR}/assets/magazine-web/template.html" "<project_path>/ppt/index.html"

スタイル B · スイススタイル：

cp "${SKILL_DIR}/assets/magazine-web/template-swiss.html" "<project_path>/ppt/index.html"

index.html の <title> プレースホルダーをすぐに置き換えます。納品前に [必填] を検索し、残っているプレースホルダーをすべて削除してください。

Web Step 3：テーマとレイアウトを選択する

選択したスタイルに応じて、必要な雑誌向けリファレンスのみを読み込みます。

• スタイル A のテーマ選択：${SKILL_DIR}/references/magazine-web/themes.md
• スタイル A のレイアウトスケルトンとテーマのリズム規則：${SKILL_DIR}/references/magazine-web/layouts.md
• スタイル B のテーマ選択：${SKILL_DIR}/references/magazine-web/themes-swiss.md
• スタイル B の固定レイアウトスケルトン：${SKILL_DIR}/references/magazine-web/layouts-swiss.md
• スタイル B のレイアウト固定規則：${SKILL_DIR}/references/magazine-web/swiss-layout-lock.md
• スタイル B のレイアウトレジストリ：${SKILL_DIR}/references/magazine-web/swiss-layout-registry.json
• 共通コンポーネントの詳細：${SKILL_DIR}/references/magazine-web/components.md
• スクリーンショットのフレーミング：${SKILL_DIR}/references/magazine-web/screenshot-framing.md（スクリーンショット／UI キャプチャを使用する場合のみ）
• 生成画像用の任意のプロンプト：${SKILL_DIR}/references/magazine-web/image-prompts.md
• 最終 QA：${SKILL_DIR}/references/magazine-web/checklist.md

ルール：

• スタイル A では厳選された 5 つのテーマのいずれかを、スタイル B ではスイススタイルのテーマプリセットのいずれかを使用します。ユーザーが美的システムを明示的に変更しない限り、独自の 16 進カラーコードを作成しないでください。
• 1 つのデッキ内でスタイル A とスタイル B のクラスシステムを混在させないでください。テンプレートを 1 つコピーし、対応するレイアウトリファレンスのみを使用します。
• スライドを作成する前に、ページのリズムを計画します。すべての <section> に light、dark、hero light、または hero dark を含める必要があります。
• スライドを一から作成するのではなく、レイアウトスケルトンを使用します。
• スライドのマークアップを追加する前に、index.html の <style> ブロックを確認し、選択したスケルトンで使用するすべてのクラスが存在することを確かめます。
• 画像は ppt/images/ の下に置き、images/01-cover.jpg のような相対パスで参照します。
• スタイル B では、すべてのスライドに swiss-layout-registry.json に登録された data-layout 値を設定します。また、レイアウトに画像スロットが定義されている場合は、ローカル画像に data-image-slot を含めます。

Web Step 4：生成、プレビュー、確認する

選択したセクションを <main id="deck"> に入力し、次の確認を実行します。

grep -n "\\[必填\\]" "<project_path>/ppt/index.html"
grep -n 'class="slide' "<project_path>/ppt/index.html"
node "${SKILL_DIR}/scripts/validate-magazine-deck.mjs" "<project_path>/ppt/index.html"

スタイル B では、静的なスイススタイル固定バリデーターも実行します。

node "${SKILL_DIR}/scripts/validate-swiss-deck.mjs" "<project_path>/ppt/index.html"

ファイルをブラウザーで直接開きます。

open "<project_path>/ppt/index.html"

最終 QA には ${SKILL_DIR}/references/magazine-web/checklist.md を使用します。納品前に P0 の問題を修正する必要があります。出力は .pptx ではなく index.html です。

---

モード 1：編集可能な PPTX ワークフロー

ステップ 1：ソースコンテンツの処理

🚧 GATE：ユーザーがソース資料を提供しています（PDF／DOCX／EPUB／URL／Markdown ファイル／テキストによる説明／会話の内容など、形式は問いません）。

ユーザーから PPT 作成に必要なコンテキストが十分に提供されていない場合は、ソースの変換に進む前に Brief Clarity Gate を実行してください。Codex への直接の依頼では、全体像を推測せず、段階的に質問してください。ユーザーがトピック、対象者、ソース、目的のいずれも示さず「PPT を作って」とだけ依頼した場合は、トピック調査や制作に進まないでください。

ユーザーがソースファイルや実質的なソースコンテンツを提供せず、トピック名や簡単な要件だけを示した場合は、まず workflows/topic-research.md を実行し、生成された Markdown／ソース資料を用意してから、ここに戻ってください。

ユーザーが Markdown 以外のコンテンツを提供した場合は、すぐに変換してください。

ユーザーが提供するもの	コマンド
PDF ファイル	python3 ${SKILL_DIR}/scripts/source_to_md/pdf_to_md.py <file>
DOCX／Word／Office ドキュメント	python3 ${SKILL_DIR}/scripts/source_to_md/doc_to_md.py <file>
XLSX／XLSM／Excel ワークブック	python3 ${SKILL_DIR}/scripts/source_to_md/excel_to_md.py <file>
CSV／TSV	プレーンテキストの表形式ソースとして直接読み込む
PPTX／PowerPoint スライド	python3 ${SKILL_DIR}/scripts/source_to_md/ppt_to_md.py <file>
EPUB／HTML／LaTeX／RST／その他	python3 ${SKILL_DIR}/scripts/source_to_md/doc_to_md.py <file>
Web リンク	python3 ${SKILL_DIR}/scripts/source_to_md/web_to_md.py <URL>
WeChat／高セキュリティサイト	python3 ${SKILL_DIR}/scripts/source_to_md/web_to_md.py <URL>（curl_cffi が必要です。このパッケージがない場合に限り、node web_to_md.cjs <URL> にフォールバックします）
Markdown	直接読み込む

DOCX／PPTX ソースの Office ベクター素材（EMF／WMF）：抽出した EMF／WMF ファイルは、独立したベクター素材として保持してください。ユーザーがラスタライズを明示的に承諾しない限り、PNG に変換しないでください。finalize_svg.py はこれらをスキップし、svg_to_pptx.py はネイティブの Office メディアとして埋め込みます。

✅ チェックポイント — ソースコンテンツの準備ができていることを確認し、ステップ 2 に進みます。

---

ステップ 2：プロジェクトの初期化

🚧 GATE：ステップ 1 が完了し、ソースコンテンツの準備ができています（Markdown ファイル、ユーザーが提供したテキスト、または会話で説明された要件のいずれも有効です）。

python3 ${SKILL_DIR}/scripts/project_manager.py init <project_name> --format <format>

形式のオプション：ppt169（デフォルト）、ppt43、xhs、story など。形式の全一覧については、references/canvas-formats.md を参照してください。

ソースコンテンツを取り込みます（状況に応じて選択してください）。

状況	操作
ソースファイルがある（PDF／MD など）	python3 ${SKILL_DIR}/scripts/project_manager.py import-sources <project_path> <source_files...> --copy
ユーザーが会話内でテキストを直接提供した	取り込みは不要です。コンテンツはすでに会話のコンテキスト内にあるため、以降のステップで直接参照できます

✅ デフォルトでは --copy を使用してください：取り込み時に、sources/ の下にプロジェクト専用のコピーが作成され、ユーザーの元ファイルはそのまま残ります。

• デスクトップ、ダウンロード、共有ドライブ、複数プロジェクトでの再利用には、--copy を優先してください。
• 元ファイルの削除をユーザーが明示的に希望した場合に限り、--move またはアーカイブ後の元ファイル削除を使用してください。
• リポジトリ内で生成された調査成果物は、誤ってコミットされるのを防ぐため、デフォルトで移動される場合があります。これを上書きするには、--copy を指定してください。
• 中間成果物（例：_files/ ディレクトリ）は、import-sources が自動的に処理します。

✅ チェックポイント — プロジェクト構造が正しく作成され、sources/ にすべてのソースファイルが格納され、変換済みの資料が準備できていることを確認します。ステップ 3 に進みます。

---

Step 3: テンプレートの選択肢

🚧 GATE：ステップ 2 が完了し、プロジェクトのディレクトリ構成が準備できています。

デフォルトのパス — 質問せずに自由にデザインします。 そのままステップ 4 に進んでください。layouts_index.json を参照したり、テンプレートと自由なデザインのどちらにするかをユーザーに質問したりしないでください。自由なデザインが標準モードです。AI がコンテンツに合わせて構成とスタイルを調整します。

テンプレートのフローはオプトイン方式です。 ユーザーの過去のメッセージに、次の明示的なきっかけがある場合にのみ、このフローに進んでください。

1. ユーザーが特定のテンプレートを指定する（例：「用 mckinsey 模板」／「use the academic_defense template」）
2. ユーザーがテンプレートに対応するスタイルやブランドを指定する（例：「McKinsey 那种」／「Google style」／「学术答辩样式」）
3. ユーザーが利用可能なテンプレートを明示的に尋ねる（例：「有哪些模板可以用」）

シナリオプリセットのヒント（進行を妨げません）。 タスクが一般的なシナリオに明らかに当てはまる場合は、${SKILL_DIR}/templates/presets/preset-directions.json を読み込み、該当するプリセットを使って、ストーリー、ソースの要件、推奨スライド構成、候補となる図表、品質チェック項目を準備してください。これによってビジュアルテンプレートが強制されることはありません。レイアウトやブランドのテンプレートファイルをコピーするのは、ユーザーがそのテンプレートを明示的にリクエストした場合、利用可能なテンプレートを尋ねてその中から選んだ場合、または引き継ぎ用マニフェストに明示的なプリセット／テンプレートの選択がすでに含まれている場合に限ります。

きっかけがある場合に限り、${SKILL_DIR}/templates/layouts/layouts_index.json を読み込み、一致するテンプレートを特定（きっかけ 3 の場合は利用可能な選択肢を一覧表示）して、テンプレートファイルをプロジェクトのディレクトリにコピーしてください。

cp ${SKILL_DIR}/templates/layouts/<template_name>/*.svg <project_path>/templates/
cp ${SKILL_DIR}/templates/layouts/<template_name>/design_spec.md <project_path>/templates/
cp ${SKILL_DIR}/templates/layouts/<template_name>/*.png <project_path>/images/ 2>/dev/null || true
cp ${SKILL_DIR}/templates/layouts/<template_name>/*.jpg <project_path>/images/ 2>/dev/null || true

控えめなヒント（進行を妨げず、任意）。 ステップ 4 に進む前に、ユーザーのコンテンツが既存のテンプレートに明らかによく合致し（例：明確な学術発表、政府機関の報告書、McKinsey 風のコンサルティング資料）、かつユーザーがテンプレートを指定していない場合、AI は次のような一文で知らせて、そのまま先に進んでもかまいません。

注：このシナリオに非常によく合う「<name>」テンプレートがあります。使用したい場合はお知らせください。そうでなければ、自由なデザインで進めます。

これはヒントであり、質問ではありません。進行を止めたり、返答を求めたりしないでください。 一致が弱い、または曖昧な場合は、ヒントを省略してください。

新しいグローバルテンプレートを作成するには、workflows/create-template.md を読み込んでください。

✅ チェックポイント — デフォルトのパスでは、ユーザーとのやり取りなしでステップ 4 に進みます。テンプレートを選ぶきっかけがあった場合は、次に進む前にテンプレートファイルをコピーします。

---

Step 4: 納品ブリーフとストラテジストのフェーズ（必須 — 省略不可）

🚧 GATE：ステップ 3 が完了し、デフォルトの自由なデザインのパスを選択したか、（きっかけがあった場合は）テンプレートファイルをプロジェクトにコピーしています。

まず、役割の定義を読み込んでください。

Read references/strategist.md

⚠️ strategist.md の必須ゲート：design_spec.md を作成する前に、ストラテジストは必ず read_file templates/design_spec_reference.md を実行し、I〜XI の全セクションで構成された仕様書を作成する必要があります。明示的なゲート規則については、strategist.md のセクション 1 を参照してください。

⚠️ ビジュアルディレクションのゲート：ストラテジストは必ず templates/visual-directions/index.json を読み込み、最も適したビジュアルディレクションのパック（または custom）を選択してください。また、それが適している理由、主な美的リスク、必須のページ役割、ページレシピ、避けるべきパターンを記録してください。

納品ブリーフを 1 つ完成させる必要があります。

納品ブリーフは、ユーザーに個別に確認を求める 8 項目ではなく、簡潔な制作上の判断です。Web 引き継ぎプロジェクトでは、まず project-brief.json から bestEffectBrief、briefMode、visualBrief、guidedBrief、expectationFit を読み込んでください。Codex への直接の依頼では、ガイド付きのヒアリングを始める前に bestEffectBrief を作成してください。bestEffectBrief.strategy = best-effect-fixed-style の場合は、事実、ソース、ブランド／知的財産、またはコンプライアンス上の問題によって納品物が実質的に変わる場合を除き、Guizang 風のマガジン Web デッキの固定スタイルで進めてください。それ以外の場合は、expectationFit.readyForProduction が false になるのであれば、ガイド付きのヒアリングを行ってください。ソース、対象読者、出力経路が十分であれば、前提を記録して、返答を待たずに進めてください。

1. キャンバス形式
2. ページ数の範囲
3. 対象読者
4. スタイルの目標
5. 配色
6. アイコンの使用方針
7. タイポグラフィの計画
8. 画像の使用方針

期待事項の契約も記録してください。

• bestEffectBrief：v5.3 で自動拡張された最高効果ブリーフ、プロンプトの品質、推奨ルート、Extreme Thin Prompt Fallback の状態、固定スタイル、前提条件
• briefMode：visual-tags、codex-guided-intake、source-first、draft-with-assumptions、best-effect-expanded、または best-effect-fixed-style
• visualBrief：選択したタグ、貼り付けられた背景情報、特別な要件、参考リンク
• guidedBrief：シナリオ、対象読者、目的、主なメッセージ、ソース、ページ数、スタイル、アセットのルール、出力形式、必須事項、避けるべき事項
• expectationFit：リスクレベル、不足しているシグナル、前提条件、競合、ソースの十分性、成功基準、本番制作の準備ができているかどうか

ブリーフでは、ユーザーにわかりやすい言葉を使ってください。役立つ場合を除き、専門的なラベルを表に出さないでください。チャットでは raster_policy、page_recipe_id、layout_family に頼らず、「編集可能な本文」「ページの役割」「メインビジュアル」「画像とテキストの二段組み」「グラフページ」「リスクページ」と表現してください。技術的なフィールド名は design_spec.md と spec_lock.md 内に記載してください。

ページ数が多い場合やソースの量が多い場合は、Step 5 の後に新しいチャットを開いて 继续生成 projects/<project_name> と入力し、workflows/resume-execute.md を使うよう勧める短い分割モードの注記を、ユーザーの言語で1つ追加してください。通常の規模では、連続モードがデフォルトです。

spec_lock.md を最終化する前に、コンテキスト予算を適用してください。

python3 ${SKILL_DIR}/scripts/spec_lock_slice.py --check-budget <project_path>
python3 ${SKILL_DIR}/scripts/execution_budget.py --page-count <N>

spec_lock.md line budget：spec_lock.md は120行以下にしてください。これを超える必要がある場合、Executor はページごとにロック全体を読み直すのではなく、python3 ${SKILL_DIR}/scripts/spec_lock_slice.py <project_path> PNN を実行します。16ページを超えるデッキでは、Step 5 の後に workflows/resume-execute.md を使ってください。execution_budget.py の結果を正とします。

ユーザーが画像を提供した場合は、デザイン仕様を出力する前に分析スクリプトを実行してください（画像ファイルを直接読み込んだり開いたりしないでください。スクリプトの出力のみを使用してください）。

python3 ${SKILL_DIR}/scripts/analyze_images.py <project_path>/images

⚠️ 画像の取り扱いルール：AI は画像ファイル（.jpg、.png など）を直接読み込んだり、開いたり、表示したりしてはなりません。画像に関する情報はすべて、analyze_images.py スクリプトの出力、または Design Specification の Image Resource List から取得してください。

出力：

• <project_path>/design_spec.md — 人が読めるデザインの説明
• <project_path>/spec_lock.md — 機械可読な実行契約（design_spec.md の決定事項を抽出したもの。Executor は各ページの作成前に必ずこれを読み直します）。ひな形については templates/spec_lock_reference.md を参照してください。
• <project_path>/design-quality-report.md — 検証中に作成または更新します。ビジュアルの方向性との適合性、ページの役割の網羅状況、アセット、レイアウトの反復リスク、残っている阻害要因をまとめます。

✅ チェックポイント — フェーズの成果物が完成しました。次のステップに自動で進みます：

## ✅ Strategist Phase Complete
- [x] One delivery brief completed (or assumptions recorded)
- [x] Design Specification & Content Outline generated
- [x] Execution lock (spec_lock.md) generated
- [ ] **Next**: Auto-proceed to [Image_Generator / Executor] phase

---

ステップ 5：画像取得フェーズ（条件付き）

🚧 ゲート：ステップ 4 が完了し、デザイン仕様とコンテンツ概要が生成され、実際のブロッカーがあれば解決されていること。

実行条件：デザイン仕様の画像行のうち、少なくとも 1 行が Acquire Via: ai および／または Acquire Via: web を必要とする場合。すべての行が user または placeholder の場合は、ステップ 6 に進んでください。

まず、Asset Factory の親コントラクトを作成または統合します。

python3 ${SKILL_DIR}/scripts/build_asset_plan.py <project_path>

asset_plan.json が信頼できる情報源です。asset-plan.md は人間が読める形式のビューにすぎません。ビルダーは既存アイテムの status、current_generation_evidence、および完了済みのプロンプトファイルを ID ごとに保持する必要があります。再実行時に Generated のエビデンスを消去してはなりません。

まず共通フレームワークを必ず読み込みます。

Read references/image-base.md

その後、必要なパス固有のリファレンスのみを遅延読み込みします。

Acquire Via	読み込むリファレンス	実行
ai	references/image-generator.md	Codex のネイティブ GPT 画像生成（利用可能な場合は image2）をデフォルトで使用します。それ以外の場合は python3 ${SKILL_DIR}/scripts/image_gen.py --asset-plan <project_path>/asset_plan.json を実行します
web	references/image-searcher.md	python3 ${SKILL_DIR}/scripts/image_search.py ... を実行します
user / placeholder	スキップ	スキップ

生成アセットのエビデンススキーマ：

{"run_id":"...","timestamp":"...","backend":"...","prompt_sha256":"...","file_sha256":"...","width":1792,"height":1024}

Generated の asset_plan.json.items[] の各行には、このスキーマに一致する、空でない current_generation_evidence が必要です。ステップ 6 の前に python3 ${SKILL_DIR}/scripts/audit_image_contracts.py <project_path>/asset_plan.json を実行します。

✅ チェックポイント — すべての行で画像生成を試みたことを確認し、ステップ 6 に進む：

## ✅ Image_Generator Phase Complete
- [x] Prompt document created
- [x] Each image: status is either `Generated` (file present in images/) or `Needs-Manual` (reported to user with filename + reason)
- [x] No row remains `Pending`

生成に失敗しても停止しないでください。references/image-generator.md の失敗時の処理ルールに従います。1 回再試行し、可能であれば Codex／image2 と設定済みバックエンドを切り替えてフォールバックします。その後、該当行を Needs-Manual にして、ファイル名と理由を報告し、ステップ 6 に進みます。

🚧 Needs-Manual の画像行はステップ 6 をブロックします：asset_plan.json のアイテムが 1 つでも Needs-Manual の場合、想定されるファイルが project/images/<filename> に存在する必要があります。存在しない場合は、Executor が想定ファイル名を明記したプレースホルダーボックスを描画する必要があります。画像参照が欠落したまま、黙って SVG 生成を開始してはなりません。

---

Step 6: Executor Phase

🚧 GATE：Step 4（該当する場合は Step 5 も）完了済みであること。asset_plan.json に未解決の Pending 行がないこと。Needs-Manual 行がある場合は、実ファイルがあるか、ラベル付きプレースホルダーの計画が明示されていること。すべての前提となる成果物が準備できていること。

選択したスタイルに基づく役割定義を読みます：

Read references/executor-base.md          # REQUIRED: common guidelines
Read references/shared-standards.md       # REQUIRED: SVG/PPT technical constraints
Read references/executor-general.md       # General flexible style
Read references/executor-consultant.md    # Consulting style
Read references/executor-consultant-top.md # Top consulting style (MBB level)

executor-base と shared-standards、およびスタイルファイルを1つだけ読む必要があります。

デザインパラメーターの確認（必須）：最初の SVG を生成する前に、Executor はデザイン仕様の主要なデザインパラメーター（キャンバスの寸法、配色、フォント計画、本文のフォントサイズ）を確認し、出力して、仕様への準拠を確認する必要があります。詳細については executor-base.md のセクション 2 を参照してください。

ライブプレビューの自動起動（必須）：最初の SVG を生成する前に、ブラウザーエディターをライブモードで起動し、Executor の作業からエクスポートまで実行状態を維持します：

python3 ${SKILL_DIR}/scripts/svg_editor/server.py <project_path> --live

• Executor の開始と同時に起動します。svg_output/ は空でもかまいません。
• デフォルトの URL は http://localhost:5050 です。ポートが使用中の場合は --port <other> を使い、実際の URL を報告します。
• 長時間実行するサイドプロセスとして起動します。ページの生成前に終了するのを待たないでください。
• 生成中に送信された注釈を読み取ったり、適用したりしないでください。後からユーザーが注釈の適用を求めた場合は、エクスポート後に workflows/live-preview.md を使用します。

生成前の一括読み込み（必須）：最初の SVG を生成する前に、spec_lock.page_layouts で参照されているすべての異なるレイアウト SVG と、spec_lock.page_charts で参照されているすべての異なるチャート SVG（バックアップのチャート参照を含む）を一括で読み込みます。各ファイルは事前に1回だけ読み込みます。

ページごとの spec_lock 再読み込み（必須）：各 SVG ページを生成する前に、Executor は必ずロックを読み込みます。ロックが予算内の場合は read_file <project_path>/spec_lock.md を実行します。予算を超えている場合、または新しいチャットでデッキの作業を再開した場合は、python3 ${SKILL_DIR}/scripts/spec_lock_slice.py <project_path> PNN を実行し、そのスライスを使用します。そこに記載された色、フォント、アイコン、画像と、ページごとの page_rhythm、page_layouts、page_charts の参照のみを使用してください。詳細については executor-base.md §2.1 を参照してください。

生成時の規律は、Global Execution Discipline のルール 7～10 に従います。メインエージェントのみを使用し、ページを順番に生成し、ページごとにロックを読み込むかスライスを取得し、SVG は手書きで作成します。

ビジュアル構築フェーズ：

• SVG ページを1ページずつ、連続して順番に生成します → <project_path>/svg_output/

品質チェックゲート（必須） — すべての SVG を生成した後、スピーカーノートを作成する前に実施します：

python3 ${SKILL_DIR}/scripts/svg_quality_checker.py <project_path>

• error（禁止された SVG 機能、viewBox の不一致、spec_lock からの逸脱など）がある場合は、先に進む前に該当ページを修正する必要があります。ビジュアル構築に戻り、そのページを再生成して、チェックをやり直してください。
• warning の項目（低解像度画像、PPT で安全でないフォント末尾など）は、容易に対応できる場合は確認して修正してください。それ以外の場合は、内容を認識したうえでリリースしてもかまいません。
• svg_output/ に対してチェッカーを実行する必要があります。finalize_svg.py の実行後にのみ実行するのでは遅すぎます（finalize によって SVG が書き換えられ、一部の違反が隠れる可能性があります）。
• チェックに合格すると、チェッカーは SVG のダイジェストを含む pipeline-state.json を書き込みます。最後にチェックに合格してから SVG ファイルが変更されている場合、svg_to_pptx.py はエクスポートをブロックします。

ロジック構築フェーズ：

• スピーカーノートを生成します → <project_path>/notes/total.md

✅ チェックポイント — すべての SVG とノートが完全に生成され、品質チェック済みであることを確認してください。そのまま Step 7 の後処理に進みます：

## ✅ Executor Phase Complete
- [x] All SVGs generated to svg_output/
- [x] svg_quality_checker.py passed (0 errors)
- [x] Speaker notes generated at notes/total.md

チャートページはありますか？ このデッキにデータチャートが含まれている場合は、Step 7 の前に workflows/verify-charts.md を実行して座標を調整します。チャートページがないデッキでは省略してください。

---

Step 7: 後処理とエクスポート

🚧 GATE：Step 6 が完了し、すべての SVG が svg_output/ に生成され、スピーカーノート notes/total.md が生成されていること。また、pipeline-state.json に、現在の svg_output ダイジェストに対する SVG 品質チェックの合格が記録されていること。

🚧 画像準備完了 GATE：Step 5 で Needs-Manual の画像行が残っている場合、Step 7.1 の実行前に、対象となるすべてのファイルが project/images/<filename> に存在している必要があります。ファイルが見つからない場合は処理を一時停止し、ファイル名と必要な保存先を報告してください。

⚠️ 以下の 3 つのサブステップは、必ず1つずつ個別に実行してください。次のコマンドを実行する前に、各コマンドの完了と成功を確認してください。 ❌ 3つのコマンドを1つのコードブロックまたは1回のシェル呼び出しにまとめることは絶対に避けてください。

正規の3コマンドパイプラインを実行します（references/shared-standards.md §5 と同じです）。

Step 7.1 — スピーカーノートを分割します：

python3 ${SKILL_DIR}/scripts/total_md_split.py <project_path>

Step 7.2 — SVG の後処理（アイコンの埋め込み／画像のトリミングと埋め込み／テキストのパス化／角丸長方形のパス化）：

python3 ${SKILL_DIR}/scripts/finalize_svg.py <project_path>

Step 7.3 — PPTX をエクスポートします（デフォルトでスピーカーノートを埋め込みます）：

python3 ${SKILL_DIR}/scripts/svg_to_pptx.py <project_path>
# Output: exports/<project_name>_<timestamp>.pptx
#
# Optional SVG snapshot preview:
# python3 ${SKILL_DIR}/scripts/svg_to_pptx.py <project_path> --svg-snapshot
#
# Optional conversion diagnostics:
# python3 ${SKILL_DIR}/scripts/svg_to_pptx.py <project_path> --trace-conversion

Step 7.4 — 視覚的な完成度を監査します：

python3 ${SKILL_DIR}/scripts/visual_review.py <project_path>
python3 ${SKILL_DIR}/scripts/audit_design_completion.py <project_path>

• ブラウザーのレンダリング依存関係を利用できない場合、visual_review.py は失敗することがあります。その場合は、視覚的な QA を黙って省略せず、design-quality-report.md に阻害要因を記録してください。
• ユーザーが記載された視覚的な阻害要因を明示的に受け入れる場合を除き、正式に納品する前に audit_design_completion.py を合格させる必要があります。

❌ finalize_svg.py の代わりに cp を使うことは絶対に避けてください。finalize_svg.py は複数の重要な処理を実行します。 ❌ --only などの追加フラグを付けることは絶対に避けてください。

任意のアニメーションフラグ：デフォルトですでに豊かな開始アニメーションが有効になっています。ユーザーから依頼があった場合にのみ調整してください。

• -t <effect> ページ遷移。デフォルトは fade
• -a <effect> 要素ごとの開始アニメーション。デフォルトは mixed
• --animation-trigger {on-click,with-previous,after-previous}
• --animation-config <path> オプションのオブジェクトレベルのサイドカー。通常は workflows/customize-animations.md を使って作成します。
• --auto-advance <seconds> キオスク形式の自動再生

任意の録音ナレーション：ナレーション／音声／動画のエクスポートをユーザーから依頼された場合にのみ、workflows/generate-audio.md を実行してください。このワークフローを使わずに notes_to_audio.py を直接呼び出さないでください。バックエンド／音声／速度／埋め込みの選択を一度確認する必要があるためです。

エクスポート後の注釈期間：ライブプレビューサービスがまだ実行中で、ユーザーが注釈を送信している場合は、エクスポート後にのみ workflows/live-preview.md を使って適用してください。

---

役割切り替えプロトコル

役割を切り替える前に、必ず最初に対応するリファレンスファイルを読んでください。読み飛ばしは禁止です。出力マーカー：

## [Role Switch: <Role Name>]
📖 Reading role definition: references/<filename>.md
📋 Current task: <brief description>

---

リファレンスリソース

リソース	パス
共通の技術的制約	references/shared-standards.md
キャンバス形式の仕様	references/canvas-formats.md
画像レイアウトの仕様	references/image-layout-spec.md
SVG 画像の埋め込み	references/svg-image-embedding.md
アイコンライブラリ	templates/icons/README.md

---

メモ

• ローカルプレビュー：python3 -m http.server -d <project_path>/svg_final 8000
• トラブルシューティング：生成中に問題（レイアウトのはみ出し、エクスポートエラー、画像の空白など）が発生した場合は、docs/faq.md の確認をおすすめしてください。実際のユーザー報告に基づく既知の解決策が掲載され、継続的に更新されています。