在此儲存庫中設定 coder-eval
目標：為使用者留下一個包含一個真實任務的任務目錄，讓他們可以立即執行，而非空的模板。此任務必須實際測試此儲存庫所提供的功能。
使用者的請求為：$ARGUMENTS
步驟 1 — 檢查必要條件
執行 coder-eval --version。安裝此插件並不會一併安裝 CLI，而後續所有步驟都依賴它。
如果缺少 CLI，請遵循 ${CLAUDE_PLUGIN_ROOT}/reference/cli-setup.md 的操作說明：提供安裝選項，執行前務必先詢問使用者，並在安裝後使用 coder-eval --version 確認。絕對不要在未經提示的情況下安裝，如果使用者拒絕，則不要繼續。
該參考文件也涵蓋了版本檢查的另一部分：此專案是否鎖定了某個 coder-eval 版本，以及當已安裝版本與其不符時該如何處理。
步驟 2 — 檢查此儲存庫是否已設定完成
此技能用於建立第一組測試套件。如果對一個已擁有測試套件的儲存庫執行此技能，它會將「第一個任務」寫在現有任務樹旁邊並報告成功 — 因此請在寫入任何內容之前先確認狀況。
根據 ${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md 找到評估任務樹的位置。如果儲存庫已有任務，請報告庫存清單並停止：包含任務檔案數量與位置、執行目錄數量，以及是否有實驗目錄。然後引導使用者使用操作現有項目的技能：
/coder-eval:lint-tasks用以檢視已有的任務；/coder-eval:analyze用以讀取已完成的執行結果。
只有在儲存庫完全沒有任務，或使用者看到庫存清單後明確要求增加更多任務時，才建立新的任務結構。無論使用者要求為何，絕對不要覆寫現有的任務檔案；僅能在旁邊新增。
一個有任務但沒有實驗目錄的儲存庫是部分設定完成的狀態，而非完全空白。請如實報告此狀態並提供缺少部分的選項 — 不要像完全空白一樣建立第一個任務。
步驟 3 — 掃描可測試的項目
請依優先順序尋找以下項目，並在寫入任何內容前先報告你的發現：
- Claude Code 技能 — 使用 glob 模式
.claude/skills/*/SKILL.md和**/skills/*/SKILL.md搜尋。技能是最有價值的評估項目，因為它們是否被觸發在失敗前是看不見的。如果找到任何技能，建議對每個技能使用/coder-eval:check-skill— 那是專為此目的建立的活化測試套件，不應在此手動建立。 - MCP 伺服器 — 尋找
.mcp.json、package.json或pyproject.toml中的mcpServers鍵，或伺服器進入點（註冊了工具的server.py/index.ts）。記錄它暴露了哪些工具。 - CLI 進入點 —
pyproject.toml中的[project.scripts]、package.json中的bin或scripts，或含有可用目標的Makefile。
如果此儲存庫是一個包含許多技能或套件目錄的 monorepo，請限制掃描範圍並詢問應專注於哪個子樹，而不是報告數十個候選項目。
如果在這三個類別中都找不到任何內容，請明確說明。然後提供一個最小但有用的替代方案 — 建立一個執行儲存庫中現有腳本或測試指令並檢查其輸出的任務 — 而不是建立一個證明不了任何事情的空白套件。
步驟 4 — 建立一個真實任務
將任務寫入步驟 2 所解析的任務樹中。如果儲存庫中沒有任何任務樹，請提出一個位置並詢問使用者。步驟 2 的「永不覆寫」規則在此仍然適用 — 這是該規則唯一存在的地方。
根據步驟 3 的發現，建立一個任務：
- CLI — 一個提示要求執行 CLI 某項功能的任務，其標準應檢查結果檔案的內容，而不僅僅是檔案是否存在。
- MCP 伺服器 — 一個使用特定工具並驗證其效果的任務。
- 技能 — 改為引導使用
/coder-eval:check-skill；活化測試套件與能力測試任務的形態不同，該技能可以正確建立它。
提示用於指導，標準用於驗證。不要在提示中重複標準要檢查的內容 — 一個提示說「確保檔案包含 X」測試的是閱讀理解能力，而非實際能力。
在撰寫標準之前，請閱讀 ${CLAUDE_PLUGIN_ROOT}/reference/task-rubric.md。這是檢查任務是否可能因錯誤原因而通過的共用清單，而你在這裡建立的這個任務將會是此儲存庫中所有後續任務的範例 — 因此值得一次做好，而不是之後再修正。關於標準類型及其欄位，請閱讀 ${CLAUDE_PLUGIN_ROOT}/reference/criteria.md。
如果使用者在此任務之後想要更多任務，請使用 /coder-eval:task；它提供相同的撰寫流程，並接受自然語言簡介。
步驟 5 — 環境變數
將所選代理程式所需的變數（例如預設的 claude-code 代理程式需要 ANTHROPIC_API_KEY）寫入 .env.example — 建立此檔案或在其中附加。
絕對不要寫入 .env：它可能已經包含真實的機密資訊。如果 .env 不存在，請檢查它是否被列在 .gitignore 中，然後再建議使用者建立它；如果沒有被忽略，請明確告知。
步驟 6 — 驗證
執行 coder-eval plan <任務目錄>/*.yaml 並反覆進行，直到它返回退出碼 0。這會透過真實的模型驗證任務的結構定義，因此任何猜錯的欄位名稱都會在此顯現。plan 接受的是任務檔案：直接傳入目錄參數會被直接拒絕（Expected a YAML task file but got a directory），因此請始終傳入明確的路徑或使用 glob 模式。不要建議使用無參數的 coder-eval plan — 零參數的發現功能僅在 coder-eval 原始碼目錄中有效，在其他任何地方執行都會返回退出碼 1。
空目錄或沒有任務的目錄並不代表有意義的成功 — 如果 plan 報告沒有任務，請將其視為建立失敗，而非通過。請注意，傳入目錄的錯誤是不同的結果：那表示你傳入了錯誤的參數類型，而非建立的任務是空的。
步驟 7 — 報告
告知使用者：
- 你在掃描中發現了什麼，以及你選擇先評估哪一項；
- 執行的確切指令：
coder-eval run <路徑>，並附上一段說明：執行此指令會消耗真實的 token，並且需要步驟 5 中的憑證； - 如果此儲存庫提供了技能，下一步是
/coder-eval:check-skill； - 之後可以使用
/coder-eval:analyze讀取執行目錄，而/coder-eval:ci則可以將此測試套件轉換為 GitHub Actions 的閘門。