技能設計審查 是做什麼的？
目標
使用評估循環來判斷一個目標技能是否仍值得存在，它是否確實能改善任務執行，以及下一步應採取的最小變更是什麼。
寧可偏好具體的測試，而不是抽象的批評。預期結果應包含一個處置決定、一份完整的計分卡，以及一個針對性的行動：根據證據和使用者的編輯權限，決定要保留、簡化、合併、重寫、刪除或修補該技能。
輸入
在評分前，請收集或推斷以下輸入：
- 目標技能路徑或技能名稱。
- 兩個風格不同的實際測試案例。每個測試案例應包含使用者請求以及執行所需的任何輸入工件、檔案或上下文。
- 每個測試案例的預期輸出格式。
- 候選重疊項：任何可能使目標技能變得多餘的鄰近技能、內建功能、工具、腳本、模板或更高層級的指令。
如果使用者沒有提供測試案例，請根據技能的目的起草兩個實際案例，並說明這些是推斷出來的。
評估循環
-
檢查目標技能。 完整閱讀其
SKILL.md。僅在需要理解正在測試的工作流程時，才閱讀參考的檔案。 -
在改進之前先評估必要性。 判斷該技能是否提供了超越強大通用代理的持久價值。當一個技能至少能提供以下一項時，它才值得保留：
- 通用代理經常會忽略的非顯而易見的領域知識。
- 一個可重複的、能防止常見失敗的工作流程。
- 工具、腳本、資源、模板或檔案路由的知識。
- 必須在不同執行之間保持穩定的輸出標準。
- 組織特定的判斷、術語或流程記憶。
- 證據顯示使用該技能相較於不使用它的基線，能提升品質。
當出現以下情況時，應簡化、合併、重寫或刪除技能：
- 它只是重述了一般的推理模式。
- 基線代理在沒有它的情況下已經表現得同樣好。
- 它增加了冗長的指令，但沒有帶來可衡量的品質提升。
- 它與更高層級的系統/開發者指令衝突。
- 它主要是為了保留過時的工具行為或已廢棄的工作流程。
- 它與另一個更強大的技能有大量重疊。
-
準備測試。 使用兩個在語氣、具體程度或工件類型上不同的測試案例。至少包含一個普通請求和一個邊緣或模糊的請求。
-
執行基線比較。 對於每個測試案例，比較在沒有目標技能的情況下處理任務的方式，與在有目標技能的情況下處理任務的方式。如果因為技能已被讀取而無法進行乾淨的基線比較，請將基線標記為「盡力而為 / 受污染」，不要假裝它是獨立的。 當可獨立運行的子代理或全新任務可用且安全時，請將有技能的測試與基線測試分開執行。只傳遞目標技能、使用者請求和原始工件；不要傳遞預期的診斷或計劃的修復。
-
使用評分量規評分。 在分配分數之前，請閱讀
references/rubric.md。對技能必要性、觸發行為、工作流程指導、輸出格式和內容品質進行評分。對於每個非完美的分數，請附上簡短的證據。 -
選擇處置方式。 選擇恰好一種處置方式：
- 保留：該技能明顯改善結果，且成本不高。
- 保留但簡化：該技能有用，但包含過多的指令、較弱的範例或過時的細節。
- 合併：該技能有用，但主要應屬於另一個更強大的技能。
- 重寫：該技能在意圖上有價值，但結構不明確或具有誤導性。
- 刪除：該技能沒有提供超越基線的可衡量價值，或者已過時。
- 修補：該技能值得保留，並且只存在一個狹窄、影響重大的差距。
-
修訂並重新執行。 如果處置方式是「修補」、「保留但簡化」、「合併」、「重寫」或「刪除」，請在使用者允許的範圍內，進行最小、有證據支援的檔案變更。對於「合併」或「刪除」，除非使用者明確要求進行破壞性清理，否則不要移除內容；請改為建議精確的合併/刪除操作。 僅在證據顯示存在差距的地方修補目標技能，然後重新執行受影響的測試或量規檢查。記錄分數是否改變以及原因。 如果使用者禁止編輯或要求僅進行審查，請不要修補檔案。取而代之的是，描述最小的建議修補，並將受影響的標準重新評分作為一次乾運行預測，同時清楚標明實際檔案未更改。
輸出格式
按以下順序返回結果：
-
裁決 說明技能是通過、有條件通過還是失敗，並給出處置方式：保留、保留但簡化、合併、重寫、刪除或修補。
-
必要性評估 說明該技能提供的持久價值、與基線代理能力或附近技能的重疊情況，以及為何該技能應該或不應該繼續佔用上下文。
-
測試案例 列出兩個測試案例及其預期輸出格式。
-
計分卡 提供一個包含標準、分數、證據和修復方案的表格。
-
比較 總結有技能與無技能的差異。
-
針對性行動 描述所做的確切變更，或者，如果使用者要求僅進行審查，則建議最小的保留/簡化/合併/重寫/刪除/修補操作。
-
重新執行結果 說明修訂後發生了什麼變化，包括任何剩餘的風險。
判斷規則
- 當所有必要標準得分為 2 且總分至少為 9 分（滿分 10 分）時，通過。
- 當總分為 6-8 分或一個必要標準得分為 1 時，有條件通過。
- 當任何必要標準得分為 0 或總分低於 6 分時，失敗。
- 必要標準是：技能必要性、觸發行為、輸出格式和內容品質。
- 不要為了美觀而最佳化。更傾向於能讓下一個代理知道要做什麼、何時做以及要產出什麼的變更。
- 保持修訂範圍狹窄、可衡量，並與測試失敗相關聯。
- 當一個技能不再能產生相對於基線代理的可衡量提升時，寧可建議刪除或合併，也不要進行潤飾。