实施计划编写

问题：从想法到改动之间的断层

在真实代码库中，一段简短需求往往对应多处文件改动、测试补强、工具链约定和提交策略。若直接让模型或新加入的工程师动手，容易出现三类问题：只说“添加校验”却不给完整代码；忽略测试失败/通过的验证闭环；把大任务混在一起，导致难以审查和回滚。writing-plans 把实施计划当作可执行文档来写，而不是产品说明。

工作方式：把计划拆成 2–5 分钟的动作

该技能会要求计划面向“熟练但不了解本仓库”的开发者，显式记录：

• 每项任务要改动的精确文件路径
• 需要写入的完整代码，而不是概括性描述
• 可执行的 bash 命令、git add / git commit 步骤
• 测试用例、预期失败与预期通过的验证顺序
• 遵循 DRY、YAGNI、TDD 和频繁提交的工程约束

计划通常保存为 docs/plans/YYYY-MM-DD-.md，并在保存后提供两种执行路径：当前会话中使用子代理逐任务执行，或切换到独立会话分批执行并设置检查点。

适用边界

它适合需要可审查、可交接、可逐步实现的开发任务，尤其是测试驱动和文件路径明确的工作。不适合只做一次性脚本、纯口头方案，或缺少明确验收标准的探索性需求。