code-worker-governance

使用方式

• 当用户想使用 code-worker MCP，或当前任务明显适合交给 code-worker 时启用。
• 进入本 skill 后，先让用户只选一次执行档位：
  • 1. 快速
  • 2. 思考
  • 3. 自动
• 先做场景判定，再决定是否真的下发 worker；不要把它当成默认执行器。
• 主线程默认只读紧凑结果，不默认读全量日志、events、diff。
• 默认先单 worker 探路；只有共享抽象稳定、改动面低重叠时才开并行 worker。
• 长任务默认进入静默治理：主线程少说、少读、少轮询。
• 这个 skill 只负责“本次动作如何使用 code-worker”；安装、配置、预览安装说明放 README，不在这里展开。

执行档位

• 选项映射：
  • 1. 快速 -> execution_tier=fast
  • 2. 思考 -> execution_tier=think
  • 3. 自动 -> execution_tier=auto
• 主线程与用户沟通时，只说 快速/思考/自动，不默认展开底层模型名。
• 真正下发单个 worker 前，主线程必须让该 worker 落成明确档位：
  • fast
  • think
• auto 只允许存在于“用户选择”和“主线程编排”阶段，不作为多子任务最终汇总的展示值。
• 如果底层 MCP 返回了短标签，展示优先级：
  • 快速（flash）
  • 思考（pro）
  • 若无短标签，仅展示 快速/思考

自动分配规则

• 当用户选择 3. 自动：
  • 先拆子任务，再给每个子任务单独分档
  • 不要把整个需求统一粗暴下发成一种档位
• 默认分到 快速：
  • 单文件小改
  • 小范围机械补丁
  • 胶水代码
  • 测试补齐
  • 低风险脚手架
• 默认分到 思考：
  • 多文件实现
  • 调试闭环
  • 跨层调用链修改
  • 共享抽象收敛
  • 命名/契约/状态流转敏感改动
  • 大范围链路梳理或复杂失败分析
• 如果任务先被判定为 纯读大范围 且决定起 worker：
  • 默认 思考
• 如果主线程无法稳定判断：
  • 默认上调到 思考

快速判定

• 推荐使用：
  • 多文件实现
  • 调试闭环：读错误、定位、修复、复跑
  • 大范围代码扫描：链路梳理、审计、模式搜索
  • 长时间后台任务：慢检查、慢构建、长推理
• 默认不用：
  • 单文件阅读
  • 单文件小改
  • 纯解释代码
  • 需求澄清、方案讨论
  • 高频碎片 follow-up

决策流程

1. 先把任务归类为：
   • 纯读小范围
   • 纯读大范围
   • 小范围改单文件
   • 多文件实现
   • 调试闭环
   • 长时间后台任务
2. 如果属于 纯读小范围 或 小范围改单文件：
   • 主线程直接做
   • 不起 worker
3. 如果属于 纯读大范围：
   • 只在主线程自己读会明显吃上下文时才用 worker
   • 用 review 倾向的 task，接受 completed_no_changes
4. 如果属于 多文件实现 或 调试闭环：
   • 优先用 worker
   • 优先把目标收窄为一个清楚子任务
   • 默认先做一轮串行探路，不把并行当起手式
5. 如果属于 长时间后台任务：
   • 用异步 worker
   • 主线程不要频繁拉日志

拆分与并行规则

• 默认拆到“可独立验收的业务边界”，不要按文件数或函数数机械拆分。
• 如果多个子任务会同时改这些共享定义，禁止直接并行：
  • 公共枚举
  • 公共 DTO / VO
  • 核心 resolver / router / orchestrator
  • 核心 service 入口
  • schema / migration / prompt 路由核心类
• 如果两个模块存在潜在共享抽象，但抽象还没稳定：
  • 先创建一个“抽象收敛任务”
  • 用单 worker 串行完成公共接口、枚举、命名、默认行为
  • 收敛后再拆模块实现
• 只有同时满足下面条件，才允许并行 worker：
  • 共享底座已稳定
  • 任务之间改动面低重叠
  • 每个子任务都能独立验收
  • 失败后不会连锁回滚另一个子任务
• 并行 worker 完成后，不要逐个重 CR：
  • 先做一次复用性 CR，检查重复抽象、命名漂移、默认值冲突
  • 再做一次统一最终 CR