triage

triage skill 概覽

triage 的用途

triage 是一個 GitHub issue 分流 skill，用來把新進 issue 透過以角色為基礎的狀態機往前推進。它能幫你分類回報、判斷是否還需要更多資訊，並把工作分派給 AFK agent 或人工維護者。如果你需要一個用於 Issue Tracking 的 triage skill，這個 skill 的目的就是減少猜測，讓 issue 處理流程保持一致。

最適合誰使用

如果你正在管理大量 issue、想要可重複的收件流程，或需要一套有結構的方法把混亂的 bug 回報轉成可執行工作，就很適合使用 triage skill。當你需要先把 bug 和 enhancement 分開，再把各個 issue 送往 needs-triage、needs-info、ready-for-agent、ready-for-human 或 wontfix 時，特別有幫助。

它的差異在哪裡

最大的差異在於明確的狀態機與角色紀律。這個 skill 不只是「把 issue 總結一下」；它要求你只能指定一個 category role 和一個 state role，而且還有一個硬性規則：每一則 triage comment 或 issue 訊息都必須以 disclosure disclaimer 開頭。如果你需要可預期的輸出、符合政策意識的路由，以及能順利交接給另一個 agent 的 triage 流程，這點就很重要。

如何使用 triage skill

安裝與先讀內容

使用以下指令安裝：

npx skills add mattpocock/skills --skill triage

安裝 triage 後，先讀 SKILL.md，再讀 AGENT-BRIEF.md 和 OUT-OF-SCOPE.md。這些檔案會說明耐久型 brief 格式，以及被拒絕構想的記錄方式；這兩部分最容易影響實際 triage 品質。這個 repo 沒有額外的 helper scripts 或參考資料夾，所以這三個檔案就是實務上的核心。

給 skill 正確的輸入

triage 的使用效果最好是在你提供 issue 標題、內容、既有 labels，以及這次 triage 的明確目標時。好的輸入會告訴 skill 你要的是分類、補充資訊、agent brief，還是最終拒絕決策。

好的 prompt 形式：

• “Triage this GitHub issue. Classify it as bug or enhancement, choose the correct state role, and say whether it should go to an AFK agent or stay with a human.”
• “Here is the issue thread and current labels. Apply the triage state machine and draft the comment with the required disclaimer.”
• “This looks under-specified. Determine whether it belongs in needs-info or ready-for-agent, and explain the missing acceptance criteria.”

用流程，不要只看標籤

實用的 triage 原則是把輸出當成路由，而不是分類學。先確認這是 bug 還是 enhancement，再檢查它是否已經具備可執行性、是否卡在回報者補充資訊、或是否明確超出範圍。如果它已經可以交給 agent 處理，brief 應該描述行為預期與驗收條件，而不是檔案路徑或實作步驟。

注意 repo 規則

有兩個細節會明顯影響輸出品質：disclaimer 規定，以及「只能有一個 category role 加上一個 state role」這條規則。如果 issue 的狀態有歧義，skill 會要求先標出衝突並請維護者確認，再做其他變更。這時候最正確的做法是先停下來釐清，而不是硬塞一個標籤。

triage skill 常見問題

triage 只適用於 GitHub issue labels 嗎？

不是。這個 skill 是以 GitHub 風格的 issue tracking 為基礎，但核心工作其實是判斷 issue 狀態並進行工作路由。如果你的 tracker 使用不同的 label 字串，仍然要先對應到 canonical roles，再依你的系統執行。

我已經會寫一般 prompt，還需要 triage 嗎？

一般 prompt 可以分類單一 issue，但 triage skill 多了可重複使用的狀態模型、brief 撰寫模式，以及明確的 out-of-scope 處理。當你想在很多 issue 上保持一致決策，而不是一次性的摘要時，這些能力就很有價值。

triage 適合初學者嗎？

適合，只要你已經懂基本的 issue labels。triage skill 比自己寫一個客製 policy prompt 更容易上手，因為它會直接告訴你有哪些狀態，以及每個轉換代表什麼。初學者最常犯的錯誤，是跳過 issue 上下文，只丟一個沒有內容、沒有討論紀錄、也沒有目前狀態的標籤要求。

什麼情況下不該用 triage？

不要把 triage 用在深入的實作規劃或 code review。它是用來做收件、路由，以及 readiness 判斷的。如果 issue 已經有完整規格，而你需要的是設計或寫碼協助，那麼其他 skill，或直接的實作型 prompt，會更適合。

如何改進 triage skill

提供更完整的 issue 上下文

當你加入完整的 issue 內容、可見留言、目前 labels，以及任何維護者備註時，triage skill 的表現會更好。只有標題通常會導致路由品質偏弱，因為 skill 無法判斷這個回報是否可重現、是否已被回覆，或是否缺少關鍵細節。

明確要求你真正需要的決策

如果你的目標是 “ready for agent”，就直接這樣說。如果你的目標是 “should this be closed as wontfix”，也請直接指出。最好的 triage 用法是清楚劃定決策邊界，這樣 skill 才能針對正確狀態最佳化，而不是產出一份泛泛的總結。

提升交接品質

當 issue 被移到 ready-for-agent 時，請求一份 agent brief，並用可長期沿用的語言寫出行為、限制與驗收條件。除非你真的需要，不然不要要求逐檔案的實作指示；repo 指南偏好行為契約，因為它們較能抵抗程式碼庫變動。

針對第一輪結果迭代

如果第一次 triage 太保守，可以補上三種資訊中的一種再重做：重現步驟、預期行為與實際行為的差異，或這個 issue 對使用者為何重要。這些細節常常會決定 issue 應該進 needs-info、ready-for-human，還是 wontfix，也會讓 triage skill 在第二輪判斷時更果斷。