用途：在进入规格或设计工作之前，深入理解问题、上下文与约束。产出 .specs/[feature-slug]/RESEARCH.md，作为 create-prd 和 create-technical-design 的主要输入。规则：不提出解决方案、不勾勒架构、不评估选项，此阶段只做理解而非决策。
主要能力与流程：
- 需求访谈：先不读代码、不抓取 URL，用 AskUserQuestion 收集用户已知信息，覆盖问题、受影响者、现状与变通做法、期望结果、约束、已知与未决事项、既有方案或竞品、研究完成标准。一次只问一个聚焦主题，相关子问题可合并；遇到新约束、干系人、边界情况或依赖要追到解决；用户标记为未知的记为开放问题，不臆造答案。
- 代码库扫描：只扫描与问题相关的技术上下文，包括相关模块/服务/组件、既有模式（文件结构、命名、数据流、测试方式）、.specs/ 中重叠的 ADR/RFC/PRD/技术设计、技术债与限制、集成边界。只记录观察，不下结论。
- 外部研究：只抓取用户提供或代码库发现中出现的 URL，不猜测或编造 URL；总结相关内容，不逐字复制大段外部内容；记录来源 URL 与关键发现。
- 综合与起草：按模板撰写 RESEARCH.md，存放于 .specs/[feature-slug]/RESEARCH.md，slug 由功能或问题名小写、连字符分隔生成，目录不存在则创建。起草前确认每节都基于观察到的事实、开放问题如实记录、全文不提出方案或架构。
- 推荐下一步：保存后提示可运行 /create-prd 转为产品需求文档、/create-technical-design 转为架构、/create-rfc 对齐重大决策。
模板包含：问题框定（现状、期望状态、影响）、干系人与用户表、约束（技术/法律合规/运营/时间团队，无则写 None identified.）、既有方案与先例表、代码库发现、外部参考表、开放问题表、推荐下一步，以及一份校验清单。
适用场景：被要求研究某主题、探索或理解问题空间、收集背景信息时。限制：不产出方案或架构；不抓取未提供的 URL；不编造答案；具体安装方式、收费与平台信息暂未提供。