菜单
Use when creating, running, or debugging elastic-package tests — pipeline fixture authoring and expected output, system tests with mock API wiring, and script tests for failure paths and upgrades. Load the reference file for the test type you are working on.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when reviewing dashboard JSON changes in a PR or branch. Extracts structured descriptions with kbdash, compares before/after, and checks guideline compliance.
Use for all CEL and mito work on integrations that collect from APIs — writing CEL programs, cel.yml.hbs templates, manifest configuration, mock-first development with the mito CLI, system test mock setup, and answering CEL/mito questions. Load this skill whenever any data stream uses the cel input type.
Use when creating a new Elastic integration package, scaffolding data streams, answering package layout or structure questions, or running the end-to-end integration build workflow. Covers package topology, scaffold commands, post-scaffold edits, and full orchestration of CEL/pipeline/test subagents.
Use when designing or modifying Elasticsearch ingest pipelines, including single-path parsing, branching logic, sub-pipelines, enrichment processors, and robust on_failure handling.
Use when reviewing, fixing, or improving an EXISTING Elastic integration package. Covers quality reviews, targeted fixes (pipelines, field mappings, CEL programs, manifests, changelogs), full improvement passes, and minor adjustments. Use create-integration instead when creating a new package or adding a new data stream from scratch.
Research a vendor, product, or feature to collect all information needed before building an Elastic integration. Investigates data collection methods, API or log documentation, sample data formats, field schemas, ECS mapping candidates, and configuration requirements. Outputs a structured research brief to research_results/<product>/. Invoke manually with /research-integration.
| name | integration-testing |
| description | Use when creating, running, or debugging elastic-package tests — pipeline fixture authoring and expected output, system tests with mock API wiring, and script tests for failure paths and upgrades. Load the reference file for the test type you are working on. |
| license | Apache-2.0 |
| metadata | {"author":"elastic","version":"1.0"} |
Load this skill whenever tasks include:
.log/.json inputs, *-expected.json output, config files)_dev/test/system/, _dev/deploy/, mock APIs, 0-hits failures)Do not use this skill as the primary guide for:
ingest-pipelines)cel-programs)elastic-package-cli)| Test type | Load when | Reference file |
|---|---|---|
| Pipeline tests | Writing fixtures, config files, expected output, debugging pipeline test failures | references/pipeline-testing.md |
| System tests (generic) | Always load for any system test work — config fields, commands, teardown, debugging | references/system-testing.md |
| Script tests | txtar failure/error tests, upgrade tests, mock services embedded in txtar | references/script-testing.md |
In addition to the generic system-testing.md, load the reference file matching your data stream's input type:
| Input type | Reference file |
|---|---|
cel | references/system-testing-cel.md |
tcp, udp | references/system-testing-tcp-udp.md |
http_endpoint | references/system-testing-http-endpoint.md |
logfile, filestream | references/system-testing-logfile.md |
kafka, gcp-pubsub | references/system-testing-kafka-pubsub.md |
aws-s3, gcs, azure-blob-storage, azure-eventhub | references/system-testing-cloud-skip.md |
When an integration supports multiple input types, load the generic reference plus each applicable input-type reference.
When working across multiple test types in one task (e.g. creating a new data stream end-to-end), load all applicable reference files.
references/pipeline-testing.md — directory layout, naming conventions, fixture formats, config options, expected output format and review, core workflow, fixture scenario coverage, data anonymization, troubleshootingreferences/system-testing.md — generic system test reference: required layout, config fields, core commands, teardown failures, sample_event.json verification, general debuggingreferences/system-testing-cel.md — CEL mock API wiring, 0-hits debugging for CEL, variable-capture patternsreferences/system-testing-tcp-udp.md — TCP/UDP log sender pattern with elastic/stream, signal coordination, port alignmentreferences/system-testing-http-endpoint.md — webhook/HTTP endpoint testing with STREAM_PROTOCOL=webhook, auth headersreferences/system-testing-logfile.md — Alpine container + SERVICE_LOGS_DIR pattern for logfile/filestream inputsreferences/system-testing-kafka-pubsub.md — Kafka broker + stream producer, Pub/Sub emulator patternsreferences/system-testing-cloud-skip.md — when and why to skip system tests for cloud storage inputs (aws-s3, gcs, azure-blob-storage, azure-eventhub)references/script-testing.md — txtar format, env smoke test, system-level skeleton, mock service docker-compose and config.yml, upgrade test pattern, pitfalls, full o365 examplesreferences/builder-setup-subagent-guidance.md — subagent operating manual for wiring data collection (docker-compose, sample logs, agent stream template, system test config, manifest var cleanup) for non-CEL data streams. The orchestrator dispatches subagents by passing this file's path in the task prompt; the subagent reads it itself in its own fresh context. Do NOT embed/paste its contents into the task prompt.references/builder-system-test-subagent-guidance.md — subagent operating manual for running elastic-package test system --generate after pipeline work completes (any testable input). Same dispatch rule as above: orchestrators pass the path, the subagent reads the file itself.