用途：把规划讨论的上下文综合成一份里程碑简报（PRD），用于交接给其他智能体或人类同事，并作为后续规划（生成 M###-ROADMAP.md）的输入。核心原则是先综合、不重新访谈：只使用对话中已有信息，缺失的决策写入 Open Questions；简报描述用户可见成果与架构决策，不列任务或实现步骤，也不引用文件路径与行号。
主要流程：
- 定位目标：读 .gsd/STATE.md 找当前活跃里程碑；无活跃里程碑时询问是新建还是追加，新建用 gsd_milestone_new 或 /gsd new-milestone，不手工建目录。
- 读模板 src/resources/extensions/gsd/templates/context.md，严格匹配其结构，标题不得省略、重命名或调序。
- 先勾勒要构建或修改的主要模块，留意可抽取的深模块，必要时做一次简短确认。
- 按模板填写，必填顺序为：Project Description、Why This Milestone、User-Visible Outcome、Completion Class、Final Integrated Acceptance、Architectural Decisions、Error Handling Strategy、Risks and Unknowns、Existing Codebase / Prior Art、Relevant Requirements、Scope、Technical Constraints、Integration Points、Testing Requirements、Acceptance Criteria、Open Questions。
- 用 write 工具写入或覆盖 .gsd/milestones/<MID>/<MID>-CONTEXT.md，不先请求批准文件内容；对难以逆转的架构决策，在 .gsd/DECISIONS.md 追加一行：- YYYY-MM-DD [MID]: <decision> — <rationale>。
- 写完后提供后续选项但不自动执行：运行 /gsd dispatch plan 生成路线图；经用户明确同意后用 mcp__github__issue_write 创建跟踪 issue（正文按资料给出的 PRD 模板）；或运行 grill-me 对简报做压力测试。
典型触发点：用户说“capture this”“write it up”；讨论阶段结束准备进入计划阶段；要把工作交接给其他智能体或同事。
限制与反模式：不重新访谈用户、不列实现任务、不引用具体行号、不编造风险或决策、不自动提交 GitHub issue（外部动作需明确确认）。成功标准包括文件存在且符合模板、User-Visible Outcome 写真实用户动作、Completion Class 诚实、每个架构决策有理由和备选方案、Open Questions 只记真正未决事项。