組織稽核轉任務管理 是做什麼的？
手動完成這項工作需要半天時間：閱讀冗長的稽核報告，判斷哪些發現應該歸為一組，為每個任務撰寫優先級與完成定義，然後手動輸入到追蹤系統。此技能負責「閱讀」與「輸入」，但「決定權」始終保留給使用者。
步驟 1：執行前先詢問
一次以一條訊息提問並等待回覆：
- 哪個組織（CLI 別名）？確認它不是客戶的正式環境，除非該專案允許對該環境進行唯讀掃描。
- 任務要建立到哪裡？ClickUp（哪個清單）或 GitHub（哪個儲存庫）。檢查對應的 MCP 伺服器是否已連線；若未連線，則停止並說明如何連線。
- 任務的擁有者是誰？指定負責人名稱，或保留為未指派。
- 有哪些需要排除？部分發現可能是已知且已被接受的問題。現在說清楚可以避免後續的干擾。
步驟 2：執行稽核
node audit.js --org <別名> --out ./out
產生 out/findings.md 與 out/findings.json。唯讀操作：所有呼叫皆為查詢或列出指令。
步驟 3：整理任務
node to-tasks.js out/findings.json
產生 out/tasks.json：每個發現類型與嚴重程度對應一個任務，每個受影響的元件作為一個核取清單項目，較長的群組會拆分為每組 25 項，並包含優先級、工作量、標籤與驗收標準。
步驟 4：與使用者一同審查
以表格型式顯示任務清單：關鍵字、標題、優先級、工作量、核取清單項目數。接著進行腳本無法判斷的調整：
- 根據團隊工作模式，合併或拆分分組不當的部分。
- 刪除使用者在步驟 1 中說要排除的發現。
- 標出看似微小但實際上重要的問題（例如擁有「修改所有資料」權限的整合使用者，既是安全問題也是變更控制問題）。
- 在團隊有自己的完成定義時，改寫驗收標準。
在使用者確認清單正確之前，不得建立任何任務。
步驟 5：建立任務
透過已連線的 MCP 伺服器建立每個已批准的任務，或者針對 GitHub 使用 node create-issues.js --repo owner/name（先用 --dry-run 預覽），包含標題、描述、優先級、標籤、核取清單（ClickUp 核取清單或 GitHub 任務清單內嵌於內容中）以及驗收標準。將每個已建立任務的 URL 記錄回 out/tasks.json 的 url 欄位。
接著回報：建立了多少個任務，在哪個系統，以及從步驟 2 到最後一個任務建立的總耗時。
規則
- 稽核絕不對組織進行寫入操作。
- 未經清單批准不得建立任何任務。
- 任何離開專案資料夾的檔案中不得包含客戶名稱。
- 若任務系統呼叫失敗，請停止，回報哪些已建立、哪些未建立，且不要盲目重試。