用途：作为 nitro agent tasks 待办清单的编排运行模型，由主会话充当 orchestrator，只负责待办、排期、环境与任务关闭，不写功能代码，把实现交给子代理，任务以 nitro agent tasks 为唯一事实来源。命令行机制参见 nitro-task、nitro-mail、nitro-memory 技能。若找不到 nitro，说明 CLI 未安装，应停止并让用户按 https://chillicream.com/docs/nitro/cli/installation 安装，不要自行安装。
角色：orchestrator（主会话）持有清单与关闭权；Planner 把用户反馈或对齐目标转成任务（问题、文件范围、修复方向、验证要求、非目标、优先级），通常由另一会话运行 nitro-task-planner 技能；Implementer 一个代理一个任务，用 nitro agent tasks show <id> --output json 读取任务与评论，只实现范围内内容并自审提交；Reviewer 读实际 diff，从正确性、范围蔓延、验证缺口三方面判断，零 blocker/major 才通过；Verifier 仅在评审失败时运行，逐条确认或驳回发现并给出最小修正计划；Fixer 严格按计划修改后重评审，最多 3 轮，之后升级给 planner。角色是能力而非模型名，不同执行环境按对应模型等级与参考文档选择模型、派生与隔离方式。
通信与记忆：orchestrator 先用 nitro agent list --role orchestrator --output json 检查是否已有同类角色，若有则不要占位，改为 nitro agent register --actor <name> --role standby，并向 planner 广播冲突后停止；无冲突才 nitro agent register --actor <name> --role orchestrator，并在每条注册命令重复 --role。之后广播上线状态。planner 简报以邮件到达，波次之间清空收件箱（nitro agent mail inbox --unread --actor <name>），在同线程用 nitro agent mail reply --message <message-id> --actor <name> 回复；邮件只是指针，任务本身才是规格。跨待办的规则存入 nitro agent memory（启动时用 nitro agent memory context 或 memory search 读取，用 nitro agent memory save "<text>" --type preference --tag <area> --actor <name> 保存），单任务裁决留在任务评论。子代理默认不读记忆，需在提示中重申标准规则。
波次模型：按区域标签把就绪任务分组为波次（nitro agent tasks ready --label <area> --output json）；无标签的退回 planner；wayfinder:* 与 research* 属于其他会话，任何列表中都跳过，不认领、不关闭。启动波次时用 nitro agent tasks update <ids...> --claim --actor <name> 认领；跳过的用 --status open --assignee "" 释放；升级的评论阻塞后以 --status blocked --assignee "" 停放。波次内严格一次一个任务；跨波次仅在区域不相交时并发，并在每个提示中写明边界。全局操作（schema 重生成、合并 main、共享配置）须单独运行，波次中不得合并。波次按依赖排序，先基础后功能再打磨。
升级与关闭：卡住或需要澄清时向 planner 升级，不要绕过它直接问用户；顺序为评论阻塞、停放任务、再邮件（同线程回复或广播）。planner 在线就立即带 2-3 个方案与建议；离线则采用最保守合理解释并在评论记 NEEDS-PLANNER，只有无合理解释才硬阻塞。不要让单个卡住的任务拖住整个波次。只有 orchestrator 在评审通过后关闭实现任务（nitro agent tasks close <id> --actor <name> --reason ...），理由需写明提交与证据；环境事故后需复查近期关闭是否真正落地。
环境与限制：orchestrator 亲自管理共享基础设施——后台开发服务器、通过 CDP 的单一已登录浏览器用于实况验证（用户交互登录，代理只读连接，不得输入凭据或登出）；认证过期时不要反复重试，由评审记为次要缺口并在末尾统一实况清扫。提交使用带路径的原子提交 git commit -m "..." -- <files>，提交前用 prettier --write 再 --check；并行代理构建 storybook 使用不同输出目录；index.lock 冲突应退避重试不得强推；需自行核实状态声明（typecheck 可能是缓存命中、cookie 可能已失效、无提交哈希的“完成”可能未提交）。代理不得关闭任务、推送、切换分支或触碰用户未提交文件，最终 git 状态归用户所有，仅在用户明确要求时推送。结构化输出使用 change-result.schema.json、review-result.schema.json、verification-result.schema.json，notVerified 为强制诚实项。节奏为：启动波次→处理完成（关闭通过项、修复或升级失败项）→记录决策→启动下一波；波次间沉淀标准规则到记忆、核对追踪器并清空邮箱。当 nitro agent tasks ready --output json 中不再有可编排的带标签实现任务时结束，最后报告已交付内容、升级任务及其邮件线程与延迟决策清单。资料未提供具体收费、平台支持范围或性能数据。