用途：当需求足够明确、且工作跨越多个步骤、文件或验证阶段时，把需求转化为可执行的实现计划，用具体文件、测试与验证步骤消除猜测。
适用时机：任务涉及多个文件、阶段或检查；需求已相对稳定；有书面执行顺序会更清晰。不适用：改动小到可直接在 update_plan 中跟踪；需求仍含糊；用户要求立刻实现且工作琐碎。
使用方式：写计划前先阅读相关代码、文档与既有规格，确认范围是一个连贯的工作单元；若计划会依赖猜测的需求，应先停下来澄清；若请求包含多个独立改动，应拆成多个计划或清晰分组。
计划格式：保存到用户指定位置，未指定则用 docs/plans/YYYY-MM-DD-<topic>.md。开头包含标题、Goal、Scope、Non-goals、Risks。随后列出文件（Create/Modify/Test 路径），以及每个任务的 Outcome、Steps、Verification（确切命令与预期结果）、Dependencies。
规划规则：使用精确文件路径；任务应可独立评审；改变运行时行为时体现测试先行；命令须能在仓库中实际运行；步骤具体化；除非为安全所需，不夹带无关重构。
衔接与限制：若同会话执行，用 update_plan 镜像任务列表，保持一个任务 in_progress，发现真实缺口时修订计划；若存在独立旁支工作，用 dispatching-parallel-agents 拆分不重叠的子任务。危险信号包括：依赖其他工具链名称、多个并行工作者改同一文件、缺少验证步骤、把迁移或契约变更埋在笼统表述中，以及"按需更新""处理边界情况"这类占位语。原文未提供具体收费、平台或效果信息。