简洁规划

要解决什么问题

接到「改这个功能」「加一层能力」这类请求时，模型容易直接开写代码，或列出一长串模糊待办。缺少单一、可执行的边界：做什么、不做什么、先改哪几个文件、怎么验。协作里还会反复追问细节，把规划本身拖成对话成本。

技能如何工作

简洁规划把用户请求收敛成一份结构化计划，而不是立刻动刀：

1. 扫描上下文 — 读 README.md、文档与相关代码，识别语言、框架、测试等约束。
2. 最小化交互 — 只在真正阻塞时提问，最多 1～2 个问题；对非阻塞未知项做合理假设。
3. 生成计划 — 固定四段：思路（Approach）（1～3 句说明做什么与为什么）、范围（Scope）（「做 / 不做」要点）、行动项（Action Items）（6～10 条原子、有序、动词开头，尽量点到具体文件或模块）、验证（Validation）（至少一项可执行的测试或检查）。

清单准则强调：原子化（一步一个逻辑单元）、动词开头（如「添加…」「重构…」「验证…」）、具体（能指文件就指文件）。

适用边界

适合需要先对齐方案再改代码的任务；不适合已经给出逐步指令、只需照做的机械执行。计划步数刻意控制在 6～10，过细或过粗都不符合模板预期。若上下文缺失严重，仍可能需要在「阻塞」处提问——技能限制的是次数，不是禁止澄清。