用途：将不确定或规模较大的工作整理为可执行方向，避免制造无谓流程。仅当用户明确要求，或工作存在实质歧义、协调需求、跨领域范围、不可逆性或风险时使用；仅因工作新、多步骤或非平凡并不足以触发规划。
主要能力：读取仓库内说明、当前文档、相关代码及已有 Plan 或 Roadmap；只研究会实质改变设计的未决问题，优先使用仓库内与第一方证据；只提出仓库无法回答且会阻塞决策的问题，合并相关问题并给出带权衡的推荐选项；在方向需要负责人批准时给出简洁 Design Brief；产出所请求的规划结果，保存的 Plan 默认写入 plans/<outcome>.md，仅在多个 Plan 需要排序或进度跟踪时创建 Roadmap；交付前检查一致性、可执行性、范围、验证与文档生命周期。
使用方式：明确调用时按用户要求的输出执行；若用户要求不写文件，则只在对话中返回规划结果，否则默认保存临时 Plan。规划过程与创建 Plan 文件是两个独立决定。不要开始实现。涉及领域术语、状态、关系、不变量、数据流或访问模式且其承载关键作用或不清晰时，先显式建模，并用一两个具体场景对照当前代码与文档做压力测试；以仓库 Glossary 为准，仅在能解决设计决策时添加紧凑的调用栈、组件树或数据流草图。
限制：不得静默更改规范术语或文档；未来变更记录在授权草稿或带 Phase 标签的 Doc Delta 中，并暴露负责人决策。不要制造其形态依赖未决关键决策的下游 Task。若验证设计会引入模块 mock 或大量新端到端基础设施，应作为明确的负责人决策并说明耦合、维护与执行成本。仓库约定优先于特定技术栈指南。Roadmap 是 Plan 链接、候选与跨 Plan 约束的轻量分组，排序须标注 Loose、Strict 或 Mixed；Plan 拥有可选的 Milestone、Phase、Task、验收标准、验证、评审位置与 Doc Delta；每个 Phase 包含对其完整范围的独立全新上下文评审。ADR 仅用于意外、权衡重且难以逆转的决策。资料未提供具体安装命令、收费或平台信息。