create-skill-test

create-skill-test 技能總覽

create-skill-test 是一個用來搭建與驗證的輔助工具，專門協助你為 dotnet/skills 儲存庫中的 agent skills 建立 eval.yaml 測試檔。它的目標是提供一個可靠的技能測試起點，而不是一個泛用的「幫我寫測試」提示。它的主要工作，是把目標 skill、plugin 名稱與情境構想，整理成符合慣例且較不容易過度擬合的測試結構，包含 fixtures、assertions 和 rubrics。

create-skill-test 最適合已經知道要評估哪個 skill、但需要快速產出一個符合儲存庫規則的測試檔的人。如果你的需求只是想跑測試、排查 validator 失敗，或從零撰寫 skill 指令，這個工具的效益就比較有限。

create-skill-test 的用途

當你要建立新的 eval 檔、替既有 eval 補充更多情境，或確認你的 rubric 是否過度綁定某一種固定輸出時，都適合使用 create-skill-test。它特別適合 create-skill-test for Skill Testing 這類流程，因為測試設計的品質和 YAML 結構本身同樣重要。

create-skill-test 幫你避開什麼問題

它最大的價值，在於幫你避開脆弱的 eval：缺少必要欄位、skill 路徑不一致、fixture 組織不佳，以及 rubric 用詞不小心獎勵了某種寫法，而不是實際行為。若你希望測試在目標 skill 演進後仍然維持可用，這些都非常關鍵。

create-skill-test 不取代什麼

它不能取代 skill-validator，也無法協助你編輯 SKILL.md 檔案。如果你的目標是診斷壞掉的測試執行，或除錯 validator 輸出，這就不是正確工具。

如何使用 create-skill-test 技能

安裝並開啟來源 skill

使用 npx skills add dotnet/skills --skill create-skill-test 安裝 create-skill-test。接著先閱讀 SKILL.md，因為那裡會說明工作流程、輸入需求，以及哪些條件會決定你的請求是否有效；在你要求模型產生任何內容之前，這些資訊都很重要。

提供正確的測試簡報

一個好的 create-skill-test install 請求，不只是「幫我做一個測試」而已。你要提供 skill 名稱、plugin 名稱、想驗證的行為，以及任何情境限制。這個 skill 預期的輸入，會像 plugins/<plugin>/skills/ 下面的目標 skill 那樣具體，所以命名精確度很重要。

較好的簡報會像這樣：

• Skill: foo-bar
• Plugin: dotnet-msbuild
• 目標：驗證 agent 能建立有效摘要，並拒絕不支援的路徑
• 情境：第一次使用者，只有部分上下文
• Fixture 需求：一個最小輸入檔與一個邊界案例檔

這樣的內容能讓 create-skill-test usage 流程有足夠結構，產出有用的 eval，而不是泛泛而談的版本。

閱讀真正有影響的儲存庫區段

先看 SKILL.md，再檢查附近是否有 README.md、AGENTS.md、metadata.json，以及 rules/、resources/、references/ 或 scripts/ 資料夾。若這些資料夾存在，也都應一併查看。在這個儲存庫快照中，只有 SKILL.md 有被揭露，所以 skill 定義本身就是主要事實來源。

反覆調整情境與 rubric

先用第一版確認測試是否真的在衡量你想要的行為。如果 rubric 獎勵的是措辭而不是結果，就把標準收緊。如果情境太寬，就拆開來寫。如果這個 skill 只需要一條順利路徑，就讓 eval 保持精簡，不要硬加額外案例。

create-skill-test 技能 FAQ

create-skill-test 只適用於 dotnet/skills 嗎？

是，這個技能是依照 dotnet/skills 儲存庫的慣例與 plugins/<plugin>/skills/ 結構來設計的。你可以把概念移植到其他地方，但當你的儲存庫也採用相同結構與驗證預期時，create-skill-test 指南的價值最高。

我應該用它取代一般提示詞嗎？

當你想要一個可重複、結構較穩定、且較少格式錯誤的 eval scaffold 時，就該用 create-skill-test。一般提示詞也能描述測試，但在儲存庫特有慣例、fixture 擺放位置，以及過度擬合檢查這些面向上，通常會比較弱。

它適合新手嗎？

如果你能指出目標 skill，並用白話描述情境，那它就適合新手。若你連 plugin 名稱、skill 路徑或被測行為都說不出來，那它就不太適合新手，因為這些輸入會直接決定產出內容。

什麼時候不該用它？

不要把 create-skill-test 用在跑測試、除錯 validator 錯誤，或撰寫新 skill。這些都是相鄰但不同的工作流程，工具不同，成功標準也不同。

如何改善 create-skill-test 技能

提供更精準的輸入

create-skill-test 最好的結果，來自具體情境，而不是空泛目標。「測試 skill 在缺少上下文時能否回傳安全 fallback」會比「做一個完整 eval」更好，因為它清楚指出哪些行為重要、哪些內容不要過度給分。

要求 rubric 品質，不要只要 YAML

如果你只要求結構，最後可能得到一個技術上可用、但仍然過度擬合的檔案。你應該明確說出什麼算成功、什麼算失敗，以及哪些細節只是附帶資訊。這是提升 create-skill-test for Skill Testing 成效最快的方法。

產出後檢查是否過度擬合

檢視 assertions 是否獎勵單一措辭、固定順序，或某個精確的範例字串；除非這種精確度真的必要。好的 eval 應該衡量 skill 需要保留的行為，而不是某一次執行剛好產生的那一組字面用語。

依 validator 回饋再修正

如果第一版輸出驗證失敗，把完整錯誤訊息和前後相鄰的 YAML 片段一起回饋回去。這通常比把整個需求重講一遍，更容易得到更好的第二版。