名称: cross-source-research 描述: 跨多源调查工作流程，用于在配置的MCP工具（Slack、Confluence、Jira、GitHub、Drive、数据库、分析工具）中研究主题。强调深度而非广度，要求阅读内容，而不仅仅是引用。 版本: 1.0.0 使用时机: 当研究主题、跨工具收集上下文、调查项目或特征的当前状态，或回答跨多个信息源的问题时。 渐进式披露: 级别: 1 参考: [] 注: 单文件技能。工作流程本身是可交付成果。
跨源研究
结构化工作流程，用于跨多个MCP连接源调查主题。目标是合成，而非引用。研究直到能够以对话方式解释主题才算完成，而不仅仅是列出找到的提及。
何时激活
触发短语: “研究”、“调查”、“当前状态是什么”、“拉取上下文关于”、“我们了解什么关于”、“收集上下文关于”、“找出关于”。
研究深度标准
这些规则适用于以下每一步。它们存在是因为默认的AI研究行为是浅层的：找到引用、总结标题、继续前进。那不是研究。
- 阅读内容，而非元数据。 打开页面，阅读正文。打开文件，阅读代码。打开线程，阅读消息。Confluence页面标题不会告诉你内部做出的决策。
- 提取“为什么”，而不仅仅是“什么”。 如果构建了一个功能，找出原因。如果做出了决策，找出谁做出的以及他们拒绝了什么。
- 追踪结果。 如果提出了某事，它是否发布了？如果发布了，是否仍在活跃？如果已弃用，为什么？跟随完整生命周期，而非仅仅公告。
- 寻找矛盾。 不同来源常常不一致。Slack线程可能说“我们决定X”，而Jira票证仍跟踪Y。标记这些。
- 当你能教授时停止。 如果你只能说“我在Slack中找到3处提及X和一个关于它的Confluence页面”，你还没完成。当你能够解释X是什么、为什么存在、处于什么状态以及接下来应该发生什么时，才算完成。
步骤1：定义问题
在搜索任何内容之前，澄清：
- 我们具体试图理解什么？
- 一个好的答案会是什么样子？（时间线？决策？指标？状态？）
- 哪些来源最可能有答案？
不要跳过此步骤。不集中的研究产生不集中的结果。
步骤2：首先检查本地知识
在接触外部工具之前，检查已知内容：
- 项目知识库（CLAUDE.md、docs/、任何知识/目录）
- 最近对话历史（会话中是否早前讨论过？）
- 任务/待办文件（是否已有开放项目跟踪此内容？）
这避免了冗余搜索，并为你提供基线上下文，使外部搜索更有针对性。
步骤3：跨源搜索
使用任务工具在来源独立时派遣并行搜索。常见来源类型及查找内容：
| 来源类型 | 查找内容 | MCP工具 |
|---|---|---|
| 聊天/消息（Slack、Teams） | 讨论、决策、公告、辩论 | 频道历史、线程回复、搜索 |
| 文档（Confluence、Notion、Wiki） | PRD、设计文档、路线图、会议笔记、决策记录 | 页面搜索、空间列表、页面内容 |
| 问题跟踪（Jira、Linear、GitHub Issues） | 票证状态、阻塞项、工程上下文、冲刺进度 | 问题搜索、问题详情、史诗内容 |
| 代码（GitHub、GitLab） | 实现、PR、代码审查、评论中的架构决策 | 代码搜索、PR搜索、文件内容 |
| Drive/文档（Google Drive、SharePoint） | 演示文稿、会议转录、策略文档、共享电子表格 | 文件搜索、文件内容、文件夹列表 |
| 分析（数据库、BI工具） | 定量证据、指标、使用数据 | SQL查询、保存报告 |
| 产品分析（Pendo、Amplitude、Mixpanel） | 功能采用、用户行为、调查响应 | 使用查询、指南指标、分段 |
并非每个来源都适用于每个问题。选择2-4个最相关的来源，而非所有。
步骤4：阅读和提取
对于步骤3中找到的每个结果：
聊天线程：阅读完整线程，而非仅第一条消息。决策常常发生在15条消息深处。记录谁说何时。
文档页面：阅读正文内容，而非仅标题和最后修改日期。寻找：陈述的目标、成功标准、状态部分、内联评论、未解决问题。
票证/问题：检查状态、分配人、链接的PR、评论和阻塞项。标记“进行中”3个月的票证与昨天创建的不同。
代码：阅读实际实现，而非仅PR标题。检查测试覆盖。阅读审查评论以了解选择原因。
数据：运行查询以验证主张。“我们有高采用率”没有数字毫无意义。“覆盖率高”需要百分比和基线。
步骤5：合成
生成结构化摘要。这是可交付成果。它应回答步骤1中的原始问题。
必要部分：
- 关键发现：我们现在知道什么？陈述事实，而非意见。包括具体数字、日期、名称。
- 找到的决策：决定了什么、由谁、何时？链接到来源。
- 矛盾或差距：来源在哪里不一致？仍未知什么？
- 建议：基于发现，接下来应该发生什么？具体。“跟进X关于Y”比“需要更多研究”更好。
合成质量检查：
- 它是否直接回答原始问题？
- 未参加此会话的人是否能理解发现？
- 主张是否有具体来源支持（非“根据Slack”，而是“根据[名称]在#频道于[日期]”）？
- 建议是否可操作（谁、什么、何时）？
步骤6：持久化
保存发现以便未来会话可用：
- 使用新发现更新相关项目知识文件
- 向任务列表添加后续项目
- 如果发现改变项目对某事的理解，更新CLAUDE.md或项目文档
未持久化的研究将重新进行。捕获一次，永远引用。