计划架构师

核心问题

拿到一份 design.md 之后，团队常面临的实际问题是：设计文档写得足够清楚，却无法直接分配给工程师执行。任务边界模糊，文件路径不明确，验证标准也常常缺失。最终，项目经理只好凭感觉切分工作，导致任务粒度过大，新人无从下手，代码评审也难以把关。

计划架构师就是为了解决这个断层而生的技能。它不负责写业务代码，而是把设计文档翻译成一份精确到每个文件的执行计划，让哪怕是“热情但缺乏判断力的初级工程师”也能按图索骥。

运作方式

该技能的核心在于极细粒度的任务拆分和测试驱动开发（TDD）的深度结合。具体工作流如下：

• 输入解析与约束确认：读取 design.md，提取目标、范围及技术栈版本，同时确认团队规模与时间限制。
• TDD 驱动拆解：严格遵循红-绿-重构循环。每个任务仅包含 2-5 分钟的工作量，且必须遵循先写失败测试、再写最小实现的逻辑。
• 多维度分层：计划会按数据层、服务层、API 层到 UI 层的顺序进行拆解，无依赖任务标注为可并行，有依赖任务则明确阻塞关系。
• 原则守护：内置 YAGNI（不实现未要求的功能）和 DRY（重复代码提取，但遵循 Rule of Three 不过度抽象）原则的自动检查。
• 产出交付：最终生成一份 plan.md 文档，包含带编号的任务列表、依赖关系图、总时长预估，以及附带一键运行命令的检查清单。

适用边界

这并非一个全自动代码生成器，它要求输入的设计文档具备一定的准确性。此外，该技能产出的是方法论层面的指导计划，最终的代码实现仍需依赖 Agent 的 exec 执行能力。它非常适合用于处理复杂的技术债务清理或大型功能模块的落地前规划。