用途：在实现非平凡任务前先规划。适用于新功能、架构决策、多文件改动等场景，目标是找到与架构、生命周期和未来演进保持一致的最小实现方案。
核心理念：宽思考、窄实现。改动前先分析周边系统，考虑数据流、状态归属、接口、生命周期、失败模式、可观测性与后续扩展；优先可推导的设计（如界面状态由后端事件、持久化状态或共享协议推导），而非自造临时客户端状态；选择最小且连贯的方案，只有在局部修补会造成状态重复、脆弱耦合或生命周期错配时才扩大范围，且不做镀金式改动。
使用方式：将计划写入项目根目录的 PLAN.md，随步骤推进增量构建；若已存在则先阅读，判断是新任务（覆盖）还是延续（修订）。六个步骤：
-
探索：阅读相关文件，理解既有模式与约定，追踪端到端流程，识别真值来源、状态归属、子系统边界与不变量，覆盖触发、处理、中间状态、完成、副作用、失败、重试与清理的完整生命周期，并寻找类似功能与先例。范围不确定时可并行探索，各自聚焦不同方向；仅涉及已知文件时用单一代理。此阶段不要开始实现。
-
澄清：向用户提问解决歧义，可涵盖技术实现、系统行为、UI/UX、性能、边界情况、状态归属、失败处理与权衡，可多轮提问，不要对用户意图做大的假设。
-
设计：给出具体实现方案，包含文件名、代码路径追踪与背景；显式比较最直接实现与最系统连贯实现；复杂任务可从简洁性、性能、可维护性、根因修复与预防、最小改动与整洁架构等多视角考虑；明确回答系统哪部分在变、前后真值来源、新增状态与不变量、受影响的组件与接口、是否产生重复逻辑或状态、更连贯的实现位置、可顺带的简化、以及保持系统连贯的最小方案。
-
复查：阅读依赖的关键文件验证假设，确认符合用户原意，覆盖完整生命周期与适用范围。
-
呈现计划：写入计划文件，包含摘要、背景、系统影响、方法、逐文件改动清单与验证方式（含端到端测试、测试命令、边界情况），只列推荐方案，等用户批准后再继续。
-
实现与验证：批准后按计划实现并逐项跟踪进度，完成后运行验证步骤确认。
限制：资料未提供安装命令、收费模式、支持平台或具体性能数据；该技能依赖 PLAN.md 流程，需要用户参与澄清与批准环节。