mcpField
G
gather-business-context

gather-business-context

github.com/openai数据与数据库56078 次安装4 周前更新
代码仓库

关于 gather-business-context

用于在深入分析前收集和整理业务背景的技能,帮助明确分析主题、相关决策、定义及权威资料。它侧重为后续分析提供可追溯的背景,而非直接给出诊断或报告。

主要功能

  1. 01界定分析主题与时间范围
  2. 02围绕具体标识检索资料
  3. 03发现并核对相关来源
  4. 04提取影响决策的背景事实
  5. 05标注来源差异与不确定性
  6. 06输出精简的背景说明

适用场景

  1. 01分析指标前查找其定义与负责人
  2. 02为产品发布分析整理当前状态
  3. 03核实不同资料中的决策记录
  4. 04为后续仪表板或报告准备背景

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/openai/role-specific-plugins --skill gather-business-context

安装后在 Claude Code 中输入/gather-business-context确认已加载。

附带文件agents/openai.yaml

详细介绍

边界

使用此技能收集界定分析所需的背景信息,而不是完成后续分析。

如果同一请求还要求提供诊断、建议、仪表板、报告或其他分析交付内容,则只返回后续步骤所需的背景信息,并继续使用适当的专项技能,例如 $metric-diagnostics、$product-business-analysis、$build-dashboard 或 $build-report。

收集业务背景

使用此技能收集理解分析问题所需的业务背景,然后再开展深入工作。重点了解主题是什么、为何重要、发生了哪些变化或正在做出什么决策、最了解相关工作的人或信息源是谁,以及哪些定义或材料应作为分析依据。这是一项检索和提取技能:收集足够的背景信息来为下一步做准备,而不是撰写最终报告、根因分析或广泛的背景扫描。如果提示已提供所需背景信息,或任务完全自成一体,则跳过此技能。

工作流

1. 确定检索目标

明确需要了解背景信息的分析主题,以及这些背景信息对下一步为何重要。确定搜索和解读信息所需的范围,例如相关产品领域、受众、时间段或决策。如果未提供时间范围,则采用任务所暗示的最窄合理时间窗口,并将其标记为假设。

2. 构建搜索锚点

使用具体标识符进行搜索,而不是宽泛猜测主题。从用户提供的名称或已发现的信息源开始,再扩展到有助于检索的相关词,例如别名、负责人、团队、日期、信息源名称、相关实体,或先前结果中找到的实体。

搜索范围应足够广,以免遗漏相关背景信息。如果返回结果过多,且快速浏览后发现大多无关,则组合多个锚点缩小检索范围,例如将指标与仪表板名称、功能与发布窗口,或客户与相关工作流结合起来。如果可能的信息源返回的内容很少,应先调整锚点,再判断该信息源是否缺失。

3. 从发现线索逐步查找权威材料
  1. 探索所有可能的信息源。 搜索每个已启用或已提供的信息源类别,以查找可能包含有用背景信息或与任务相关数据的内容。在每个结构化数据源中,重新进行目录或元数据发现,以查找相关架构、数据集、表、视图、模型和指标。用户指定的信息源、已知表、仪表板和语义层锚点只是起点,而不是检索的终点。
  2. 比较重复信息和冲突。 当多个信息源内容重叠或相互矛盾时,应比较其权威性、新近程度、定义、范围和直接性。优先采用最接近决策、定义、实施或测量过程的材料;必要时,沿着链接查找佐证。记录重大冲突,并说明下游分析应依据哪个信息源或哪些信息源的组合。
4. 仅提取影响决策的背景信息

将业务背景视为固定的提取目标,而非开放式摘要。提取会影响下游分析的事实:主题的业务含义、此刻的重要性、定义或衡量方式、核实途径、近期变化,以及分析中应保留的不确定性。例如,指标定义、当前推出状态、仪表板链接、负责人的备注、信息源冲突或明确的下一步。

背景说明应聚焦于有助于界定下一步分析的细节。除非能提供有用背景,否则略去宽泛背景、相关历史或大段信息源原文。

5. 保持来源记录简洁且可追溯

对于每个有用的来源,记录足够的归属信息,以便后续工作可以核查:该来源适用于何时、属于哪类来源、确立了哪些事实背景,以及有哪些重要注意事项或冲突。区分来源事实与推断,不要暗示已经审阅来源、了解相关方观点、确认指标,或确信程度超出了实际查明的范围。

6. 明确处理冲突

当来源之间存在可能改变后续表述的分歧时,应保留分歧,而不是将其淡化。优先采用最新的明确决策材料,而非较早的计划;优先采用负责人撰写的文档,而非第三方摘要;如果问题涉及当前已上线、已发布、已记录或可查询的内容,则优先采用实现材料,而非愿景计划。只有当非正式来源明确记录了后续决策或负责人确认时,才将其视为强于规范材料的依据。

如果分歧仍未解决,应同时呈现两种观点,标明冲突,并说明需要什么来源或负责人来解决。如果背景信息已过时或不完整,应说明缺少什么,以及接下来该去哪里查找。

7. 表述框架合理后即停止

当后续任务的表述已足够清晰,且可能启用或已提供的来源类别均已核查、确认不可用或判定信息不足时,就停止搜集背景信息。停止前,确保对下一步工作所需的信息已有足够了解,包括主题是什么、为何重要、重要定义来自哪里、有哪些近期背景,以及仍存在哪些信息缺口。

如果相关来源已启用或已提供,且很可能补充有用背景信息,就继续查找。如果未找到预期来源,应将其列为信息缺口,而不是暗示该来源不存在。

8. 适用时提供精简的背景说明

优先提供聚焦的背景说明,而非完整报告或原始检索结果。应包含足够的信息,让下一步分析无需重复搜索即可继续:简短总结、相关背景、重要定义或来源链接、不确定性或注意事项,以及引用。保持易读,但不要为了精简而删去解释表述框架或来源质量的细节。

如果用户只要求快速了解情况,应缩短结构,同时保留引用、冲突和缺失的规范材料。

标准

根据来源实际能够证明的内容来评估来源。非正式讨论有助于发现线索和了解近期背景,但找到持久性材料后,通常应优先用其作为定义、决策、状态和测量结果的证据。优先选择接近实际工作、足够新以反映现状且明确说明其证明内容的来源。将缺失的权威来源材料列为背景信息缺口。

确保重要主张可追溯。只有在来源能澄清后续任务应如何表述或解读时,才将其视为有用来源;仅仅提及主题的来源无关紧要。保留足够证据以便日后核查工作,并在依据薄弱、过时、间接或相互冲突时,标明解读、假设、冲突和不确定性。

保留可能改变表述框架的分歧。优先采用负责人撰写或接近决策过程的材料,以及能够证明当前情况的证据,而非二手摘要或推测。不要从沉默中推断共识。说明需要什么来源或负责人才能解决重要冲突。

评论

支持 Markdown