Imported from DJackyB/Project_Rent (.claude/skills/development-task-routing/SKILL.md). Install upstream with npx skills add DJackyB/Project_Rent --skill development-task-routing. Copyright stays with the author.

开发任务拆分与分派

概览

这个 skill 用于新任务启动阶段，先解决“任务怎么拆、谁来做、做到什么算完成、什么时候回收”，再进入具体实现。

核心目标：

• 把任务拆成可执行、可验收、可交接的子任务
• 把关键判断留在主 AI 手里，不把总控外包
• 根据任务性质把工作交给最合适的执行者
• 接受手工配置和人工接线，不为了“一次到位全自动”而过度工程化
• 非必要不加保底防御，让真实问题尽早暴露

与其他 skill 的关系

• 先用本 skill 做任务启动、拆分、分派、回收计划和联调安排
• 子任务落地时，再按需要调用：
  • delivery-first-code-guardrails
  • module-boundary-and-configuration
  • engineering-documentation-rules
• 如果任务本身非常小，不强行套完整编排流程，直接做即可
• 如果只是想快速开启新任务，可直接复用 references/task-kickoff-prompts.md 里的固定起手模板

工作顺序

处理新任务时，按下面的顺序思考和执行：

1. 先定义目标、非目标、约束、真源和交付边界。
2. 自动判断当前任务是否需要进入 plan 模式。
3. 判断任务规模：小任务、中任务或大任务。
4. 如果需要拆分，先拆阶段，再拆成可交接的子任务。
5. 为每个子任务指定执行者、前置条件、回收点和验收方式。
6. 显式区分代码任务、配置任务、手工任务和验收任务。
7. 执行过程中由主 AI 持续维护任务图、依赖关系和风险状态。
8. 集成阶段显式联调、回收、验收，不默认“拼起来就能用”。

原则 1：先自动判断是否需要进入 plan 模式

主 AI 在任务启动时，先判断当前任务是否只是可以直接落地的小任务，还是已经进入需要先规划再执行的复杂区间。

应进入 plan 模式的情况

• 涉及多个阶段，且阶段之间存在明显依赖
• 存在多个可选方案，且不同方案后果不直观
• 涉及多个执行者协同，主 AI 需要先定义分工
• 需要先澄清范围、非目标、风险边界或验收策略
• 需要你拍板的大型决策尚未确认
• 一旦直接开工，返工成本明显较高

可不进入 plan 模式的情况

• 单点 bug，问题与修复范围都很清楚
• 小范围优化，目标明确且不涉及架构取舍
• 局部实现或配置修补，不存在重要路线分叉
• 主 AI 已有足够上下文，可以直接执行并快速验证

执行要求

• 如果判断需要 plan 模式，先规划，再执行。
• 如果环境支持 plan 模式，就进入 plan 模式组织步骤、依赖和回收点。
• 如果当前环境不支持切换 plan 模式，也要按 plan 模式的思路先输出明确计划，再继续执行。
• 不要把“先计划”理解成拖延；计划只服务于降低返工和沟通成本。

原则 2：先判断值不值得拆

• 单点 bug、小范围逻辑调整、单文件修复，不为了“看起来规范”而硬拆。
• 涉及多模块、逻辑与 UI 并存、配置与接线并存、需要多人或多 AI 协作的任务，必须拆。
• 拆分的目的不是制造流程感，而是降低上下文成本、返工成本和交接成本。

适合直接做的小任务

• 改一个明确定位的 bug
• 调整一个清晰边界内的小功能
• 补一个局部测试
• 修一处文案、参数或简单接线

必须拆分的任务

• 新功能开发，且同时涉及核心逻辑、UI、配置、资源或验收
• 优化已有功能，且需要跨多个路径定位瓶颈或拆分风险
• 修复复杂 bug，且需要复现、定位、修复、回归验证分阶段推进
• 任何明显适合不同执行者分工的任务

原则 3：先拆阶段，再拆任务

推荐先按阶段拆，再决定每一段由谁执行：

1. 启动与约束确认
2. 方案与接口定义
3. 子任务实现
4. 配置、接线或资源整理
5. 联调与验收
6. 文档与收尾

一个子任务只有在满足以下大部分条件时，才算拆得合格：

• 有明确目标
• 有清晰边界
• 输入和输出明确
• 可单独交给某个执行者
• 完成后可被主 AI 回收
• 有明确验收方式
• 写入范围或操作范围清晰

原则 4：大型决策必须先询问用户，再执行

凡是会显著影响范围、成本、路线、兼容性或后续维护方式的大型决策，主 AI 都必须先询问用户，不得自行拍板。

必须先询问的决策

• 是否要改架构或改模块边界
• 是否要引入长期配置、长期自动化或新的基础设施
• 是否要放弃现有实现路线，改走另一条方案
• 是否要做影响较广的重构、迁移或接口改造
• 是否接受某些明显的取舍：性能换复杂度、速度换质量、自动化换手工、短期修补换长期治理
• 是否把原本人工执行的环节改成自动化，或反过来

询问方式

• 用简洁语言说明当前决策点
• 明确列出推荐选项和主要代价
• 说明如果不做这个决策，当前最保守的推进方式是什么
• 在用户答复前，不要默认进入高影响路线

可默认决策的情况

• 明显局部且可逆的小实现细节
• 不改变总体方向的低风险局部取舍
• 不影响其他执行者分工和后续维护方式的技术细节

原则 5：执行者按任务性质分配，不按工作量平均分配

不要追求“大家都做一点”，而要追求“最适合的人做最适合的事”。

主 AI

主 AI 默认负责：

• 任务规模判断和拆分
• 最终方案、约束、优先级和依赖关系
• 子任务包编写
• 执行者选择与顺序安排
• 阶段性回收和结果审核
• 联调、冲突消解和最终验收
• 对外说明、风险汇总和下一轮安排

主 AI 不应外包：

• 架构走向和关键取舍
• 子任务边界定义
• 最终是否达到可交付状态的判断

Claude Code

优先交给 Claude Code 的任务：

• 核心业务逻辑
• 关键数据流、状态流和规则实现
• 高风险重构
• 对代码质量要求最高的核心片段
• 最容易留下隐性 bug 的复杂实现

不优先交给 Claude Code 的任务：

• 纯手工配置
• 一次性低价值拼接
• 上层方案未定时的盲写实现

Codex 子 agent

优先交给 Codex 子 agent 的任务：

• 边界清晰、写入范围独立的实现切片
• 不阻塞主路径的读码分析、搜索、测试补充或辅助实现
• 主 AI 已经定义好接口后的局部落地
• 可并行推进的 sidecar 子任务

不优先交给 Codex 子 agent 的任务：

• 会阻塞下一步关键决策的任务
• 与其他实现写入范围高度重叠的任务
• 需要深度架构取舍的核心设计判断

Antigravity

优先交给 Antigravity 的任务：

• 需要人工介入的 UI 配置、Prefab / Inspector / 场景接线
• 代码不值得自动化的一次性拼接工作
• 依赖肉眼判断、交互体验或外部工具操作的工作
• 代码做不了，或做了反而更脆弱的部分

交给 Antigravity 时仍然必须写清：

• 目标对象
• 需要修改的配置或节点
• 不应误动的范围
• 成功标准
• 最短验收路径

人工执行

适合保留人工执行的任务：

• 产品取舍、视觉取舍、命名取舍
• 一次性配置固化
• 明显比自动化更便宜的接线工作
• 高风险操作前的最终确认
• 真实体验验收

如果当前环境无法直接调用某个执行者，也不要抹掉它的职责，而应在计划里保留该 owner，并把它标记为待转交或待人工执行。

原则 6：接受显式配置和手工接线，不强求一次性全自动

• 如果显式配置、手工接线或人工拼接更清晰、更便宜、更稳定，就接受它。
• 不要为了少一次手工操作，提前引入一套沉重的自动化结构。
• 一次性工作、低复用工作、强依赖人工判断的工作，不必强行代码化。
• 手工步骤不是“没做完”，但必须被明确记录、明确分派、明确验收。

推荐做法

• 优先显式配置，而不是运行时猜测
• 优先把手工步骤写成任务，而不是藏在口头说明里
• 优先让配置缺口暴露出来，而不是用伪自动化掩盖

不推荐做法

• 为了一次性接线搭长期框架
• 把人工步骤伪装成不透明脚本
• 实际仍需手工调整，却对外宣称“已经全自动”

原则 7：非必要不做保底防御，让问题提前暴露

• 缺配置、缺引用、错误接线、非法状态、契约不满足时，应尽早报错。
• 不要为了流程“看起来顺”，就增加静默 fallback、默认值补齐或假装成功。
• 只有被明确设计为可选能力的部分，才允许受控降级。
• 主链路的真实问题，应该在启动、集成或验收阶段尽快暴露，而不是拖到线上或更深层调用才爆。

可接受的降级

• 可选 UI 效果缺失
• 非关键增强能力缺失
• 明确声明为可选模块的功能暂时关闭

不可接受的降级

• 核心业务逻辑错误
• 关键配置缺失
• 契约或生命周期不成立
• 关键数据真源不明确

原则 8：每个子任务都必须有任务包

交给任何执行者之前，主 AI 都应尽量提供标准任务包。

任务包至少应包含：

• 子任务名称
• 执行者
• 分派原因
• 目标
• 范围边界
• 前置条件
• 输入材料
• 预期输出
• 非目标
• 验收标准
• 允许修改的范围或操作范围
• 回传结果的方式

如果是手工任务或配置任务，还应补充：

• 目标对象或目标节点
• 当前现状
• 需要人工确认的点
• 最短验收路径

原则 9：先定接口和边界，再并行

• 在接口、契约、边界还没定清楚之前，不要急着把实现分发出去。
• 适合并行的任务应满足：低耦合、低写入冲突、可独立验证、不会阻塞主 AI 的下一步判断。
• 配置与接线任务通常应在结构稳定后启动，但不要拖到最后才想起。
• 联调和验收必须有明确 owner，不能成为无人负责的尾巴。

适合并行的任务

• 独立逻辑切片
• 独立测试补充
• 独立文档更新
• 已定接口下的局部实现

不适合并行的任务

• 核心方案仍在摇摆的任务
• 写入同一批关键文件的任务
• 必须等上游结果确认后才能开始的任务

原则 10：主 AI 必须显式回收、联调和验收

子任务完成不代表整体完成。

主 AI 在回收阶段应显式检查：

• 接口是否对齐
• 命名和约定是否一致
• 代码结果和配置结果是否真正接上
• 手工步骤是否已经完成
• 测试或人工验收是否覆盖关键风险
• 是否仍存在被掩盖的问题

联调不是简单拼接，而是一个独立阶段，应包含：

• 结果汇总
• 冲突消解
• 配置补齐
• 行为验证
• 风险复核
• 对外说明

原则 11：不同任务类型采用不同编排重心

新功能

• 主 AI 先定目标、非目标、接口和子任务图
• Claude Code 负责关键核心实现
• Codex 子 agent 负责辅助实现、测试、分析或低耦合切片
• Antigravity 或人工负责 UI 配置、场景接线、资源拼接和体验核对
• 主 AI 最后联调、验收、补文档

优化已有功能

• 主 AI 先定优化目标、瓶颈范围和不允许破坏的行为
• Claude Code 负责关键热路径或复杂重构
• Codex 子 agent 负责辅助排查、局部整理、测试或旁路改动
• Antigravity 或人工负责编辑器配置、可视化核查或体验确认
• 主 AI 回收并确认“优化收益是否真实存在”

修复 bug

• 如果是小 bug，直接修，不为套流程而拆
• 如果是复杂 bug，拆成复现、定位、修复、回归验证、人工验收几个阶段
• 根因分析和最终收口仍由主 AI 保持统一口径

输出模板

当主 AI 使用本 skill 启动一个开发任务时，建议至少输出：

1. 总目标
2. 非目标
3. 是否进入 plan 模式，以及原因
4. 任务规模判断
5. 真源、约束和主要风险
6. 需要先询问用户的大型决策清单
7. 子任务列表
8. 每个子任务的执行者、原因、前置条件和验收标准
9. 并行与串行关系
10. 需要人工执行或手工配置的清单
11. 联调回收点
12. 最终验收方式

审查清单

开始执行前检查：

• 当前任务是否需要先进入 plan 模式？
• 这个任务真的需要拆吗？
• 是否存在尚未向用户确认的大型决策？
• 当前拆分颗粒度是否适合交接？
• 是否已经明确谁负责总控、谁负责实现、谁负责人工步骤？
• 是否把本该显式配置的内容错误地推给自动推断？
• 是否把本该暴露的问题用 fallback 掩盖掉了？
• 是否存在没人负责的联调或验收尾巴？
• 是否把不值得自动化的事情强行自动化了？
• 是否把高价值核心实现交给了最值得信任的执行者？

常见错误

• 明明已经进入复杂决策区，却还跳过 plan 直接开工
• 大型路线选择没有问用户，主 AI 自行拍板
• 小任务也强行拆分，导致流程成本高于执行成本
• 把关键架构判断外包出去，主 AI 失去总控
• 没定接口就让多个执行者同时写实现
• 手工配置明明必需，却没人明确负责
• 为了一次性工作搭长期自动化框架
• 用默认值、静默降级或保底逻辑掩盖真实问题
• 联调和验收没有 owner，最后谁都以为不是自己的事