建立工作流程
工作流程是一個可重複使用的流程單元，將「用戶想要做的事情」轉化為「先做什麼、接下來做什麼、每個步驟使用哪個工具、以及它會產出什麼」。這個技能引導你從用戶需求出發，建立一個符合 docs/workflow/index.md 規範的 WORKFLOW.md 檔案。
建立前請先閱讀規範：docs/workflow/index.md（三層漸進式揭露、圖形步驟一對一對應、流程規則、工具呼叫慣例）。
使用時機
- 用戶要求「建立一個工作流程 / 流程 / 標準化流程」
- 用戶描述一個多步驟任務，希望將其固化為自動執行的流程
- 用戶要求修改或改進現有的工作流程
- 用戶在對話中做了可重複使用且多步驟的事情，並說「把這個流程固化下來」
建立流程
第一階段：理解意圖
先進行訪談，不要急著寫檔案：
- 它解決什麼任務？ 為任務類別命名（例如「程式碼審查」、「發行說明」）。
- 觸發場景：用戶何時會使用它？收集觸發詞（中文 + 英文）。
- 輸入與輸出：需要哪些輸入（檔案 / 目錄 / 字串）？會產出什麼（檔案 / 報告）？
- 現有步驟：用戶是否已經有習慣的流程？從對話歷史中提取工具呼叫序列、修正以及輸入 / 輸出格式。
- 邊界與規則：哪些事情不能做？產出物放到哪裡？如何處理失敗？
在進入下一階段之前，使用 ask_user 補齊遺漏的資訊。
第二階段：設計流程圖
使用 mermaid 繪製執行流程，遵循圖形步驟對應規則（規範 5.2.1）：
- 每個節點必須有對應的步驟章節；每個步驟在圖形中必須出現一次
- 節點名稱與步驟名稱完全一致，且在全域範圍內唯一（
step-N前綴不必出現在節點中） - 決策節點使用菱形
{}，也必須有步驟章節，並使用Branch說明每個分支的去向 - 並行步驟（分散）在圖形中為一個節點
- 圖形必須完整：開始、分支、結束
在撰寫步驟之前，先向用戶展示圖形以確認。
第三階段：撰寫 WORKFLOW.md
在 <workspace>/workflows/<名稱>/ 下建立目錄與檔案：
- frontmatter（第一層元資料）：
name：kebab-case，與目錄名稱一致，僅使用小寫字母 / 數字 / 連字符description：功能 + 使用時機 + 觸發詞（中文和英文），決定觸發頻率inputs/outputs：明確宣告，標記為必要version/tags：可選
- 概述：一段文字說明它的功能、使用時機以及產出物
- 流程圖：與第二階段一致的 mermaid 圖形
- 步驟：每個步驟一個
### <id>: <名稱>章節，包含屬性：Tools/Input/Depends on/Action/Check（決策節點加上Branch，可選when） - 流程規則：順序約束、資料依賴、驗證關卡、副作用約束、最終狀態檢查
- 工具呼叫慣例：優先使用內建工具，腳本作為備用方案，多讀少寫，路徑慣例
漸進式揭露：將長表格放在
REFERENCES.md，確定性邏輯放在scripts/，保持主體簡潔（少於 500 行）。
第四階段：自我檢查與驗證
撰寫完成後，對照規範檢查：
- 圖形步驟一對一對應：圖形中沒有「孤立」節點，章節中沒有「孤立」步驟
- 節點名稱唯一且與步驟名稱一致
- 每個步驟都有具體且可判定的
Check（例如「檔案存在且非空」，而不是「確認成功」） - 工具名稱精確（
read_file/exec，而不是「查看檔案」） inputs/outputs與步驟引用一致- 規則涵蓋失敗處理（重試 / 回滾 / 詢問用戶）
- frontmatter 的
description包含功能與觸發詞
使用 workflow_list 確認新工作流程已被發現，並使用 workflow_get <名稱> 驗證其可讀性。
第五階段：交付
告訴用戶：
- 工作流程名稱與路徑
- 觸發場景（什麼措辭會觸發它）
- 流程概述（多少步驟、決策 / 並行度）
- 可選：建議 2-3 個真實測試請求以驗證其運作
修改現有工作流程
- 先使用
workflow_get <名稱>讀取當前內容 - 保持 frontmatter 中的
name與目錄名稱不變 - 遵循相同的規範進行修改；編輯後執行第四階段的自我檢查
注意事項
- 僅寫入工作區
workflows/，絕不修改內建的唯讀工作流程；同名的工作區工作流程會覆蓋內建版本 - 一個工作流程解決一類任務；不要堆疊不相關的流程
- 步驟保持在 3-8 個；超出時拆分或引用子流程
- 絕不撰寫惡意或誤導性的指示；規則必須可稽核