使用方式

• 当用户想使用 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. 先把任务归类为：

• 纯读小范围
• 纯读大范围
• 小范围改单文件
• 多文件实现
• 调试闭环
• 长时间后台任务

1. 如果属于 纯读小范围 或 小范围改单文件：

• 主线程直接做
• 不起 worker

1. 如果属于 纯读大范围：

• 只在主线程自己读会明显吃上下文时才用 worker
• 用 review 倾向的 task，接受 completed_no_changes

1. 如果属于 多文件实现 或 调试闭环：

• 优先用 worker
• 优先把目标收窄为一个清楚子任务
• 默认先做一轮串行探路，不把并行当起手式

1. 如果属于 长时间后台任务：

• 用异步 worker
• 主线程不要频繁拉日志

拆分与并行规则

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

推荐工作流

1. 先单 worker 探路

• 暴露共享抽象
• 识别核心耦合点
• 判断哪些任务真能独立

1. 如需共享底座，先串行完成
2. 只把独立切面并行下发
3. 所有拆分任务统一最终 CR，不做“一子任务一 CR”

Tool 选择

• 极小任务：主线程直接做，不用 MCP
• 小范围且明确能一次收敛：
• code_worker_implement_in_workspace
• 多文件、长任务、需要后台挂起：
• code_worker_start_implementation
• 后续配合 get_job / wait_for_job
• 非必要不用：
• include_logs: true
• include_events: true
• include_diff: true

等待策略

• code_worker_wait_for_job 只用于短前台观察，不作为主循环。
• 默认前台观察一次即可：
• 建议 max_wait_ms=180000~240000
• 不要把单次前台等待压到 5 分钟以上
• 只要前台观察后同时满足这些条件，就视为“健康可放行”：
• status=running
• process_alive=true
• heartbeat 正常
• last_error_kind 为空
• token_progressing=true 或 stream_progressing=true
• 一旦判定为“健康可放行”：
• 主线程立刻停止前台长等
• 不继续反复 wait_for_job
• 改成静默阶段，按 next_recommended_check_after_ms 调 code_worker_get_job
• 若 MCP 未给明确建议值，长任务默认 300000~600000ms 读一次
• 默认不展开 logs/events/diff
• 如果线程历史明显变长，或长任务结束后还要继续 follow-up：
• 默认优先使用 context-compression 做摘要收口
• 先压历史，再继续主线程执行
• 静默阶段的主线程行为：
• 不做阶段性复盘
• 不根据“安静很久”本身中断任务
• 不为了确认“是不是还在想”而补发高频探测
• 只有出现这些信号，才缩短查询间隔或升级介入：
• liveness_state=running_suspected_stall
• liveness_state=running_stalled
• heartbeat 不健康
• last_error_kind 非空
• checks 失败或终态异常
• 如果长任务超过 10 分钟但仍持续 token_progressing：
• 视为正常工作，不作为异常信号
• 如果任务进入 text_delta / final_result 附近：
• 再给一次短前台观察窗口即可，不要重新回到高频轮询

use_case 选择

• fast_patch
• 明确很小的实现补丁
• scaffold_or_tests
• 补测试、脚手架、胶水代码
• debug_loop
• 复现、定位、最小修复、复跑
• agentic_coding
• 多文件实现、跨层改动
• complex_reasoning
• 大范围代码扫描、架构/链路梳理、复杂失败分析

task brief 模板

下发 worker 时，主线程只给最小必要上下文，建议结构：

Task:
- Task label: <短标签，供最终汇总>
- Goal: <单一明确目标>
- Requested tier: <用户选择 fast/think/auto>
- Resolved tier: <本 worker 实际使用 fast/think>
- Scope: <允许改动的目录/文件>
- Do not touch: <禁止路径>
- Validate: <检查命令>
- Output: <希望 worker 最终说明什么>
- Previous result: <如有续跑，仅带 job_id / 终态 / 当前 diff 摘要>

• 对实现类 worker，默认要求最终输出使用短结构，减少主线程二次理解成本：

Summary
- Goal completed: <yes/no>
- Files changed: <list>
- Checks run: <list + result>
- Residual debt: <only if any>
- Risk points: <only if any>
- Contract-impacting changes: <only if any>

规范传递规则

• 主线程命中的 skill 或 AGENTS 规则，不会自动完整传到下游 worker。
• 必须显式写进 task brief 的约束才认为会稳定生效，例如：
• 命名统一业务术语
• 失败统一 log.error
• 不做无关重构
• 只更新当前步骤必要字段
• 路径边界、禁止路径、检查命令这类硬约束，优先通过 MCP 参数表达，不只靠文字提醒。

约束模板

如果当前仓库有明确研发规范，task brief 里追加一段：

Implementation constraints:
- <规则 1>
- <规则 2>
- <规则 3>

例如：

Implementation constraints:
- 命名统一业务术语，不混用 renew/extend
- 核心步骤前写简短注释
- 失败统一 log.error，带关键标识
- 不做无关重构

低成本 CR 规则

• 主线程先做 L1 轻审，只有命中高风险才升级 L2 重审。
• 主线程默认按这个顺序审：

1. status
2. task_label
3. execution_tier / model_label
4. failure_reason
5. files_changed
6. review_summary
7. checks_run
8. 只展开核心文件 diff

• 默认不看：
• stdout_tail
• stderr_tail
• recent_events
• tool_events
• L1 轻审 默认只看：
• files_changed
• review_summary
• checks_run