用途：在已有功能规格（spec.md）基础上执行实施规划工作流，把模板 templates/plan-template.md 复制为 specs/[###-feature-name]/plan.md，并生成项目结构、数据模型、算法模型三类设计产物。
主要流程：1）从分支名或用户输入（如 001-feature-name）提取功能名，在 ./specs 下精确匹配功能目录；2）预检查目录与 spec.md 是否存在，缺失则报错（如 Feature directory not found、Spec file not found）；3）复制模板并填充技术上下文，未知项标记为 NEEDS CLARIFICATION；4）依次执行阶段一（项目结构，聚焦源码文件、控制目录深度、尽量减少改动文件数）、阶段二（数据模型，提取该功能专有的全部数据模型并规划其结构、访问与更新，用简单示例说明，避免代码实现）、阶段三（算法模型，提取包未提供的专有算法，描述目标与结果，侧重算法描述而非实现，需小示例）。
GitHub 环节：需先获得用户许可，提交并推送计划分支，创建带 Plan 标签的 issue（标题形如 [001-add-frontend][Plan] ...），通过 gh api graphql 的 addSubIssue 变更将其设为功能 issue 的子 issue，创建合并到 main 的 Pull Request 且正文首行为 fix #[plan-issue-number]，更新功能 issue 正文添加计划 issue id，并列出贡献者让用户选择 reviewer（PR 作者不可担任）。
规则：使用绝对路径；门禁失败或存在未解决澄清项时报错；生成的计划文件需人工评审。
适用场景：需要从功能规格生成结构化设计文档并纳入 GitHub 评审流程的开发项目。限制：依赖 specs 目录与 spec.md 的存在和严格命名匹配；仅覆盖规划产物，不提供具体代码实现；资料未提供安装命令、收费与平台支持信息。