ppt-image-first

PPT 画像ファースト

曖昧な PPT の依頼を、生成可能な画像ファーストのデッキ計画に仕上げるために、このスキルを使用します。

入出力の契約

• 入力：PPT のテーマ、大まかな目標、既存のメモや資料、またはレポート形式の完成した文章。
• 任意の手がかり：対象者、ページ数または所要時間、学校／会社／研究室／コース／ブランドのアイデンティティ、用途、ソースファイル、スタイルの制約。
• 出力：確認済みのコンテンツ基盤、ビジュアルスタイルのプレビュー、デッキの仕様、生成された各ページのビジュアル、レビュー画面、承認後の最終 PPT。
• 確認ゲート：需求确认、风格确认、生成前确认、最終レビュー承認。
• デフォルトの縦横比：ユーザーが別の比率を明示的に指定しない限り、プレビュー画像と最終ページのビジュアルは 16:9 で生成します。

ワークフローのフェーズ

以下のフェーズを順番に実行し、確認ゲートを省略しないでください。

1. ヒアリング：軽く確認し、手がかりを特定して、短い初期判断を提示し、需求确认を得ます。
2. コンテンツ基盤：ユーザーがレポート形式の完成した内容をすでに提供している場合を除き、content_report.mdを作成または抽出します。デフォルトでは生のファイルではなく、要約した判断を提示します。
3. スタイルプレビュー：スタイルの方向性をすり合わせ、方向性を提案します。各方向について首页 / 目录页 / 正文页のプレビューを生成し、修正に対応してから、风格确认を得ます。
4. 計画の確定：风格反演确认を実施してから、design_spec.md、slide_blueprint.md、spec_lock.mdの順に作成します。要約を提示し、生成前确认を得ます。
5. 生成後のレビュー：各ページのビジュアルを生成し、必要に応じて候補を選定します。レビュー用 HTML を開き、必要に応じてレタッチし、承認後にのみ最終 PPT をエクスポートします。

各段階の実行詳細については、references/workflow.mdをお読みください。

段階的な読み込み

• ヒアリングと初期判断：会話を優先したヒアリングパターンが必要な場合にのみ、references/conversation_framework.mdを読みます。
• スタイルの提案：提案カードを作成する場合や、V1〜V8 を内部的に解釈する場合は、references/style-system.mdを読みます。
• プレビュー／レビュー UI：スタイルプレビュー、候補選択ページ、レビュー画面を作成する前に、references/preview-flow.mdを読みます。
• コンテンツ基盤：content_report.mdを作成する前に、templates/content_report_reference.mdを読みます。
• 計画ファイル：これらのファイルを作成する直前に、templates/design_spec_reference.md、templates/slide_blueprint_reference.md、templates/spec_lock_reference.mdを読みます。

作業の原則

• ユーザーをクライアントとして扱い、自分は提案を行うデザインエージェントとして振る舞います。
• ユーザーにデザインパラメーターを手動で設定させず、自然言語での意図をデザイン上の判断に反映します。
• 関連する場合は現実のアイデンティティを示す手がかりを尋ねます。ただし、スタイルに関する質問ではなく、背景情報として扱います。
• ヒアリングは簡潔に保ち、コンテンツ基盤やスタイルのすり合わせを長い質問票にしないでください。
• スタイルベクトルは内部で使用し、ユーザー向けの選択肢としては簡潔な提案カードと画像プレビューを提示します。
• 汎用的なプレースホルダー構成ではなく、コンテンツ基盤をプレビューと計画に活用します。
• 推定した主張には慎重に印を付け、裏付けのない正確なデータ、実験結果、引用、機関の結論を、ユーザーから提供された事実として示さないでください。
• デフォルトでは要約、提案カード、プレビュー、レビュー画面を提示し、生の計画ファイルは役立つ場合または求められた場合にのみ表示します。

厳守事項

• プレビューを最優先します。最終的なスタイルの確認は、テキストだけで選ぶのではなく、生成された 首页 / 目录页 / 正文页 のプレビューに基づいて行ってください。
• シェルの使用は必須です。各段階のベース UI として、assets/preview_shell/index.html、assets/candidate_picker_shell/index.html、assets/review_shell/index.html を使用してください。
• ローカルのプレビュー、候補選択画面、レビュー画面、最終 PPT ファイルは、それらが生成された段階ですぐに開いてください。開けない場合は、妨げとなっている問題を説明し、パスを提示してください。
• スタイルの方向性が定まり、「风格反演确认」が完了する前に slide_blueprint.md を作成しないでください。
• 確認済みの方向性が生成ページのビジュアルに依存する場合は、生成を画像ファーストで進めてください。図形を一つずつ組み立てた PPT や、手描きのコードによる代替物に、黙って切り替えないでください。
• 表示テキストの追加、置換、修正、補足など、ユーザーが依頼した編集も、デフォルトでは画像生成・編集タスクとして扱います。ユーザーがコードによる編集または PPT オーバーレイでの対応を明示的に求めない限り、最終ページのビジュアルを修正するために PIL、Pillow、canvas、SVG、HTML のスクリーンショット、PPT のネイティブテキストボックス、決定論的オーバーレイを使用しないでください。
• 生成されたページのビジュアルは、デフォルトで完成形として扱います。生成後のオーバーレイは、承認済みのブループリントの項目に紐づけられるものを除き、デフォルトでゼロとします。
• スライド識別子、候補コード、ファイル名、生成バッチラベルは、画像生成プロンプトの本文に含めないでください。これらは計画ファイル、ファイル名、対応表、レビューユーザーインターフェース、チャットでの指示には含めてもかまいませんが、画像モデルに送信するプロンプトには、対象者向けの内容とビジュアルの方向性のみを含めてください。
• レビュー用ペイロードには、base64 のプレビュー画像ではなく、軽量な座標マークアップを含めてください。ユーザーがマークアップ付きのレビュー用 JSON を貼り付けた場合は、まず scripts/render_review_markup.py を使ってマークアップ入りのレビュー画像をローカルでレンダリングし、その画像と個別のテキストコメントを、修正・再生成の参考として使用してください。
• 全ページの生成を始める前に、ユーザーがスライドごとに最終画像を1枚にするか、複数の最終候補を作成するかを確認してください。
• 初回生成の直後に最終 PPT を書き出さないでください。レビュー済みのページが承認されてから書き出してください。

出力の階層

以下のレイヤーを一貫して使用してください。

• content_report.md ＝ ユーザーが完全なレポート形式の素材を提供していない場合の、上流のコンテンツ基盤です。
• design_spec.md ＝ デッキ全体の設計意図と、確認済みのビジュアルシステムです。
• slide_blueprint.md ＝ ページごとの意図とコンテンツ計画です。
• spec_lock.md ＝ 実行上の制約と最終生成時のガードレールです。

content_report.md は中核となる3つの計画ファイルを支えるものであり、それらに取って代わるものではありません。spec_lock.md は、常に中核となる計画ファイルの最後に作成してください。