matzehg/minto-deck

Minto Deck

デッキとメモは、見出しだけで聴衆が議論を追える構成にします。このスキルは、すべてのデッキとメモをアンサーファーストにし、まずストーリーラインを構築して変更が容易なうちに承認を得た上で、既存のデッキやメモを同じ基準でレビューします。方法論は references/ にあり、レンダリングツールに依存しないため、Claude.ai、Cowork、Claude Code、その他Agent-Skills互換のホストで同じように動作します。

3つのモード

リクエストごとに1つのモードを選択し、応答の最初の行にそのモード名を記述します。

• ビルド：ユーザーが新しいデッキ、ストーリーライン、ゴーストデッキ、まだ存在しないデッキのスピーカーノート、または既存資料のスライドへの作り直しを希望する場合。
• メモ：ユーザーがアンサーファーストな散文（管理職サマリー、ブリーフィングノート、議事録、その日のテーゼ、意思決定メモ、ステータスノート、または結論から始める要約）を希望する場合。出力はテキスト（チャット、ドキュメント、ファイル）であり、スライドは生成しません。
• 監査：ユーザーが既存のデッキやメモをレビュー、チェック、批評、評価してほしい場合。監査モードでは、ユーザーが書き直しを依頼しない限り変更は行いません。その場合は、最初にレポートを提示し、次に書き直しを行います。

「デッキを直して」のようなリクエストは、監査の後に修正されたストーリーラインに対するビルドステージ1が続きます。開始前にその旨を伝えてください。「これらのノートを要約して」という付加希望のないリクエストは単なる要約であり、このスキルの範囲外です。「キーメッセージが最初に来るように要約して」「今日のテーゼは」「管理職サマリーを書いて」はメモモードです。メモとデッキの両方が必要な場合は、先にメモを実行します。承認されたメモのストーリーラインが、ゴーストデッキの統治理念とキーラインになります（メモモードの「ビルドへの架け橋」を参照）。

言語

応答、タイトル、ノート、すべての成果物は、ブリーフィングの言語で記述します。ブリーフィングが混在している場合は、一度だけ確認します。方法論の用語は英語のままにし、デッキがドイツ語の場合は初出時にドイツ語の対訳を括弧書きで付けます（例：「Governing Thought (Kernbotschaft)」）。references/glossary.md に対訳ペアが定義されているので、プロジェクト間で一貫性を保つためにそれらを使用します。

ビルドモード

ステージ0：ブリーフィング契約

タイトルを書き始める前に、以下の項目を確定します。まずはリクエスト、添付資料、会話履歴から取得します。不足していてストーリーラインに影響を与える項目のみを質問し、それ以外はステージ1の出力で前提として記載して進めます。一度に3つ以上の質問はしないでください。

1. 聴衆とその質問：誰が会議室にいて、デッキが終わったときに何を理解し、決定し、実行しなければならないか。
2. 目的とデッキの種類：決定資料、ステータスレポート、提案・ピッチ、専門家向け講演、読み物デッキ。references/audit-checklist.md に種類ごとの必須要素がリストされています。この種類が、ステージ2に何を含めるべきかを決定します。
3. ユーザーが既に持っている統治理念（あれば）。ない場合は、資料から導出し、導出済みとラベル付けします。
4. 設定：ライブプレゼンテーションか、発表者なしで読まれるか。これにより密度モード（スピーカー主導 or 読解優先）とハンドアウトの要否が決まります。
5. 時間（議論時間を含む）と、それに基づくスライド数。
6. 資料とソース：どのようなエビデンスが存在するか、何が不足しているか、何を作り出してはいけないか。数字、引用、例はユーザーの資料から取得するか、明確にプレースホルダーとしてマークします。
7. 制約：テンプレート、コーポレートデザイン、機密性、スライド制限、必須スライド。テンプレートは assets/templates/ にあり、テンプレートごとに1フォルダ、ファイルとそのレイアウトに関する短いメモが含まれています。ブリーフィングで指定されたものを選択し、複数該当する場合は質問します。テンプレートはユーザーまたはその雇用主の資産です。公開リポジトリに入れないでください。
8. 表記法：資料に実績値、計画値、予測値、前期比、差異が含まれる場合、デッキはデフォルトでIBCS表記法を使用します。その旨をレジスターに記載し、「IBCS表記法なし」をゲートでの未解決項目としてリストアップし、ユーザーが拒否できるようにします。

ステージ1：ゴーストデッキ

構築前に references/minto-pyramid.md と references/storyline-ghost-deck.md を読んでください。ゴーストデッキは、スライド本体のない完全な議論です。

以下の順序で構築します：

1. 統治理念を書く：聴衆の質問に答える1文であり、合理的な人が反論できる内容であること。
2. SCQAでオープニングを書く：聴衆がまだ共有していない状況と複雑化要因だけに絞ります。統治理念をどこに配置するか決定します（デフォルトではスライド2の管理職サマリー）。
3. キーラインを書く：統治理念を証明する3～5つの主張。セットとしてテストします：同じ種類のアイデア、重複なし、合わせて十分、1つの論理的な順序。
4. 各キーラインの主張をサポートスライドに展開する。すべてのスライドタイトルは1つの主張を述べる完全文です。同レベルのものは平行な文法でグループ化します。
5. クロージングを追加する：統治理念の再述、聴衆が決定する提案としての決定または次のステップ、デッキの種類に応じた明示的な依頼。
6. レジスターを構築する：すべての名前付きエンティティ（プロセス、組織、役割、システム、オプション、クライテリア）について、すべてのスライドで使用する正確な名前、カテゴリ、定義、ステータス（ブリーフィングから、または仮説）を記載します。各セットを1つのカテゴリと1つの命名パターンでテストします。レジスターはユーザーが名前、メンバー、順序を編集するためのポイントであり、ステージ2では唯一のソースとして使用します。
7. 時間枠を導出し、削除優先順位をマークする。セクションデバイダーはおおよそ20スライドから使用し、それより短いデッキではトラッカーを使用します。
8. 読み通しテストを実行する：タイトルだけを上から下まで読む。議論にギャップ、重複、飛躍がある場合は、スライド本体ではなくタイトルを修正します。

出力は references/storyline-ghost-deck.md のゴーストデッキ形式そのまま：番号付きタイトルをセクションごとにグループ化、レジスター、時間枠、前提条件、未解決項目、そして資料が別の構成をサポートする場合は最大1つの代替キーライン。その後停止します。承認質問で応答を締めくくります。ユーザーが「デッキ」を要求した場合でも、同じターンでスライドやノートやファイルを生成しないでください。ゲートがこの方法の要点であり、ストーリーラインの変更は今は数分、後では数時間のコストになります。ユーザーが明示的にワンショット実行を要求した場合は、ゲートをスキップする旨を伝えて続行します。

ユーザーがタイトルを編集した場合、影響を受けるストーリーラインの部分のみを再生成し、読み通しテストを再実行します。承認済みのセクションは再オープンしません。

表記法のプレビュー：ユーザーがIBCS表記法に確信が持てない場合は、ステージ2の本番前に1つのチャートスライドを両方のバリエーションで作成し、選択してもらいます。明示的な要求がない限り、2つの完全なデッキを2つの表記法で作成することはありません。

ステージ2：フルデッキ

承認されたゴーストデッキからのみ開始します。まず references/stage-2-checklist.md を読んでください。これは納品前にチェックされるページです。次に references/consulting-practices.md、references/visual-design.md、references/speaker-notes.md、references/timing-qa-handout.md を読んでください。資料に実績値、計画値、予測値、前期比、差異が含まれる場合は references/ibcs-notation.md も読んでください。読解優先デッキまたはハンドアウトの手順については references/reading-decks.md を読んでください。

以下の順序で作成します：

1. スライド本体。スライドごとに1つのメッセージ。本体はタイトルを証明します。メッセージが行う比較に基づいて、エビデンスの形式（チャート、表、カード、図、テキスト）を選択します（consulting-practices.md のチャートと表のルールに従う）。すべての外部主張にはソース行を付けます。すべての数字には単位、期間、分母を付けます。密度はステージ0で固定されたモードに従います。スピーカー主導の密度では、穴を残さないようにタイプと形状をスライドいっぱいに拡大します。決定資料では、推奨するオプションの詳細の前にオプションを示し、タイトルでオプションとして明示します。すべてのエンティティはレジスターから、レジスターの名前と順序で使用します。
2. スライド2の管理職サマリー：ゴーストデッキからドラフト（統治理念、キーライン、依頼）。最終版はステップ8で、他のすべてのスライドが存在し、数字が確定した後に作成します。密度モードに応じた形式（visual-design.md セクション8参照）。
3. すべてのスライドのスピーカーノート：ノートペインに、speaker-notes.md の構造に従って：キーポイント、オープニングライン、トークトラック、指し示すエビデンス、トランジション、時間配分。プロンプトであり、スクリプトではありません。
4. タイミング計画：別の表として：スライド、分数、累計、削除優先順位。
5. Q&A準備：別のドキュメントとして：聴衆が尋ねるであろう質問を、何を攻撃するかでグループ化し、それぞれに短い回答と、そのエビデンスを含むスライドまたはバックアップへのポインタを付けます。
6. バックアップスライド：予想される質問に答えるエビデンスを含むが、主要な議論を構成しないもの。Q&Aドキュメントから参照します。
7. ハンドアウトバリアント：デッキが発表者なしでも読まれる場合：同じストーリーライン、読解優先の密度、スライド上のソース、配信の合図なし。変換ルールは reading-decks.md セクション6参照。
8. 管理職サマリー、最終版。完成したスライドに対してスライド2を書き直します。太字の行はすべて、スライドが証明する主張であり、すべての数字は対応するスライドと一致します。
9. 一貫性チェック。デッキのテキストをダンプし、レジスターのすべてのセットをチェックします：同じメンバー、同じ名前、出現するすべてのスライドで同じ順序。メンバーが出現または消失する場合、その理由がスライドまたはノートに記載されていることを確認します。サブセットがその全体集合とクライテリアを命名していることを確認します。ゴーストデッキのエビデンスカラムをチェックします：「欠落」とマークされたすべてのタイトルが、スライド上と配信ノートにプレースホルダーとして存在することを確認します。
10. 自己チェック：納品前に references/audit-checklist.md に照らしてチェックします。visual-design.md セクション12のビジュアルチェックを含みます。ブロッカーは修正します。警告は配信ノートにリストアップします。

レンダリング

方法論はツールに依存しません。ファイルはホストが提供するもので作成され、以下の優先順位で選択します：

1. ホストのネイティブPowerPoint機能（Anthropicの pptx スキル、PowerPointコネクタ、または同等のスライドツール）。テキスト、表、チャートを編集可能に保ち、ノートをノートペインに配置できるため。
2. そのような機能がない場合、pptxgenjs と scripts/pptx-helpers.js をサンドボックスで使用。ヘルパーはゾーン、グリッド、タイプスケール、リスト形式の表、カード、シェブロン、ノートペインをエンコードするため、ビルドファイルにはデッキのコンテンツのみが含まれます（scripts/README.md と scripts/example-build.js 参照）。
3. ファイルを全く生成できない場合は、ノート付きのMarkdownアウトライン。その旨を伝えます。

編集可能な .pptx を納品します。KeynoteとGoogle Slidesはこれをインポートできます。Keynoteネイティブのファイルは作成しません。チャートはネイティブに保ちます。スピーカーノートはノートペインに配置し、スライド上のテキストボックスには決して入れません。ユーザーからテンプレートが提供された場合はそれを適用し、そうでない場合はニュートラルなものを使い、その旨を伝えます。納品前に、デッキのテキストをダンプし、タイトル、順序、ノートの存在、残っているプレースホルダーをチェックします。その後、すべてのスライドをフルサイズでレンダリングし、それぞれを確認します：重なり、浮いたコネクタ、指し示すものよりも狭いボックス、折り返されたキー・バリュー行、まとまったホワイトスペース、スプレッドシート形式の表。サムネイルではこれらは表示されません。

メモモード

開始前に references/memo-format.md と references/minto-pyramid.md を読んでください。メモはデッキと同じピラミッドを散文に平坦化したものです：統治理念が先頭に立ち、セクション見出しがキーラインの主張であり、各段落がその見出しを証明します。2つのステージ、1つの軽いゲート。

ステージ0：ブリーフィング

以下の項目をリクエスト、資料、会話から取得します。不足していてストーリーラインを変更するものだけを質問します。一度に最大3つの質問までにします。

1. 聴衆とその質問：誰がこれを読み、その後何を理解し、決定し、実行しなければならないか。混合聴衆（社内外の読者）は内部参照の密度を下げ、帰属のハードルを上げます。
2. メモの種類：管理職サマリー、ブリーフィングノート（Vermerk）、議事録、決定メモ、ステータスノート。memo-format.md に種類ごとの必須要素がリストされています。
3. ユーザーが既に持っている統治理念。ない場合は資料から導出し、導出済みとラベル付けします。ゲートはユーザーがそれを置き換えるために存在します。
4. 長さの予算（単語数またはページ数）と出力先：チャット応答、ドキュメント、ファイル。
5. 資料とソース：何を使用してよいか、何を作り出してはいけないか、ステートメントがどのように帰属されるか。講演や会議のレポートの場合、話者が名前で言及されるか、役割で言及されるか、全く言及されないかを確定します（memo-format.md セクション5）。
6. デッキが後続するかどうか。はいの場合、ストーリーラインが引き継がれるように構築します。

ステージ1：ストーリーライン

memo-format.md セクション2の形式で納品します：1文の統治理念。SCQAの4行すべてからなるオープニング：状況と複雑化要因はそれぞれ1文、複雑化要因が提起する質問、そしてその回答としての統治理念をそのまま記載し、読者がゲートで回答が質問に答えているかを確認できるようにします。3～5つのキーラインの主張を完全文で、テーマまたは議論の順序で（ソース資料の順序ではなく）、それぞれにエビデンスマーク（利用可能、欠落、またはプレースホルダー、およびソース）を付けて記載します。順序とそのクライテリア。ソース間の相違がどこにあるか、どの主張の下で議論されるか。メモの種類にその要素がある場合、読者にとって次に何が続くか。帰属設定。前提条件と未解決項目。メモが一貫性を保つ必要のあるプロセス、組織、役割、システム、オプションに名前を付ける場合の短いレジスター（「セット」行で各セットを1つの複数名詞で命名し、そのメンバーを固定順でリストアップします。複数名詞テスト：研究所はプロセスのセットには属しません）。キーラインで読み通しテストを実行します。1つの承認質問で締めくくり、停止します。例外：ユーザーがワンショット実行を要求した場合、またはメモが極めて短く（キーライン2つ以下）ステージ1が実質的に最終出力と変わらない場合、その場合はゲートをスキップして完全なメモを納品します。

ステージ2：完全なメモ

承認されたストーリーラインからのみ開始します。完全なメモは以下の構造を持ちます（memo-format.md セクション3参照）：

1. ヘッダー：宛先、差出人、日付、件名、機密分類、メモの種類。
2. 統治理念：最初の行、太字。キーラインの前に立つコンテキストなし。
3. SCQAオープニング：ステージ1の形式で、ただし状況と複雑化要因は最初の段落にまとめます。質問と回答は暗黙のうちに（回答はすでに統治理念として述べられています）。
4. キーラインのセクション：セクション見出し（キーラインの主張）、見出しを証明する段落。エビデンス（引用、数字、例）を、メモの種類に適した密度で埋め込みます。各段落は1つの主張を証明します。
5. 結論と依頼（メモの種類に応じて）。
6. 帰属とソース（種類に応じてインラインまたは脚注）。
7. 付録：レジスター、定義、詳細な数値。

密度と口調は memo-format.md セクション4に従います。セクション見出しのみの読み通しテストを実行します。納品前に、すべてのセットがレジスターと一致していることを確認します。

ビルドへの架け橋

メモモードの後、ユーザーがデッキを要求した場合：承認されたメモのストーリーラインからゴーストデッキを構築します。統治理念とキーラインはメモのものと同じです。オープニングはSCQAのままですが、スライドのリズムに合わせて短くします。レジスターはメモのレジスターを引き継ぎ、「セット」行はそのままにします。ビルドモードステージ1で開始します。最初のラインは「Build mode, from approved memo storyline」です。

監査モード

開始前に references/audit-checklist.md、references/minto-pyramid.md、references/stage-2-checklist.md、および監査対象の資料の種類に応じて references/memo-format.md または references/storyline-ghost-deck.md を読んでください。

以下の順序で動作します：

1. 素材を入手する：ファイル、リンク、貼り付けられたアウトライン、エクスポートされたテキスト。スライドの場合は、タイトル、ノートペインのテキスト、スライド本体のテキストを抽出します。
2. レジスターを再構築する：エンティティ名、カテゴリ、一貫性。欠落したセット、壊れたセット、混合カテゴリのセット。
3. SCQAをテストする：統治理念（またはその欠如）、オープニング、質問と回答の一致。
4. キーラインの構造をテストする：同じ種類、重複なし、合わせて十分、論理的な順序。読み通しテスト。
5. スライドごと／段落ごとのテスト：タイトルは完全文で主張を述べているか。本体はタイトルを証明しているか。ソース、単位、期間。
6. 視覚的テスト（デッキの場合）：チャートの種類とメッセージの一致。表の明瞭性。IBCS準拠（該当する場合）。密度。
7. スピーカーノートのテスト（デッキの場合）：構造、内容、時間配分。
8. レポート：発見事項を、クリティカル（ブロッカー）、メジャー（構造的）、マイナー（表面的）に優先順位付けします。問題ごとに、標準への参照を示します。証拠のある書き直しの提案をします。
9. 書き直し（要求された場合のみ）：監査レポートの後に、修正されたストーリーライン（ビルドステージ1）または修正されたメモ（メモステージ2）を、変更内容の要約とともに提供します。

統治理念がないことは常にブロッカーです。キーラインに4つ以上の主張がある、または3つ未満であることはブロッカーです（主張が1つだけのデッキは許可されます。その場合、タイトルに「First」「Second」のような順序語を含んではなりません）。スライド上の孤立したパーツ（どの主張にも属さない図や表）はブロッカーです。メモ内の帰属されていない主張はブロッカーです。「懸念事項」や「リスク」のスライドは、それらが議論する主張の下に配置されない限りブロッカーです。

監査は常に1回の応答で行われます。ファシリテートされたレビューは行いません。

参照

すべての方法論は references/ に文書化されています。

• references/minto-pyramid.md：完全なピラミッド原則。統治理念、キーライン、MECE、フルセンテンスタイトル、SCQA。
• references/storyline-ghost-deck.md：ゴーストデッキの形式と構築ルール。読解テスト。
• references/stage-2-checklist.md：納品前チェックリスト。
• references/consulting-practices.md：チャートと表の選択ルール、エビデンスの形式、ソースの帰属。
• references/visual-design.md：タイポグラフィ、グリッド、色、密度モード。
• references/speaker-notes.md：スピーカーノートの構造。
• references/timing-qa-handout.md：タイミング計画、Q&A準備、ハンドアウト。
• references/ibcs-notation.md：IBCS表記法のルール。
• references/reading-decks.md：読解優先デッキとハンドアウト変換。
• references/memo-format.md：メモの構造と種類ごとの要素。
• references/audit-checklist.md：監査基準とブロッカー。
• references/glossary.md：英語とドイツ語の用語対訳。
• scripts/pptx-helpers.js：pptxgenjsヘルパー（ゾーン、グリッド、タイプスケール、表、カード、ノートペイン）。
• scripts/example-build.js：ビルドファイルの例。
• scripts/README.md：ビルドスクリプトのドキュメント。
• assets/templates/：テンプレートフォルダ。

制限

• 音声書き起こしや翻訳は行いません。
• ソース資料をそのまま並べただけの要約は行いません（アンサーファーストでない、または新しい議論を構築しないもの）。
• 方法論の語彙は維持します。ドイツ語のデッキでは初出時に英語の用語を括弧書きで付けますが、語彙を翻訳してはいけません。
• スピーカーノートをスライド上のテキストボックスに配置してはいけません。
• 未承認のストーリーラインからスライドを生成してはいけません。ワンショットは明示的な要求に限ります。
• 推測でソースを作り出してはいけません。