team-builder

team-builder 技能概览

team-builder 的作用

team-builder 是一个交互式 agent 选择器，用于基于 markdown 的 agent 库来组建并发团队并分发任务。它最适合你已经维护了多个 persona 文件，并且需要一种更快的方法来挑选、组合和运行适合当前任务的那一组 agent。

适合谁安装

如果你会跨 security、SEO、architecture、research 或 operations 等角色复用 agents，并且希望在最终确定之前先浏览可用 agents，再决定选谁，那么就安装 team-builder skill。它适合偏好“选择与组合”，而不是把单一 prompt 写死的团队。

它的突出之处

不同于默认假设只有一个 assistant 角色的通用 prompt，team-builder for Workflow Automation 的设计重点是 agent 发现和按需组队。它的核心价值，是在你拥有大量 persona 文件、不同领域，以及适合并行处理的工作时，减少凭经验猜测的成本，让你更容易挑出专业分工，而不是从零即兴拼装。

如何使用 team-builder 技能

正确安装并放置

通过你的 skills manager 使用 team-builder install 路径安装，然后把这个 skill 放在它需要浏览的 agent 文件旁边。这个仓库期望 markdown persona 文件包含清晰的 identity、rules、workflow 和 deliverables，因此只有当你的 agent 库本身已经结构化且易读时，它的效果才最好。

准备它所期望的输入

team-builder usage 的用法不是“让它直接干活”，而是“让它为这项工作组建合适的团队”。你要提供目标、涉及的领域，以及预算、时间或并行度等限制条件。一个好的请求示例是：“为产品发布组建一个团队：SEO、release management 和 QA；优先快速评审，尽量减少重叠。”

先读这些文件

先从 SKILL.md 开始，再查看这个 skill 会浏览的任何 agent 文件。特别留意每个 persona 文件的第一个 # Heading 和开头段落，因为工作流就是用这些字段来识别并描述 agents 的。如果你的 repo 使用 domain 文件夹或共享文件名前缀，务必确认命名模式是否与该 skill 的分组逻辑一致。

使用正确的仓库布局

这个 skill 同时支持子目录和扁平结构，但二者的取舍很重要。对于多词或边界清晰的领域，使用文件夹；只有在共享前缀足够一致且简短时，才使用平铺文件。如果文件名不统一，skill 可能会把 agents 分错组，这也是 team-builder guide 用户最常见的落地阻力。

team-builder 技能 FAQ

team-builder 比普通 prompt 更好吗？

当任务需要在多个专业 agents 之间做选择时，是的。普通 prompt 可以模仿输出结果，但它不能浏览你的 agent 库、分组 persona，也无法在更少人工筛选的情况下帮你组建团队。

我需要现成的 agent 集合吗？

需要。这个 skill 默认你已经有可供选择的 markdown persona 文件。如果你只有一个通用 assistant prompt，team-builder 的价值就很有限，因为并没有什么真正可组合的内容。

这个技能适合新手吗？

如果你的 agent 文件已经整理得很干净，而且命名清晰，那么它对新手也友好。如果你还在设计 personas，它就没那么适合新手，因为 picker 的质量取决于一致的 headings、描述，以及文件夹或文件名规范。

什么情况下不该用它？

当你只需要一个确定性的单一 prompt、任务只是一次性的简单工作，或者你的 agent 命名太混乱，无法支持可靠浏览时，不要使用 team-builder。这类场景下，直接 prompt 或更简单的模板会更快。

如何改进 team-builder 技能

让 agent 文件更容易排序

team-builder skill 的最大质量杠杆，其实是底层 persona 文件的质量。给每个 agent 一个清晰的一级标题、简洁的首段，以及明确的领域标识，这样 picker 就能在不通读整份文件的情况下区分不同 specialist。

先修命名，再调 prompt

如果你依赖平铺文件名，就要保持共享前缀一致，并避免那些会在第一个连字符处被切分得很乱、含义又模糊的多词领域。条件允许时，优先用子目录来做领域隔离，因为这样会让 team-builder for Workflow Automation 更容易推理，也更不容易把文件分错类。

先把约束提出来

最好的 team-builder usage 输入，会明确团队需要优化什么：速度、覆盖面、成本、准确性，还是跨领域覆盖。如果你不写清约束，选出来的团队可能在技术上相关，但并不适合真实任务。

根据团队匹配度持续迭代

第一次运行后，检查被选中的 agents 是否重叠过多，或者是否漏掉了关键专长。然后通过明确排除的领域、必需交付物，以及 agents 之间预期如何交接，来收紧请求。这个反馈循环对提升团队质量的帮助，通常比在 prompt 里堆砌更多泛泛的细节更大。