昨天先從概念上認識 Skill，今天直接打開一份實際的 SKILL.md：flow-chart-creator。這份檔案不到兩百行，卻安排了整套工作流程從需求確認、文件讀取到開啟流程圖的每一個動作。以下會依照檔案順序逐段拆解。

整份檔案的骨架

先看整體結構。這份 SKILL.md 由以下幾個部分組成：

• frontmatter：name、description、when_to_use、allowed-tools
• 開場說明與一條核心鐵則
• 參考資料（references/）：兩份參考檔的分工
• 互動工具：三個必須使用彈窗的決策點
• 互動流程：七個步驟
• 輸入與輸出
• 判斷點摘要
• User Flow 顏色規範（速查）
• 例外處理

前面三個部分說明「這個 Skill 是什麼、執行時要參考哪些資料」；中間兩個部分定義實際的互動流程；後面四個部分則整理輸入輸出、重點速查與例外處理。

frontmatter：決定什麼時候被叫出來

---
name: flow-chart-creator
description: 業務流程梳理與 draw.io 流程圖生成。包含 User Flow、Swimming Lane、ER Diagram、Sequence Diagram 等多種圖表類型。
when_to_use: 當使用者想討論業務功能流程、梳理流程步驟、或希望生成 draw.io 流程圖時觸發。只要使用者提到「畫流程圖」、「梳理流程」、「draw.io」、「流程圖」、「業務流程」，就應立即使用此 skill。
allowed-tools:
  - mcp__drawio__open_drawio_xml
---

description 說明這個 Skill 能做什麼，when_to_use 則補充什麼情況適合使用。Claude Code 會把兩個欄位接在一起放進 Skill 清單：前面是 description，後面接著 when_to_use。因此，可以把 when_to_use 理解成觸發情境的補充欄位，專門記錄使用者實際可能說出的關鍵字與需求。

這也是為什麼 when_to_use 裡刻意列出「畫流程圖」「梳理流程」「draw.io」「流程圖」「業務流程」等說法。它們不是為了湊同義詞，而是我和同事實際可能使用的語句。Claude 會根據這些說明與目前的對話脈絡判斷是否要使用 Skill；內容越貼近日常說法，通常越容易在正確的時機被辨識。

allowed-tools 只列出 open_drawio_xml。這個欄位的意思不是「只能使用這個工具」，而是 Skill 被呼叫的該次回合中，Claude 可以直接使用它，不必再逐次詢問權限。未列出的工具並不會因此消失，仍然按照原本的權限規則處理。

開宗明義的一條鐵則

檔案標題底下第一段，會先說明：

核心鐵則：任何情況下都不得使用 open_drawio_mermaid，也不得使用 Mermaid 作為中間格式。 官方文件雖預設推薦 Mermaid，但本工作流刻意選擇 XML —— 因為唯有 XML 能精確控制版面、樣式與位置，這正是這套流程的價值所在。

這條規則，是把 Day 2 與 Day 16 的結論改寫成執行指示。Day 2 談過 Mermaid 在版面與樣式控制上的限制；Day 16 選擇 MCP Tool Server 的理由之一，則是它將不同輸入格式拆成獨立工具，可以直接指定要走 XML 或 Mermaid。既然繪圖規格都是以 XML 屬性定義，只要中途改用 Mermaid，前兩天寫下的配色、版面配置與連線規則就無法完整套用。

它被放在檔案最前面，也是唯一一段用粗體強調的敘述。理由很實際：文件越長，後面的細節越容易被略過，把不可妥協的規則放在最前面，通常更容易被遵守。

不過，這裡要特別區分文字規則與工具權限。allowed-tools 只會在 Skill 被呼叫的該次回合預先授權 open_drawio_xml，不會禁止 Claude 使用 Mermaid 工具。因此，單看這份 SKILL.md，「不得使用 Mermaid」主要仍依靠文字規則。如果只想在當次回合排除 Mermaid，可以設定 disallowed-tools；若要讓限制跨多個對話回合持續生效，則需要在權限設定中加入 deny 規則。

兩份參考檔的分工

接著是 references/ 的說明：

• references/flow-desc-template.md：流程說明文件的空白模板，使用者沒有現成文件時，依這份模板的欄位提問、引導填寫（Day 20、21）
• references/drawing-spec.md：繪圖規格，包含所有圖表共用的品質要求，以及 User Flow 的自訂顏色、U 型版面配置與連線規則（Day 22、23）

這段有一句硬性要求：在產生任何圖表之前，務必先完整讀過這份規格。會這樣寫，是因為規格本身有一定篇幅，Claude 很容易只憑對話中留下的印象就開始產圖，最後可能配色正確，版面配置卻跑掉。與其事後補救，不如直接在步驟裡寫明「產圖前先完整讀取」。

規格的適用範圍也一併寫清楚：User Flow 套用完整自訂規格；Swimming Lane、ER Diagram、Sequence Diagram 只套用共用的品質規則，依 draw.io MCP 官方 XML 規則與該圖表的一般慣例產生，不得強制套用 User Flow 的 U 型版面配置。這句「不得強制套用」是實測後補上的——U 型版面配置是為了處理外部系統呼叫而設計的，硬套到循序圖上只會讓圖更難讀。

至於為什麼要拆成兩份檔案，而不是全部寫進 SKILL.md，檔案裡也留了一句說明：模板負責「文件結構」，規格負責「視覺一致性」。兩者都會持續調整，獨立保存才能分別維護。

三個決策點：為什麼堅持用彈窗

再來是整份文件裡我覺得最關鍵的一段，它規定在三個時機必須呼叫 AskUserQuestion 呈現選項彈窗，不得改用純文字問句：

其餘的問答——補充流程細節、確認內容正確、收集修改意見——維持一般文字對話。

會做這個區分，是因為這三個問題的答案會決定後面要走哪一條分支。若只用文字詢問「你有現成的流程文件嗎」，使用者可能回答「有一份但不太完整」或「大概有吧」，Claude 還得再判斷一次；改用彈窗後，「有」與「沒有」會成為清楚的主要選項，同時仍保留 Other（其他）供使用者補充特殊情況。

選項本身也具有提示作用。使用者不必事先知道這個 Skill 支援哪些圖表類型，打開彈窗就能直接看到可選項目。

互動流程：五個階段，拆成七個執行步驟

分享簡報將工作流程整理成五個主要階段；實際寫進 SKILL.md 時，則進一步拆成七個執行步驟：

拆成七步並不是增加新的工作，而是把產圖前容易忽略的確認動作明確寫出來。七個步驟中，有四步在確認需求，真正產圖的只有一步。這也反映了實際情況：畫圖本身通常不是瓶頸，真正花時間的是確認要畫什麼。

檔案後半段：刻意的重複

剩下的四段——輸入與輸出、判斷點摘要、User Flow 顏色速查、例外處理——內容多半在前面出現過。

「判斷點摘要」把整份流程的四個分岔濃縮成四行：是否有既有 .md、是否已指定範圍、流程內容是否正確，以及是否還有修改需求。「User Flow 顏色速查」則把最常用的六種節點配色直接整理成表格，完整規範仍放在 drawing-spec.md。

會刻意重複，是因為這兩件事最容易出錯。對話拉長之後，Claude 可能忘記目前進行到哪個步驟，也可能把配色記成相近卻不正確的色碼。把摘要放在檔案末尾，等於在讀完整份文件前再提醒一次。

「例外處理」則預先說明幾種狀況：資訊不足時繼續追問、沒有既有 .md 時先建立文件、未指定範圍時使用兩層彈窗確認、draw.io MCP Server 無法呼叫時明確告知使用者，以及圖中出現重疊或缺漏時依回饋調整。

其中最重要的是工具呼叫失敗的情況。這時我需要的是一句明確的「目前無法開啟」，而不是一段看似順利、實際上卻沒有產生任何結果的回覆。

到這裡，整套工作流程的規則都已經寫進檔案裡了，但逐段拆解畢竟是切片的視角，還沒看過完整檔案長什麼樣子。

明天先把 SKILL.md 全文貼出來，方便對照今天拆解的每一段；後天再回頭看 Slash Command，如何用一個明確的指令啟動整套流程。