用途：当用户要求计划、路线图、从规格到实现的拆解，或希望把决策记录下来时使用本技能，产出可执行的实施计划并保存为计划文件。
模式：选择满足需求的最轻模式。quick-plan 适用于小/中型且非破坏性任务，无迁移、无多阶段发布，输出 3–8 个 Work Item（WI-###），每项含测试与验收。full-plan（默认）适用于迁移/持久化变更、API/契约变更（公开工具、schema、SDK）、多阶段路线图、性能敏感工作，输出结构化计划各章节。
流程：澄清目标与约束、识别歧义并给出默认值；盘点现状行为（入口→状态/存储→副作用→持久化，关键文件/模块与不变量、归属与优先级规则）；把目标转为显式规则与优先级，覆盖空/无、非法/畸形、边界尺寸、冲突状态、多端协调、持久化/恢复、I/O 失败等边界；建立 Decision Log（决策、备选方案、理由、为何否决其他方案）与 Open Questions（阻塞正确性的问题、由谁决定、未决定时的默认）。
结构：拆为 Work Item（WI-###），每项含目标、可度量的验收（正确性+性能+UX）、先写的测试（文件名与测试意图，单元/集成/e2e）、触及区域（文件路径与关键函数/类/符号）、依赖（其他 WI、外部工具/服务）、风险与缓解、回滚/还原策略，并加优先级与估算（S/M/L）及 WI 间顺序/依赖。必须有 plan lint：章节齐全（Outcomes、Constraints、Current Behavior、Target Rules、Work Items、Testing）；WI 编号连续且引用一致；每个 WI 都有测试与验收。
写文件：若有 templates/TEMPLATE.md 则按其模板，否则按上述结构；计划写入 dev-docs/plans/YYYYMMDD-HHMM-<topic>.md，并始终报告保存路径。
测试与验收：每个 WI 必须包含实施前要写的显式测试；无法写测试时须明确指出并提出最小测试接缝。计划含 Testing Procedures 章节与结尾的 Manual Test Checklist。验收须可度量可验证。计划末尾须有 Plan→Verify 交接：每个 WI 需收集的证据、所需夹具/样例数据、迁移/持久化要求。
持久化、可观测性与发布：若更改持久化内容（DB、磁盘缓存、配置文件、客户端存储的 API），须加 Data Model、Migration Plan（前向、回滚、新旧客户端兼容）、不变量与校验查询、必要的回填/重建索引策略。若触及索引/搜索/性能路径，须定义指标（延迟、吞吐、内存、DB 体积增长）、日志位置与开启详细追踪方式、验收阈值。若行为变更对用户可见或有风险，须加 Rollout Plan（特性开关、分阶段启用、默认开/关）、kill switch 条件与快速回滚方式。
输出要求：始终产出计划文件并在回复中给出路径；仅在会改变规则时问 1–2 个澄清问题。本技能未提供关于收费、价格或具体平台的资料。