team-builder

team-builder 技能總覽

team-builder 的功能

team-builder 是一個互動式代理挑選器，用來從以 markdown 為基礎的代理庫中組合並派送平行團隊。當你已經維護多個 persona 檔案，並且需要更快地挑選、分組與執行最適合任務的組合時，它特別有用。

適合安裝的人

如果你會在安全性、SEO、架構、研究或營運等不同角色之間使用可重複利用的代理，並且希望在正式決定之前先瀏覽可用代理，建議安裝 team-builder skill。它很適合偏好「先選擇、再組合」而不是把單一 prompt 寫死的團隊。

它的亮點

和假設只有單一助手角色的通用 prompt 不同，team-builder for Workflow Automation 的設計核心是代理探索與臨時團隊組裝。當你手上有很多 persona 檔案、不同領域，而且工作可以平行處理時，它的主要價值就在於減少猜測，讓你不用從零臨場拼湊，而是直接挑出專家組合。

如何使用 team-builder 技能

正確安裝與放置

先透過你的 skills manager 使用 team-builder install 路徑安裝，接著把這個技能放在它應該瀏覽的代理檔案旁邊。這個 repository 期待 markdown persona 檔案具備清楚的身分、規則、工作流程與交付內容；因此，當你的代理庫本來就有條理、又容易閱讀時，這個技能的效果最好。

準備它需要的輸入

team-builder usage 的模式不是「叫它直接把工作做完」，而是「叫它為這個工作組出正確的團隊」。你要提供目標、涉及的領域，以及任何限制，例如預算、時間或可平行化程度。好的請求會像這樣：Build a team for a product launch: SEO, release management, and QA; prioritize fast review and minimal overlap.

先讀這些檔案

先從 SKILL.md 開始，再檢視這個技能會瀏覽的任何 agent 檔案。特別留意每個 persona 檔案的第一個 # Heading 與開頭段落，因為這些欄位是工作流程用來辨識與描述代理的依據。如果你的 repo 使用領域資料夾或共用檔名前綴，務必確認命名規則和這個技能的分組邏輯一致。

使用正確的 repository 版型

這個技能同時支援子目錄與扁平版型，但兩者的取捨很重要。若你的領域是多字詞，或本來就明確分開，請用資料夾；只有在共用前綴一致且簡短時，才適合用扁平檔案。如果檔名不一致，技能就可能把代理分錯組，這也是 team-builder guide 使用者最常卡關的地方。

team-builder 技能 FAQ

team-builder 比一般 prompt 更好嗎？

如果任務取決於在多個專業代理之間做選擇，答案是肯定的。一般 prompt 可以模擬輸出，但它不能瀏覽你的代理庫、分組 persona，或幫你用更少的人工掃描來組出團隊。

我需要先有現成的代理集合嗎？

需要。這個技能預設你已經有可供挑選的 markdown persona 檔案。如果你只有一個通用型助手 prompt，team-builder 的價值就不大，因為沒有什麼真正可供組合的內容。

這適合初學者嗎？

如果你的 agent 檔案已經整理得很乾淨、命名也清楚，那它對初學者算友善。若你還在設計 personas，則相對不那麼友善，因為挑選器的品質很依賴一致的 heading、描述，以及資料夾或檔名慣例。

什麼情況下不該用它？

當你只需要單一、可預測的 prompt、任務是一次性而且很簡單，或你的 agent 命名太雜亂、無法支援可靠瀏覽時，就不要用 team-builder。在這些情況下，直接 prompt 或更簡單的 template 會更快。

如何改善 team-builder 技能

讓 agent 檔案更容易被排序

對 team-builder skill 來說，最重要的品質槓桿就是底層 persona 檔案的品質。為每個 agent 提供清楚的第一個 heading、簡潔的第一段，以及明確的領域，這樣挑選器才能不必讀完整個檔案，就分辨出專家。

先修正命名，再調整 prompts

如果你依賴扁平檔名，請保持共用前綴一致，並避免含糊、而且在第一個連字號就會切開得很糟的多字詞領域。若可行，請用子目錄來做領域區隔，因為這會讓 team-builder for Workflow Automation 更容易推理，也比較不會把檔案分類錯誤。

先把限制條件說清楚

最好的 team-builder usage 輸入，會包含團隊必須優先最佳化的目標：速度、廣度、成本、準確度，或跨領域覆蓋。如果你省略限制條件，選出來的團隊雖然可能在技術上相關，卻不一定符合實際工作需求。

根據團隊適配度反覆調整

第一次執行後，檢查被選出的 agents 是否重疊太多，或漏掉了關鍵專長。接著，透過明確指出要排除的領域、必須交付的成果，以及 agents 之間預期的交接方式，來收緊需求。這個回饋迴圈，對提升團隊品質的幫助，比一味在 prompt 裡加更多泛泛細節還要大。