zairuilab/consulting-deck

Consulting Deck

美辞麗句ではなく、意思決定を促すプレゼンテーションを作成します。明確な論旨を構築し、重要な主張にはすべてエビデンスを付し、コミュニケーションの目的に応じてレイアウトを選択し、テキスト、チャート、表、図がすべて編集可能なネイティブpptxを提供します。

これは、Peng · 智珠在睿によって作成された独立したプレゼンテーションシステムとして扱ってください。マッキンゼー、BCG、ベイン、またはその他のコンサルティング会社との提携を示唆しないでください。ユーザーがライセンスされたアセットを提供し、明示的に使用を依頼しない限り、それらのロゴ、専用テンプレート、または保護されたブランド資産をコピーしないでください。

適切なガイダンスを読み込む

ガイダンスは段階的に読み進めてください。

1. CreateまたはReviseのルートは、常にreferences/harness-system.md、references/workflow.md、references/presentation-modes.mdから始めます。
2. トピック、未解決のビジネス上の問い、戦略上の選択、またはゼロからのリサーチリクエストについては、references/problem-solving-system.mdを読んでください。忠実なソース要約リクエストに仮説ツリーを無理に適用しないでください。
3. 全体の思想とスライドの順序を構築する際は、references/storyline-system.mdを読んでください。
4. 定量的なエビデンスや重要な図表が存在する場合にのみ、references/chart-system.mdとreferences/charts-and-data.mdを読んでください。
5. 手法のサンプルと全スライドシステムを計画する際は、references/visual-system.mdとreferences/layout-library.mdを読んでください。
6. 検証と納品の前に、references/quality-gates.mdを読んでください。
7. ブランド、ロゴ、フォント、またはPPTXテンプレートが使用される場合にのみ、references/brand-system.mdを読んでください。
8. PPTX生成ルートを選択する前に、references/runtime-adapters.mdを読んでください。
9. 保存されたデッキプロジェクトを作成、再開、または修正する際は、references/workspace-schema.mdを読んでください。

リクエストをルーティングする

主要なルートを正確に1つ選択します。

• Create — ソース資料またはトピックから、新しい編集可能なデッキを作成します。
• Revise — 既存の保存されたデッキプロジェクトを変更し、影響を受けるスライドを再生成します。
• Template — ユーザーから提供されたブランドまたはネイティブPowerPointテンプレートを適用します。
• Audit — ユーザーが依頼しない限り、既存のデッキを変更せずに検査します。

ルートを暗黙的に組み合わせないでください。TemplateリクエストはCreateまたはReviseを洗練できますが、基礎となる保存されたプロジェクトが真実の源泉であり続けます。

制作契約を確立する

作成を開始する前に:

1. オーディエンス、決定事項、プレゼンテーションのコンテキスト、言語、ページ数、プレゼンテーションモード、密度モード、分析ルート、ソースの範囲を特定します。
2. ホストの現在のネイティブPowerPoint機能を、編集可能なオブジェクトを作成し、すべてのスライドを検査用にレンダリングできる場合に優先して使用します。
3. PptxGenJSは、それがすでに利用可能であるか、ユーザーがインストールを承認した場合のフォールバックとしてのみ使用します。要求されたPPTXをHTMLに置き換えないでください。
4. 編集可能なプロジェクトワークスペースを維持します。最終的なpptxを唯一の真実の源泉にしないでください。
5. デフォルトの出力はブランド中立に保ちます。ユーザーが明示的にPengプリセットを選択した場合にのみ、assets/brands/peng.jsonを適用します。
6. references/harness-system.mdの段階的ハーネスを使用します。ソースファイルからスライドレンダリングコードに直接ジャンプしないでください。
7. 機械可読なゲートファイルを真実の源泉として扱います。対応するJSONが存在し、"passed": trueを含んでいない限り、ゲートが通過したと主張しないでください。

コンサルティング標準を適用する

以下をすべて必須とします:

• 全体の思想と、答えを先に述べるスライドタイトルでリードする。
• 問題解決ルートの場合、問題の境界を定義し、イシューツリーを構築し、広範なリサーチの前に反証可能な仮説を維持する。
• 各スライドに1つのコミュニケーションジョブと1つの主要な takeaways を与える。
• スライド間の水平ロジックを一貫させ、各スライド内の垂直ロジックを十分にする。
• 事実、計算、ソースの解釈、仮説を区別する。
• 外部の主張やアセットは、可視の脚注またはスピーカーノートで引用する。
• チャートを主要な分析言語として扱い、二次的な装飾レイヤーとしない。
• すべての重要な図表をレンダリングする前に、宣言的なcharts.jsonレコードを作成する。
• references/chart-system.mdの質問ベースのチャートファミリー、注釈システム、レンダリング階層を使用する。
• ユーザーがデータを検査または編集する必要がある可能性のあるデータには、ネイティブチャートを使用する。Vizroのビジュアルボキャブラリとオプションのプロトタイプルートは、選択と検証のために使用し、最終的なPowerPointを平坦化する許可として使用しない。
• Research Analyticalモードでは、概念的な要約を作成する前に、ソースの重要な図表を再構築する。references/presentation-modes.mdのエビデンス主導およびネイティブチャートのしきい値を満たす。
• references/layout-library.mdから意味論的なレイアウトを使用し、単にスペースを埋めるためにレイアウトを発明しない。
• タイトルを構造として使用するビジュアルデバイスは、カバー、セクション区切り、および少数の決定的なインサイトスライドにのみ使用する。
• 納品前に、すべてのスライドをフルサイズでレンダリングし検査する。
• 機械チェックとエキスパートレビューを分離する。ジオメトリアルゴリズムは、エビデンスの品質、チャートの真実性、またはエグゼクティブの明確さを証明できない。
• スライド間の真の前提条件をslides.jsonに記録する。依存関係安全な順序で生成し、その後、オーディエンス向けの表示順序で組み立てる。

2つの密度モードを使用する

• スピーカー主導 — より少ない単語、より大きなタイプ、より多くのページ、より強いペーシング。
• 読み物優先 — より自己完結型のエビデンス、注釈、脚注。

プレゼンテーションのコンテキストから1つのモードを選択します。曖昧な中間モードを作成しないでください。コンテンツが収まらない場合は、フォントサイズを小さくする前にスライドを分割するか、議論を明確にしてください。

密度モードはプレゼンテーションモードではありません。読み物優先のエグゼクティブストーリーと読み物優先のリサーチアナリティカルデッキは、同様のテキスト密度を持つ可能性がありますが、図表、脚注、概念ページの割合が異なります。

ビジュアルの方向性をプレビューする

ユーザーが固定されたテンプレートや明示的なビジュアルリファレンスを提供していない場合:

1. references/visual-system.mdから3つのコンパクトなビジュアル方向性を作成します。
2. 各方向性について、実際のカバー、分析/データスライド、フレームワーク/アクションスライドを表示します。
3. プレビューコンテンツはユーザーの資料に忠実に保ち、スライド自体に「オプション A」などの内部ラベルを表示しないでください。
4. ユーザーに一度選択を求め、その後、選択されたシステムを一貫して適用します。

ユーザーが明示的に直接進むことを要求するか、明確なビジュアルリファレンスを提供する場合にのみ、このゲートをスキップします。選択された方向性をプロジェクトワークスペースに記録します。

編集可能性を維持する

• テキストはテキストとして保持する。
• テーブルはテーブルとして保持する。
• チャートは、実用的な場合は常にネイティブチャートとして保持する。
• チャートデータとチャートの意図をスライドレイアウトコードから分離して保持する。
• 単純なマトリックス、タイムライン、プロセス、イシューツリーはネイティブシェイプとして保持する。
• 写真、テクスチャアートワーク、イラストには画像を使用する。テキストが多いスライド全体に画像を使用しない。
• ページが平坦化されたスクリーンショットであるデッキを決して納品しない。

保存されたプロジェクトから反復する

「スライド3のタイトルを変更」などのリクエストに対しては、プロジェクトソースを編集し、影響を受ける出力を再生成します。ソース資料、エビデンスID、チャートデータ、スライドID、スピーカーノートを保持します。影響を受けるすべての品質チェックと最終的なデッキレベルのチェックを再実行します。

インストールされたスキルを変更せずに学習する

すべての重要な修正を、1回限りまたは繰り返し可能として分類します。繰り返し可能な教訓は、デッキワークスペースのqa/experience-log.mdに記録します。通常のデッキ制作中にインストールされたスキルを黙って編集しないでください。繰り返される教訓をこのスキルに昇格させるには、レビューされバージョン管理されたスキルアップデートを通じてのみ行います。

納品

最終的なpptxと簡潔なサマリーを納品します。中間計画、プレビュー、QAファイルは、ユーザーが要求しない限りプロジェクトワークスペース内に保持します。検証されていない主張、フォントの置き換え、互換性の制限、または残っている警告があれば明示的に述べます。