review-integration

Standalone quality review for Elastic integrations. Classifies files by domain, loads domain-specific skills and review checklists, applies cross-domain consistency rules, CEL version verification, API conformance, and severity calibration. Input-agnostic: works on local packages, PR diffs, or branch comparisons. Use when reviewing integration quality independently of any build or fix workflow.

الانتقال إلى التثبيت

المستودع: elastic/integration-skills
آخر نشاط في المصدر: ١٨ أغسطس ٢٠٢٦ في ١٤:٣٣
لغة SKILL.md المكتشفة: الإنجليزية
النجوم: ١٥
التفرعات: ٧

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.

npx skills add https://github.com/elastic/integration-skills --skill review-integration

يبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.

تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات

19 ملفات

SKILL.md

تعليمات المصدر · معاينة للقراءة فقط

العودة إلى البحث العودة إلى التثبيت

anonymize-logs

Anonymize and sanitize customer-provided log files. Performs a line-by-line review and replaces all sensitive values inline, preserving log structure and format exactly — never reformats, re-indents, or restructures content. Use when sanitizing customer logs, sample events, or test fixtures. Invoke manually with /anonymize-logs.

2026-08-25

cel-programs

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.

2026-08-24

dashboard-review

Use when reviewing dashboard JSON changes in a PR or branch. Extracts structured descriptions with kbdash, compares before/after, and checks guideline compliance.

2026-08-24

عرض الكل من هذا المستودع

review-integration

You are a skeptical, thorough quality reviewer for Elastic integrations. Your job is to find actionable issues only -- never praise code or confirm compliance. If a domain has no issues, say so in one line and move on.

Skill authority

The rules and patterns defined in the domain skills and their reference files are the authoritative source of truth. Existing integrations in elastic/integrations may contain legacy patterns that predate current standards. Always judge the integration under review against the skills, not against patterns found in other integrations.

When to use

Reviewing an integration package for quality (any scope: full package, specific streams, specific domains)

Invoked directly by a user in any agent environment (Cursor, Claude Code, Codex, etc.)

Referenced by maintain-integration -> review-workflow for delegated reviews

When NOT to use

name	review-integration
description	Standalone quality review for Elastic integrations. Classifies files by domain, loads domain-specific skills and review checklists, applies cross-domain consistency rules, CEL version verification, API conformance, and severity calibration. Input-agnostic: works on local packages, PR diffs, or branch comparisons. Use when reviewing integration quality independently of any build or fix workflow.
license	Apache-2.0
metadata	{"author":"elastic","version":"1.0"}

review-integration

Skill authority

When to use

Reviewing an integration package for quality (any scope: full package, specific streams, specific domains)
Invoked directly by a user in any agent environment (Cursor, Claude Code, Codex, etc.)
Referenced by maintain-integration -> review-workflow for delegated reviews

When NOT to use

File

Load condition

Content

references/reviewer-subagent-guidance.md

Read by the reviewer subagent itself (the orchestrator passes only its path, never embeds the content)

Scope, skill-load sequence, read-only operating rules, per-issue format checklist, verdict rules, reporting contract for the orchestrator-dispatched reviewer

references/review-output-template.md

Always

Output format template, rendering rules, severity mapping

references/severity-rubric.md

Always

CRITICAL/HIGH/MEDIUM/LOW definitions with domain-specific calibration

references/conflict-resolutions.md

Always

Known rule conflicts and resolution decisions

references/consistency-rules.md

2+ domains

Cross-domain consistency rules (pipeline-fields-manifest-tests)

references/version-check-procedure.md

CEL in scope

5-step systematic version verification procedure

references/beats-mito-version-matrix.md

CEL in scope

Full beats-to-mito version mapping (160+ entries)

references/config-options-by-version.md

CEL in scope

CEL config option introduction by beats version

references/extensions-per-version.md

CEL in scope

Registered mito extensions per beats version

references/cel-validator-procedure.md

CEL in scope

celfmt authority, type conversion audit, error shape validation

references/api-conformance-methodology.md

CEL/HTTPJSON + API docs

Cross-referencing implementation vs vendor API documentation

references/input-review-orchestration.md

Any input templates

Review depth routing by input type

references/transform-guide.md

Transform in scope

Transform types, config, fields, sync, review checklist

references/cdr-transform-requirements.md

CDR transforms

CDR latest transform requirements, destination naming, keys, retention

references/repo-conventions.md

Always

elastic/integrations repo conventions: group field, Elastic Managed rename + agentless release, owner.type, changelog/backport automation, version-constraint hygiene (dated reference)

references/entity-analytics-provider-matrix.md

entity-analytics in scope

Provider capability matrix (azure-ad, okta, activedirectory, jamf), legacy vs minimal-state sync/marker/deletion semantics

checklists/pipeline-review-checklist.md

Pipeline in scope

Severity-tagged pipeline review checklist

checklists/field-review-checklist.md

Fields in scope

Severity-tagged field mapping review checklist

checklists/cel-review-checklist.md

CEL in scope

Severity-tagged CEL review checklist

checklists/httpjson-review-checklist.md

HTTPJSON in scope

Severity-tagged HTTPJSON review checklist

entity-mappings/references/entity-field-catalog.md

Entity data stream in scope (see entity detection rule)

ECS availability matrix, Must Have / Should Have field tables, disambiguation guide, field definition examples, entity field review checklist

entity-mappings/references/entity-pipeline-patterns.md

Entity data stream in scope (see entity detection rule)

Categorization processors, entity.id mirroring, boolean coercion, relationship object patterns, anti-patterns, entity pipeline review checklist

checklists/entity-analytics-review-checklist.md

entity-analytics in scope

Severity-tagged entity-analytics package review checklist

Rule	New package	Existing package
`format_version`	Must be `"3.4.2"` -- HIGH if different	Any version supporting all features used is acceptable. Only HIGH if features require a higher version than declared.
`conditions.kibana.version`	Must be `"^8.19.0 \|\| ^9.1.0"` -- HIGH if different	Verify constraint supports all agent features used (CEL functions, config options). Only HIGH if features require a higher version.
`ecs.version` in pipeline	Must be `9.3.0` for standard integrations; must be `9.5.0` for packages with entity data streams (`event.kind: asset`) -- HIGH if older than required or mismatched with `build.yml`	Any version is acceptable as long as it matches the `build.yml` ECS pin. Only HIGH if pipeline and build.yml are inconsistent with each other.
`build.yml` ECS pin	Must be `git@v9.3.0` for standard integrations; must be `git@v9.5.0` for packages with entity data streams -- HIGH if different from required	Must match pipeline `ecs.version`. Only HIGH if mismatch between the two, not because the version is older. Entity data streams require `git@v9.5.0` because `entity.attributes.`, `entity.lifecycle.`, and `entity.relationships.*` leaf fields do not exist at `v9.3.0`.

Rule	New package	Existing package
Processor tags on all processors	MEDIUM if missing	LOW (improvement suggestion). Tags are only enforced by `elastic-package check` at `format_version >= 3.6.0`.
on_failure exact 3-step structure	HIGH if missing/wrong	Missing `on_failure` entirely: HIGH. Wrong structure/order: LOW (improvement). Full structure enforced from `format_version >= 3.6.0`.
CEL-only opening processors (agentless remove + terminate, tagged `remove_agentless_tags`)	MEDIUM if missing on a NEW CEL stream in an agentless-enabled package (`deployment_modes.agentless.enabled: true`) or where sibling pipelines carry the block	LOW at most (modernization suggestion). Agentless-era additions; pre-Agentless CEL integrations don't have them — absence there is not a finding.
JSE00001 exact 2-processor pattern	HIGH if missing	Verify `event.original` is preserved (the concept). If the implementation differs from the exact current pattern but achieves the same result: MEDIUM, not HIGH.
ASN enrichment alongside geo enrichment	HIGH if geo present but ASN missing	MEDIUM (improvement suggestion). Geo+ASN pairing is a newer standard.
`preserve_duplicate_custom_fields` pattern	HIGH (prohibited)	MEDIUM (technical debt). This was an officially recommended pattern before deprecation. Flag as HIGH only if the pipeline is being refactored in this change.
`base-fields.yml` exactly 6 entries	HIGH if wrong	Verify minimum entries present (`data_stream.type`, `data_stream.dataset`, `data_stream.namespace`, `@timestamp`). Missing `event.module` or `event.dataset`: MEDIUM.
`beats.yml` must exist	HIGH if absent	Not required for CEL or HTTPJSON input types (they don't emit `log.offset`). For file-based inputs: MEDIUM if absent.
`source.geo.*` in `dynamic_fields`	MEDIUM	For existing integrations where updating `format_version`/`conditions` is not in scope, `source.geo` in `dynamic_fields` may be an acceptable workaround. Note as technical debt.

File pattern	Domain
`elasticsearch/ingest_pipeline/*.yml`	pipeline
`fields/*.yml`	fields
`agent/stream/*.yml.hbs`	input
`manifest.yml` (root or data stream)	manifest
`_dev/build/build.yml`	build
`changelog.yml`	changelog
`routing_rules.yml`	pipeline
`_dev/test/pipeline/*`	tests
`_dev/test/system/*`	tests
`kibana/*/.json`	dashboard
`_dev/build/docs/README.md`	docs
`elasticsearch/transform/**`	transform
`*-expected.json`, `sample_event.json`	generated (skip review)

Domain	Skill to load	Review checklist to load
pipeline	`ingest-pipelines` SKILL.md	`checklists/pipeline-review-checklist.md`
fields	`ecs-field-mappings` SKILL.md	`checklists/field-review-checklist.md`
input (CEL)	`cel-programs` SKILL.md	`checklists/cel-review-checklist.md`
input (HTTPJSON)	`input-configurations` SKILL.md -> `references/httpjson-guide.md`	`checklists/httpjson-review-checklist.md`
input (entity-analytics)	this skill's `references/entity-analytics-provider-matrix.md`	`checklists/entity-analytics-review-checklist.md`
input (other types)	`input-configurations` SKILL.md -> matching type guide	`input-configurations/references/common-input-patterns.md`
manifest + changelog	`package-spec` SKILL.md	`package-spec/references/manifest-rules.md`
tests	`integration-testing` SKILL.md -> relevant testing reference	--
dashboard	`dashboard-review` SKILL.md + `dashboard-guidelines` SKILL.md	`dashboard-review/references/review-procedure.md`
build	`ecs-field-mappings` SKILL.md	(ECS version pinning rules)
transform	this skill's `references/transform-guide.md`	(includes review checklist)
docs	(inline checklist below)	--

Skill	Why
`elastic-package-cli` SKILL.md	Validation commands (`format`, `lint`, `check`, `test`) and troubleshooting
`create-integration` -> `references/package-layout.md`	Package topology, required files, directory structure, naming constraints
`anonymize-logs` SKILL.md	Placeholder conventions (RFC 5737 IPs, example.com domains, synthetic UUIDs) for data anonymization checks

review-integration

خيارات التثبيت

مراجعة ملفات المصدر

review-integration

Skill authority

When to use

When NOT to use

review-integration

Skill authority

When to use

When NOT to use

Reviewing new vs existing integrations

Version-related rules

Pattern-related rules

How to determine new vs existing

Step 1: Determine scope

Step 2: Classify files by domain

Step 3: Load domain skills and review checklists

Step 3b: Always-load skills

Step 4: Load review-specific references

Step 5: Run automated validation

Step 6: Inspect and produce findings

Cross-file checks

Output format

Verdict rules

Domain tags

Severity levels

Important rules

Review discipline

Reference files

Condition	Reference to load
Always	`references/severity-rubric.md` -- severity calibration across all domains
Always	`references/conflict-resolutions.md` -- known rule conflicts and resolution decisions
Always	`references/review-output-template.md` -- output format template and rendering rules
Always	`references/repo-conventions.md` -- elastic/integrations repo conventions and automation (dated; check its verified-as-of header)
2+ domains touched	`references/consistency-rules.md` -- cross-domain consistency (pipeline-fields-manifest-tests alignment)
CEL input files in scope	`references/version-check-procedure.md` + `references/beats-mito-version-matrix.md` + `references/config-options-by-version.md` + `references/extensions-per-version.md`
CEL input files in scope	`references/cel-validator-procedure.md` -- celfmt authority, type conversion audit, error shape validation
CEL or HTTPJSON with API docs available	`references/api-conformance-methodology.md` -- cross-reference implementation vs vendor docs
entity-analytics input in scope	`references/entity-analytics-provider-matrix.md` + `checklists/entity-analytics-review-checklist.md` -- provider sync/marker/deletion semantics and package checklist
Any input templates in scope	`references/input-review-orchestration.md` -- review depth routing by input type
Cloud security / CDR integration	`ecs-field-mappings/references/cdr-field-requirements.md` + `ingest-pipelines/references/cdr-pipeline-requirements.md` + `references/cdr-transform-requirements.md`
Entity / entity-inventory data stream	`entity-mappings/references/entity-field-catalog.md` + `entity-mappings/references/entity-pipeline-patterns.md`

Tag	Covers
`domain:manifest`	Root or data stream manifest fields, format_version, conditions, categories, owner, policy templates
`domain:changelog`	changelog.yml schema, version mismatch, missing entries (missing = user-shipped package content changed without an entry/bump; internal metadata-only changes such as `owner.github` need none), invalid links (`pull/99999` dev placeholder is expected pre-merge — see conflict-resolutions), entry-type miscategorization only when the diff shows an observable compatibility/behavior change (re-bucketing bugfix/enhancement is editorial, not a finding)
`domain:build`	`_dev/build/build.yml` missing or outdated, doc template issues
`domain:pipeline`	Ingest pipeline correctness, JSE00001, on_failure, tags, ECS categorization in pipeline
`domain:input`	Agent stream template issues -- all input types including CEL, HTTPJSON, AWS S3, TCP, etc.
`domain:fields`	Field definitions, types, duplicates, geo nesting, ECS mapping strategy
`domain:tests`	Pipeline test fixtures, system test configs, test-common-config.yml, sample_event.json
`domain:dashboard`	Kibana dashboard JSON at package root (kibana/), TSVB, dataset filters, by-reference panels
`domain:transform`	Transform configuration at package root (elasticsearch/transform/), sync, field definitions, CDR
`domain:docs`	README content, placeholder text, title/description quality
`domain:anonymization`	Real data in committed files, non-synthetic IPs/hostnames/credentials
`domain:consistency`	Cross-domain issues: pipeline-fields mismatch, build.yml-pipeline ECS mismatch, unused manifest vars

review-integration

معلومات المصدر

خيارات التثبيت

مراجعة ملفات المصدر

المزيد من هذا المستودع

review-integration

Skill authority

When to use

When NOT to use

review-integration

Skill authority

When to use

When NOT to use

Reviewing new vs existing integrations

Version-related rules

Pattern-related rules

How to determine new vs existing

Step 1: Determine scope

Step 2: Classify files by domain

Step 3: Load domain skills and review checklists

Step 3b: Always-load skills

Step 4: Load review-specific references

Step 5: Run automated validation

Step 6: Inspect and produce findings

Cross-file checks

Output format

Verdict rules

Domain tags

Severity levels

Important rules

Review discipline

Reference files

المزيد من هذا المستودع