用途
该技能用于协调多智能体（multi-agent）团队的任务执行，核心目标是把复杂任务拆解为可并行处理的单元，设计任务之间的依赖关系，编写清晰的任务描述，并在执行过程中监控与再平衡各成员的工作负载。适用于需要并行推进的复杂开发任务、代码审查与审计、以及多任务工作流的编排。
主要能力
任务拆解策略
- 按层（By Layer）：按架构层拆分，如前端组件、后端 API 端点、数据库迁移/模型、测试套件。适合全栈功能与垂直切片。注意：按层属于以问题为中心的拆解方式（本质上是规划者/编码者/测试者角色的变体），仅当各层确实拥有可隔离的上下文时才有效；若团队成员在每层边界反复交接上下文则会失败。当上下文可清晰划分时，应优先使用“按文件所有权”或“按组件”。
- 按组件（By Component）：按功能组件拆分，如认证模块、用户资料模块、通知模块。适合微服务与模块化架构。
- 按关注点（By Concern）：按横切关注点拆分，如安全审查、性能审查、架构审查。适合代码审查与审计。
- 按文件所有权（By File Ownership）：按文件/目录边界拆分，如 src/components/ 归实现者 1、src/api/ 归实现者 2、src/utils/ 归实现者 3。适合并行实现与冲突避免。
依赖图设计
原则：
- 最小化链深度——优先宽而浅的图，而非深链。
- 识别关键路径——最长链决定最短完成时间。
- 谨慎使用 blockedBy——只添加真正必需的依赖。
- 避免循环依赖——任务 A 阻塞 B、B 阻塞 A 会造成死锁。
模式：
- 独立式（并行性最佳）：任务 A、B、C 并行汇入集成。
- 顺序式（必要依赖）：任务 A → B → C。
- 菱形（混合）：任务 A 分出 B、C，再汇入任务 D。
blockedBy/blocks 用法示例：
TaskCreate: { subject: "Build API endpoints" } -> Task #1
TaskCreate: { subject: "Build frontend components" } -> Task #2
TaskCreate: { subject: "Integration testing" } -> Task #3
TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] } -> #3 waits for #1 and #2
任务描述最佳实践
每个任务应包含：
- 目标（Objective）：需要完成什么（1-2 句）。
- 所属文件（Owned Files）：该成员可修改的文件/目录的明确列表（关键项：团队负责人的首要指令要求在每个 spawn 提示中都包含此项）。
- 需求（Requirements）：期望的具体交付物或行为。
- 接口契约（Interface Contracts）：本工作如何与其他成员的工作衔接。
- 输出路径（Output Path，针对产出制品的任务）：成员必须写入最终报告或交付物的位置。审查者/调试者/研究者角色必需；仅当成员直接编辑代码且无单独报告时可省略。
- 验收标准（Acceptance Criteria）：如何验证任务已正确完成。
- 范围边界（Scope Boundaries）：明确不在范围内的内容。
- 完成协议（Completion Protocol）：例如“完成后，在给负责人发消息之前先调用 TaskUpdate(completed)。”留在 in_progress 状态的任务会阻塞依赖工作。
模板示例：
## Objective
Build the user authentication API endpoints.
## Owned Files
- src/api/auth.ts
- src/api/middleware/auth-middleware.ts
- src/types/auth.ts (shared -- read only, do not modify)
## Requirements
- POST /api/login -- accepts email/password, returns JWT
- POST /api/register -- creates new user, returns JWT
- GET /api/me -- returns current user profile (requires auth)
## Interface Contract
- Import User type from src/types/auth.ts (owned by implementer-1)
- Export AuthResponse type for frontend consumption
## Acceptance Criteria
- All endpoints return proper HTTP status codes
- JWT tokens expire after 24 hours
- Passwords are hashed with bcrypt
## Out of Scope
- OAuth/social login
- Password reset flow
- Rate limiting
工作负载监控
失衡信号与应对：
- 某成员空闲、其他人忙碌 → 分配不均 → 重新分配待处理任务。
- 某成员卡在一个任务上 → 可能存在阻塞 → 主动询问并提供帮助。
- 所有任务都被阻塞 → 依赖问题 → 优先解决关键路径。
- 某成员任务量是其他人的 3 倍 → 过载 → 拆分任务或重新分配。
再平衡步骤：
- 调用 TaskList 评估当前状态。
- 识别空闲或过载的成员。
- 使用 TaskUpdate 重新分配任务。
- 使用 SendMessage 通知受影响的成员。
- 监控吞吐量是否改善。
通过钩子实现质量门禁
为在任务级边界强制执行规则而无需人工盯守，可接入原生团队钩子：
- TaskCreated——退出码 2 阻止任务创建。用于强制每个任务描述都包含所有权与验收标准。
- TaskCompleted——退出码 2 阻止完成。用于在任务关闭前把关 lint / 类型检查 / 测试。
- TeammateIdle——退出码 2 使成员带着反馈返回工作。用于成员标记自己空闲但工作实际未完成时。
钩子把“信任并期望”变为“信任并验证”，且不会使 spawn 提示膨胀。
使用方式
该技能以策略与模板形式提供，供团队负责人在拆解任务、创建任务、设置依赖、编写任务描述、监控负载和配置钩子时参照执行。具体调用方式与集成细节暂未提供。
适用场景
- 将复杂任务拆解为可并行执行的单元。
- 设计任务依赖关系（blockedBy/blocks）。
- 编写带明确验收标准的任务描述。
- 监控并再平衡团队成员间的工作负载。
- 识别多任务工作流中的关键路径。
限制
- “按层”拆解仅在上下文可真正隔离时有效，否则会因反复交接上下文而失败。
- 依赖关系应谨慎添加，过多 blockedBy 会降低并行度。
- 循环依赖会导致死锁，必须避免。
- 关于具体平台支持、收费方式、价格等信息暂未提供。