用途：在完成功能规格后生成实施计划，把规格转为按文件依赖分组的可执行任务，并输出 plan.md。适用时机为使用 /spectacular:spec 之后。
输入：用户提供 /spectacular:plan {spec-path}，例如 /spectacular:plan @specs/a1b2c3-magic-link-auth/spec.md；其中 a1b2c3 为 runId，magic-link-auth 为功能 slug。
主要能力：从规格中提取 runId 与 feature slug；切换到 /spectacular:spec 创建的 worktree（如 .worktrees/{runId}-main），worktree 不存在则报错要求先运行 spec；派发 general-purpose 子代理读取规格并生成计划；任务质量校验（XL 任务必须拆分、必须给出显式文件路径、补充验收标准、禁止通配符、过多 S 任务需合并）；分析文件重叠构建依赖图；按依赖划分串行或并行阶段；估算时间与并行收益；将计划写入 specs/{runId}-{feature-slug}/plan.md（含 runId、feature、created、status 前置信息）并提交到 worktree 分支。
多仓库支持：通过 find . -maxdepth 2 -name ".git" -type d 统计仓库数，超过一个进入 multi-repo 模式，每个任务必须标注 Repo 字段，文件路径相对所属仓库根目录。
任务组织：建议按 PR 大小切成主题一致的任务（约 4-7 小时），如数据库基础、代理系统、服务层、API 层、UI 层；避免机械地按文件拆成过小任务。
使用方式：按步骤执行——提取 runId 与 slug、切换 worktree、派发子代理生成计划、审阅 plan.md、提交计划、向用户汇报后停止，等待用户自行运行 /spectacular:execute。
限制：worktree 必须存在，无回退主仓库；若校验发现严重问题须停止并让用户修改规格后重跑；不自动执行计划。关于收费与具体平台支持，资料暂未提供。