TomorrowLM 子智能体驱动开发
用于编排已经明确拆分的多子代理开发任务。它负责任务边界、上下文交接和执行顺序；TDD、调试、代码审查、最终验证和 Git 收尾由对应技能按需负责。
适用条件
同时满足以下条件时使用：
- 已有可执行计划，包含两个或以上边界清晰的子任务。
- 子任务可以独立交接，并能明确需求、依赖、文件范围和验证方式。
- 确实需要新子智能体分别处理，而不是主会话顺序执行或只做并行调查。
以下情况不使用：
- 需求尚未形成计划。
- 任务高度耦合，无法独立交接。
- 只是单文件修改、单次调查或主会话直接实现。
HARD-GATE
- 没有真实分派新子智能体时，不得声称使用了本技能。
- 子智能体不能依赖主会话隐式历史；主控制者必须传入完成任务所需的完整上下文。
- 并行任务必须明确文件边界、共享依赖和冲突处理方式；不能只以“并行”作为隔离依据。
- 最新代码没有验证证据时，不得标记任务完成或宣称整体完成。
执行流程
- 确认存在可执行计划；没有计划时先使用
writing-plans。 - 为每个任务准备完整上下文：需求、验收标准、依赖、允许修改的文件、验证方式和已知风险。
- 上下文必须隔离；并行修改可能冲突时，再使用独立工作区或其他文件隔离手段。
- 每个任务分派一个新的实现子智能体。行为变更、Bug 修复或重构时衔接
test-driven-development；调试任务衔接systematic-debugging。 - 实现交付后，按任务风险进行规格审查和代码质量审查；规格审查未通过时不进入质量审查。
- 审查问题由实现者或主控制者修复；修复后对受影响范围执行 Delta Review，必要时重新进行规格审查。
- 所有修改完成后，由
verification-before-completion对最新代码执行最终验证。 - 全部子任务完成后，再执行一次整体验证；提交、合并和分支收尾交给对应 Git 流程处理。
角色边界
- 主控制者：拆分任务、准备上下文、分派子智能体、处理冲突、决定审查范围并收口。
- 实现子智能体：只实现分派任务，完成必要测试和自审，汇报状态与风险。
- 规格审查者：检查需求是否完整实现，以及是否存在多余实现。
- 代码质量审查者：检查代码质量、契约、安全性和影响面，不负责调试或修复。
verification-before-completion：根据最新命令输出验证并允许或拒绝完成声明。
异常处理
NEEDS_CONTEXT：补充缺失上下文后重新分派，不要求子智能体猜测。BLOCKED：判断是上下文、能力、任务规模还是计划问题，再补充信息、升级模型、拆分任务或回报用户。DONE_WITH_CONCERNS：先阅读疑虑；涉及正确性或范围的问题必须解决，观察性说明可以记录后继续审查。- 审查发现问题：修复后重新审查，不得直接进入下一个任务。
技能衔接
dispatching-parallel-agents：多个真正独立的调查或操作并行执行时使用；需要完整实现交接时使用本技能。test-driven-development：负责测试先行，本技能不重复定义红绿重构细节。systematic-debugging：负责复现、根因和影响面调查，本技能只负责任务编排。requesting-code-review：负责正式代码和影响面审查，本技能只决定交接时机。verification-before-completion：负责最新代码的最终验证和完成声明。