ch3sh-lc/myworkflow/task-router

任务分类速查

会话入口是 hook：它在启动时注入任务分类概念与阶段链。本表是备用速查，用于两种场合——拿不准归哪类时，或长会话内切换任务类型、上下文里已经堆了很多别的东西时。

第零步：续接还是新任务

用户说「继续 / 接着做 / 下一步 / 恢复 / 上次那个」时，默认是续接，不是新任务——先判定再动手：

• 判据：本轮请求是否指向已有进行中的工作（被中断 / 压缩 / 交接 / 有未完成交付物）？是 → 续接；否 → 新任务，按第一步正常判级。
• 续接必须先对账（R1）：用可核查证据确认进度——读交付物 / 状态文件（STATE / PROGRESS / design）/ 运行记录 / 上一轮回执；禁止凭对话记忆假设「应该做完了」；对不出结论先做只读探查，不猜。
• 三级状态（R2，复用 produced / verified / accepted）：已 accepted → 跳过，不重做；已 produced 未 verified → 补验证 / 补证据，不重做产物；尚未开始 → 正常做；判不清 → 按「未完成」处理并先探查。
• 只推进最小下一步（R3）：续接不是重跑整条流程——找出下一个未完成的独立交付物，只做它，做完再判下一步。
• R8 续接同样有技能意识：续接回合与普通回合一样，按本技能判 L1/L2/L3 并 skill(...) 加载对应技能；Host 每轮注入的【每轮纪律】照常生效。
• 需求漂移（R4）：用户中途的新指令若改变目标 / 范围 / 验收标准 → 先确认再重排（只问会改变决策的问题），确认后更新计划；禁止硬续旧计划、禁止静默改范围。
• R5 失败后续接：同一种失败不得重复——记录已试路径与错误指纹，换方法 / 降级 / 上报，并写明「这次为什么与上次不同」。
• R7 交接四样：把任务交给别人或接手时必须给/要四样——已做 / 未做 / 证据（runId 或产物路径）/ 下一步 + 未解决项；接手方先复核再动手。
• 中断恢复（R6）：出现压缩摘要（compaction）或会话重启后，从磁盘事实重建进度，并重新确认任务级别与要加载的技能。

第一步：判定工作级别（L1 单智能体 / L2 子智能体 / L3 团队）

先判级别，再判类别：级别决定「谁来做、怎么协作」，类别决定「加载哪个技能」。

• L1 单智能体（solo）适用：单一不可再分交付物、单文件小改、一次回答闭环、纯问答。形态：当前上下文直接做完，不建团队、不下 mission、不派 leaf、不建 goal。判据：单文件或纯问答才是 L1；出现「≥2 个可独立交付物」或「跨域/接口依赖/需持续负责人」即不再属于 L1。空档规则：单个交付物但改动涉及 ≥2 个文件 → 归 L2（按文件组平铺派 subagent；确实无法派发时当前上下文分文件组做完并逐组自检），仍不建团；只有出现「≥2 个可独立交付物」或「跨域/接口依赖/需持续负责人」才升 L3。
• L2 子智能体（subagent）适用：一个可独立完整执行的交付单元——有明确输入、明确产出、可独立验收（常见形态是 ≥2 个平铺、无依赖的小交付物；不需要跨回合持续负责人；结果可一次性回收）。形态：主智能体派 subagent，一个执行者端到端做完（调查→实现→自检→修复），交回真实产物与证据。L2 的本质是「一个可独立验收的完整交付单元」，不是「小任务」的同义词。升级判据（与「myworkflow-lightweight-dispatch」同一组，任一命中）：出现跨交付物接口/依赖、需要跨回合持续负责人、需多批推进与补位、需要并发调整与验收裁量 → L3。
• L3 智能体团队（team）适用：大型、长程任务——把超大任务切成若干相互独立的部分，模仿真人团队「各自独立工作 → 沟通 → 整合」；判据仍是多域协作、交付物之间存在接口/依赖、需要跨回合持续负责人、需要多批推进与补位。不要因为「任务大」就建团，要因为「需要持续负责人与并行独立交付」才建团。 形态：建团队，按角色分工（见下一条）。关键等价关系：团队里的每个 member 相当于一个 L2（领域级的 L2）——各自独立端到端完成自己那份，再与其他人沟通整合。
• L3 角色：leader 只做四件事——定目标与边界、建团队、下模块委托（mission）、监督与验收裁量；不亲自产出交付物、不写业务文件、不逐批派活、不替成员拆叶子任务。member 是持久存在的域 owner：收到「目标+边界+输入+验收」后自己规划、自己授权派发、自己验收结算，端到端完成一整件事。leaf 是 fresh 上下文的最小任务包执行者，一次实现并自检后交回产物与证据；leader 与 member 都可以启动 leaf，leaf 不能再开 leaf。
• member 之间可直接沟通：member 与 member 可直接相互发消息、不经过 leader 中转。任务切分在开始时不可能完美，执行中会出现交叉、重叠、接口变化、相互依赖；成员之间直接沟通比「上报 leader 再转发」效率更高。leader 只在边界冲突需要裁决、目标需要变更、验收标准需要修改时介入，日常协作 member 自行协商；沟通后若改了交付边界，同步 leader 记录在案即可，不必阻塞等待批准。
• member 与 leaf 的区别：leaf/subagent 寿命绑定具体任务——任务完成即结束、不保留；职责是一个具体任务（输入=被派发的任务包，输出=可验收产物），只与派发者/owner 沟通。member 长期存在——睡眠/随时唤醒复用、跨任务保留知识与状态；职责是一个领域（「集中体」，掌管这一整类可能的工作；输入=领域目标与边界，输出=领域内多批交付物），可直接与其它 member、leader 沟通。一个 member 相当于一个领域级的 L2。
• 用户意愿优先：用户明确要求团队 / 子智能体时，遵循用户指定级别（需求澄清时确认一次级别选择），即使判据倾向更低级；若用户要求与「禁止阶段拆分」冲突，按后者拒绝并说明原因、给出可执行的横向重排方案。
• 禁止阶段拆分（硬规则）：一个交付物内部不得按时间/工序拆成多个窗口或智能体接力（如「调研→设计→实现→审查」各派一人）。合法切分只有横向切分：拆出的每一份都能独立交付、独立验收。横切之后出现交叉/重叠/依赖，靠 member 之间直接沟通解决，不靠拆阶段解决。
• leaf 不能再开 leaf：leader 与 member 都可以启动 leaf；leaf 不能再启动 leaf，也不能建同级成员或团队；需要更大能力时交回 owner 决策。

第二步：按交付物形态选类别（速查表）

检查 / 审计 / 验证 / 排查：E3 零猜想（硬规则）

判定为检查 / 审计 / 验证 / 排查类任务后，先声明「本任务按 E3 零猜想执行」，再动手：

• 每条结论必须绑定证据与出处：命令 + exit code、文件 + 行号、runId、产物 sha256、日志片段至少一项；没有证据的观察不算结论。
• 无法核实的写「未核实 / 无法判定」，并说明影响与下一步核实方法；禁止用「应该 / 大概 / 可能 / 通常」下结论。
• 假设必须显式化：拿不到证据时写「假设（未核实）」并立刻去核实（E2），不把假设当事实。
• 禁止编造：不得补造 API / 路径 / 行号 / 版本 / 测试结果来让报告「看起来完整」（E5）。
• 关键事实交叉核对两个独立来源（源码 + 实测 / 文档 + 运行输出），冲突时以可执行结果为准并记录冲突（E6）。
• 代价优先（E7）：结论含「可以改 / 没问题」时必须附代价与风险说明（不可逆 / 影响面 / 能否回滚）；高风险先备份、预演、小步验证，不确定按高风险处理。

专门任务（专项包技能）分类

判据（任一命中）：① 用户明确要做某项专项工作；② 目标领域对应 packdge 专项技能（<packdge>-<skill>）；③ 不属既有「代码 / 文稿 / 调研 / 检查」类。

分界一句话：改仓内代码 / 文件 → 一般开发任务；多源检索出报告 → 深度调研；有现成 packdge 专项技能 → 专门任务，直接加载。

路由动作：查 DSH 技能 catalog（含 packdge 技能）→ 命中即 skill(name="<packdge>-<skill>")；无命中不得臆造技能名，回退 L1/L3 或询问用户。

与级别关系：只决定加载哪个技能，不改 L1/L2/L3 与「不要因为任务大就建团」。

级别与技能的对照

• L1：不加载协作类技能，当前上下文直接做完。
• L2：加载 skill(name="myworkflow-lightweight-dispatch")（L2 子智能体操作规程）。
• L3：加载 skill(name="myworkflow-task-dispatch")（L3 拆分契约）+ skill(name="myworkflow-subagent-protocol")（协作协议）。

不在这张表里的技能

以下技能不参与任务分类，但在上表任一流程中都可能被调用：

• 工具性：req-clarify（需求澄清）、lessismore（输出克制）、registry-maintain（注册表维护）
• 协作与执行：task-dispatch、lightweight-dispatch、subagent-protocol、integration-verify
• 项目管理：project-init、project-maintain
• 代码细节：root-cause-analysis、real-world-verify、github-collab

• 替代口径：要求「跳过验证 / 先跑起来再说」时，不再用专门质疑技能——把「先验证再行动、发现红旗给可执行替代方案」并入 agent-dev-loop 的验证门禁与 req-clarify 的确认规则（见这两个技能正文）。

完成判据

• [ ] 已给出工作级别 + 理由（L1/L2/L3 与命中的判据）
• [ ] 用户明确指定级别时，已按「用户意愿优先」记录取舍
• [ ] 已按交付物形态选定类别并加载对应技能
• [ ] 级别与动作一致：L1 不派发、L2 平铺派发、L3 建团队并下 mission
• [ ] 若发生切分，已确认每份都能独立交付、独立验收（无阶段接力）
• [ ] 若是续接回合：已先对账确认进度（不凭记忆）、已跳过 accepted 交付物、只推进最小下一步
• [ ] 若成员间出现交叉/依赖，已按「member 之间可直接沟通」直接协商解决（不靠拆阶段）
• [ ] 若属检查 / 审计 / 验证 / 排查类：已按 E3 零猜想执行（结论绑证据与出处、无法核实的写「未核实」、未编造、关键事实已交叉核对）
• [ ] 若属专门任务（专项包技能）：已查 DSH 技能 catalog 命中 <packdge>-<skill> 并加载；无命中已回退 L1/L3 或询问用户（未臆造技能名）