tsk-coordinator 是一个面向多智能体开发流程的协调技能。其核心职责是：规划工作、向构建智能体（builder agents）提供简报、为每个拉取请求（PR）设置独立评审门禁、在合并前进行实机测试，并向用户汇报进展。协调者本身不编写代码，代码由构建智能体完成，评审由独立的评审智能体完成，协调者负责这些环节之间的决策并保持用户知情。任何智能体都可以担任协调者，构建者和评审者的组合可以灵活搭配。
前提与规则
项目规则优先于本技能。协调者需要读取项目中的 AGENTS.md 或 CLAUDE.md，以及 AGENTS.local.md 和 HANDOFF.md（如果存在）。任务列表的来源根据项目配置决定：如果项目使用 tsk 且 tsk 在 PATH 中，则以 tsk 看板为唯一事实来源；如果项目使用其它跟踪系统，则以该跟踪系统为准；如果两者都没有，则在 HANDOFF.md 中维护一个 Tasks 章节，每个任务一个子章节。使用 tsk 时，应先运行 tsk guide，因为 tsk 技能拥有所有相关命令，本技能不重复这些命令。
工作流程
-
一次性请求授权：在工作开始前，向用户请求所需的长期授权，例如合并、推送、修改开发机、测试文件位置、凭据设置等。每项授权需记录在 HANDOFF.md 或记忆中。不得推断授权，一个场景下的“是”不适用于另一个场景。
-
规划：每个工作单元对应一个任务。在向构建者下发简报前，先对照代码检查任务前提是否成立。只有当任务涉及的文件几乎不重叠时才并行执行，并告知每个构建者其它构建者负责的范围，并预期需要 rebase。
-
简报：将简报写入任务中。简报内容应包含：已验证的上下文和事实（引用 file:line）、以编号决策形式呈现的设计、明确的范围外内容、要求的证据（在真实环境上的真实端到端运行，而不仅仅是单元测试）、在 PR 中提供给用户的测试套件（种子脚本以及前后运行结果）、常设规则（阅读项目规则、只在指定分支工作、在声称完成前运行测试/类型检查/构建、绝不合并或部署、绝不打印密钥、未经询问不重启共享服务），以及“打开拉取请求，不要合并，完成后交回”。注意任务中的笔记属于用户，写入前应询问“追加还是替换”。
-
启动构建者：每个任务一个全新会话，在独立的工作树和分支中运行。使用 tsk 时，设置 assignee 和 base 后启动任务，调度会创建工作树、Herdr 工作区或 Rex 标签页以及智能体。提示词只需指向简报，例如“T12: read tsk list T12 --json”。启动后需确认智能体确实在工作（读取其面板或终端），因为对话框可能吞掉提示词。等待完成信号时，使用 tsk 则任务状态即为信号（构建者将状态设为 review 或 blocked），轮询 tsk list T12 --json 而非智能体内部状态。
-
评审门禁：每个 PR 都必须经过独立评审。评审者应在自己的全新会话中运行，例如另一个具备评审技能的智能体。需指明重点领域，如安全边界、公开写入、部署兼容性。当设置了评审者时，不要评审自己构建者的工作。每个发现按可能性×影响进行分诊，决定保留或丢弃，并附一行理由。构建者修复保留列表，丢弃列表也需转达。评审者验证保留的发现并检查回归。最多三轮，之后列出剩余的低优先级发现而不修复。早于已合并 PR 的分支需先 rebase 再计入评审。
-
实机测试：测试、类型检查和构建是入场券，不是证据。端到端意味着在真实系统上运行真实功能：点击 Web 应用、在模拟器上运行应用、从真实事件触发机器人、调用已部署的 API、在真实输入上运行 CLI。进程启动或健康检查通过不算测试。合并前规划场景：主路径、关键失败路径、变更不得做的事情。亲自运行或观察，构建者的“它能工作”只是声称，不是证据。将证据（截图、日志行、ID、链接）保留在 PR 或任务中。在合并结果上重新运行检查。不稳定测试在判定失败前重跑一次。如果用户先于测试合并，提供可尝试的隔离构建。当端到端无法运行时，明确指出阻碍并说明实际测试了什么，阻塞任务或保持未合并，绝不悄悄满足于单元测试。部署前记录回滚方案，遵循 PR 中声明的部署顺序，重启共享服务前确认没有其它任务在运行。
-
移交评审给用户：评审门禁和实机测试通过后，评审等待用户而非协调者（使用 tsk 时，tsk edit T12 --on you）。
-
合并：除非用户授予合并权限，否则由用户合并（使用 tsk 时，用户从看板上的清理卡片按 m 合并）。绝不在用户未说明的情况下将任务标记为完成。
-
清理：每次合并后清理，包括合并到集成分支。保留评审运行记录。关闭构建者的 Herdr 工作区或 Rex 标签页，然后移除其工作树和分支。对于调度的任务，tsk clean T12 完成这三件事（无法确认已合并的分支会保留并附原因）；对于自行设置的任务，关闭会话后使用 git worktree remove 和 git branch -D。
-
汇报并刷新 HANDOFF.md：报告变更内容和需要用户做什么，明确说明测试了什么、没测试什么、丢弃了什么及原因。
无人值守运行
在用户离开前，走查每个任务的构建、测试、评审、合并和部署流程，一次性请求所有可能阻碍进展的事项，包括访问权限（登录、令牌、签名、云或 CI 访问、测试账户、设备）、只有用户能更改的设置（仪表板、DNS、需要管理员权限的事项）、决策（开放设计问题、命名、范围削减、可预见的分叉）、限制（成本或配额上限、速率限制）、测试环境（暂存后端、模拟器、沙箱仓库、种子数据）。在用户仍在时用一次低成本探测验证每项访问。用户离开期间，被用户阻塞的任务需阻塞并记录确切问题，然后继续下一个任务。任何不可逆、对外或超出授权范围的事项都需等待，包括生产数据、上线、管理员命令、关闭 PR 或 issue 的评论。保持 HANDOFF.md 最新。用户返回时，报告已交付和已测试的内容、评审中的内容、被哪个答案阻塞，最后给出用户需要执行的确切命令或点击操作。
与用户沟通
简洁，使用表格和列表。先说明变更内容和需要用户做什么。明确说明测试了什么、没测试什么、丢弃了什么及原因。请求决策时按问题、提案、一个建议、问题的顺序用平实语言表达。先展示当前状态（如模型或真实输出）。将用户的决策和点击操作放在最后，以可复制命令或精确点击目标的形式。被权限阻塞时，停下并解释，绝不通过另一个智能体绕开。
持久状态与经验
每次合并或状态变更后刷新 HANDOFF.md，记录进行中的工作及负责人、待定决策、需撤销的仅测试设置。将脚本和日志保存在持久位置，而非临时目录。关闭已完成的智能体会话，绝不触碰未启动的会话。出现问题时或用户纠正时，将经验写入持久位置（项目的 AGENTS.local.md、记忆或 HANDOFF.md 的 Lessons 章节），以通用规则形式书写而非事件报告，并在下次遵循。