spawn
作者 alirezarezvanispawn 會在已初始化的 AgentHub session 中,於隔離的 git worktrees 啟動 N 個平行 subagents。你可以使用 /hub:spawn,搭配選用的 session ID,或 optimizer、refactorer、test-writer、bug-fixer 等範本,用來比較不同解法。
此 skill 評分為 68/100,代表可列入目錄但能力仍有限。目錄使用者能快速理解核心指令與平行 worktree-agent 概念;但建議僅在你已使用周邊 AgentHub 工作流程,或願意自行補齊缺少的操作細節時安裝。
- 透過宣告的 /hub:spawn 指令與使用情境說明,觸發方式清楚:可為已初始化的 AgentHub session 啟動多個互相競爭的 agents。
- 提供具體使用範例,包括 latest-session、明確 session ID,以及以範本為基礎的呼叫方式。
- 清楚定義預期的平行代理模式:N 個 subagents 在隔離的 git worktrees 中處理同一項任務,並可選用 optimizer/refactorer/test-writer/bug-fixer 等策略。
- 依賴已初始化的 AgentHub session,以及其引用的 session/config 慣例,因此不是可獨立使用的通用平行代理流程。
- 未隨附腳本或本機參考檔案,且範本指引指向 ../agenthub/references/agent-templates.md;若安裝環境中沒有該檔案,導入風險會提高。
spawn skill 概覽
spawn 的用途
spawn 是一個 AgentHub skill,可針對同一個 session task 啟動多個平行 coding agents。與其讓單一 assistant 依序解決問題,spawn skill 會在彼此隔離的 git worktrees 中建立 N 個 subagents,讓它們用不同策略競爭,同時避免互相覆寫變更。
當你已經初始化 AgentHub session,並希望針對實作、重構、測試、最佳化或除錯工作進行平行探索時,就適合使用它。
最適合 Agent Orchestration 的情境
spawn for Agent Orchestration 最適合用在任務存在多個合理解法路徑的時候。它適合希望 agents 探索不同方案、比較產出,並降低一開始就被第一個實作方向錨定風險的團隊或個人開發者。
適合的任務包含效能調校、大型重構、不穩定 bug 調查、補齊測試覆蓋率,以及那些透過獨立做法能看出取捨差異的程式碼變更。
這個 spawn skill 的不同之處
核心差異在於隔離加上結構化競爭。每個 agent 都在自己的 git worktree 中工作,讓平行編輯彼此分離,也讓後續比較更安全。這個 skill 也支援 optimizer、refactorer、test-writer、bug-fixer 等 templates,因此派送 prompt 時可以對應工程任務類型,而不是只使用泛用的「解決這個問題」指令。
採用前的考量
這個 skill 預設你已經在使用周邊的 AgentHub workflow。它不是一個不需設定、可直接在任何 repository 執行的獨立套件。repository path 只包含 SKILL.md,因此使用者應預期 skill definition 會依賴相鄰的 AgentHub 慣例與參照內容,包括 session configuration,以及 skill folder 外部的 template files。
如何使用 spawn skill
spawn 安裝情境
從來源 repository 安裝 skill:
npx skills add alirezarezvani/claude-skills --skill spawn
安裝後,請確認你的環境支援 AgentHub commands,且已經初始化 session。這個 skill 暴露的 command 是:
/hub:spawn
是否安裝 spawn,應取決於你是否需要協調多個平行 agents,而不只是想要另一個 prompt shortcut。若你的 workflow 不使用 git worktrees 或 session-based orchestration,建議先檢視更完整的 AgentHub setup,再依賴這個 skill。
spawn 基本用法
常見 command 形式如下:
/hub:spawn
/hub:spawn 20260317-143022
/hub:spawn --template optimizer
/hub:spawn --template refactorer
使用 /hub:spawn 會套用最新的 session。當你需要指定特定 AgentHub session 時,傳入 session ID。當任務適合某種專門的操作模式時,加入 --template <name>。
這個 skill 支援的 template 意圖包括:
optimizer:重複進行 edit/evaluate/keep-or-discard 循環refactorer:重整結構、測試,並反覆迭代直到通過test-writer:新增測試並衡量 coverage improvementbug-fixer:重現、診斷、修復並驗證
能改善 agent 產出的輸入
好的 spawn 使用 prompt,其實從 command 執行前就開始了:session task 應該要足夠具體,讓多個 agents 可以獨立行動並比較結果。請包含目標 files、acceptance criteria、test commands、constraints,以及「更好」的定義。
較弱的 session goal:
Improve the API code.
較強的 session goal:
Refactor the user lookup API to reduce duplicate database calls without changing response shape.
Focus on src/api/users.ts and src/services/user-cache.ts.
Run npm test -- users and npm run lint.
Preserve public types. Prefer minimal changes unless an agent can prove a cleaner design with tests.
這會讓 spawned agents 擁有共同目標,同時保留採用不同策略的空間。
執行前應閱讀的檔案
先從 engineering/agenthub/skills/spawn 中的 SKILL.md 開始。接著檢查這個 skill 參照的相鄰 AgentHub materials,尤其是任何 session setup docs,以及已安裝 repository 中若有提供的 agent-templates.md。最重要的是確認 session 如何命名、N 個 agents 如何選擇、worktrees 會建立在哪裡,以及最後如何比較或選擇要 merge 的結果。
spawn skill 常見問題
什麼時候該用 spawn,而不是一般 prompt?
當平行探索真的有價值時,就使用 spawn。一般 prompt 通常足以處理小型編輯、文件修改,或只有明顯單一答案的任務。當不同實作策略、測試設計或除錯假設可能導向明顯不同的結果時,spawn skill 會更有用。
spawn 適合初學者嗎?
只有在你已經理解周邊 AgentHub workflow 與基本 git worktree 行為時,它才算適合初學者。command 本身很簡單,但操作模型更進階:多個 agents 會產生各自分離的變更,而這些變更需要 review、testing 與 selection。
哪些因素會阻礙 spawn 成功使用?
主要阻礙包括尚未初始化 AgentHub session、任務定義不清楚、缺少 test commands,以及 repository 不適合進行平行 worktree 變更。另一個限制是 skill folder 本身很精簡;真正有用的 orchestration context 位於更廣泛的 AgentHub system 中,因此不要把它當作完全 self-contained 的工具來評估。
什麼時候不該使用 spawn?
避免將 spawn 用於 secrets handling、不可逆的 production operations、極小的一行修正,或那些重複 agent 工作只會製造噪音而不是帶來洞察的任務。當你無法執行測試或比較產出時,它也不適合,因為平行 agents 的價值取決於能以證據為基礎進行選擇。
如何改善 spawn skill 的使用效果
讓 spawn prompts 更容易比較
若想從 spawn 得到更好的結果,請定義每個 agent 都能最佳化的成功指標。好的比較條件包含通過測試、降低 runtime、縮小 diff size、更清楚的 API boundaries、改善 coverage,或提供已重現 bug 的證據。沒有共同標準時,平行產出會變得難以判斷。
有意識地分配多樣化策略
當每個 agent 收到不同策略時,這個 skill 的 template guidance 最能發揮效果。針對 bug fix,一個 agent 可以從重現問題開始,另一個從近期 git history 下手,另一個則從 boundary-condition tests 切入。針對最佳化,一個可以減少 allocations,另一個可以使用 cache,另一個可以改變 algorithmic complexity。多樣性正是 spawn skill 的重點。
避免常見失敗模式
常見失敗包括在模糊目標上 spawning agents、讓所有 agents 都遵循同一個計畫、跳過驗證,以及合併看起來最大包但不是最有證據支持的解法。請讓任務保持有界,要求 test commands,並要求 agents 摘要各自的 approach、tradeoffs、files changed 與 verification results。
第一次 spawn 執行後繼續迭代
第一次執行後,請先比較 worktrees 再 merge。保留最強的候選結果,丟棄較弱 branches,或根據已學到的內容進行第二輪 spawn。一個實用的 follow-up instruction 是:
Use the best result from agent 2 as the baseline.
Spawn new agents to improve reliability and reduce diff size.
All agents must preserve the public API and run the same test command.
這會把 spawn 從一次性的競賽,變成實用的 agent orchestration loop。
