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,以及基于模板的调用方式。
- 定义了目标 parallel-agent 模式:N 个 subagents 在隔离的 git worktrees 中处理同一任务,并可选择 optimizer/refactorer/test-writer/bug-fixer 等策略。
- 依赖已初始化的 AgentHub session 以及相关的 session/config 约定,因此它不是一个可独立使用的通用 parallel-agent 工作流。
- 未随附脚本或本地参考文件,模板说明指向 ../agenthub/references/agent-templates.md;如果安装环境中没有该文件,上手和落地风险会增加。
spawn skill 概览
spawn 的作用
spawn 是一个 AgentHub skill,用于在同一个会话任务中并行启动多个 coding agents。它不是让一个 assistant 按顺序解决问题,而是通过 spawn skill 创建 N 个隔离在不同 git worktrees 中的 subagents,让它们用不同策略竞争式地完成任务,同时避免相互覆盖代码变更。
当你已经初始化 AgentHub session,并希望针对实现、重构、测试、优化或 bug 修复进行并行探索时,适合使用它。
最适合 Agent Orchestration 的场景
spawn for Agent Orchestration 最适合那些存在多条合理解决路径的任务。它适合希望让 agents 探索备选方案、比较产出,并降低过早锁定第一个实现方案风险的团队或个人开发者。
典型适用场景包括性能调优、大型重构、偶发 bug 排查、补充缺失测试覆盖,以及那些独立方案能够暴露不同取舍的代码改动。
这个 spawn skill 的不同之处
它的核心差异在于隔离环境与结构化竞争。每个 agent 都在自己的 git worktree 中工作,这能让并行编辑彼此分离,也让后续比较更安全。该 skill 还支持 optimizer、refactorer、test-writer、bug-fixer 等 templates,因此派发 prompt 时可以匹配具体工程任务类型,而不是使用泛泛的“解决这个问题”指令。
采用前需要考虑的事项
这个 skill 默认你已经在使用完整的 AgentHub 工作流。它不是一个无需配置、可以在任意 repository 中直接运行的独立 package。该 repository 路径下只包含 SKILL.md,因此用户应预期这个 skill definition 会依赖相邻的 AgentHub 约定和引用,包括 session configuration 以及 skill 文件夹之外的 template files。
如何使用 spawn skill
spawn 安装前提
使用以下命令从源 repository 安装该 skill:
npx skills add alirezarezvani/claude-skills --skill spawn
安装后,确认你的环境支持 AgentHub commands,并且已经初始化过 session。该 skill 暴露的命令是:
/hub:spawn
是否安装 spawn,应取决于你是否需要协调多个并行 agents,而不只是想要另一个 prompt shortcut。如果你的工作流不使用 git worktrees 或基于 session 的 orchestration,那么在依赖这个 skill 之前,应先检查更完整的 AgentHub 设置。
spawn 基本用法
常见命令形式包括:
/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:添加测试并衡量覆盖率提升bug-fixer:复现、诊断、修复并验证
能提升 agent 产出质量的输入
高质量的 spawn 使用方式在执行命令之前就开始了:session task 应该足够具体,让多个 agents 能够独立行动并比较结果。请包含目标文件、验收标准、测试命令、约束,以及“更好”具体意味着什么。
较弱的 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 材料,尤其是已安装 repository 中可用的 session setup docs 和 agent-templates.md。最需要确认的细节包括:sessions 如何命名、如何选择 N 个 agents、worktrees 创建在哪里,以及最终比较或 merge 选择如何处理。
spawn skill 常见问题
什么时候应该用 spawn,而不是普通 prompt?
当并行探索确实有价值时,使用 spawn。对于小改动、文档更新,或答案明显唯一的任务,普通 prompt 通常已经足够。spawn skill 更适合那些不同实现策略、测试设计或调试假设可能带来显著不同结果的任务。
spawn 适合新手吗?
只有在你已经理解周边 AgentHub 工作流和基本 git worktree 行为时,它才算适合新手。命令本身很简单,但运行模型更进阶:多个 agents 会生成彼此独立的代码变更,你需要进行 review、测试和选择。
什么会阻碍 spawn 成功使用?
主要阻碍包括未初始化的 AgentHub session、不清晰的任务定义、缺少测试命令,以及 repository 不适合进行并行 worktree 变更。另一个限制是 skill 文件夹本身很精简;真正有用的 orchestration context 位于更完整的 AgentHub system 中,因此不要把它当作一个完全自包含的工具来评估。
什么时候不该使用 spawn?
避免将 spawn 用于 secrets 处理、不可逆的生产操作、很小的一行修复,或那些重复 agent 工作只会制造噪音而不是带来洞察的任务。如果你无法运行测试或比较产出,它也不适合使用,因为并行 agents 的价值依赖于基于证据的选择。
如何改进 spawn skill 的使用效果
让 spawn prompts 更便于比较
要让 spawn 产出更好结果,请定义所有 agents 都能据此优化的成功指标。好的比较标准包括测试通过、运行时间降低、diff 更小、API 边界更清晰、覆盖率提升,或 bug 复现证据更充分。没有共同标准时,并行产出会很难判断优劣。
有意识地分配不同策略
当每个 agent 都获得不同策略时,该 skill 的 template guidance 最有价值。修复 bug 时,一个 agent 可以从复现入手,另一个从近期 git history 入手,第三个从边界条件测试入手。做优化时,一个可以减少 allocations,另一个可以引入 cache,另一个可以改变算法复杂度。多样性正是 spawn skill 的重点。
避免常见失败模式
常见失败包括:在目标模糊时启动 agents、让所有 agents 都走同一个计划、跳过验证,以及因为某个方案看起来改动最大就直接 merge,而不是选择证据最充分的方案。保持任务边界清晰,要求提供测试命令,并让 agents 总结它们的方法、取舍、修改文件和验证结果。
在第一次 spawn 运行后继续迭代
第一次运行后,先比较各个 worktrees,再决定是否 merge。保留最强候选方案,丢弃较弱分支,或者基于已获得的信息再运行第二轮 spawn。一个有用的后续指令是:
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 循环。
