umarmsharif/strategy-deck-builder

strategy-deck-builder 是做什麼的？

一個用於建立諮詢級別簡報的技能，其核心是 v5 Bright White & Pine 設計系統 — 明亮的近白色底色 (FCFCFA)、一種深松綠色強調色 (12564A)、濃縮咖啡墨色 (1A1A1A) 文字、每份簡報可自訂的顯示字型（預設 Charter）搭配 Manrope 正文字型，強調效果透過細線和字重來實現，而非彩色條塊，並以 pptx 格式為主要交付方式。此系統的設計初衷是為了摒棄現在普遍被視為AI設計特徵的模式 — 溫暖的奶油色底色、全篇僅使用一種字型、單邊強調條、眉毛形狀的標籤、過大的章節數字。抗粗製濫造的姿態已融入其 DNA：請參閱 references/anti-slop.md（與簡報相關的「粗製濫造」分類目錄）和 scripts/deck_qa.js 中的靜態檢查。

規範性參考實作是 assets/reference-build.js — 一個完整、經過渲染測試的 pptxgenjs 範例。可以打開它來比對幻燈片意圖，然後複製其中的程式碼區塊。完整的配方庫、輔助函數和常見陷阱表單位於 references/build-helpers.md。

何時觸發

對於以下任何情況，都應主動使用此技能：

• 策略簡報、提案簡報、諮詢交付物、案例研究回應
• 董事會報告、高層簡報、路線圖簡報、轉型計畫
• 市場進入分析、診斷簡報、建議簡報、高階摘要
• 任何使用者提及「諮詢風格」、「MBB風格」、「麥肯錫風格」、「貝恩風格」、「BCG」或真實公司名稱的內容
• 任何需要品牌級別輸出且文案精確的、面向客戶的精緻簡報

工作流程

請依序執行以下步驟。前/後階段的抗粗製濫造檢查閘門是不可妥協的。

步驟 0 — 強制性抗粗製濫造前置檢查

此技能產生的文案必須經得起懷疑論者的檢視。在草擬任何投影片文案、備註、論點句子、背景說明或簡報文字之前，請先閱讀 references/anti-slop.md，以便根據那些會使簡報讀起來像是機器撰寫的AI特徵，來校準語言風格。

閱讀後，在草擬文案時請遵守以下限制：

• 不允許使用破折號，除非其具有你能夠辯護的特定作用（每頁最多一個）
• 零填充性流行詞彙（深入探討、善用、強健、無縫、變革性、範例、尖端、遊戲規則改變者，以及 anti-slop.md 目錄中的其他詞彙）
• 不允許使用否定平行結構（「不是X，而是Y」；「不只是A，更是B」）
• 句子少於 30 個詞；使用具體名詞和特定數字，避免抽象概念
• 使用行動標題，而非主題標題（最重要的規則 — 請參閱 slide_patterns.md）

即使結構工藝完美，一旦文案讀起來像是通用的諮詢AI產物，簡報的價值就會被大打折扣。此檢查閘門的目的就是為了防止這種情況發生。

步驟 1 — 說明簡報需求

在撰寫任何投影片或一行 build.js 程式碼之前，使用 AskUserQuestion（或在無法使用該工具時直接提問）進行兩次連續的詢問：

詢問 1 — 簡報設定：

1. 受眾 + 目標 — 誰會閱讀這份簡報？你希望他們做出什麼決定或採取什麼行動？
2. 簡報原型 — 診斷 / 建議 / 路線圖 / 市場進入 / 轉型 / 提案 / scqa / scr / bluf / 歸納 / 問題樹 / 演繹。簡報可以是單純型（全篇使用一個原型）或分層型（一個主幹原型搭配章節級別的覆蓋）。如果是分層型，請決定哪個原型運行哪些投影片範圍，並遵守此決定；不要將其簡化回單一形式。
3. 輸出格式 — pptx / html / md / gamma / briefing（可複選；預設：pptx）

詢問 2 — 品牌 + 視覺簡報：

1. 配色方案 — 根據意圖詢問（僅強調色；亮白底色 + 冷色中性色保持不變）。提供：松綠 12564A（預設；冷靜、現代、成長） / 石板藍 1F3A5F（企業、金融、信任） / 牛血紅 6E1423（正式、權威） / 客戶色碼（品牌鎖定的工作）。選擇會設定 ACCENT，並衍生出 ACCENT_DK（約 70% 亮度）+ TINT（約 8% 疊加在白色上）+ TINT_BORDER。牛血紅的淡色調會略帶粉紅 — 如果選擇了它，請將其調暖。經過驗證的方案值位於 design_system.md §1。
2. 標題字型 — 根據意圖詢問（正文字型保持 Manrope；只有標題字型會改變）。提供：Charter（編輯風格的襯線字型，預設，到處都能良好渲染） / Manrope Bold（現代，全無襯線） / Palatino（溫暖的襯線字型） / Baskerville（正式襯線字型；在 PowerPoint/Google Slides 中效果最佳，在 LibreOffice 預覽中較弱）。選擇會設定 DISPLAY，對於全無襯線選項則會設定 DISPLAY_BOLD=true。任何已安裝且有特色的字型都可以，只要它不在過度使用的清單中（Inter, Roboto, Fraunces, Geist, Plus Jakarta, Space Grotesk）。選擇全無襯線意味著刻意接受了單一字型家族的建議 — 請參閱 references/anti-slop.md。
3. 品牌 + 內容簡報 — 客戶/公司名稱、簡報者、日期，以及一個粗略的逐頁構想（即使只是條列式筆記也沒問題；Claude 會將其結構化）。

結構化綱要位於 assets/inputs.example.json。投影片數量不是必需的輸入 — 讓它根據內容訪談和原型來決定。對於高階簡報，預設為 8–12 頁；對於更深入的分析，預設為 15–18 頁；對於主簡報綜合，則為 26 頁以上。

在觸碰任何建構腳本之前，先根據答案編寫 inputs.json。將輸入與建構腳本分開，意味著同一個腳本可以處理未來所有簡報。

步驟 1.5 — 強制性：在撰寫任何內容草稿前建立鬼魂大綱

在填充投影片主體、面板、圓點、甘特圖行或任何文案之前：先輸出一份鬼魂大綱版本的 inputs.json，其中僅包含：

• title_slide 已填寫
• slides[i].breadcrumb、slides[i].title、slides[i].context 已填寫（標題必須是行動標題 — 請參閱 slide_patterns.md 中的通用慣例）
• slides[i].layout 已選擇（Claude 從依原型篩選的池中果斷選擇）
• 所有 slides[i].content 區塊保持為空 {} 或僅包含存根欄位名稱

將鬼魂大綱以表格形式呈現，包含以下欄位：# | 章節 / 原型 | 麵包屑導航 | 行動標題 | 版面配置 | 背景說明（一句話） | 主要視覺 / 數據（5 秒測試）。

章節 / 原型 欄位使得分層結構一目了然。對於單純型簡報（全篇使用一個原型），每一行都攜帶相同的值（例如 — / diagnostic）。對於分層型簡報，該欄位會說明投影片所屬的章節以及該章節運行的原型 — 例如 Build case / inductive、Sequence play / roadmap、Close ask / bluf。章節邊界在視覺上變得明顯（相鄰行共享一個章節標籤；變更處即為分界點）。

然後使用 AskUserQuestion（或直接提問）提出以下問題：

1. 敘事弧線在各章節之間是否成立？（全部批准 / 修改特定投影片 / 重大重構）
2. 是否有任何標題沒有陳述「所以呢？」？（列出需要修正的投影片編號，或「全部沒問題」）
3. 是否有任何版面配置選擇對於其投影片的功能來說感覺不對 — 包括其版面配置與該投影片所屬章節原型衝突的情況？（列出投影片編號，或「全部沒問題」）
4. 是否有任何背景說明或視覺描述缺少關鍵細節？（列出投影片編號，或「全部沒問題」）

在獲得明確批准之前，請不要開始草擬任何主體內容。如果使用者要求更改，請更新鬼魂大綱表格並重新提問 — 在使用者表示「全部沒問題」或同等意思之前，請勿進入步驟 1.6。

為什麼要這樣做：丟棄 10 個投影片標題比丟棄 10 張完成的投影片要快得多。金字塔原理 / SCQA 結構化討論在此處，以低成本版本進行。跳過此步驟是完成後簡報需要重做的最常見原因，也是稀疏的英雄投影片潛入本該是密集實用模式的位置的原因。

在鬼魂大綱內部選擇模式： Claude 會從依原型篩選的池（scripts/pattern_filter.js --archetype=<value>）中果斷選擇版面配置。僅當兩個模式在內容適配性上真正難分軒輊，或使用者先前已表達過品味偏好時，才使用 AskUserQuestion 來引出選擇。對每張投影片進行細粒度的選擇會導致每份簡報產生 10–12 次強制提問，但品質並無相應提升；應避免這種做法。

單調性防護（選擇性挑選器）： 在填充版面配置欄位時，掃描是否有兩張或更多相鄰投影片會共用相同的視覺語彙 — 最常見的是水平條（請參閱 references/slide_patterns.md →「在相鄰投影片之間變化條形圖的表現手法」）。當發現連續使用相同語彙時，請自行變換處理方式，或為重複的投影片提出預覽挑選器：一個 AskUserQuestion，首先推薦一個版面配置（標記為 (推薦)），然後提供 2 個渲染安全的替代方案，每個選項的 preview 欄位都附有簡短的 ASCII 迷你版型圖，以便使用者根據圖像而非模式名稱進行選擇。這維持選擇性 — 它僅在檢測到重複、真正的平局或使用者詢問「我有什麼選項？」時觸發，而不是在每張投影片上。它是步驟 4.5 變體模式的廉價對應物：在使用者選擇之前，什麼都不會建構。

僅當使用者已經提供了完整的 inputs.json 或明確表示「跳過鬼魂大綱」時，才可以跳過步驟 1.5。否則，它是不可妥協的。

步驟 1.6 — 逐張投影片建立的紀律（5 步驟）

對於每張投影片，請依此順序填入綱要。不要跳步。

1. 訊息傳遞 — 首先撰寫 slides[i].title。它必須是行動標題（「所以呢？」）。如果你無法寫出標題，表示你還不了解這張投影片的目的。
2. 結構 — 從支援該標題的目錄中選擇 slides[i].layout。預設使用密集的實用模式（diagnostic-three-panel、prioritisation-matrix、phased-roadmap-gantt、three-col-comparison、waterfall-baseline-to-target）。將稀疏的調味料（stat-row、big-numeral-findings）僅用作章節之間的橋樑，切勿作為簡報的主體。
3. 圖形 / 主要視覺 — 填入 slides[i].content。視覺元素應在 5 秒內可讀。對於矩陣：圓點位於何處？對於甘特圖：哪些工作流重疊？對於瀑布圖：哪個項目占主導地位？
4. 支援 — 填入 slides[i].context（一句話的背景框架）和 slides[i].footer_note（來源 + 注意事項）。這兩者在數據投影片上是不可妥協的。
5. 打磨 — 由 scripts/check_titles.js + 步驟 7 抗粗製濫造後置檢查 + 步驟 8 飛行檢查交付閘門處理。在交付前執行。

在訊息傳遞之前選擇版面配置，是稀疏英雄投影片潛入的原因。在版面配置之前選擇視覺元素，是圖表最終無法支援其標題的原因。在內容之前進行打磨，是浪費工作。順序很重要。

完整參考：references/methodology/slide_creation_process.md。

步驟 2 — 閱讀設計系統與模式

總是閱讀（每次建構），依此順序：

1. references/design_system.md — 鎖定的調色盤/字型/結構。沒有理由就不要偏離。
2. references/slide_patterns.md — 主模式目錄 + 通用慣例（行動標題、選擇性顏色、圖表誠實性、條形/柱形排序、直接標籤、按面積縮放的圓圈、頁尾紀律、瀑布圖特定規則）。
3. references/build-helpers.md — 調色盤常數、header()/title()/footer() 輔助函數、每個模式配方（§2.x）以及常見陷阱表單。每個建構的實作參考。assets/reference-build.js 是練習使用這些內容的工作範例。
4. references/methodology/content-interview.md — 內容訪談框架（情況 → 問題 → 假設 → 證據 → 論證 → 答案）。在觸碰任何建構腳本之前，執行第一階段。

按需閱讀（僅在觸發條件適用時）：

• references/chart-selection-guide.md + references/chart-library/ — 當投影片需要圖表時。由步驟 2.5 驅動；請勿預先載入。
• references/slide-job-to-layout.md — 在步驟 1.5 和 4.5 中選擇版面配置時使用，以使模式選擇可追溯而非直覺。
• references/raci-guidance.md — 在建構 RACI 或任何角色所有權投影片時使用。

如果使用者提供參考簡報或投影片作為比對，請從其縮圖中提取版面配置，並從其文字中提取章節結構。將任何外部參考僅視為結構參考：研究其建構方式，切勿複製其文字、數字或圖像。

步驟 2.5 — 圖表投影片：查閱圖表資料庫 + 圖表選擇指南

當投影片需要圖表（條形圖、折線圖、堆疊圖、雙面板圖、組合條形/折線圖、小多圖、瀑布圖、馬賽克圖）時，請不要即興創作。依序查閱兩個參考資料：

首先，references/chart-selection-guide.md — 頂部的快速選擇表將投影片的預期訊息映射到圖表類型。原則：圖表類型適合訊息，而非資料形狀。應用圖表特定提示（無 3D、直接標籤線條、條形邏輯順序等）。

…

[內容因原始輸入截斷而省略]