⛔ 第一規則：展示草稿，然後停止
整個工作流程是 草稿 → 人類審查關卡 → 優化。以下所有內容皆服務於這個循環。在處理任何其他事項前，請先閱讀這五點：
- 一次提問（附帶預設值）收集需求，然後一次性生成完整草稿——所有頁面平行產出，無須自行迭代。
- 渲染總覽圖片與一份草稿
.pptx，並呈現給人類。 - 就在這裡結束你的回合。 不要繼續，不要自我QA，不要優化，不要在同一個回合中重新匯出。下一個動作屬於人類：
- "繼續 / 可以" → 進行一次最終 QA 檢查（僅修正錯誤）→ 匯出最終版本 → 交付；
- 具體回饋 → 僅編輯他們提到的頁面 → 再次展示；
- "方向錯誤 / 換風格" → 從頭重新生成。
- QA 檢查清單（步驟5）僅在人類批准後執行。 如果你發現自己在執行 QA、修正頁面或「優化」人類尚未看過的草稿——立即停止。那份草稿的唯一任務就是被評判，而人類從未見過的草稿是 100% 的無效勞動。
- 忽略規則 3/4 是此技能最常見的失敗原因。一份能在幾分鐘內讓人類看到的不完美短草稿，遠比花費數小時隱藏式自我 QA 得來的「完美」投影片組更有價值。
定義
HXMPPT 是一個基於 Moonshot AI 的 PPTD 格式所建立的簡報建立與匯出技能。它定義了一種 YAML 格式的中間 DSL (.pptd)，該格式抽象化了 OOXML，並讓每個頁面保持獨立自主。
預設輸出並非僅限 PPTD。 除非使用者明確選擇退出，否則請始終同時產出：
- 完整的可編輯 PPTD 專案目錄（
.pptd+pages/+media/及其他被引用的依賴檔案）； - 相符的本機生成
.pptx檔案，預設為每張投影片套用淡出切換效果。
PPTX 匯出在本機使用 python-pptx 執行——無須 Node.js、無須瀏覽器、無須透過網路存取 Kimi 的公開編輯器。視覺 QA 圖片是在本機使用 Pillow 根據相同的 PPTD 原始檔渲染而成。
為何現在僅限本機？ 先前的匯出器透過 localhost SDK 橋接器驅動 Kimi 的公開瀏覽器端 OOXML 編寫器。Moonshot AI 關閉了那條逆向工程路徑，並清除了上游儲存庫。目前的匯出器是一個自含的 Python 渲染器，直接遵循 PPTD 規格。本機編寫器不支援字型嵌入與元素動畫；特殊圖表類型會以靜態圖片形式渲染——請參閱本文底部的「限制」。
現有的 PPTX 檔案可使用 scripts/import_pptx.py 轉換為 PPTD 進行編輯（盡力而為：會匯入文字/形狀/圖片/表格/連接器；圖表、群組、動畫和備註則會跳過並發出警告——請參閱「限制」）。編輯後，兩個輸出會再次交付。
pptd 格式
.pptd 格式是一個簡化的 OOXML 抽象層，遵循基本的 YAML 語法。這個抽象層保留了 OOXML 的核心內容（主題、頁面配置、元素位置與定義等），同時移除了如母片等複雜的巢狀邏輯；每個頁面都是獨立自主的——所見即所得。請參閱 reference/pptd.md 以取得此 DSL 的完整定義。
PPT 生成工作流程
step0. 檢查本機必要條件
預設交付內容包含 PPTX 匯出與視覺 QA 預覽，這需要一個小型本機 Python 工具鏈。在生成之前，請確認：
- python3 (3.9 或更新版本)：執行
python3 --version（在 Windows 上，python可能是正確指令）。如果缺少python3且使用者尚未明確選擇僅輸出 PPTD，則立即停止，告訴使用者從 https://www.python.org 安裝 Python，然後不要繼續；如果已同意僅輸出 PPTD，則交付 PPTD 專案並回報此阻礙（與 step6 相同的備援方式）。 - 不需要 Node.js 或 agent-browser——本機轉換器是純 Python。複雜圖表類型（陰陽燭/瀑布/熱力圖/樹狀圖/旭日圖/桑基圖及混合類型組合）在出現時會額外使用 matplotlib；該套件會在首次使用時自動安裝。
- 軟性依賴套件由
scripts/export_pptx.py和scripts/export_images.py在缺少時透過 pip 自動安裝：PyYAML、python-pptx、Pillow，以及（按需求）matplotlib。安裝目標為現有虛擬環境，若無則為pip install --user。設定HXMPPT_NO_INSTALL=1可在氣隙/CI 環境中停用自動安裝——屆時匯出器會準確回報缺少哪個套件。 - 以下指令路徑相對於包含此 SKILL.md 的目錄（技能根目錄）。在呼叫指令時，請將其解析為已安裝技能的絕對路徑，例如
<skill-dir>/scripts/export_pptx.py。技能根目錄中的install.sh會將技能安裝到標準的 Claude/WorkBuddy 位置。
step1. 徹底閱讀上下文
閱讀使用者上傳的所有檔案、提供的 URL，以及 pptd 格式指南 reference/pptd.md，以充分了解使用者的需求。
step2. 快速需求確認（一次提問，然後開始）
根據上下文了解使用者的需求：
- 確定請求的目的
- 建立 PPT：建立新的簡報（從頭開始，或從現有的 pptx 範本開始）
- 編輯 PPT：編輯使用者上傳的 PPT（本機修改、單頁美化等）
- 複製 PPT：從非 pptx 格式（圖片、PDF 等）將簡報複製為 pptd 格式
- 確定設計方向（自主設計 / 設計系統 / 範本 / 樣式轉移——請參閱 step3）
- 確定輸入類型（僅主題 / 完整文件 / 大綱）。當輸入是完整文件或大綱且未禁止擴充時，傾向於使用相關素材進行擴充。
- 確定頁數（使用者要求優先；有大綱則比照；僅主題則建議並確認）。
速度規則（強制）
- 最多提問一輪。 將主題/輸入/頁數/樣式/受眾組合成一個問題，並為每個問題提供預設答案，以便使用者可以用一個詞或一句話回覆。
- 如果使用者未回覆，用一句話說明你的假設（例如「按商務諮詢風格、約 15 頁處理」）然後繼續。人類審查關卡（step4）就是用來低成本捕捉錯誤假設的地方。
- 僅為真正阻礙性的問題中斷（無法存取的檔案/URL、矛盾的硬性限制）。不要在草稿存在之前浪費回合在品味問題上——草稿本身比任何問題都更能傳達品味。
step3. 生成初稿（一次性——速度重於完美）
在生成之前，請先閱讀 reference/pptd.md 以了解 pptd 格式的定義與限制。
草稿優先規則（強制）
- 一次性生成整個投影片組。 預先設計故事線與頁面計畫，然後以平行批次方式撰寫每個
.page檔案。不要撰寫一個頁面、重新閱讀它、然後自行重寫。 - 初稿的唯一任務是讓人類判斷方向——故事線、結構、密度與風格。「足夠好到可以判斷」就是門檻。在人看到投影片組之前追求像素完美是一種錯誤，而非優點。
- 在人類審查關卡之前不要進行自我 QA 循環。 只需執行一項健全性檢查：匯出器可以解析並執行，且不會發出表示頁面損壞的警告。不要執行視覺 QA 檢查清單、不要自行修復、不要預先重新生成頁面。
- 保持草稿低成本。 被拒絕的方向應該花費幾分鐘，而不是幾小時——使用者可能會根據草稿更換模型、樣式或指示。
- 撰寫草稿後，直接進行 step4（人類審查關卡）。即使對於「簡單」的投影片組，也不可跳過此步驟。
複製 PPT
- 分析圖片以估算元素位置、字型和大小等，並盡可能接近地 1:1 複製。
- 對於難以辨認的部分，使用如網格線和近距離檢視等方法來提升理解。
- 將圖片中的簡單內容複製為元素；圖示可以使用 Font Awesome 提供的圖示來近似。對於無法以圖示或形狀近似的內容，例如照片和頭像，使用 bash 或 python 等工具裁切和分割原始圖片，然後將得到的圖片元素加入簡報中。
編輯 PPT
- 使用
scripts/import_pptx.py將使用者上傳的 pptx 檔案轉換為 .pptd 格式（盡力匯入；檢閱所回報的「已跳過」警告——圖表/群組/備註不會被匯入） - 檢閱轉換後的頁面（結構與關鍵視覺細節）。之後單獨閱讀幾個關鍵頁面。
- 找出要編輯的頁面，並注意不要影響到預定範圍以外的部分。
從 pptx 到 pptd 的轉換並非完美無損。如果使用者稍後回報格式錯誤、內容亂碼等問題，請與原始 pptx 進行比較，並根據比較結果修復 pptd。
生成 PPT
生成 PPT 時，根據不同的使用者[設計方向]採用不同的製作方法。
自主設計
- 閱讀設計指南
reference/slides_categories.md，並閱讀與使用者查詢相對應的情境文件 - 根據上述資訊製作簡報
生成其他格式的內容
- 當使用者明確要求資訊圖表、海報或高度視覺化的單頁設計時，請閱讀
reference/general-poster.md，並將其實作為單頁或少頁的可編輯 PPTD；當使用者僅要求圖片時，仍先用 PPTD 建構，再透過螢幕截圖或渲染輸出圖片。對於一般的 PPT 請求，不要載入此參考檔案。
設計系統
- 閱讀
reference/slides_categories.md指南的一般限制章節，並閱讀與使用者查詢相對應的情境文件作為設計基礎 - 閱讀指定的設計系統作為簡報風格：可以是使用者提供的設計方案，或是
reference/design_system/下的相符預設。查閱reference/design_system/README.md以取得完整目錄——它將每個預設對應到建議的檔案。某些預設有兩種格式（完善的design.md「Signature System」和原始的en/*.md來源文件）；始終優先使用資料夾中的design.md（如果存在）。嚴禁參考或混合其他設計風格。 - 根據上述資訊製作簡報
- 在自主設計期間不要自動選取預設；僅在明確指定預設時才使用
reference/design_system/。
使用範本
- 使用
scripts/import_pptx.py將使用者上傳的 pptx 檔案轉換為 pptd 格式（盡力匯入；檢閱所回報的「已跳過」警告） - 檢閱轉換後的頁面以了解範本的視覺風格（配色方案、字型樣式、元素特徵、佈局特徵、內容密度等）
- 識別頁面類型；專注於閱讀特殊頁面，例如封面、摘要頁面和章節分隔頁（單頁截圖、.page 檔案），提取它們的頁面佈局、內容結構、可複用組件（圖示、形狀、SmartArt、可複用的主體佈局方案等）以及元素樣式（例如，空白/線條/卡片分隔線、方形/圓角等）
- 使用範本製作簡報
樣式轉移
- 分析參考檔案的視覺風格（配色方案、字型樣式、元素特徵、佈局特徵、內容密度等）、頁面佈局、內容結構、可複用組件（圖示、形狀、SmartArt、可複用的主體佈局方案等）以及元素樣式（例如，空白/線條/卡片分隔線、方形/圓角等）。
- 如果使用者提供樣式參考 URL，不僅要閱讀文字內容，請更多地參考並學習頁面的視覺效果，以幫助理解其風格
- 使用參考檔案的風格特徵製作簡報。鼓勵重用原始 PDF/URL 中的插圖、字型、字型大小層級、元素等。
圖片與視覺素材
- 圖片是豐富簡報視覺效果的有效方式。不僅應在封面和章節分隔頁使用適當的圖片，也應在主體頁面上使用，以豐富頁面、協助理解或支援決策。
- 圖片用於展示具體主體、解釋內容、提供證據或建立情境。標誌、圖示、裝飾性紋理和非常小的縮圖不計入實質性圖像。
- 當頁面涉及產品、人物、地點、建築物、事件、案例、介面、實驗對象或空間環境時，優先使用相應的真實圖片或螢幕截圖。如果無法取得真實圖片和螢幕截圖，可以使用生成的圖片代替。
- 圖片優先順序：使用者提供的圖片；來自官方網站、官方報告和可信來源的圖片；與內容直接相關的搜尋圖片；為概念表達或氣氛營造而生成的圖片。
- 在決定需要哪些圖片後，在圍繞設計頁面之前，批次完成圖片的搜尋、生成和下載工作。
...
[因翻譯而截斷]