PPT as Code

クリエイター中心の段階的ワークフローでHTMLベースのプレゼンテーションを計画および構築します。

コアパイプライン: 取り込み -> 必要に応じてソース素材を正規化 -> 必要に応じてソースシーンを導出 -> 入力モードを検出 -> DSLの場合: deck.mdを解析 -> deck_source.jsonをコンパイル -> モードにルーティング -> 参照を読み込む -> ギャップを診断 -> 成果物を生成 -> キーディシジョンを確認 -> 可視化を計画 -> 画像を計画 -> HTML前QAを実行 -> HTMLを配信 -> オプションのワークベンチ同期 -> オプションのPPTXエクスポート

---

必須ルール

[!CAUTION]

直列実行とゲートディシプリン

このワークフローは厳密な直列パイプラインです。

1. 直列実行: ステップは順序通りに実行する必要があります。各ステップの出力は次のステップの入力になります。
2. ブロッキング = 完全停止: BLOCKINGステップは続行する前に明示的なユーザー確認が必要です。
3. 推測実行なし: 現在のゲートがクリアされるまで、将来の成果物を事前に構築しないでください。
4. ルートのバランスを保つ: ユーザーのリクエストが明確に必要とするのでない限り、軽量なデッキをより重いスタックにエスカレートしないでください。
5. 配信をデフォルトにする: 理論的エッセイではなく、使用可能な成果物、プロンプト、またはHTML引き渡しルートを配信してください。
6. 最終成果物は動作する必要がある: ユーザーが直接引き渡しを望む場合、CDNのみのプロトタイプよりも自己完結型ファイルまたはローカルで実行可能なフォルダを優先します。

[!IMPORTANT]

basicとadvancedの厳密な実行セマンティクス

• basicとadvancedを曖昧なチェックリストではなく、厳密な有限状態ワークフローとして扱います。
• 一度に1段階ずつ進めます。複数のブロッキングステップを1ジャンプで無言でバンドルしないでください。
• 沈黙、暗黙の緊迫感、または「続行」などの一般的なリクエストは、必須の確認をバイパスする許可にはなりません。
• ユーザーが明示的にオーバーライドを明確な指示で名付けた場合のみ、ブロッキングステップをバイパスします。例えば:
  • skip breakdown confirmation
  • do not ask for step-by-step confirmation
  • run the rest end-to-end without checkpoints
• ユーザーが部分的なオーバーライドを与える場合、名付けられたチェックポイントのみをスキップし、ワークフローの残りは厳密に保ちます。
• ユーザーが明示的にオプトアウトしない場合、デフォルトの厳密なステップバイステップモードを保ちます。

[!IMPORTANT]

クリエイター中心配信

• デフォルト配信は長いコードダンプではなく、段階的成果物 + HTMLルートまたはプロンプトパック + 画像計画です。
• ユーザーがクリエイターであるか、素早く移動したい場合、デフォルトでは大きなコードブロックよりも段階的なプロンプトと中間成果物を優先します。
• ユーザーが明示的にコードを要求した場合またはワークフローが最終HTML段階に達した場合のみ、完全な実装を使用します。

[!IMPORTANT]

PPTXエクスポート引き渡し

• ppt-as-codeはHTMLファーストのプレゼンテーションスキルのままです。
• PPTXエクスポートはHTMLワークフローの代替ではなく、オプションの最終配信後処理です。
• デフォルトエクスポートターゲットはhtmlです。ユーザーが明示的にPowerPoint配信を望む場合、pptxまたはbothを許可します。
• ターゲットにPPTXが含まれる場合、まず静的HTMLパスを完了し、次にdeck_manifest.jsonを生成し、次にpptx-export-for-ppt-as-codeに引き渡します。
• deck_manifest.jsonはエクスポートブリッジであり、PPTX配信の単一の情報源です。プライマリルートとしてアドホックなDOM スクレイピングに依存しないでください。
• PPTXエクスポートはスタティックのみです。モーションは静的状態にダウングレードされ、シンプルなページは編集可能な状態を保つべき、複雑なページは全スライドのラスタ画像へのフォールバックが発生する場合があります。

[!IMPORTANT]

Slidev風DSL入力

• ppt-as-codeはオプションのdeck.mdドラフトをSlidev風オーサリング入力として受け入れることができます。
• これはドラフト入力レイヤーであり、実際のSlidevプロジェクトまたは構文との互換性の約束ではありません。
• deck.mdが存在する場合、通常のquick、basic、またはadvancedワークフローに入る前に、それをdeck_source.jsonに解析します。
• deck.mdはアイデア出しを加速できますが、basicまたはadvancedの確認ゲートをバイパスしてはいけません。
• deck_source.jsonはDSL入力の正規化された内部表現です。最終配信成果物ではありません。

[!IMPORTANT]

ソース正規化ルール

• ユーザーがスライドアウトラインではなく外部ソース素材から開始する場合、デッキの分解またはスクリプト作業前にその素材を正規化します。
• これらのアダプターが環境で利用可能な場合、それらを比例して使用します:
  • PDF -> pdf_to_md.py
  • DOCX / EPUB / HTML / LaTeX -> doc_to_md.py
  • 通常のウェブページ -> web_to_md.py
  • WeChat などの高摩擦ページまたはボット対策ページ -> web_to_md.cjs
• 正規化されたマークダウンはデッキ計画の作業ソースになります。最終デッキではありません。
• アダプターが利用できない場合、ワークフローをブロックしないでください。ソースを手動で要約し、フォールバックについて明示的な注記で続行してください。

[!IMPORTANT]

ソースからシーンへのルール

• 開始素材が長い記事、PDF、ドキュメント、または正規化されたウェブソースである場合、確認された分解を書く前に予備的なシーンマップを導出します。
• ソースからシーンへのパスは、素材を最終スライドではなく、可能性のあるスライドグループにクラスタ化する必要があります。
• それを使用して、可能性のあるページシーケンス、候補シーンロール、強い引用、強い統計、画像に値するセクションを識別します。
• source_scene_map.mdを確認された分解の代替ではなく、計画アクセラレータとして扱います。

[!IMPORTANT]

永続化戦略

• デフォルトは会話ファースト成果物です。
• ユーザーが明示的にデッキ素材の永続化を望むか、リポジトリが明らかにファイルベースの出力を招待する互換性のあるプロジェクト構造を既に持つ場合のみ、ファイルを書き込みます。
• 永続化が有効な場合、deck_brief.md、theme_breakdown.md、style_options.md、deck_script.md、style_system.json、image_plan.md、index.html、assets/などの慣例的な成果物名を使用します。

[!IMPORTANT]

PPTファースト文法

• PPTのようなはステージのような意味です。一度に1つのアクティブなスライド、明確なページ状態、および目に見えるプレゼンテーション装置。
• ユーザーが明示的にプレゼンテーションを要求したときに、デッキが長いウェブページ、編集記事、またはダッシュボードシェルにドリフトしないようにしてください。
• 完成したデッキは、関連する場合、カバー、フック、コンセプト、比較、引用、データ、ディバイダー、結論などの明確なスライドロールを保持する必要があります。

[!IMPORTANT]

コピーの関連性とテキスト密度ルール

• スライド上のすべての目に見える文は、ページの論文を支援する必要があります。ラインがポイントを強化しない場合は、それをカットしてください。
• ジェネリックなシーン設定、曖昧なインスピレーション行、空の遷移コピー、または「PPTのような」メタ言語などの装飾的なフィラーを追加しないでください。
• Overview、Background、Key Takeaway、Page 01、Closing Thoughts、または類似の足場などの一般的なラベルを避けます。ただし、オーディエンスにとって実際の構造的意味を持つ場合は除きます。
• 密集した説明コピーよりも、1つの強力なステートメント。プラス少量のサポートテキストを優先します。
• 混雑したスライドを縮小してテキストサイズを解決しないでください。ページがテキストが多すぎる必要がある場合は、コンテンツをより多くのスライドに分割するか、弱いコピーを削除してください。
• 小さいキャプション、小さい脚注、小さい印刷注釈を避けます。ただし、ソース、数値、またはコンプライアンスに必要な場合は除きます。
• スライドが画像主導またはチャート主導である場合、ビジュアルに仕事をさせてください。スペースを埋めるだけのために追加のテキストを追加しないでください。
• 短く、高いシグナルのヘッドラインを使用します。スライドタイトルはトピックラベルではなく、ポイントを伝える必要があります。

[!IMPORTANT]

スタイルロックルール

• quickとbasicでも、実際のビジュアル方向が必要です。裸のテクニカルスケルトンを返さないでください。
• スタイルが決まっていない場合、最終HTML作業を開始する前に3〜4つのデザイン方向をお勧めします。
• 選択されたモードが参照選択を必要とし、閲覧が利用可能な場合、最終的なビジュアル方向をロックしないでください。
• 参照が選択されたか、ワークフローが明示的にスタイルワード合成へのフォールバックを行った場合、最終実装前に構造化されたデザイン制約に方向を翻訳します。

[!IMPORTANT]

可視化計画ルール

• チャート、図、インフォグラフィック、およびKPIカードはデッキ構造の一部であり、後期実装ガーニッシュではありません。
• スクリプトが確認されたら、ページごとにそのページがテキスト主導、画像主導、チャート主導、図主導、またはカード主導であるかを決定します。
• 最終HTML作業が始まる前に、これらの決定をvisual_plan.mdに記録してください。
• 可視化の選択は新規性ではなく、ページの論文に従う必要があります。チャートや図がページを明確にしない場合、無理に追加しないでください。
• 可視化の配置も早期に決定する必要があります: full-width、left、right、top-band、bottom-band、center-focus、またはsplit-2col。
• quickは意図的に完全な可視化レイヤーから除外されています。スキルが明示的にbasicまたはadvancedにアップグレードされない限り、quickにチャート主導、図主導、またはカード主導のページを追加しないでください。

[!IMPORTANT]

可視化スタイル継承

• すべてのチャートと図は、デッキのデザイン制約を継承する必要があります。
• 別のビジュアルシステムを導入するのではなく、デッキのタイポグラフィ、色ロジック、スペースのリズム、および強調言語を使用してください。
• チャートコンテナ、ラベル、グリッドライン、フィル、アウトライン、およびカードは、埋め込まれたサードパーティのウィジェットではなく、デッキネイティブに感じる必要があります。
• ビジュアルトークンが必要な場合、アドホックな方法で発明するのではなく、アクティブなデザイン制約から導出します。

[!IMPORTANT]

画像ワークフロールール

• 画像の数より画像の品質が重要です。弱い画像は画像がないより悪いです。
• デッキトピック全体からのみボディ画像を検索しないでください。
• 画像が必要な各ページについて、まずページを1つの論文に圧縮し、次にページレベルのキーワードを導出し、次に検索します。
• 画像ダウンロードが失敗した場合、ソースリンクを保持し、失敗を記録し、実行をブロックするのではなく、ユーザーに手動ダウンロード用のリンクを渡します。

[!IMPORTANT]

HTML前品質チェック

• 静的HTMLを生成する前に、承認された成果物に対して軽いQAパスを実行します。
• QAパスは、ページシーケンスの一貫性、タイトル階層の一貫性、画像を含むスライドながら使用可能な資産またはフォールバックリンクが不足しているもの、および各スライドが明確なページの論文を持っているかどうかをチェックする必要があります。
• QAパスが隙間を発見した場合、HTMLが準備完了として扱われる前に、それらを解決または表示してください。

[!IMPORTANT]

ネットワークおよびツールフォールバック

• 閲覧またはダウンロードが利用できない場合、ワークフローをブロックしないでください。
• advancedでは、ウェブ参照検索が利用できない場合、ウェブ参照ブランチをスキップし、選択されたスタイル方向およびユーザーが提供したインスピレーションから直接構造化されたデザイン制約を導出します。
• ファイル永続化が利用できないか不要な場合、リポジトリ書き込みを強制するのではなく、会話で同じ段階的成果物を保ちます。

[!IMPORTANT]

ランタイム情報源

• ランタイム動作はSKILL.mdおよび現在のモード/参照ファイルから来る必要があります。
• 安定したフィードバックはログに残されるべきではなく、メインドキュメントに統合する必要があります。

[!IMPORTANT]

ワークベンチアーキテクチャルール

• 将来のビジュアルワークベンチは計画成果物を独立して編集したり、ドリフトさせたりしてはいけません。
• キャンバスエディターが範囲内にある場合、統合されたワークベンチ編集ソースとしてdeck_model.jsonを使用してください。
• ワークベンチ編集は最初にdeck_model.jsonを更新し、次にアップストリーム成果物を同期し、次にHTMLをリフレッシュする必要があります。
• ワークベンチを汎用ウェブページエディターではなく、ppt-as-codeデッキの内部オーサリングレイヤーとして扱います。
• v1ワークベンチスコープは、このスキル自体の成果物契約に既に従うデッキに限定されています。

[!IMPORTANT]

ワークベンチ同期ルール

• theme_breakdown.md、deck_script.md、style_system.json、visual_plan.md、image_plan.md、およびdeck_manifest.jsonは相互に直接同期すべきではありません。
• deck_model.jsonはビジュアルキャンバスと成果物層の間のブリッジです。
• 自由なキャンバス操作を成果物システムに安全に投影できない場合、ビジュアル自由より同期安全性を優先します。
• これらのケースでは、以下の結果の1つを要求してください:
  • アクションを制限する
  • 結果をneeds_reviewとしてマークする
  • 結果をhtml_only_overrideとしてマークする
• 複数の競合する真実の情報源を無言で作成しないでください。

[!IMPORTANT]

変更ルーティングルール

• ユーザーが既存のデッキの変更を要求する場合、何かを編集する前にリクエストを分類します。
• プライマリなアップストリーム成果物に変更をルーティングします:
  • 構造変更 -> theme_breakdown.md
  • コピー変更 -> deck_script.md
  • 可視化変更 -> visual_plan.md
  • 画像変更 -> image_plan.md
  • スタイル変更 -> style_system.json
  • エクスポート動作変更 -> deck_manifest.json
• フォントサイズ、色システム、スペース、半径、プログレスバースタイル、またはチャートラベルサイズなどのグローバルスタイル変更はstyle_system.jsonに属します。
• スライド固有のスタイル例外もstyle_system.jsonに属し、HTMLを最初に編集するのではなくslide_overridesブロックを使用します。
• deck_manifest.jsonをコンテンツ編集ソースとして扱わないでください。これは配信層成果物です。
• ワークベンチモードでは、ドラッグアンドリサイズ編集は最初にdeck_model.jsonに書き込み、次に正しい成果物ターゲットに同期する必要があります。
• 次の場合を除き、index.htmlを最初に編集しないでください:
  • ユーザーが明示的にHTMLのみのホットフィックスを要求する
  • 問題が実装固有である
  • 利用可能なアップストリーム成果物が存在しない
• プライマリ成果物を更新した後、影響を受けた下流成果物のみを再生成し、次にHTMLをリフレッシュしてください。

ロールディスパッチプロトコル

このスキルは単一のインラインエージェントとして動作します。ロール切り替えは必要ありません。

---

リソースマニフェスト

UI メタデータ

ファイル	パス	目的
スキルインターフェースメタデータ	${SKILL_DIR}/agents/openai.yaml	表示名、簡単な説明、デフォルトプロンプト

参照

リソース	パス	ランタイムの使用
クイックモードワークフロー	${SKILL_DIR}/references/quick-mode.md	mode = quickの場合のみ必須
ベーシックモードワークフロー	${SKILL_DIR}/references/basic-mode.md	mode = basicの場合のみ必須
アドバンスドモードワークフロー	${SKILL_DIR}/references/advanced-mode.md	mode = advancedの場合のみ必須
ビジュアルおよび画像ワークフロー	${SKILL_DIR}/references/visual-and-images.md	スタイル、参照、または画像が範囲内の場合は必須
可視化レイヤーガイド	${SKILL_DIR}/references/visualization-layer.md	チャート、図、インフォグラフィック、またはKPIカードが範囲内の場合は必須
可視化エンジンガイド	${SKILL_DIR}/references/visualization-engines.md	チャートまたは図エンジンを選択する場合は必須
参照検索パック	${SKILL_DIR}/references/reference-search-pack.md	参照ロックまたは画像/ソース検出に閲覧が使用される場合は必須
コンポーネントライブラリガイダンス	${SKILL_DIR}/references/component-libraries.md	ルートがライブラリが必要な場合のみ必須
PPTXエクスポート引き渡し	${SKILL_DIR}/references/pptx-export-handoff.md	エクスポートターゲット = pptxまたはbothの場合のみ必須
ソース正規化ガイド	${SKILL_DIR}/references/source-normalization.md	入力がPDF、DOCX、EPUB、HTML、LaTeX、またはウェブページから開始される場合のみ必須
ソースからシーンへのガイド	${SKILL_DIR}/references/source-to-scenes.md	長いソース素材が分解前のシーンマッピングを必要とする場合のみ必須
品質チェッカーガイド	${SKILL_DIR}/references/quality-checker.md	自明でない実行で静的HTML生成前に必須
デッキDSL参照	${SKILL_DIR}/references/deck-dsl.md	入力モード = dslの場合のみ必須
デッキソース契約	${SKILL_DIR}/references/deck-source-contract.md	入力モード = dslの場合のみ必須
変更ルーティングガイド	${SKILL_DIR}/references/change-routing.md	既存のデッキの改良または変更時に必須
スタイルシステム契約	${SKILL_DIR}/references/style-system-contract.md	スタイルをロック、編集、または再生成する必要がある場合は必須
デッキモデル契約	${SKILL_DIR}/references/deck-model-contract.md	ワークベンチまたはキャンバスエディターが範囲内の場合は必須
ワークベンチアーキテクチャ	${SKILL_DIR}/references/workbench-architecture.md	ビジュアルワークベンチを評価または構築する場合は必須
ワークベンチ同期ガイド	${SKILL_DIR}/references/workbench-sync.md	ワークベンチ編集が成果物に流れ込む必要がある場合は必須

ワークフロー

ワークフロー	パス	目的
mode-delivery	${SKILL_DIR}/workflows/mode-delivery.md	モードルーティングおよび出力形成

---

ワークフロー

ステップ 1: 入力取り込み

ゲート: リクエストはウェブベースのプレゼンテーション、HTMLデッキ、スライドシステム、reveal.jsデッキ、プレゼンテーションページ、または密接に関連するデッキ構築ワークフローについてです。

実行:

1. リクエストの形状を抽出します:
   • トピック
   • オーディエンス
   • 配信コンテキスト: ライブプレゼンテーション、共有リンク、非同期読み取り、またはスクリーン録画
   • ソース素材形式: ノート、記事、PDF、DOCX、EPUB、HTML、LaTeX、通常のウェブページ、高摩擦ウェブページ、またはdeck.md
   • 入力モード: structured、dsl、または未指定
   • エクスポートターゲット: html、pptx、both、または未指定
   • 現在のスタック: ネイティブHTML、React、Next.js、reveal.js、または未指定
   • ユーザーが既に提供したもの: ノート、アウトライン、生素材、参照、画像、既存コード、またはdeck.md
2. 不足している入力を診断します:
   • テーマの分解
   • スタイルの方向
   • オーディエンスのポジショニング
   • デッキ構造
   • ビジュアル参照
   • 画像資産
3. リクエストが以下のいずれかについてであるかを識別します:
   • ゼロからの構築
   • 既存のデッキの改善
   • ルートの選択
   • スクリプト、スタイル、イメージまたはモーションの改善
   • ワークベンチ/キャンバスエディターの評価または定義
4. リクエストが変更の場合、プライマリ変更タイプを分類します:
   • structure_change
   • copy_change
   • visualization_change
   • image_change
   • style_change
   • export_change
   • implementation_hotfix
5. 成果物永続化戦略を決定します:
   • デフォルトは会話ファースト成果物
   • ユーザーがそれを要求するか、リポジトリがそれをサポートしている場合のみファイル永続化を有効にします
6. 永続化が有効な場合、リポジトリ慣例に適合する最も近い合理的なプロジェクトフォルダまたはデッキフォルダを選択します。
7. 自明でない実行のための標準的な成果物セットを定義します:
   • deck_brief.md
   • theme_breakdown.md
   • style_options.md
   • deck_script.md
   • style_system.json
   • visual_plan.md
   • image_plan.md
   • index.html
   • assets/
8. エクスポートターゲットにPPTXが含まれる場合、オプションのエクスポート成果物を追加します:
   • deck_manifest.json
   • output.pptx
9. 入力モードがdslの場合、オプションのドラフト成果物を追加します:
   • deck_source.json
10. リクエストが長いソース素材から開始される場合、オプションの計画成果物を追加します:
    • source_scene_map.md
11. 自明でないbasicまたはadvanced実行の場合、オプションのQA成果物を追加します:
    • qa_report.md
12. リクエストがワークベンチまたはビジュアルエディターについてである場合、オプションのエディター成果物を追加します:
    • deck_model.json
    • slide_overrides

チェックポイント:

## ステップ 1 完了
- [x] プレゼンテーションリクエストが識別されました
- [x] 不足している入力が診断されました
- [x] 関連する場合、変更タイプが分類されました
- [x] 永続化戦略が定義されました
- [ ] 次: ステップ 1A に自動進行

---

ステップ 1A: ソース正規化、ソースからシーンへ、入力モード検出、およびDSLコンパイル

ゲート: ステップ 1 完了。リクエストは入力層を識別するのに十分に明確です。

実行:

1. ソース正規化が必要かどうかを検出します:
   • PDF -> 利用可能な場合はpdf_to_md.pyを使用
   • DOCX / EPUB / HTML / LaTeX -> 利用可能な場合はdoc_to_md.pyを使用
   • 通常のウェブページ -> 利用可能な場合はweb_to_md.pyを使用
   • WeChat などの高摩擦ウェブページ -> 利用可能な場合はweb_to_md.cjsを使用
2. ソース正規化が必要な場合:
   • ${SKILL_DIR}/references/source-normalization.mdを読む
   • デッキ計画が始まる前に、素材をマークダウンに正規化します
   • 正規化されたマークダウンを後の分解、スクリプト、画像作業のためのデッキソース入力として使用します
   • アダプターが利用できない場合、手動で要約し、明示的なフォールバック注記で続行します
3. ソースが長形式でスライド型ではない場合:
   • ${SKILL_DIR}/references/source-to-scenes.mdを読む
   • ソースをスライドグループの可能性、シーンロール、引用、統計、および画像に値するセクションにクラスタ化するシーンマップを導出します
   • 成果物永続化が有効な場合、それをsource_scene_map.mdとして具体化します
4. 入力モードを検出します:
   • ユーザーがdeck.mdを提供するか、デッキドラフトファイルから開始することを明示的に要求する場合はdsl
   • それ以外の場合はstructured
5. 入力モードがdslの場合:
   • ${SKILL_DIR}/references/deck-dsl.mdを読む
   • ${SKILL_DIR}/references/deck-source-contract.mdを読む
   • deck.mdを実際のSlidev構文ではなく、Slidev風DSLとして解析します
   • 結果をdeck_source.jsonに正規化します
6. コンパイル中に必要なフォールバックを適用します:
   • 不足しているフロントマターフィールド -> デフォルトを入力
   • 不明なレイアウト -> bulletsにダウングレード
   • 不足しているタイトル -> 最初の意味のあるテキストから推測
   • 不足しているキーワード -> 後の画像計画用に空のままにします
   • サポートされていないSlidev のみの構文 -> テキストとして保持し、境界を明確にラベル付けします
7. deck.mdをドラフト入力のみとして保ちます。HTMLまたはエクスポートの最終的な情報源として扱わないでください。

チェックポイント:

## ステップ 1A 完了
- [x] ソース素材が正規化されるか、必要に応じてフォールバックが記録されました
- [x] 必要な場合、ソースシーンが導出されました
- [x] 入力モードが検出されました
- [x] 存在する場合、deck.md が解析されました
- [x] 必要な場合、deck_source.json が準備されました
- [ ] 次: ステップ 2 に自動進行

---

ステップ 2: モードルーティング

ゲート: ステップ 1A 完了。リクエストはモードを選択するのに十分に明確です。

実行:

1. ${SKILL_DIR}/workflows/mode-delivery.mdを読む。
2. quick、basic、またはadvancedの明示的なユーザー選択を尊重します。
3. ユーザーがモードを選択しなかった場合、推測します:
   • MVPデッキ、軽量プロトタイプ、および「まず実行させる」にはquickを選択します
   • 確認された分解、確認されたスクリプト、HTML前の画像処理が必要なクリエイター向けのデッキ計画にはbasicを選択します
   • 参照駆動型デッキデザイン、豊かなスタイル決定、または静的ファースト次動作追加ワークフローにはadvancedを選択します
4. リクエストを満たす最小ルートを保ちます。

チェックポイント:

## ステップ 2 完了
- [x] 実行モードが選択されました
- [x] ルーティング根拠が準備されました
- [ ] 次: ステップ 3 に自動進行

---

ステップ 3: 参照読み込み

ゲート: ステップ 2 完了。1つの実行モードが選択されました。

実行:

1. 正確に1つのプライマリモード参照を読み込みます:
   • quick -> ${SKILL_DIR}/references/quick-mode.md
   • basic -> ${SKILL_DIR}/references/basic-mode.md
   • advanced -> ${SKILL_DIR}/references/advanced-mode.md
2. スタイル、参照、または画像が関連する場合、${SKILL_DIR}/references/visual-and-images.mdを読み込みます。
3. チャート、図、インフォグラフィック、またはKPIカードが出現する可能性がある場合、${SKILL_DIR}/references/visualization-layer.mdと${SKILL_DIR}/references/visualization-engines.mdを読み込みます。
4. 参照ロックまたは画像/ソース検出に閲覧を使用する場合、${SKILL_DIR}/references/reference-search-pack.mdを読み込みます。
5. ルートが本当にコンポーネントまたはチャートライブラリが必要な場合のみ、${SKILL_DIR}/references/component-libraries.mdを読み込みます。
6. ソース入力がドキュメントまたはウェブ素材から正規化する必要がある場合のみ、${SKILL_DIR}/references/source-normalization.mdを読み込みます。
7. 長いソース素材が分解前のシーンマッピングを必要とする場合のみ、${SKILL_DIR}/references/source-to-scenes.mdを読み込みます。
8. 自明でない実行で静的HTML生成前に、${SKILL_DIR}/references/quality-checker.mdを読み込みます。
9. エクスポートターゲットがpptxまたはbothの場合のみ、${SKILL_DIR}/references/pptx-export-handoff.mdを読み込みます。
10. 入力モードがdslの場合のみ、${SKILL_DIR}/references/deck-dsl.mdと${SKILL_DIR}/references/deck-source-contract.mdを読み込みます。
11. リクエストが既存のデッキの変更についてである場合、${SKILL_DIR}/references/change-routing.mdを読み込みます。
12. スタイルをロック、変更、または再生成する必要がある場合、${SKILL_DIR}/references/style-system-contract.mdを読み込みます。
13. ビジュアルワークベンチまたはキャンバスエディターが範囲内にある場合、${SKILL_DIR}/references/deck-model-contract.md、${SKILL_DIR}/references/workbench-architecture.md、および${SKILL_DIR}/references/workbench-sync.mdを読み込みます。

チェックポイント:

## ステップ 3 完了
- [x] プライマリモード参照が読み込まれました
- [x] サポート参照が関連する場合のみ読み込まれました
- [ ] 次: ステップ 4 に自動進行

---

ステップ 4: 成果物セットアップとギャップ診断

ゲート: ステップ 3 完了。アクティブなモードワークフローが読み込まれました。

実行:

1. 選択されたモードの成果物セットを定義します。
2. basicとadvancedの場合、ブリーフ成果物を最初に準備します。
   • 永続化が有効な場合、それをdeck_brief.mdとして具体化します。
   • そうでない場合、会話でそれをインラインに保ちます。
3. どの成果物が今必要か後で必要かを決定します:
   • quick: ブリーフまたはアウトライン、スタイル方向、最小HTMLルート
   • basic: ブリーフ、分解、スタイルオプション、スクリプト、スタイルシステム、ビジュアル計画、画像計画、HTML
   • advanced: basicと同じ。プラス構造化されたデザイン制約およびオプションのモーション追加
   • 長いソース入力: 確認された分解前にsource_scene_map.mdを追加
   • dsl: 正規化されたドラフト入力成果物としてdeck_source.jsonを追加
   • 自明でない実行: HTML前QA成果物としてqa_report.mdを追加
   • pptxまたはboth: 静的HTMLの準備ができた後、マニフェストとPPTXハンドオフを追加
   • ワークベンチスコープ: 統一キャンバスソースとしてdeck_model.jsonを追加
4. リクエストが変更の場合、HTMLに触れる前にプライマリなアップストリーム成果物を定義します:
   • 構造 -> theme_breakdown.md
   • コピー -> deck_script.md
   • 可視化 -> visual_plan.md
   • イメージ -> image_plan.md
   • スタイル -> style_system.json
   • エクスポート -> deck_manifest.json
   • 実装のみのホットフィックス -> index.html
5. HTMLが始まることを許可される前に解決する必要がある不足しているギャップを記録します。

チェックポイント:

## ステップ 4 完了
- [x] 選択されたモードの成果物リストが定義されました
- [x] 関連する場合、プライマリなアップストリーム編集ターゲットが選択されました
- [x] 即時ギャップが記録されました
- [ ] 次: 選択されたモードワークフローに分岐

---

ステップ 5: クイックワークフロー

ゲート: 選択されたモードがquickです。

実行:

1. 軽量なデッキブリーフを作成します:
   • トピック
   • オーディエンス
   • コアメッセージ
   • 不足している入力
2. テーマがまだ曖昧な場合、実装前に軽量なアウトラインを作成します。
3. 正規化されたソース素材が存在する場合、迅速なアウトラインをロックする前に、コンパクトなソースからシーンへのパスを使用して、可能性のあるページグループに圧縮します。
4. スタイルが不足している場合、3〜4つのスタイル方向をお勧めし、デフォルトの推奨として1つを明確にマークします。
5. ユーザーが明示的に選択を望まない限り、推奨される方向で続行します。
6. 最終的なクイックHTMLルートの前に、軽量なHTML前QAパスを実行します。
7. 以下を作成します:
   • 最小限のスライド構造
   • 1つのカバー方向
   • 最小限のHTMLルートまたは短いプロンプトパック
8. ユーザーがquickで画像を要求した場合、visual-and-images.mdのページ-論文キーワードワークフローを使用しますが、画像計画を軽量に保ちます。
9. quickに可視化レイヤーを追加しないでください。デッキがチャート、図、インフォグラフィック、またはKPIカードが必要な場合は、basicまたはadvancedにアップグレードしてください。
10. ユーザーがpptxまたはbothを望む場合、スライドロールを明確に保ち、後のマニフェスト引き渡しをサポートします。
11. basicへの向上パスを含めます。

チェックポイント:

## ステップ 5 完了
- [x] 軽量な構造が準備されました
- [x] ビジュアル方向が準備されました
- [x] 最小HTMLルートまたはプロンプトパックが準備されました
- [ ] 次: ステップ 17 に自動進行

---

ステップ 6: ベーシックワークフロー A - 分解ファースト

ゲート: 選択されたモードがbasicです。

実行:

1. 現在の入力と不足しているギャップでブリーフ成果物を準備します。
2. スタイルオプション成果物で3〜4つのデザイン方向をお勧めします。
3. 常に矢印/プログレス/ページ装置の提案をスタイルパックの一部として含めます。次のようなオプションを使用します:
   • floating
   • transparent
   • large footprint
   • small footprint
4. 正規化された長形式ソースが存在する場合、確認された分解前にsource_scene_map.mdを導出します。
5. スライドスクリプトが存在する前に、テーマ分解成果物を準備します。
6. テーマ分解成果物は次を定義する必要があります:
   • デッキの論文
   • ページシーケンス
   • 各スライドが何を言おうとしているのか
   • どのページが画像が必要な可能性があるのか
7. 永続化が有効な場合、これらをdeck_brief.md、style_options.md、theme_breakdown.md、および関連する場合はsource_scene_map.mdとして具体化します。

ブロッキング: スクリプト生成が開始される前に、ユーザーにテーマ分解の確認を要求します。

チェックポイント:

## ステップ 6 完了
- [x] ブリーフ成果物が準備されました
- [x] スタイルオプションが準備されました
- [x] テーマ分解が準備されました
- [ ] 次: ブロッキング - 分解確認を待機

---

ステップ 7: ベーシックワークフロー B - スクリプトロック

ゲート: 選択されたモードがbasicで、ユーザーがテーマ分解を確認しました。

実行:

1. 選択されたスタイル方向をロックします。
2. ローカルのライティングスタイルノートが存在する場合、voice_profile.md、brand.md、writing_style.md、またはプロジェクトノートなどの可能性のあるスタイルドキュメントをスキャンします。
3. 最終HTML作業が始まる前に、選択されたスタイル方向をstyle_system.jsonまたは同等の構造化スタイルオブジェクトに翻訳します。
4. デッキスクリプト成果物を準備します。
5. デッキスクリプト成果物はスライドごとに次を定義する必要があります:
   • シーンまたはページの目的
   • ヘッドラインまたはコアコピー
   • サポートコピーまたはキュー テキスト
6. コピー関連性およびテキスト密度ルールを適用します:
   • ページの論文を直接サポートしないラインを削除します
   • 目に見えるコピーを十分にまばらに保ち、スライドが大型タイプであり続けることができます
   • ページが密集した小型テキストでのみ機能する場合、圧縮するのではなく、複数のスライドに分割します
7. 永続化が有効な場合、これらをstyle_system.jsonとdeck_script.mdとして具体化します。
8. まだキーワード抽出または画像検索を開始しないでください。

ブロッキング: 可視化と画像作業が開始される前に、ユーザーにスライドスクリプトの確認を要求します。

チェックポイント:

## ステップ 7 完了
- [x] スタイルがロックされました
- [x] 関連する場合、style_system.json が準備されました
- [x] ローカルボイスガイダンスが適用されました
- [x] デッキスクリプトが準備されました
- [ ] 次: ブロッキング - スクリプト確認を待機

---

ステップ 8: ベーシックワークフロー C - 可視化計画

ゲート: 選択されたモードがbasicで、ユーザーがスライドスクリプトを確認しました。

実行:

1. ${SKILL_DIR}/references/visualization-layer.mdを読む。
2. ${SKILL_DIR}/references/visualization-engines.mdを読む。
3. visual_plan.md成果物またはインラインの同等物を準備します。
4. 各スライドについて、以下のいずれかであるかを決定します:
   • text-led
   • image-led
   • chart-led
   • diagram-led
   • card-led
5. スライドが可視化される場合、記録します:
   • 選択されたエンジン
   • 配置
   • チャートまたは図のタイプ
   • コンテンツソース
   • デッキから継承されたスタイル制約
   • フォールバックモード
6. テキストまたはイメージの方がより効果的に機能するページに可視化を強制しないでください。
7. 永続化が有効な場合、それをvisual_plan.mdとして具体化します。

チェックポイント:

## ステップ 8 完了
- [x] 可視化の決定が準備されました
- [x] 関連する場合、visual_plan.md が準備されました
- [ ] 次: ステップ 9 に自動進行

---

ステップ 9: ベーシックワークフロー D - 画像計画

ゲート: 選択されたモードがbasicで、ユーザーがスライドスクリプトを確認しました。

実行:

1. 画像計画成果物を準備します。
2. イメージが必要な各スライドについて:
   • スライドを1つの論文に圧縮します
   • 正確に1〜2個のページレベルキーワードを導出します
   • 閲覧が利用可能な場合、選択されたスタイル方向とともにそれらのキーワードを使用して検索します
   • 閲覧が利用できない場合、検索が発生したふりをするのではなく、検索文字列と画像インテントを提供します
3. 永続化が有効で、ダウンロードが利用可能な場合のみ、選択された画像をassets/にダウンロードしようとします。
4. ダウンロードが失敗した場合、画像計画成果物に記録します:
   • スライド番号
   • キーワード
   • ソースURL
   • 失敗の理由
   • 注記: user needs to download manually
5. 永続化が有効な場合、計画をimage_plan.mdとして具体化します。
6. 失敗したダウンロードを隠さないでください。ユーザーにリンクを表示してください。

ブロッキング: HTMLの実装が開始される前に、ユーザーにスクリプト、可視化計画、画像計画の確認を要求します。

チェックポイント:

## ステップ 9 完了
- [x] 画像計画が準備されました
- [x] スライドレベルのキーワードが抽出されました
- [x] ダウンロード試行またはフォールバックリンクが記録されました
- [ ] 次: ブロッキング - スクリプト、可視化、画像確認を待機

---

ステップ 10: ベーシックワークフロー E - スタティックHTML

ゲート: 選択されたモードがbasicで、ユーザーがスクリプト、可視化計画、画像計画を確認しました。

実行:

1. ${SKILL_DIR}/references/quality-checker.mdを読む。
2. 承認された分解、スクリプト、ビジュアル計画、画像計画に対して軽いQAパスを実行します。
3. qa_report.mdまたはインラインQAノートで確認します:
   • ページシーケンスの一貫性
   • タイトル階層の一貫性
   • 可視化のタイプと配置フィット
   • 画像ギャップまたはフォールバックリンク
   • ページ論文カバレッジ
4. HTMLの生成前に、残りのギャップを解決または表示します。
5. スタティックHTML出力を生成します。
6. デッキをプレゼンテーションファーストに保ちます:
   • 一度に1つのアクティブなスライド
   • 明確なナビゲーション状態
   • 目に見えるプログレスまたはページ装置
7. スライドに合わせるためだけにフォントサイズを削減しないでください。テキストを削除するか、ページを分割します。
8. 永続化が有効な場合、最終出力をindex.htmlおよび必要に応じてqa_report.mdとして具体化します。
9. ユーザーが最終成果物を望む場合、CDNのみのプロトタイプよりも自己完結型HTMLファイルまたはローカルで実行可能なフォルダを優先します。

チェックポイント:

## ステップ 10 完了
- [x] スタティックHTMLが生成されました
- [x] プレゼンテーション文法が保持されました
- [ ] 次: ステップ 17 に自動進行

---

ステップ 11: アドバンスドワークフロー A - 方向選択

ゲート: 選択されたモードがadvancedです。

実行:

1. ブリーフ成果物を準備します。
2. 3〜4つのデザイン方向をお勧めします。
3. 閲覧が利用可能な場合、選択を支援する場合、方向をシェイプするインスピレーションを検索します。
4. スタイルオプション成果物で、各方向を以下の観点から説明してください:
   • トーン
   • 階層