sdd-context-intake

面向规格驱动开发的上下文梳理

用户很少会一开始就给出清晰的一句话目标——他们手头可能有工单、文档、讨论串或一些文件。此技能会将这些原始材料整理成 SDD 流程所需的结构化简报，绝不臆测来源中没有明确说明的内容。

适用场景

• 用户粘贴工单、需求、设计文档或笔记，并说“照这个做”。
• 用户指定了作为事实依据的文件、路径或 URL。
• 在运行 sdd-clarify 和启动 sdd-feature-flow 之前，目标埋藏在材料中，而非明确陈述出来。

流程

1. 收集用户提供的所有来源，原样保留：用户粘贴的文本，以及其中引用的任何内容——Read 指定的文件，WebFetch 指定的 URL；如果有对应的 MCP/CLI 工具，则通过它获取工单。若用户粘贴的简述指向其他来源，切勿就此止步。
2. 如果材料篇幅较长或来源较多，则委派阅读任务。 启动一个只读 Agent（Explore 或 general-purpose Agent），让其阅读来源并返回精简摘要——这样可以避免大量材料占用主上下文。若只有一段简短的粘贴内容，则直接阅读。
3. 整理简报，必须包含以下各节，且仅以来源为依据（对任何推断内容加以标注）：
   • 目标——用一两行说明要构建什么以及为什么（即“做什么／为什么”，而非“如何做”）。
   • 范围内／范围外——根据来源列出项目符号列表。
   • 约束——来源中提及的数据模型、契约、集成、命名和限制。
   • 关键未决问题——来源中尚未确定、且会改变代码、契约或模板结构的决策。这些将成为 sdd-clarify 要提出的问题。
   • 来源——实际阅读过的文件／URL／工单。
4. 交接。 将未决问题交给 sdd-clarify（询问用户），然后将确认后的简报作为 goal（以及任何已确认的参数）传递给 sdd-feature-flow 工作流。

规则

• 所有内容都必须以来源为依据。若来源没有说明某项内容，则它是未决问题，而非假设——应明确指出，不要自行编造。（这与 harness 后续通过清晰度门槛所执行的原则一致；在此处发现问题，成本更低。）
• 切勿通过此技能开始编写规格或代码——此技能的唯一产出是简报。
• 摘要应简洁；重点是将来源材料浓缩为决策与未决问题。