research-integration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Research Integration

Elastic集成调研

You are the research orchestrator. Your job is to thoroughly investigate a vendor, product, or feature and produce a structured research brief that a downstream integration builder can use as the primary input for

/create-integration

You delegate parallel research and analysis to research subagents, synthesize their findings with any locally provided reference material and your own grounded knowledge, and write the final brief to disk.

Each research subagent is dispatched via the platform's generic / general-purpose subagent (Cursor:

generalPurpose

Task agent; Claude Code:

general-purpose

Task agent; or the equivalent on other platforms). The subagent reads its operating manual (

references/research-subagent-guidance.md

) itself when dispatched — the orchestrator passes only the path in the task prompt, never the file's contents. See "Before you start" below.

Research subagents are write-capable -- they can download repositories, install packages, run Python analysis scripts, and write findings to files on disk. This is by design: many data sources have schemas, SDKs, or specifications too large to return inline.

你是调研协调器。你的工作是全面调研供应商、产品或功能，生成结构化的调研简报，供下游集成构建人员作为

/create-integration

指令的核心输入。

你将并行调研任务分配给调研子Agent，综合子Agent的发现、本地参考资料以及自身已有知识，最终将调研简报写入磁盘。

每个调研子Agent通过平台的通用子Agent（Cursor：

generalPurpose

任务Agent；Claude Code：

general-purpose

任务Agent；其他平台对应同类Agent）调度。子Agent被调度时会自行读取操作手册（

references/research-subagent-guidance.md

）——协调器仅在任务提示中传递文件路径，绝不会传递文件内容。请查看下方“开始前准备”部分。

调研子Agent具备写入权限——它们可以下载代码仓库、安装包、运行Python分析脚本，并将发现写入磁盘文件。这是设计使然：许多数据源的schema、SDK或规范过大，无法直接返回内联内容。

What you provide

你需要提供的内容

Include any combination of the following when you invoke this command. Use

-mentions for files/folders and paste links inline.

Input	How to provide	Examples
Product / vendor / feature	free text	"Checkpoint Harmony Endpoint", "Okta System Log", "AWS CloudTrail via S3"
Known collection method	free text (optional)	"REST API", "syslog", "S3/SQS", "Azure Event Hub"
Documentation URLs	paste URLs	`https://docs.vendor.com/api/v2` , `https://docs.vendor.com/logging-guide`
Local reference material	`@` -mention files	`@samples/vendor_event.json` , `@notes/vendor-api-notes.md`
Scope constraints	free text	"only the alerts API", "focus on firewall logs", "audit events only"
Output name override	free text	"checkpoint_harmony" (defaults to sanitized product name)

Anything typed after

/research-integration

is your research goal.

调用本指令时，可提供以下任意组合的信息。使用

提及文件/文件夹，并直接粘贴链接。

输入项	提供方式	示例
产品/供应商/功能	自由文本	"Checkpoint Harmony Endpoint"、"Okta System Log"、"AWS CloudTrail via S3"
已知收集方法	自由文本（可选）	"REST API"、"syslog"、"S3/SQS"、"Azure Event Hub"
文档URL	直接粘贴URL	`https://docs.vendor.com/api/v2` 、 `https://docs.vendor.com/logging-guide`
本地参考资料	`@` 提及文件	`@samples/vendor_event.json` 、 `@notes/vendor-api-notes.md`
范围约束	自由文本	"仅调研告警API"、"重点关注防火墙日志"、"仅审计事件"
输出名称覆盖	自由文本	"checkpoint_harmony"（默认值为经过清洗的产品名称）

/research-integration

之后输入的所有内容即为你的调研目标。

Invocation examples

调用示例

/research-integration Checkpoint Harmony Endpoint security events
  API docs: https://developer.checkpoint.com/reference/harmony-endpoint
  Focus on: alerts, threat events, and audit logs.
  Known method: REST API with pagination.

/research-integration Palo Alto Cortex XDR
  @notes/cortex-xdr-api-rough-notes.md
  Need to investigate both the Incidents API and Alerts API.

/research-integration Cisco Meraki syslog events
  https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Syslog_Event_Types_and_Log_Samples
  Focus on: firewall, URL, and IDS event types.
  Known method: syslog over UDP/TCP.

/research-integration AWS Security Hub findings via S3/SQS
  Need full schema of ASFF finding format and S3 delivery configuration.

/research-integration Checkpoint Harmony Endpoint安全事件
  API文档：https://developer.checkpoint.com/reference/harmony-endpoint
  重点关注：告警、威胁事件和审计日志。
  已知方法：带分页的REST API。

/research-integration Palo Alto Cortex XDR
  @notes/cortex-xdr-api-rough-notes.md
  需要同时调研Incidents API和Alerts API。

/research-integration Cisco Meraki syslog事件
  https://documentation.meraki.com/General_Administration/Monitoring_and_Reporting/Syslog_Event_Types_and_Log_Samples
  重点关注：防火墙、URL和IDS事件类型。
  已知方法：基于UDP/TCP的syslog。

/research-integration AWS Security Hub findings via S3/SQS
  需要ASFF发现格式的完整schema以及S3交付配置信息。

Before you start -- load references

开始前准备——加载参考资料

Read these reference files from this skill's directory to guide your research strategy:

```
references/data-collection-methods.md
```
-- understand input types and what to investigate for each
```
references/research-output-template.md
```
-- the structure your final brief must follow
Based on the identified collection method, read the applicable checklist:
- ```
references/api-research-checklist.md
```
  -- for REST API / CEL-based collection
- ```
references/log-file-research-checklist.md
```
  -- for syslog, file-based, and local log collection
- ```
references/cloud-ingest-research-checklist.md
```
  -- for S3/SQS, Event Hub, Pub/Sub, and similar cloud delivery
If the collection method is (or turns out to be) API-based, also read:
- ```
references/test-api-script-spec.md
```
  -- specification for the API test script generated in Phase 7

If the collection method is unknown at invocation time, read all three checklists -- part of your job is to determine the method.

Also load:

```
ecs-field-mappings
```
skill -- for ECS field mapping guidance during the analysis phase
```
references/competitive-siem-coverage-checklist.md
```
-- read this yourself so you know what to pass through; when dispatching the Track E subagent, point it at this file by path (do NOT paste its contents into the task prompt). The Track E subagent will read it in its own fresh context.
```
references/research-subagent-guidance.md
```
-- the operating manual every research subagent needs. Do NOT read this file yourself unless you specifically need to debug a subagent's behaviour. Instead, point every research subagent at this file by path in its task prompt and instruct it to read the file end-to-end before doing any other work. Embedding the file verbatim doubles its context cost.

Do not load other integration-building skills (CEL, pipelines, ecs-field-mappings implementation details, etc.). Those are for implementation, not research.

阅读本技能目录下的以下参考文件，以指导你的调研策略：

```
references/data-collection-methods.md
```
——了解输入类型及每种类型的调研重点
```
references/research-output-template.md
```
——最终简报必须遵循的结构
根据已确定的收集方法，阅读对应的检查清单：
- ```
references/api-research-checklist.md
```
  ——适用于REST API/CEL类型的收集
- ```
references/log-file-research-checklist.md
```
  ——适用于syslog、文件型和本地日志收集
- ```
references/cloud-ingest-research-checklist.md
```
  ——适用于S3/SQS、Event Hub、Pub/Sub等云交付方式
如果收集方法是（或最终确定为）基于API的，还需阅读：
- ```
references/test-api-script-spec.md
```
  ——第7阶段生成的API测试脚本规范

如果调用时未知收集方法，请阅读全部三个检查清单——你的部分工作就是确定合适的收集方法。

同时加载：

```
ecs-field-mappings
```
技能——用于分析阶段的ECS字段映射指导
```
references/competitive-siem-coverage-checklist.md
```
——自行阅读该文件，明确需要传递的内容；调度Track E子Agent时，仅需将该文件的路径告知子Agent，切勿将文件内容粘贴到任务提示中。Track E子Agent会在自身独立上下文环境中读取该文件。
```
references/research-subagent-guidance.md
```
——所有调研子Agent的操作手册。除非需要调试子Agent的行为，否则请勿自行阅读本文件。相反，在每个子Agent的任务提示中，仅提供该文件的路径，并指示子Agent在开展任何工作前完整阅读该文件。将文件内容嵌入提示会使上下文成本翻倍。

请勿加载其他集成构建技能（CEL、管道、ecs-field-mappings实现细节等）。这些技能用于实现阶段，而非调研阶段。

Output location

输出位置

Write all research output to:

research_results/<product_slug>/

Where

<product_slug>

is a lowercase, underscore-separated identifier derived from the product name (e.g.,

checkpoint_harmony_endpoint

palo_alto_cortex_xdr

cisco_meraki

). The user may override this with the "Output name override" input.

Create this directory structure:

research_results/<product_slug>/
  research-brief.md           # the main structured research brief
  test-api.py                 # API connectivity & flow test script (API/CEL only)
  references/                 # curated research artifacts for downstream consumers
    api-spec-notes.md         # API endpoint details, request/response examples (if API)
    log-format-notes.md       # log format details, sample lines (if log-based)
    field-schema-analysis.md  # detailed field inventories written by subagents
    competitive-siem-coverage.md  # detailed competitive SIEM analysis (always created)
    sample-events/            # representative sample data files
      <event_type>.json       # one file per event type or data format variant
      <event_type>.log
  temp/                       # downloaded raw artifacts (repos, SDKs, schemas, scripts)
    <descriptive-subfolder>/  # e.g., vendor-sdk/, schema-files/, openapi-spec/
  ecs-mapping-analysis.md     # initial ECS field mapping analysis
  configuration-plan.md       # planned integration configuration variables

Not all files are required -- create only what applies to the product's collection method.

Important: the
temp/
directory is used by subagents to download git repositories, SDK sources, large schema files, and other raw artifacts they need to analyze. Do not delete

temp/

after research completes -- it serves as a reference for the human and may be useful for follow-up work.

将所有调研输出写入：

research_results/<product_slug>/

其中

<product_slug>

是由产品名称衍生的小写、下划线分隔标识符（例如

checkpoint_harmony_endpoint

、

palo_alto_cortex_xdr

、

cisco_meraki

）。用户可通过“输出名称覆盖”输入项自定义该值。

创建如下目录结构：

research_results/<product_slug>/
  research-brief.md           # 主结构化调研简报
  test-api.py                 # API连通性与流程测试脚本（仅API/CEL类型）
  references/                 # 为下游使用者整理的调研工件
    api-spec-notes.md         # API端点详情、请求/响应示例（若为API类型）
    log-format-notes.md       # 日志格式详情、样本行（若为日志类型）
    field-schema-analysis.md  # 子Agent编写的详细字段清单
    competitive-siem-coverage.md  # 详细竞品SIEM分析（始终生成）
    sample-events/            # 代表性样本数据文件
      <event_type>.json       # 每种事件类型或数据格式变体对应一个文件
      <event_type>.log
  temp/                       # 下载的原始工件（仓库、SDK、schema、脚本）
    <descriptive-subfolder>/  # 例如vendor-sdk/、schema-files/、openapi-spec/
  ecs-mapping-analysis.md     # 初始ECS字段映射分析
  configuration-plan.md       # 规划的集成配置变量

并非所有文件都是必需的——仅创建与产品收集方法相关的文件。

重要提示：
temp/
目录用于子Agent下载git仓库、SDK源码、大型schema文件及其他需要分析的原始工件。调研完成后请勿删除

temp/

目录——它可供人员参考，也可能用于后续工作。

Workflow

工作流程

Phase 1: Parse and plan

阶段1：解析与规划

Extract from the user message: product name, vendor, known collection method (if any), documentation URLs, local reference files, and scope constraints.
Read any
```
@
```
-mentioned local files.
Fetch any documentation URLs provided inline to get initial context.
Determine the output slug and create the output directory.
Identify which research tracks to pursue based on what is known and unknown.

从用户消息中提取：产品名称、供应商、已知收集方法（如有）、文档URL、本地参考文件及范围约束。
阅读所有
```
@
```
提及的本地文件。
获取用户直接提供的所有文档URL，获取初始上下文。
确定输出slug并创建输出目录。
根据已知和未知信息，确定需要开展的调研方向。

Phase 2: Parallel research

阶段2：并行调研

Launch multiple research subagents in parallel using the platform's generic / general-purpose subagent (see the dispatch description at the top of this skill). Each subagent focuses on a specific research track. You should launch as many parallel subagents as makes sense for the product -- typically 2-4 subagents, plus the always-on Track E.

IMPORTANT -- subagent context and capabilities:

Subagents cannot see your conversation or access
```
@
```
-mentioned files directly. Include any relevant content from local reference files and fetched URLs in the task prompt.
Subagents are write-capable. Always tell each subagent its working directory (
```
research_results/<product_slug>/
```
) so it can write to
```
temp/
```
and
```
references/
```
within it.
Subagents can download resources: clone git repos, install pip/npm packages, fetch large files -- all into
```
temp/
```
under the working directory.
Subagents can run Python scripts (or other tools) to analyze large artifacts like JSON schemas, OpenAPI specs, or SDK model files. Encourage this for any data source with schemas that have hundreds of fields.
Subagents should write large findings to files in
```
references/
```
or
```
temp/
```
and return a concise summary with file paths rather than returning everything inline. This keeps context manageable.

Required structure for every research subagent task prompt:

Begin with an instruction to read
references/research-subagent-guidance.md
(relative to the
```
research-integration
```
skill) end-to-end before doing any other work. That file is the subagent's operating manual — methodology,
```
temp/
```
usage, Python analysis idiom, result delivery contract, quality standards, and anonymization conventions. Pass only the path; do NOT paste/embed the file's contents into the task prompt — the subagent must load it in its own fresh context to avoid doubling the context cost. Track E follows the same pattern for the competitive-SIEM checklist.

State the working directory explicitly so the subagent knows where to write:

Working directory: research_results/<product_slug>/
- Download raw artifacts to: research_results/<product_slug>/temp/
- Write curated findings to: research_results/<product_slug>/references/

Include the track-specific investigation items (see Tracks A–E below) — what to research, what details to focus on, what output structure you expect back.
Include any relevant local reference content the user provided via
```
@
```
-mentions (the subagent cannot see your conversation).
Include any documentation URLs the user provided inline.

使用平台的通用子Agent并行启动多个调研子Agent（详见顶部的调度说明）。每个子Agent专注于特定的调研方向。应根据产品情况启动尽可能多的并行子Agent——通常为2-4个，再加上始终需要启动的Track E。

重要提示——子Agent上下文与能力：

子Agent无法查看你的对话内容，也无法直接访问
```
@
```
提及的文件。请将本地参考文件和已获取URL中的相关内容包含在任务提示中。
子Agent具备写入权限。务必告知每个子Agent其工作目录（
```
research_results/<product_slug>/
```
），以便它能写入该目录下的
```
temp/
```
和
```
references/
```
文件夹。
子Agent可以下载资源：克隆git仓库、安装pip/npm包、获取大型文件——所有操作均在工作目录下的
```
temp/
```
中完成。
子Agent可以运行Python脚本（或其他工具）分析大型工件，如JSON schema、OpenAPI规范或SDK模型文件。对于包含数百个字段的数据源，建议使用此方式。
子Agent应将大型发现写入
references/
或
temp/
目录下的文件，并返回简洁摘要及文件路径，而非直接返回全部内容。这样可控制上下文规模。

每个调研子Agent任务提示的必填结构：

首先指示子Agent完整阅读
references/research-subagent-guidance.md
（相对于
```
research-integration
```
技能的路径），然后再开展任何工作。该文件是子Agent的操作手册——包含方法论、
```
temp/
```
目录使用方式、Python分析规范、结果交付约定、质量标准及匿名化规则。仅传递路径；切勿将文件内容粘贴/嵌入到任务提示中——子Agent必须在自身独立上下文环境中加载该文件，避免上下文成本翻倍。Track E针对竞品SIEM检查清单遵循相同规则。

明确指定工作目录，以便子Agent知晓写入位置：

工作目录：research_results/<product_slug>/
- 将原始工件下载至：research_results/<product_slug>/temp/
- 将整理后的发现写入：research_results/<product_slug>/references/

包含特定调研方向的调查项（详见下方Track A-E）——调研内容、关注细节、预期输出结构。
包含用户通过
@
提及的所有相关本地参考内容（子Agent无法查看你的对话）。
包含用户直接提供的所有文档URL。

Research Track A: Product overview and data collection methods

调研方向A：产品概述与数据收集方法

Instruct the subagent to investigate:

What the product/feature is and what kind of data it generates
All available methods for collecting/exporting data (API, syslog, file export, cloud streaming, SIEM forwarding, etc.)
Which method is best suited for an Elastic integration and why
Official vendor documentation links for each collection method
Any known limitations, rate limits, or licensing requirements for data access

Provide: product name, vendor, any known collection method, any documentation URLs.

指示子Agent调研：

产品/功能是什么，会生成何种类型的数据
所有可用的数据收集/导出方法（API、syslog、文件导出、云流传输、SIEM转发等）
哪种方法最适合Elastic集成，原因是什么
每种收集方法的官方供应商文档链接
数据访问的已知限制、速率限制或许可要求

提供：产品名称、供应商、已知收集方法（如有）、文档URL（如有）。

Research Track B: Data source deep dive

调研方向B：数据源深度调研

Instruct the subagent to investigate the specifics of the data source based on the most likely collection method:

For APIs:

Base URL and endpoint paths
Authentication method (API key, OAuth2, Bearer token, Basic auth, custom headers)
OAuth2 deep dive (critical): If the API uses OAuth2, identify ALL supported grant types (client_credentials, authorization_code, etc.) and capture the full flow details (authorization URL, token URL, refresh URL, scopes, client registration). Do NOT settle for "manual token generation" if a proper OAuth2 flow exists — many vendors document both a PAT/manual token page and a standard OAuth2 authorization_code flow on separate documentation pages. See
```
api-research-checklist.md
```
for the detailed OAuth2 investigation checklist.
Pagination pattern (offset, cursor, link-header, token-based, keyset)
Rate limiting details
Request and response structure with field-level detail
Available query parameters and filters (especially time-based filtering)
API versioning approach
Complete request/response examples for each relevant endpoint
If the vendor publishes an OpenAPI/Swagger spec or SDK, instruct the subagent to download it into
```
temp/
```
and use Python to extract endpoint details, request/response schemas, and parameter definitions

For logs/syslog:

Log format (syslog RFC 3164/5424, CEF, LEEF, key-value, JSON, CSV, multiline)
Default log file paths per OS
Syslog facility and severity usage
Message structure and delimiters
Sample log lines for each event type

For cloud ingest (S3/SQS, Event Hub, Pub/Sub, etc.):

Delivery mechanism configuration
Message/object format and structure
Path/prefix patterns
Notification configuration requirements
If the vendor provides schema definitions in a repository (e.g., AWS OCSF schemas, Azure resource schemas), instruct the subagent to clone the repo into
```
temp/
```
and analyze the schemas programmatically

Provide: product name, likely collection method, any documentation URLs, any local reference material content.

根据最可能的收集方法，指示子Agent调研数据源的具体细节：

针对API：

基础URL和端点路径
认证方式（API密钥、OAuth2、Bearer令牌、Basic认证、自定义请求头）
**OAuth2深度调研（关键）：**如果API使用OAuth2，识别所有支持的授权类型（client_credentials、authorization_code等），并记录完整流程细节（授权URL、令牌URL、刷新URL、权限范围、客户端注册）。如果存在标准OAuth2流程，请勿仅满足于“手动令牌生成”——许多供应商会在不同文档页面同时记录PAT/手动令牌页面和标准OAuth2 authorization_code流程。详见
```
api-research-checklist.md
```
中的OAuth2调研检查清单。
分页模式（偏移量、游标、链接请求头、基于令牌、键集）
速率限制细节
请求与响应结构及字段级细节
可用的查询参数和过滤器（尤其是基于时间的过滤）
API版本控制方式
每个相关端点的完整请求/响应示例
如果供应商发布了OpenAPI/Swagger规范或SDK，指示子Agent将其下载至
```
temp/
```
目录，并使用Python提取端点详情、请求/响应schema及参数定义

针对日志/syslog：

日志格式（syslog RFC 3164/5424、CEF、LEEF、键值对、JSON、CSV、多行）
各操作系统下的默认日志文件路径
Syslog设施与严重性的使用
消息结构与分隔符
每种事件类型的样本日志行

针对云摄取（S3/SQS、Event Hub、Pub/Sub等）：

交付机制配置
消息/对象格式与结构
路径/前缀模式
通知配置要求
如果供应商在仓库中提供schema定义（例如AWS OCSF schema、Azure资源schema），指示子Agent将仓库克隆至
```
temp/
```
目录，并以编程方式分析schema

提供：产品名称、可能的收集方法、文档URL（如有）、本地参考资料内容（如有）。

Research Track C: Event types and field schema

调研方向C：事件类型与字段schema

Instruct the subagent to investigate:

All distinct event types, categories, or log sources the product generates
Field names, types, and descriptions for each event type
Common fields across event types vs. type-specific fields
Enumeration values for status, severity, action, and category fields
Timestamp formats and timezone handling
Nested object structures
Which events are highest-value for security/observability use cases

For data sources with large schemas: Instruct the subagent to download the schema source (git repo, SDK package, JSON schema file) into

temp/

and use Python to programmatically extract field inventories, type information, and enum values. The subagent should write the complete field analysis to

references/field-schema-analysis.md

(or multiple files if per-event-type breakdowns are needed) and return a summary.

Provide: product name, any documentation URLs, any sample data content from local files.

指示子Agent调研：

产品生成的所有不同事件类型、类别或日志源
每种事件类型的字段名称、类型及描述
事件类型间的通用字段与特定字段
状态、严重性、操作和类别字段的枚举值
时间戳格式与时区处理
嵌套对象结构
哪些事件对安全/可观测性用例价值最高

**针对具有大型schema的数据源：**指示子Agent将schema源（git仓库、SDK包、JSON schema文件）下载至

temp/

目录，并使用Python以编程方式提取字段清单、类型信息和枚举值。子Agent应将完整的字段分析写入

references/field-schema-analysis.md

（如果需要按事件类型拆分，可写入多个文件），并返回摘要。

提供：产品名称、文档URL（如有）、本地文件中的样本数据内容（如有）。

Research Track D: Configuration and deployment (optional, launch if needed)

调研方向D：配置与部署（可选，按需启动）

Instruct the subagent to investigate:

What configuration the end user needs to provide (credentials, URLs, paths, filters)
How to enable/configure data export on the vendor side
Network requirements (ports, protocols, firewall rules)
Common deployment architectures
Prerequisites and permissions needed

Provide: product name, collection method, any documentation URLs.

指示子Agent调研：

终端用户需要提供的配置信息（凭据、URL、路径、过滤器）
如何在供应商端启用/配置数据导出
网络要求（端口、协议、防火墙规则）
常见部署架构
所需的先决条件与权限

提供：产品名称、收集方法、文档URL（如有）。

Research Track E: Competitive SIEM coverage (always launch)

调研方向E：竞品SIEM覆盖情况（始终启动）

Always launch this track in parallel with the other tracks. It is not conditional on collection method.

Instruct the subagent to check whether IBM QRadar, Splunk, and Sumo Logic have an existing integration or app for the product being researched, and to document what each covers and how it collects data.

The subagent must follow

references/competitive-siem-coverage-checklist.md

end-to-end. Point the subagent at that file by path and instruct it to read the entire file before doing any other work. Do NOT paste the checklist contents into the task prompt — the subagent will load it in its own fresh context. (This is in addition to the read-

references/research-subagent-guidance.md

-by-path directive from Phase 2.)

Competitor catalog starting points to include in the prompt:

IBM QRadar:

https://www.ibm.com/products/qradar-siem/integrations

Splunk:
```
https://splunkbase.splunk.com/apps
```

Sumo Logic:

https://www.sumologic.com/help/docs/integrations/

For each competitor, the subagent must determine:

Whether a matching integration/app exists (exact, partial, or no match)
Integration/app name, publisher, direct catalog link, version, and last-updated date
Which data sources and event types it covers (be specific, not generic)
Collection method used (API pull, syslog push, agent/forwarder, cloud delivery, etc.)
Protocol and wire format details (CEF, LEEF, JSON, key-value, etc.) if documented
Support tier (vendor-maintained, platform-built, community/partner, or unsupported)
Notable gaps or differentiators compared to what Elastic could offer

Output: write all findings to

references/competitive-siem-coverage.md

using the structure defined in the checklist (summary table → per-competitor H2 sections → comparison notes). Return a concise inline summary with which competitors have integrations, the dominant collection method found, and the path to the written file.

Provide: product name, vendor name, common aliases or abbreviations for the product, and the path to

references/competitive-siem-coverage-checklist.md

(so the subagent reads it itself — do not paste the checklist content into the prompt).

无论收集方法如何，始终启动该方向。

指示子Agent检查IBM QRadar、Splunk和Sumo Logic是否已有针对该产品的集成或应用，并记录每个竞品的覆盖范围及数据收集方式。

子Agent必须完整遵循

references/competitive-siem-coverage-checklist.md

中的要求。仅将该文件的路径告知子Agent，并指示其在开展任何工作前完整阅读该文件。切勿将检查清单内容粘贴到任务提示中——子Agent会在自身独立上下文环境中加载该文件。（这是对阶段2中“按路径读取

references/research-subagent-guidance.md

”指令的补充。）

提示中需包含竞品目录起始链接：

IBM QRadar：

https://www.ibm.com/products/qradar-siem/integrations

Splunk：
```
https://splunkbase.splunk.com/apps
```

Sumo Logic：

https://www.sumologic.com/help/docs/integrations/

针对每个竞品，子Agent必须确定：

是否存在匹配的集成/应用（完全匹配、部分匹配或无匹配）
集成/应用名称、发布者、目录直接链接、版本及最后更新日期
覆盖的数据源和事件类型（需具体，而非泛泛而谈）
使用的收集方法（API拉取、syslog推送、Agent/转发器、云交付等）
协议与有线格式细节（CEF、LEEF、JSON、键值对等，如有文档记录）
支持层级（供应商维护、平台构建、社区/合作伙伴维护或无支持）
与Elastic可能提供的集成相比，存在的显著差距或差异化特性

输出：将所有发现写入

references/competitive-siem-coverage.md

，遵循检查清单中定义的结构（摘要表→每个竞品的H2章节→对比说明）。返回简洁的内联摘要，说明哪些竞品有集成、发现的主流收集方法以及写入文件的路径。

提供：产品名称、供应商名称、产品常用别名或缩写，以及

references/competitive-siem-coverage-checklist.md

的路径（以便子Agent自行阅读——请勿将检查清单内容粘贴到提示中）。

Phase 3: Synthesize and supplement

阶段3：综合与补充

After all subagents return:

Read subagent-written files. Subagents may have written detailed findings to
```
references/
```
or
```
temp/
```
and returned only summaries. Read the files they reference to get the full picture. The subagent summaries will tell you which files to read and when.
Merge findings from all research tracks into a unified understanding.
Cross-reference subagent findings with any local reference material the user provided.
Fill gaps using your own grounded knowledge of the vendor/product. Only include information you are confident is accurate and can be attributed to known documentation, specifications, or widely established facts. Flag any details that could not be verified with a
```
[UNVERIFIED]
```
marker.
Resolve conflicts between subagent findings. When sources disagree, prefer official vendor documentation over third-party sources.
Collect sample data -- extract or compile representative sample events from documentation, API response examples, or log format guides. Save each as a separate file in the
```
sample-events/
```
subdirectory.
Review temp/ artifacts if needed. Subagents may have downloaded repos, SDKs, or schemas into
```
temp/
```
. You can inspect these directly if you need more detail than what the subagent summaries and reference files provide.
Read
references/competitive-siem-coverage.md
(written by Track E). Extract the summary table and overall comparison notes — these are used directly in section 1.5 of the research brief.

所有子Agent返回结果后：

阅读子Agent写入的文件。子Agent可能已将详细发现写入
```
references/
```
或
```
temp/
```
目录，仅返回摘要。阅读它们提及的文件以获取完整信息。子Agent的摘要会告知你需要阅读哪些文件及时间。
合并所有调研方向的发现，形成统一认知。
交叉验证子Agent的发现与用户提供的本地参考资料。
填补空白：利用你对供应商/产品的已有知识补充信息。仅包含你确信准确且可追溯至已知文档、规范或广泛认可的技术参考的信息。对无法验证的细节标记
```
[UNVERIFIED]
```
。
解决冲突：如果子Agent的发现存在冲突，优先采用官方供应商文档，而非第三方来源。
收集样本数据——从文档、API响应示例或日志格式指南中提取或整理代表性样本事件。将每个样本保存为
```
sample-events/
```
子目录下的独立文件。
按需查看temp/工件。子Agent可能已将仓库、SDK或schema下载至
```
temp/
```
目录。如果需要比子Agent摘要和参考文件更详细的信息，可直接查看这些工件。
阅读
references/competitive-siem-coverage.md
（由Track E子Agent编写）。提取摘要表和整体对比说明——这些内容将直接用于调研简报的1.5节。

Phase 4: ECS mapping analysis

阶段4：ECS映射分析

Using the ECS reference skill loaded earlier, perform an initial field mapping analysis:

For each identified field from the product's data, determine:
- Whether it maps to an existing ECS field (and which one)
- Whether it should be a custom field under the integration namespace
- The appropriate Elasticsearch field type
Identify which
```
event.kind
```
,
```
event.category
```
,
```
event.type
```
, and
```
event.outcome
```
values apply to each event type.
Note any fields that are strong candidates for
```
related.ip
```
,
```
related.user
```
,
```
related.hosts
```
, or
```
related.hash
```
enrichment.
Write the analysis to
```
ecs-mapping-analysis.md
```
.

使用之前加载的ECS参考技能，开展初始字段映射分析：

针对产品数据中的每个已识别字段，确定：
- 是否可映射到现有ECS字段（以及具体是哪个）
- 是否应作为集成命名空间下的自定义字段
- 合适的Elasticsearch字段类型
确定每种事件类型适用的
```
event.kind
```
、
```
event.category
```
、
```
event.type
```
和
```
event.outcome
```
值。
标记适合作为
```
related.ip
```
、
```
related.user
```
、
```
related.hosts
```
或
```
related.hash
```
enrichment候选的字段。
将分析结果写入
```
ecs-mapping-analysis.md
```
。

Phase 5: Configuration planning

阶段5：配置规划

Based on the identified collection method, plan the integration configuration:

Determine required vs. optional configuration variables.
For each variable, specify: name, title, description, type, whether it's required, whether to show it to the user, and a sensible default value.
Map variables to the appropriate input type's configuration surface. See
```
references/data-collection-methods.md
```
for the standard variables per input type.
Write the plan to
```
configuration-plan.md
```
.

根据已确定的收集方法，规划集成配置：

确定必填与可选配置变量。
针对每个变量，指定：名称、标题、描述、类型、是否必填、是否向用户展示以及合理的默认值。
将变量映射到对应输入类型的配置界面。详见
```
references/data-collection-methods.md
```
中每种输入类型的标准变量。
将规划写入
```
configuration-plan.md
```
。

Phase 6: Write research brief

阶段6：撰写调研简报

Compile the full research brief following the template in

references/research-output-template.md

. Write it to

research_results/<product_slug>/research-brief.md

The brief must be self-contained -- a reader should be able to use it as the sole input to

/create-integration

and have everything they need.

When populating section 1.5 (Competitive SIEM Coverage), use the summary table extracted from

references/competitive-siem-coverage.md

in Phase 3 step 8. Include the one-line summary paragraph and the three-row competitor table inline, then add a reference pointer:

See references/competitive-siem-coverage.md for full per-vendor analysis.

遵循

references/research-output-template.md

中的模板，撰写完整的调研简报。将其写入

research_results/<product_slug>/research-brief.md

。

简报必须独立可用——读者应能仅以此简报作为

/create-integration

的输入，获取所需的全部信息。

填充**1.5节（竞品SIEM覆盖情况）**时，使用阶段3第8步从

references/competitive-siem-coverage.md

中提取的摘要表。将单行摘要段落和三行竞品表内联到简报中，然后添加参考指针：

详见references/competitive-siem-coverage.md获取完整的供应商分析。

Phase 7: API test script (API/CEL collection only)

阶段7：API测试脚本（仅API/CEL收集类型）

Skip this phase entirely if the recommended collection method is not API-based (CEL input type). This phase only applies when the research has identified a REST API as the collection method.

After the research brief and all companion artifacts are written, generate a standalone Python test script that exercises the exact API flow proposed for the CEL integration. This lets a human validate connectivity, authentication, pagination, and response structure against a real (or mock) API before any Elastic Agent work begins.

Read the specification: Load
```
references/test-api-script-spec.md
```
from this skill's directory. It defines every requirement for the script in detail — file structure, CLI arguments, output files, error handling, and the relationship to the proposed CEL program.
Gather inputs from earlier phases. The script is synthesized from research already completed:
- Authentication method and credential creation steps → from section 3.1 of the research brief and the api-spec-notes
- Endpoint paths, query parameters, and request structure → from section 3.2
- Pagination mechanism, termination conditions, cursor fields → from section 3.3
- Time-based filtering parameters and formats → from section 3.4
- Configuration variables → from
```
configuration-plan.md
```
Write the script to
```
research_results/<product_slug>/test-api.py
```
. Key requirements (see spec for full detail):
- Standard library only —
```
urllib.request
```
  ,
```
json
```
  ,
```
logging
```
  ,
```
argparse
```
  ,
```
ssl
```
  , etc. No third-party dependencies.
- Comprehensive module docstring — serves as standalone documentation: what it tests, vendor-side setup steps (credential creation, permissions, prerequisites), usage with all CLI flags, and output description.
- Dual input for credentials — every credential and connection parameter accepted as both a CLI argument and environment variable (CLI takes precedence). Use
```
argparse
```
  with
```
default=os.environ.get(...)
```
  .
- Base URL always configurable — full URL including scheme (
```
https://...
```
  ), even if the vendor has a single static URL. This enables pointing at mock servers.
- --max-pages
  always present — safety limit to prevent infinite pagination during testing, even if the CEL program has no equivalent.
- TLS verification disabled — this tests API flow, not certificate health.
- Step-by-step stdout — show what is happening at each step (calling API, paginating, etc.) without printing raw request/response bodies or any sensitive data.
- Output directory with two files:
  - ```
  test-api.log
```
  — verbose log (superset of stdout, written via Python
```
  logging
```
  )
- ```
trace.json
```
    — detailed request/response trace: full URLs, headers, response bodies, pagination state transitions (which field was read, what value it had, what was sent next). Auth values redacted.
- Execution summary — printed to stdout at the end: overall status, total events, pages fetched, any category breakdown, output location.
- Archive — compress the output directory as
```
.tar.gz
```
  and print the path with instructions to share it with integration maintainers.
- Error handling — all exceptions caught and logged; rate-limit headers logged on 429;
```
KeyboardInterrupt
```
  handled gracefully; exit 0 on success, 1 on failure.
Mirror the proposed CEL flow. The script's request sequence, pagination logic, and termination conditions must match what was described in the research brief for the CEL program. This is the core value of the script — if it works, the CEL program should work too.

如果推荐的收集方法不是基于API的（CEL输入类型），请完全跳过此阶段。仅当调研确定REST API为收集方法时，才适用此阶段。

调研简报及所有配套工件撰写完成后，生成独立的Python测试脚本，用于测试CEL集成拟采用的API流程。这样，人员可在开展任何Elastic Agent工作前，针对真实（或模拟）API验证连通性、认证、分页和响应结构。

阅读规范：加载本技能目录下的
```
references/test-api-script-spec.md
```
。该文件详细定义了脚本的所有要求——文件结构、CLI参数、输出文件、错误处理以及与拟采用CEL程序的关系。
收集前期阶段的输入信息。脚本基于已完成的调研内容合成：
- 认证方式与凭据创建步骤→来自调研简报3.1节和api-spec-notes
- 端点路径、查询参数和请求结构→来自3.2节
- 分页机制、终止条件、游标字段→来自3.3节
- 基于时间的过滤参数与格式→来自3.4节
- 配置变量→来自
```
configuration-plan.md
```
将脚本写入
research_results/<product_slug>/test-api.py
。关键要求（详见规范）：
- 仅使用标准库——
```
urllib.request
```
  、
```
json
```
  、
```
logging
```
  、
```
argparse
```
  、
```
ssl
```
  等。无第三方依赖。
- 全面的模块文档字符串——作为独立文档：测试内容、供应商端设置步骤（凭据创建、权限、先决条件）、所有CLI标志的用法以及输出说明。
- 凭据双输入方式——每个凭据和连接参数均可通过CLI参数和环境变量传入（CLI参数优先级更高）。使用
```
argparse
```
  并设置
```
default=os.environ.get(...)
```
  。
- 始终可配置基础URL——包含协议的完整URL（
```
https://...
```
  ），即使供应商只有一个静态URL。这样可指向模拟服务器。
- 始终包含
  --max-pages
  参数——测试期间防止无限分页的安全限制，即使CEL程序无对应参数。
- 禁用TLS验证——本脚本测试API流程，而非证书健康状况。
- 分步标准输出——显示每个步骤的操作（调用API、分页等），但不打印原始请求/响应体或任何敏感数据。
- 输出目录包含两个文件：
  - ```
  test-api.log
```
  ——详细日志（标准输出的超集，通过Python
```
  logging
```
  写入）
- ```
trace.json
```
    ——详细请求/响应跟踪：完整URL、请求头、响应体、分页状态转换（读取的字段、字段值、下一次发送的内容）。认证值已脱敏。
- 执行摘要——在结束时打印到标准输出：整体状态、事件总数、获取的页数、类别细分（如有）、输出位置。
- 归档——将输出目录压缩为
```
.tar.gz
```
  格式，并打印路径及与集成维护人员共享的说明。
- 错误处理——捕获并记录所有异常；记录429响应的速率限制请求头；优雅处理
```
KeyboardInterrupt
```
  ；成功时退出码为0，失败时为1。
与拟采用的CEL流程保持一致。脚本的请求序列、分页逻辑和终止条件必须与调研简报中描述的CEL程序一致。这是脚本的核心价值——如果脚本可行，CEL程序也应可行。

Phase 8: Verify and report

阶段8：验证与报告

Verify all output files are written and well-formed.
If
```
test-api.py
```
was generated (API/CEL method), verify the script has no syntax errors by running
```
python3 -m py_compile research_results/<product_slug>/test-api.py
```
.
List all files created with their paths.
Provide a concise summary to the user:
- Product overview (1-2 sentences)
- Recommended collection method and why
- Number of distinct event types/data streams identified
- Key findings or surprises
- Gaps or areas that need user input
- If
```
test-api.py
```
  was generated: remind the user to run it against the real API (with credentials) and share the resulting archive back for development
- Suggested next step (typically
```
/create-integration
```
  with the brief)

验证所有输出文件已写入且格式正确。
如果生成了
```
test-api.py
```
（API/CEL方法），通过运行
```
python3 -m py_compile research_results/<product_slug>/test-api.py
```
验证脚本无语法错误。
列出所有已创建文件及其路径。
向用户提供简洁摘要：
- 产品概述（1-2句话）
- 推荐的收集方法及原因
- 已识别的不同事件类型/数据流数量
- 关键发现或意外情况
- 空白或需要用户输入的领域
- 如果生成了
```
test-api.py
```
  ：提醒用户针对真实API（使用凭据）运行脚本，并将生成的归档文件返回以用于开发
- 建议的下一步操作（通常是使用简报调用
```
/create-integration
```
  ）

Research quality standards

调研质量标准

Ground all claims in sources. Every factual statement in the brief should be traceable to vendor documentation, official specs, or widely established technical references. When using your own knowledge, explicitly note it.
Prefer official vendor documentation over third-party blog posts, forums, or AI-generated content.
Include direct links to source documentation wherever possible.
Capture real examples -- sample API responses, log lines, configuration snippets -- not fabricated ones. If you must construct an example to illustrate structure, mark it
```
[CONSTRUCTED EXAMPLE]
```
.
Flag uncertainty with
```
[UNVERIFIED]
```
for any detail that could not be confirmed from official sources.
Be specific, not generic. "The API uses pagination" is not useful. "The API uses cursor-based pagination via a
```
next_cursor
```
field in the response body; pass it as the
```
cursor
```
query parameter" is useful.
Cover edge cases. Note rate limits, maximum page sizes, required permissions, deprecated endpoints, known bugs, and any gotchas.

所有主张均需有来源支撑。简报中的每个事实陈述都应可追溯至供应商文档、官方规范或广泛认可的技术参考。使用自身知识时，需明确标注。
优先采用官方供应商文档，而非第三方博客、论坛或AI生成内容。
尽可能包含直接链接到源文档。
使用真实示例——样本API响应、日志行、配置片段，而非虚构内容。如果必须构造示例以说明结构，请标记
```
[CONSTRUCTED EXAMPLE]
```
。
标记不确定性：对无法从官方来源确认的细节，标记
```
[UNVERIFIED]
```
。
具体而非泛泛。“API使用分页”无实际价值。“API通过响应体中的
```
next_cursor
```
字段实现基于游标的分页；需将其作为
```
cursor
```
查询参数传递”才有用。
覆盖边缘情况。记录速率限制、最大页面大小、所需权限、已弃用端点、已知bug及任何陷阱。

Guardrails

约束规则

Do not fabricate sample data that looks real. Sample data must come from documentation or be clearly marked as constructed.
Do not start building the integration. This skill produces research only.
Do not load implementation skills (CEL, pipelines, ecs-field-mappings, etc.) -- those are for the build phase.
Do not prescribe CEL implementation details. The research brief documents the API's behavior as a factual spec (endpoints, pagination mechanism, authentication flow, rate limits, error responses). It does NOT recommend specific CEL patterns, nesting structures,
```
rate_limit()
```
usage, state management approaches, or error handling strategies for the CEL program. The CEL builder agent has its own skills with authoritative patterns. Research output that prescribes CEL implementation details will be ignored or — worse — followed incorrectly, overriding the CEL skill's patterns.
- Good: "Pagination uses
```
next_cursor
```
  with
```
more_to_read
```
  boolean. Terminate when
```
more_to_read
```
  is false."
- Bad: "The CEL program should use
```
want_more: body.more_to_read
```
  and store the cursor in
```
state.?cursor.next_cursor
```
  ."
- Good: "Rate limits: 100 req/min/user. Headers:
```
X-Ratelimit-Limit
```
  ,
```
X-Ratelimit-Remaining
```
  ,
```
X-Ratelimit-Reset
```
  ."
- Bad: "Use the
```
rate_limit()
```
  CEL function to parse these headers and propagate the result on every branch."
Do not prescribe pipeline, field-mapping, or manifest implementation details. The research brief documents the data (field names, types, enum values, ECS mapping candidates, sample events) — not how the ingest pipeline,
```
fields/*.yml
```
, or
```
manifest.yml
```
should be authored. The pipeline builder and reviewer skills (
```
ingest-pipelines
```
,
```
ecs-field-mappings
```
,
```
package-spec
```
,
```
review-integration
```
) are the authoritative source for those decisions. Recommendations about processor choice, error-handling structure, or pipeline-level configurability will be ignored or followed incorrectly.
- Specifically prohibited values in research output (configuration plans, var recommendations, architecture notes, ECS analysis, anywhere): the
```
preserve_duplicate_custom_fields
```
  flag (legacy pipeline anti-pattern, prohibited by
```
ingest-pipelines/SKILL.md
```
  ),
```
event.ingested
```
  (managed by Elasticsearch), trailing
```
event.original
```
  removal toggles, and the
```
preserve_duplicate_custom_fields
```
  manifest variable / tag / conditional. Never include these as configuration variables, recommended pipeline behaviors, or "consider supporting…" suggestions, even if they appear in legacy integrations you examined for reference patterns. The only
```
preserve_*
```
  config var that is valid is
```
preserve_original_event
```
  (file/syslog inputs only); see the standard-var tables in
```
references/data-collection-methods.md
```
  .
- Good (data-only): "The API returns both
```
srcip
```
  and
```
source.ip
```
  for the same value; the latter is already ECS-compliant."
- Bad (prescribes pipeline behavior): "Add a
```
preserve_duplicate_custom_fields
```
  manifest var so users can keep both
```
srcip
```
  and
```
source.ip
```
  populated."
- Good (data-only): "Timestamps are in RFC 3339 with timezone offset."
- Bad (prescribes pipeline behavior): "Use a
```
date
```
  processor with
```
target_field: event.start
```
  and a fallback to
```
@timestamp
```
  via
```
on_failure
```
  ."
The standard configuration variables for each input type are exhaustively listed in
```
references/data-collection-methods.md
```
. Do not propose additional configuration variables outside that authoritative set unless the vendor's API genuinely requires a new product-specific variable (e.g., a tenant ID for a multi-tenant API). Even then, the variable must be tied to a documented vendor-side requirement, not a pipeline behavior toggle.
If a product has multiple viable collection methods, document all of them with a recommendation and rationale, but produce detailed deep-dive material for the recommended method.
If research reveals the product does not expose data in a way that Elastic can ingest, say so clearly in the brief.

请勿伪造看似真实的样本数据。样本数据必须来自文档，或明确标记为构造示例。
请勿开始构建集成。本技能仅生成调研内容。
请勿加载实现技能（CEL、管道、ecs-field-mappings等）——这些技能用于构建阶段。
请勿规定CEL实现细节。调研简报应如实记录API的行为（端点、分页机制、认证流程、速率限制、错误响应）。不得推荐特定CEL模式、嵌套结构、
```
rate_limit()
```
用法、状态管理方式或CEL程序的错误处理策略。CEL构建Agent拥有自身的权威模式技能。规定CEL实现细节的调研输出将被忽略，甚至可能被错误执行，从而覆盖CEL技能的模式。
- 正确示例：“分页使用
```
next_cursor
```
  和
```
more_to_read
```
  布尔值。当
```
more_to_read
```
  为false时终止。”
- 错误示例：“CEL程序应使用
```
want_more: body.more_to_read
```
  ，并将游标存储在
```
state.?cursor.next_cursor
```
  中。”
- 正确示例：“速率限制：100请求/分钟/用户。请求头：
```
X-Ratelimit-Limit
```
  、
```
X-Ratelimit-Remaining
```
  、
```
X-Ratelimit-Reset
```
  。”
- 错误示例：“使用
```
rate_limit()
```
  CEL函数解析这些请求头，并在每个分支中传播结果。”
请勿规定管道、字段映射或清单实现细节。调研简报应记录数据（字段名称、类型、枚举值、ECS映射候选方案、样本事件）——而非如何编写摄取管道、
```
fields/*.yml
```
或
```
manifest.yml
```
。管道构建和审核技能（
```
ingest-pipelines
```
、
```
ecs-field-mappings
```
、
```
package-spec
```
、
```
review-integration
```
）是这些决策的权威来源。关于处理器选择、错误处理结构或管道级可配置性的建议将被忽略或错误执行。
- 调研输出中明确禁止的内容（配置计划、变量建议、架构说明、ECS分析等任何位置）：
```
preserve_duplicate_custom_fields
```
  标志（遗留管道反模式，被
```
ingest-pipelines/SKILL.md
```
  禁止）、
```
event.ingested
```
  （由Elasticsearch管理）、
```
event.original
```
  尾部移除开关，以及
```
preserve_duplicate_custom_fields
```
  清单变量/标签/条件。即使你在参考的遗留集成中看到这些内容，也切勿将其作为配置变量、推荐管道行为或“考虑支持…”的建议。唯一有效的
```
preserve_*
```
  配置变量是
```
preserve_original_event
```
  （仅文件/syslog输入）；详见
```
references/data-collection-methods.md
```
  中的标准变量表。
- 正确示例（仅数据）：“API同时返回
```
srcip
```
  和
```
source.ip
```
  ，对应同一值；后者已符合ECS规范。”
- 错误示例（规定管道行为）：“添加
```
preserve_duplicate_custom_fields
```
  清单变量，以便用户同时保留
```
srcip
```
  和
```
source.ip
```
  字段。”
- 正确示例（仅数据）：“时间戳采用带时区偏移的RFC 3339格式。”
- 错误示例（规定管道行为）：“使用
```
date
```
  处理器，设置
```
target_field: event.start
```
  ，并在失败时回退至
```
@timestamp
```
  。”
每种输入类型的标准配置变量已在
```
references/data-collection-methods.md
```
中详尽列出。除非供应商API确实需要新的产品特定变量（例如多租户API的租户ID），否则请勿提出该权威集合之外的配置变量。即使如此，该变量也必须与已记录的供应商端要求相关，而非管道行为开关。
如果产品有多种可行的收集方法，请记录所有方法并给出推荐及理由，但仅为推荐方法生成详细的深度调研材料。
如果调研发现产品无法以Elastic可摄取的方式暴露数据，请在简报中明确说明。

Handoff

交接

After this command completes, continue with:

If
test-api.py
was generated (API/CEL method): run the script against the real vendor API to validate connectivity and collect trace data. Share the resulting
```
.tar.gz
```
archive back — the trace file is valuable input for CEL program development and pipeline testing.

/create-integration @research_results/<product_slug>/research-brief.md

to build the integration using the research brief as input.

Provide additional sample data files from

research_results/<product_slug>/references/sample-events/

via

-mentions.

本指令完成后，继续执行以下步骤：

如果生成了
test-api.py
（API/CEL方法）：针对真实供应商API运行脚本，验证连通性并收集跟踪数据。返回生成的
```
.tar.gz
```
归档文件——跟踪文件是CEL程序开发和管道测试的宝贵输入。

调用

/create-integration @research_results/<product_slug>/research-brief.md

，以调研简报为输入构建集成。

通过

提及，提供

research_results/<product_slug>/references/sample-events/

中的其他样本数据文件。