用途：在实施代码改动前，先形成方案、范围与验证计划。它从“为什么”出发，说明改动对用户的价值、如何契合现有系统，以及将以哪些可验证切片交付。
主要能力：一是确立 Why，明确服务对象、解决的问题与成功标准，并据此形成验收标准与范围判断；若用户只给出做法（如“加一列”“换成 X”），需追问其目的。二是决定 How，基于现有模块、接口或模式选择方案，说明哪些保持不变、哪些权衡重要；仅在选择关键时比较替代方案，保持抽象，不写代码或伪代码。三是把 What 切成有序切片，每个切片包含可观察结果、在真实系统上的验收方式、触及的边界，以及服务于 Why 的哪一部分。四是确定验证与权限，包括测试优先选择、项目验证方式、提交策略与需审批事项。
使用方式：先检查解决规划决策所需的说明、代码、测试与配置，复用已有上下文。若仓库有 verify 技能，可在其功能映射中定位请求所指功能。对尚未观察到的依赖（外部端点、GPU 路径、第三方权限、部署目标）应先实际验证一次。规划本身不授权修改产品或生成持久化产物，计划默认保留在对话中。若仅被问可行性，报告方案、影响、风险与是否继续后即停止。
适用场景：小型、清晰、低风险的改动可用简短对话式计划；较大改动按 Why、How、What、Validation and Authority、Risks and Open Decisions 结构展开。计划被接受后可用 /implement-plan 继续；若用户已授权明确低风险实现，简短计划无需再引入审批轮次，但新的设计决策仍需审批。
限制：规划阶段不进行实现；切片若不能服务于 Why 应删除而非延后；每个切片应可独立提交、评审与回滚；测试、类型检查或 lint 支持验收但不替代真实系统验收。资料未提供具体安装命令、收费、平台或效果信息。