matzehg/minto-deck

Minto Deck

一份簡報或備忘錄應是觀眾僅從標題就能跟隨的論證。此技能確保每份簡報與備忘錄皆為「結論先行」，先建立故事線以便在變更成本低廉時獲得論證核准，並依據相同標準審查現有簡報與備忘錄。方法論獨立於任何渲染工具，儲存於 references/ 中，因此在 Claude.ai、Cowork、Claude Code 或任何相容 Agent-Skills 的平台上行為一致。

三種模式

每次請求選擇一種模式，並在回覆的第一行標明。

• 建構模式（Build）：用戶想要新的簡報、故事線、草稿簡報、尚未存在的簡報的講者備註，或將素材重組為投影片。
• 備忘錄模式（Memo）：用戶想要「結論先行」的論證散文：管理摘要、簡報筆記（Vermerk）、活動或會議報告、一日或會議論點、決策備忘錄、狀態筆記，或應以結論引導而非重述來源的摘要。輸出為文字（聊天、文件或檔案），絕非投影片。
• 審查模式（Audit）：用戶擁有簡報或備忘錄（檔案、連結、貼上的大綱、匯出的文字）並希望對其進行審查、檢查、批評或評分。除非用戶要求改寫，否則不要在審查模式中修改；此時應先報告，再進行改寫。

像「修正我的簡報」這樣的請求，是先進行審查模式，再對修正後的故事線進行建構模式階段一。請在開始前說明。單純的「摘要這些筆記」且無進一步需求，不屬於此技能範疇；「摘要並使關鍵訊息優先呈現」、「今日的論點是什麼」、「撰寫管理摘要」則屬於備忘錄模式。當同時需要備忘錄與簡報時，先執行備忘錄模式：經核准的備忘錄故事線將成為草稿簡報的核心思想與關鍵論點（參見備忘錄模式下的「連結至建構模式」）。

語言

以簡報所屬的語言進行回覆、產出標題、筆記與所有產出物。若簡報為混合語言，請詢問一次。保留方法論術語為英文，並在簡報為德文時於首次使用時附上德文對照，例如「Governing Thought (Kernbotschaft)」。references/glossary.md 儲存固定配對；請使用它們，以確保簡報在不同專案間保持一致。

建構模式（Build）

階段 0：簡報合約

在撰寫任何標題前，請確立以下項目。首先從請求、附件材料與對話歷史中取得。僅針對遺漏且會改變故事線的項目進行提問；否則在階段一輸出中陳述假設並繼續。一次不要問超過三個問題。

1. 觀眾及其問題：與會者是誰，他們在簡報結束時必須理解、決定或執行什麼。
2. 目的與簡報類型：決策文件、狀態報告、提案或提案簡報、專家演講、閱讀型簡報。references/audit-checklist.md 列出各類型的必要元素；類型決定階段二應包含的內容。
3. 用戶已有的核心思想（如果有的話）。若用戶沒有，則從材料中推導出一個，並標示為「推導所得」。
4. 設定：現場演示或無演示者閱讀。這決定了密度模式（講者主導或閱讀優先），以及是否需要講義版本。
5. 時間長度，包含討論時間，及其後的投影片預算。
6. 材料與來源：有哪些證據，缺少什麼，哪些不可虛構。數字、引述與範例來自用戶的材料，或清楚標示為佔位符。
7. 限制條件：模板、企業設計、保密性、投影片限制、強制性投影片。模板存放於 assets/templates/，每個模板一個資料夾，包含檔案與其版型的簡短說明；選擇簡報合約中指定的模板，或當多個模板適用時進行詢問。模板為用戶或其雇主的財產：請將其遠離公開儲存庫。
8. 符號表示法：當材料包含實際值、計劃、預測、前期或差異時，簡報預設使用 IBCS 符號表示法。請在登錄表中說明，並在關卡中將「未使用 IBCS 符號表示法」列為開放議題，以便用戶可以拒絕。

階段 1：草稿簡報（Ghost Deck）

在開始建構前，請先閱讀 references/minto-pyramid.md 與 references/storyline-ghost-deck.md。草稿簡報是完整的論證，不包含投影片主體。

按以下順序建構：

1. 撰寫核心思想：一句能回答觀眾問題，且理性的人可能不同意的一句話。
2. 撰寫 SCQA 開場。僅保留觀眾尚未共享的情境與衝突。決定核心思想出現的位置（預設為投影片 2 的管理摘要）。
3. 撰寫關鍵論點：三到五個共同證明核心思想的主張。將其作為一組測試：相同類型的想法、無重疊、共同充分、一個邏輯順序。
4. 將每個關鍵論點主張擴展為其支援投影片。每個投影片標題都是一個完整的句子，陳述一個主張。使用平行語法對同級項目進行分組。
5. 加入結尾：重申核心思想、決策或後續步驟（作為觀眾決定的提案），以及如果簡報類型有此要求的明確請求。
6. 建立登錄表：每個命名實體（流程、機構、角色、系統、選項、準則）使用將在每張投影片上出現的確切名稱、其類別、定義與狀態（來自簡報或假設）。測試每個集合是否屬於同一類別及同一命名模式。登錄表是用戶編輯名稱、成員與順序的依據；階段二僅使用登錄表作為唯一來源。
7. 根據時間長度推導時間骨架，並標記刪減優先順序。僅在約 20 張投影片以上時使用章節分隔頁；較短的簡報使用時間追蹤器。
8. 執行「閱讀測試」：從上到下僅閱讀標題。如果論證有斷層、重複或跳躍，修正標題，而非投影片主體。

輸出確切的草稿簡報格式（參見 references/storyline-ghost-deck.md）：按章節分組的編號標題、登錄表、時間骨架、假設、開放議題，以及最多一個替代關鍵論點（如果材料支援不同結構）。然後停止。以核准問題結束回覆。在同一次回覆中不要產出投影片、筆記或檔案，即使用戶要求「完整的簡報」：關卡是方法的重點，且現在更改故事線僅需幾分鐘，而後續更改則需要數小時。如果用戶明確要求一次性完成，請說明關卡將應其要求跳過，並繼續。

當用戶編輯標題時，僅重新產生受影響的故事線部分，並重新執行閱讀測試。不要重新開啟已核准的部分。

符號表示法預覽：如果用戶對 IBCS 符號表示法不確定，請在階段二開始前以兩種變體建構一張圖表投影片，讓他們選擇。僅在明確要求下，才以兩種符號表示法產出兩份完整簡報。

階段 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. 投影片主體。 每張投影片一個訊息；投影片主體證明標題。根據訊息所做的比較，選擇證據形式（圖表、表格、卡片、圖解、文字），並遵循 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；輔助程式編碼了區域、網格、字體階層、清單樣式表格、卡片、V 形與備註窗格，因此建構檔案僅包含簡報的內容（參見 scripts/README.md 與 scripts/example-build.js）。
3. 當完全無法產出檔案時，使用包含備註的 Markdown 大綱；請說明。

交付可編輯的 .pptx 檔案。Keynote 與 Google Slides 可匯入此格式；請勿產出 Keynote 原生檔案。保持圖表為原生。將講者備註放入備註窗格，切勿放入投影片上的文字方塊中。當用戶提供模板時，應用其模板；否則保持中性並說明。在交付前，傾印簡報文字並檢查標題、順序、備註存在性與遺留的佔位符。然後以全尺寸渲染每張投影片並逐一檢視：重疊、浮動連接線、比指向它們的框更窄的框、換行的鍵值行、聚合的空白、試算表風格的表格。縮圖無法顯示這些問題。

備忘錄模式（Memo）

在開始前，請閱讀 references/memo-format.md 與 references/minto-pyramid.md。備忘錄應用與簡報相同的金字塔結構，但扁平化為散文：核心思想先行，章節標題即為關鍵論點主張，每個段落證明其標題。兩個階段，一個輕量關卡。

階段 0：簡報

從請求、材料與對話中取得以下項目；僅針對遺漏且會改變故事線的項目進行提問，一次最多三個問題。

1. 觀眾及其問題：誰閱讀此文，以及他們之後必須理解、決定或執行什麼。混合觀眾（內部和外部讀者）會降低內部參考的密度並提高歸因門檻。
2. 備忘錄類型：管理摘要、簡報筆記（Vermerk）、活動或會議報告、決策備忘錄、狀態筆記。memo-format.md 列出各類型的必要元素。
3. 用戶已有的核心思想。若無，則從材料中推導出一個，並標示為「推導所得」；關卡的存在是為了讓用戶可以替換它。
4. 長度預算（字數或頁數）與目的地：聊天回覆、文件、檔案。
5. 材料與來源：可以使用哪些材料，哪些不可虛構，如何歸因陳述。對於關於談話或會議的報告，應確定是否提及演講者姓名、以角色提及，或完全不提及（memo-format.md 第 5 節）。
6. 後續是否會產出簡報。若是，則需建構可轉移的故事線。

階段 1：故事線

以 memo-format.md 第 2 節的格式交付：一句話的核心思想；包含全部四個 SCQA 行（情境與衝突各一句話、衝突引發的問題、核心思想作為答案）的開場，讓讀者可以在關卡檢查答案是否回答了問題；三到五個完整句子的關鍵論點主張，按主題或論證順序排列（絕不按來源材料的順序），每個附有證據標記（可用、缺少或佔位符，以及來源）；順序及其準則；來源之間的分歧位置及其將在哪個主張下被論證；當備忘錄類型有此元素時，備忘錄指出後續對讀者的影響；歸因設定；假設與開放議題；當備忘錄命名了必須保持一致的流程、機構、角色、系統或選項時，應包含簡短登錄表，附帶「集合」行，以一個複數名詞命名每個集合，並以固定順序列出其成員（複數名詞測試：機構不屬於流程集合）。對關鍵論點執行閱讀測試。以一個核准問題結束並停止。例外情況：用戶要求一次性完成，或備忘錄極短（少於一段）且故事線本身即為最終版本。