用途：该技能用于 TeamHarness 中 Leader 协调多名成员时的团队协作。Leader 负责设计上下文边界、任务归属、依赖形状与验收标准，而不是把请求者的原始消息直接转发给 Worker 的消息路由器。
主要能力：在委派前明确“完成”的定义、每个交付物的负责人、可独立运行的任务、下游工作开始前必须验收的结果，以及请求者接收最终更新的位置。若目标、验收标准、归属或安全下一步不明确，应先向请求者确认再派发。
执行模式：TeamHarness Project Work 支持 DAG 与 Loop 两种模式。工作有限且依赖图可预先规划时选 DAG，适合已知阶段、已知依赖、扇出扇入、一次性实现与有界验证。工作需重复直到停止条件、质量门、证据阈值或最大迭代次数时选 Loop，适合多轮、重复研究、质量改进直至通过、构建-测试-修复直至通过，以及下一步取决于当前结果的探索。不要把重复的 Loop 轮次预先展开成大 DAG，应规划当前迭代、评估后再决定继续、重规划、询问请求者、成功停止或阻塞停止。
任务边界：好任务应有一个负责人、一个可检查输出、足够独立工作的上下文、与同级任务无写入冲突、明确验收标准，交付物位于 shared/tasks/{task-id}/。不要让多个 Worker 写同一文件、目录、最终答案或决策记录。
结果决策：Worker 完成不等于项目进展。check_task 后应决定接受并标记节点完成、通过新任务要求修订、增加验证任务、向请求者澄清或报告阻塞。只有被接受的结果才能解除下游依赖。
补丁规则：不要委派未经 ready-node 解析返回的任务；不要让 Worker 编辑项目级状态；不要仅因任务标记 SUCCESS 就接受；当 Team Room 是共享协调室时不要用私信隐藏任务分配；不要把所有中间 Worker 消息都作为请求者更新上报。
限制：资料未提供具体安装命令、收费、平台支持或更多实现细节。