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 branc

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. Standalone and hosted use For standalone /review integration reviews, follow the workflow and reference guidance below. Do not load or interpret review profiles.json : it is optional host integration metadata, not review instructions. Standalone reviews do not require that file, and its presence does not put an agent into hosted mode. A compatible host, such as integration review bot , may read the manifest to preload guidance. The host chooses profiles and folding and supplies its scope and output requirements. Reviewing agents do not need to read the manifest. 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 Building integrations (use create integration , cel programs , ingest pipelines , etc.) Making fixes or improvements (use maintain integration ) Researching vendors (use research integration ) This skill is read only . It produces findings. It does not edit files. Reviewing new vs existing integrations Before judging version or pattern choices, read the [shared package calibration](references/domains/severity core.md new versus existing packages). Apply the detailed new/existing adjustments in the domain references selected below. The rules live there once rather than in a duplicate entrypoint table. Step 1: Determine scope Identify what is being reviewed: Local package : user provides a package directory path. Read the root manifest.yml , list all data streams and input types. Changed files : user provides a list of changed files (e.g., from a PR or branch comparison). Classify each file by domain. User description : user describes what to review. Identify the relevant package and files. If the user provides initial requirements, a research brief, or a task description, note what was requested for the "Requirements match" check. Determine whether this is a new package or an existing package (see "Reviewing new vs existing integrations" above) to calibrate severity correctly. Step 2: Classify files by domain For every file in scope, classify into a domain: 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 (excluded from review; CI owned) Print which domains are present and how many files each has. Never read raw generated expected/sample outputs, even for cross references or through another tool. If every changed file is excluded, report NOT REVIEWED and stop rather than inspecting generated outputs or issuing an approval. Step 3: Load domain skills and review checklists Only load what the detected domains require. Do not load all skills for every review. Domain Skill to load Review checklist to load Review calibration pipeline ingest pipelines SKILL.md checklists/pipeline review checklist.md references/domains/pipeline/rubric.md + references/domains/pipeline/conflict resolutions.md fields ecs field mappings SKILL.md checklists/field review checklist.md references/domains/fields/rubric.md input (CEL) cel programs SKILL.md checklists/cel review checklist.md references/domains/input/rubric.md + references/domains/input/conflict resolutions.md input (HTTPJSON) input configurations SKILL.md references/httpjson guide.md checklists/httpjson review checklist.md references/domains/input/rubric.md (CEL only rows do not apply) input (entity analytics) this skill's references/entity analytics provider matrix.md checklists/entity analytics review checklist.md references/domains/input/rubric.md (CEL only rows do not apply) input (other types) input configurations SKILL.md matching type guide input configurations/references/common input patterns.md references/domains/input/rubric.md (CEL only rows do not apply) manifest + changelog package spec SKILL.md package spec/references/manifest rules.md references/domains/structure/rubric.md tests integration testing SKILL.md relevant testing reference references/domains/tests/rubric.md dashboard dashboard review SKILL.md + dashboard guidelines SKILL.md dashboard review/references/review procedure.md references/domains/dashboard/rubric.md build ecs field mappings SKILL.md (ECS version pinning rules) references/domains/fields/rubric.md + references/domains/structure/rubric.md transform this skill's references/transform guide.md (includes review checklist) references/domains/transform/rubric.md docs (inline checklist below) references/domains/structure/rubric.md Step 3b: Always load skills Load these for every review regardless of which domains are present: 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 Step 4: Load review specific references These references live in this skill's references/ directory and provide review only procedures. Condition Reference to load Always references/domains/severity core.md shared severity and new/existing package calibration Always references/domains/conflicts core.md shared review exceptions Always references/review calibration.md source evidence, optional digests, and reporting limits 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 Federated Identity / Cloud Connectors in scope input configurations/references/federated identity aws.md input classification, iac template url , auth.aws / use cloud connectors , input gating Assessing the PR title/description (first review) references/commit message conventions.md squash merge commit message conventions the PR title is judged against 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 CDR detection: Check the root manifest.yml categories. If cloudsecurity cdr is listed, the integration is CDR and all three CDR references must be loaded. Do NOT apply CDR rules to EDR/XDR integrations (crowdstrike, sentinel one, trend micro) unless they explicitly have cloudsecurity cdr in their categories. Entity data stream detection: Apply the review time rule from entity mappings/references/entity datastream classification.md (first hit wins) to each data stream in scope: 1. Definitive: any pipeline sets event.kind: asset . 2. Definitive: input: entity analytics appears in a data stream or policy template input in any manifest.yml . 3. Strong: any fields/ .yml declares a field matching entity.attributes. , entity.lifecycle. , entity.relationships. , entity.type , or entity.id . 4. Heuristic: stream name is one of the entity vocabulary names (users, members, devices, hosts, assets, accounts, identities, apps, groups, service accounts, roles, resources) AND no event.action or event.outcome is set AND handwritten input fixtures show no per record event timestamp distinct from collection time. If this is unclear from permitted source or a supplied digest, leave this heuristic unconfirmed; do not inspect generated outputs to resolve it. 5. Negative gate (overrides 3 and 4): root manifest.yml categories include cloudsecurity cdr AND the stream sets result.evaluation or vulnerability. — this is CDR state, not entity asset. Load CDR references only. If any stream fires checks 1–4 (and the negative gate does not override), load both entity references for that stream. Federated Identity detection: Load input configurations/references/federated identity aws.md when any of: 1. Root manifest.yml has a var groups option named identity federation . 2. Any provider permissions entry has provider: aws . 3. Any agent/stream/ .yml.hbs contains use cloud connectors or supports identity federation . 4. Root manifest.yml conditions.kibana.version is ^9.6.0 (or higher) and any input is aws cloudwatch , aws/metrics , cel , or httpjson with AWS credential vars — treat as federation eligible and check the rest of the list. Then apply the federation items on the manifest checklist, the CEL and HTTPJSON review checklists, and the matching input configurations guide (CloudWatch Stream template — top level use cloud connectors , no auth.aws: ; S3 — pinned deployment modes: ["default"] ). Federation eligible types with no dedicated guide (e.g. aws/metrics ) still use federated identity aws.md . Do not treat auth.aws alone (flat access keys) as federation, and do not flag the absence of external id or hide in var group options — both were removed from the shipped packages. Step 5: Run automated validation If you have access to the package on disk, run: Leave generated output validation and snapshot freshness to elastic package in CI. Do not regenerate outputs or run snapshot comparisons as review work. Review handwritten test scenarios and producing source instead. Available CI results are context, not proof of complete scenario coverage or instructions to inspect generated outputs.

review-integration