Research 是一个调研类技能，核心目的是阻止“凭记忆作答却称之为调研”的行为。它把调研分成两半，且顺序固定：先查本项目自己的记录文档，再查项目之外的既有方案（prior art）。
一、按提问形态匹配做法
- 如果是一个问题（例如“这可行吗”“我们这样做对吗”“不要动代码”）：去查、报告、停止。在被告知可以动手之前不做任何编辑（audit-only）。
- 如果是工作的一部分（例如“调研并修复”“翻查 GitHub 并迭代到正确为止”）：把调研放进循环里。查看、应用、复查，并说明每一轮基于什么，不要为了写报告而中断循环。
二、选择深度并说明
- quick：单个事实、单个 API、单个 flag；一两个来源，用一段话回答。
- medium：回答“人们通常怎么做”、选择方案；3-6 个来源，比较后给出推荐。
- very thorough：架构、重构、“这个问题一定在某处被解决过”；普查该领域，点出经典方案，按 ROI 排序给出选项。
三、用并行子代理扩展广度 为每个子代理指定范围、Thoroughness 级别、Do not edit files.，以及返回约定：代码要给出精确路径、行号和简短引用；外部仓库要给出 URL、技术、许可证和适用性。
四、先穷尽项目记录文档 在搜索网络之前，先把项目已经写明的内容查完：
- 工单与规格：tracker issue、PRD 或 spec、QA 反馈、引发此事的 Slack 或 Discord 讨论串——即该项目视为记录的东西。
- 仓库自身的规划文档：plans/、docs/、ADR、AGENTS.md、CONTEXT.md、README。
- 当问题涉及视觉时使用 Figma dev mode。设计是事实来源（→ ui-system）。
- 仓库本身：用 git log -S<symbol> 和 git log -p 查代码为何变成这样；查 node_modules 或 site-packages 中的 vendored 源码，而不是凭记忆的 API 表面。 当两份文档互相矛盾时，要指出来，而不是默默选一个。“Double check against X, Y, Z”意味着逐份重读并分别按文档作答，而不是重扫自己的 diff。
五、再查外部既有方案 几乎肯定有人解决过这个问题，去找出来并借鉴：
- GitHub：gh search repos、gh search code、gh api。读真实源码，而不是 README。推荐照搬前先看许可证。
- arXiv 与论文：涉及 agents、生成、模拟、调度或评分的内容。
- 厂商文档与 changelog：用于确认 API 事实。教程、博客、Reddit、HN、YouTube：用于了解实践中真正会遇到什么。 报告哪些可复用、该复制哪个模式、哪些应舍弃。
六、给证据分级 对来源排序，并标明某个论断属于哪一档：
- 厂商文档或已发布源码。最强。
- 维护者声明、论文、一手仓库。
- 博客、教程、论坛帖、模型记忆。最弱，需标注。 每个非显而易见的论断都要附 URL。没有 URL 就写“unverified”，而不是直接陈述。
七、不要做的事
- 凭记忆作答并称之为调研。“你确定吗？”“你调研了吗？”意味着你已经被抓到这么做了。
- 没打开文档或源码就断言某事不可能或不支持。
- 当问题是“人们通常怎么做”时，只停在第一个结果。
- 只丢回一堆链接。交付物是推荐结论，来源放在其下。
- 把调研丢掉。当调研驱动了改动时，PR 描述要写明发现了什么以及为什么（→ pr-update）。当它是一次尚无 PR 的大型普查时，写进仓库的规划文档，让它比聊天记录活得更久。