用途：面向值得认真完成的任务，提供澄清→计划→目标→工作流→人工审查的结构化循环。触发语包括“work this”“run a work loop”“do this properly”“run it through the gate”“/work”等。
主要流程：CLARIFY → PLAN → GOAL → workflow.js（PASS 后进入人工审查 tuicr；FAIL 则修复重跑；人工拒绝回到 CLARIFY）。澄清阶段用 AskUserQuestion 确认期望结果、禁止变更项、约束、可验证的成功标准、审查面以及审查所用的 provider 等。计划阶段进入 plan mode，产出任务表与 Run sizing（审查镜头、机械检查、规则检查、打分检查、测试先行、lens provider 等），并写入 work:dispatch 块以武装本次运行。
主要能力与用法：dispatch 由 work-dispatch.sh 完成（含 Phase 3+4）；workflow.js 通过 farm-out 调度实现与独立验证；校验由脚本按退出码完成，reд probes、acceptanceCmd 与 mechanicalChecks 均为脚本判定的退出码，无代理自行执行命令。计划审查在建 args 上经 plan-lint.ts 与 plan-preflight.ts 在基线执行，由 work-dispatch.sh 在运行仍武装时强制执行。状态分两处：plansDirectory 下的计划文件归 plan mode 所有，work 只读取并哈希；.work/<run-id>/ 存放 args、verdict JSON 与被哈希的计划归档 plan-<hash12>.md。
限制：plan 文件非持久，重进 plan mode 会就地覆盖；dispatch 归档的是内容寻址快照，若计划需长存应自行 git add -f。.work/ 与计划目录应加入 .gitignore。fan-out 超过 maxAgents（默认 50）会在参数校验阶段抛错，提示按维度拆分。更改 workflow.js 后应运行其测试套件（workflow-harness.mjs、workflow.test.ts、plan-review.test.ts）。readOnly 审计同样需要 planPath 与 specHash。其余细节（如 tuicr 的具体安装、价格、平台支持等）暂未提供。