run 是一項用於 Claude 的 AgentHub orchestration 技能，可觸發 /hub:run 來初始化任務、產生 agents、評估結果，並合併勝出的方案。適合用在可量化的程式碼改善，或需要評審比較的創意產出情境；使用時應明確提供 task、agent、eval、metric、direction 與 template 等參數。
此技能評分為 70/100，代表可收錄於目錄，但最適合已採用 AgentHub 工作流程的使用者。目錄使用者可以清楚看到指令觸發方式、範例，以及預期的端到端生命週期價值；不過 repository 證據除了 `SKILL.md` 之外偏少，未完整說明相依性、安裝方式或操作上的邊界情境。
- 觸發方式清楚：frontmatter 定義了 `command: /hub:run`，描述也說明可用於 `/hub:run` 或完整的 AgentHub competition execution。
- 提供具體使用範例，涵蓋最佳化、重構、測試覆蓋率與 LLM judge 情境。
- 將初始化、baseline 擷取、agent spawning、evaluation 與 winner merge 串成單一可由 agent 呼叫的指令，形成有意義的生命週期工作流程。
- 依賴更完整的 AgentHub 指令集（`/hub:init`、baseline、spawn、eval、merge），但此技能目錄項目僅包含 `SKILL.md`，沒有支援參考資料或安裝指引。
- 參數行為只有高層次說明；從 repository 證據中看不出邊界情境、失敗處理、metric 擷取格式與 judge mode 細節。
run skill 概覽
run skill 的功能
run 是一個用於 Claude 的 AgentHub 編排 skill，提供 /hub:run 指令。它能在單一請求中執行完整的競賽式流程：初始化任務、擷取 baseline、啟動多個 agents、評估各自輸出，並合併勝出的結果。當你希望用 agentic workflow 比較多種解法，而不是只要求一個直接答案時，就適合使用 run skill。
最適合哪些 AgentHub 使用者
run skill 最適合已經採用 AgentHub command pattern，並且想要用單一高階入口執行 multi-agent 工作流程的團隊。它適用於效能最佳化、重構、測試產生、錯誤修復，以及可量測的程式碼改善等工程任務。若使用 judge mode，它也能支援非程式碼的創意選擇，例如從多個候選版本中挑出最佳行銷文案。
安裝前的主要判斷點
如果你想要一個可重複使用的指令，把 AgentHub lifecycle 串起來，而不用手動呼叫 /hub:init、baseline capture、agent spawning、evaluation 與 merge 步驟，就可以安裝 run。但不要把它當成一般用途的自動化執行器：它的價值取決於任務是否能被評估或判斷，以及你的 AgentHub 環境中是否具備相關指令。
關鍵差異
一般 prompt 可能只是要求 Claude「嘗試幾種方法」，但 /hub:run 會給 agent 一個有明確參數的結構化 lifecycle：task、agents 數量、可選的 eval command、metric、optimization direction，以及 template。這種結構讓結果更容易比較、稽核與合併。
如何使用 run skill
run 安裝與 repository 檢查
使用你的 skill manager 從 repository 安裝此 skill，例如：
npx skills add alirezarezvani/claude-skills --skill run
接著先檢查 upstream file：
engineering/agenthub/skills/run/SKILL.md
這個 repository path 包含核心行為與範例。在提供的 tree 中，這個 skill 沒有可見的 companion scripts/、resources/、references/ 或 rules/ 資料夾，因此導入時主要取決於你是否理解 SKILL.md 裡的 command contract，以及是否已有較完整的 AgentHub command set 可用。
基本 run 使用模式
指令格式如下：
/hub:run --task "..." --agents 3 --eval "..." --metric metric_name --direction lower --template optimizer
重要參數：
--task：必填；agents 要競爭完成的確切工作。--agents：選填；來源範例中預設為 3。--eval：選填；用來衡量結果的 command。--metric：使用--eval時必填；要比較的數值。--direction：比較 metric 時必填；使用lower或higher。--template：選填；範例包含optimizer、refactorer、test-writer與bug-fixer。--judge：當沒有確定性 metric，需要由 LLM judge 比較輸出時很有用。
把粗略目標改寫成有效指令
較弱的請求是：
/hub:run --task "make it faster"
更好的 run 使用 prompt 是：
/hub:run --task "Reduce p50 latency in the product search endpoint without changing response schema" --agents 3 --eval "pytest bench.py --json" --metric p50_ms --direction lower --template optimizer
這個版本能提升輸出品質，因為它定義了目標範圍、保留了限制條件、提供 agents 可量測的 benchmark、指明 metric，並說清楚哪個方向代表勝出。若是測試覆蓋率工作，請使用越高越好的 metric：
/hub:run --task "Add tests for untested utils without modifying production behavior" --agents 3 --eval "pytest --cov=utils --cov-report=json" --metric coverage_pct --direction higher --template test-writer
合併前的建議工作流程
在重要程式碼上使用 run skill 前，請確認 repository 是乾淨的、測試可重現，而且 eval command 會回傳機器可讀或至少能穩定解析的輸出。先從 2–3 個 agents 開始，以控制成本與速度。程式碼任務盡可能使用 deterministic evals；--judge 則保留給文案或設計方案等主觀輸出。勝出結果合併後，仍然要手動 review diff；這個 skill 負責編排選擇流程，但不會取代程式碼 ownership。
run skill 常見問題
run 是用於 Agent Orchestration，還是單純 prompting？
run 是用於 Agent Orchestration。它的設計目的是協調多個 agents 走完整 lifecycle，並選出勝者。如果你只需要一段說明、一個重構建議或一份草稿，普通 prompt 會更簡單。當比較、評估與合併紀律很重要時，再使用 run skill。
run 要順利運作，必須先具備什麼？
你需要一個與 AgentHub 相容的設定，讓 /hub:run 和相關 lifecycle commands 能被辨識。對可量測的軟體任務來說，你也需要可靠的 eval command、清楚的 metric name，以及已知的 optimization direction。缺少這些條件時，指令可能仍可用 judge mode 執行，但結果會比較不客觀。
什麼情況應該避免使用這個 skill？
對於沒有驗收條件的模糊任務、沒有 rollback plan 的破壞性變更，或測試與 benchmarks 不穩定的專案，應避免使用 run。也不要預設使用過多 agents；如果任務定義不清楚，更多 agents 可能只會增加成本與 review 負擔，不一定提升品質。
run skill 適合初學者嗎？
如果你已經理解 command-style Claude skills 與基本 AgentHub 概念，run skill 算是容易上手。初學者可能會卡在 eval parameters，特別是 --metric 與 --direction。建議先用 judge mode 處理低風險的創意任務，或在嘗試效能、重構、重度合併流程之前，先用簡單的 test command 練習。
如何改善 run skill 的使用效果
用更清楚的任務邊界改善 run skill 結果
run skill 在任務範圍窄到 agents 能各自獨立完成時表現最好。請包含目標檔案、預期行為、限制條件，以及哪些內容不能變更。例如「Refactor auth module」可以接受，但「Refactor src/auth/session.ts to reduce duplication while preserving public function signatures and existing tests」能給 agents 一個更安全的操作範圍。
強化 evals 與 metrics
對程式碼任務來說，eval command 是最重要的品質槓桿。優先使用會明確失敗、並產生穩定 metric 的 commands。請將 metric 搭配正確方向：latency 與 error count 通常使用 lower；coverage、throughput 或 score 通常使用 higher。如果 eval output 含糊不清，即使 agents 產出有用的成果，merge decision 也可能變得不可靠。
留意常見失敗模式
常見失敗模式包括任務範圍過大、缺少 metrics、test suites 不穩定、應該量測的任務卻使用 judge-mode decisions，以及 template 與工作不匹配。可量測的效能改善使用 optimizer，覆蓋率工作使用 test-writer，保持結構的清理使用 refactorer，缺陷修復使用 bug-fixer。template 選錯可能會把 agents 推向錯誤類型的解法。
第一次輸出後持續迭代
第一次 /hub:run 之後，請檢查勝出的 diff 與落選的解法。如果沒有任何方案可接受，不要只是用同一個 command 重跑一次。應該收緊任務、加入限制、改善 eval，或縮小範圍。如果勝出方案接近可用但仍不完整，請針對缺漏問題執行 follow-up command，而不是重新啟動整個 lifecycle。