用途：生成 SPEC.md，即 GSDL 流水线（取源→头脑风暴→SPEC.md→切片→评审→分支→执行→验证→PR→闭环）的第三步检查点。SPEC.md 是项目唯一、权威的计划文档，需清晰可执行到初级开发者或执行子代理能据此实现，并详细到人工评审者可在第五步批准或拒绝。
主要能力：读取磁盘上的种子文件，提出澄清问题，按固定结构生成 SPEC.md 并保存。该步骤为 LARGE 层级，吸收第二步（头脑风暴/澄清意图），错误会传播到整条流水线。gsdl 编排器可从任意会话模型调用，并路由到 LARGE：会话本身已是 LARGE 时内联执行（首选），否则由编排器的 Question Relay 协议驱动 LARGE 子代理向用户提问并回传答案。不得在更小层级运行，也不得让用户自行切换模型。
使用方式：前置条件为项目目录 .planning/[project-name]/ 存在，且种子文件 .planning/[project-name]/seed.md（第一步输出）存在；若项目结构不存在，先运行 gsdl-fetch-source（接受跟踪项、文档或纯想法）。流程：一、直接从磁盘读取 seed.md，理解问题、功能想法、参考与开放问题，注意其 ## Source 块；二、提出澄清问题（不可跳过），覆盖问题/目标、目标用户、核心功能、用户故事、验收标准、范围/边界、数据需求、设计/UI、边界情况、验证方式，聚焦“做什么”和“为什么”；三、按模板生成 SPEC.md，含简介/概述、目标、用户故事、功能需求、非目标、设计考虑（可选）、技术考虑（可选）、验证计划、成功指标、开放问题；四、保存到 .planning/[project-name]/SPEC.md（固定文件名），向用户确认路径，展示供评审后再进入第四步分解。
适用场景：需要产出计划、编写规格、记录需求、形式化功能，或把模糊意图转为可执行计划时。
限制与规则：创建 SPEC.md 后不要开始实现；生成前必须提问；根据反馈迭代，后续步骤每次从磁盘重读该文件；每个项目仅一个 SPEC.md，多特性用 ## 分节而非多文件；验证计划不可省略。边界情况：无种子文件先运行 gsdl-fetch-source；需求模糊时提更具体问题；已有 SPEC.md 默认原地更新并在 ## Amendments 记录日期，仅当用户明确要求保留旧版时才创建 SPEC-YYYYMMDD.md 快照。输出格式为 Markdown，位置 .planning/[project-name]/，文件名固定 SPEC.md，例如 .planning/eng-441-user-authentication/SPEC.md。