maintain-integration

When to use vs create-integration

Use this skill when the package already exists:

• reviewing quality, ECS compliance, or correctness of an existing package
• fixing specific issues: pipeline errors, field mappings, ECS categorization, CEL programs, manifests
• running a full quality improvement pass (review → fix → re-validate loop)
• making minor adjustments to existing data streams

Use create-integration instead when:

• creating a new integration package from scratch
• adding a new data stream to an existing package (create-integration → references/add-datastream-workflow.md)

Modes

Review only (read-only, no edits)

→ Read references/review-workflow.md fully before starting.

Run automated validation, delegate inspection to a subagent (see Dispatch convention in references/review-workflow.md) pointing it at review-integration/references/reviewer-subagent-guidance.md as its operating manual, present findings with no file changes.

Full improvement pass (analyze → fix → re-validate)

→ Read references/improve-workflow.md fully before starting.

Analyze issues (from prior review or fresh reviewer run), prioritize by severity, fix directly or delegate to subagents, re-validate, and report.

Minor direct fix (no subagents needed)

For small targeted changes you can handle inline without loading a full workflow:

• manifest field corrections (title, description, format_version, conditions, owner)
• changelog entries and version bumps — see package-spec skill
• documentation placeholder text in _dev/build/docs/README.md
• _dev/build/build.yml creation or ECS reference bump
• simple field file fixes (typos, missing entry, duplicate removal)
• CEL formatting only — run celfmt -s -agent -i cel.yml.hbs -o cel.yml.hbs in the stream's agent/stream/ directory

Run elastic-package lint and elastic-package check after any direct edits to confirm no regressions.

Skills to load for direct work

• elastic-package-cli — validation and test commands
• package-spec — manifest rules, version bumps, and changelog schema

Do not load domain-specific skills (pipelines, CEL, ECS, field mappings) into your own context. Delegate to subagents that already have that knowledge.

Subagents

All specialised work is delegated to the platform's generic / general-purpose subagent (Cursor: generalPurpose Task agent; Claude Code: general-purpose Task agent; or the equivalent on other platforms). Each task prompt must point the subagent at the relevant *-subagent-guidance.md file by path and instruct it to read that file (plus the skill SKILL.md it lists in "First steps") end-to-end before doing any other work. Do NOT read the guidance file yourself or paste its contents into the task prompt — that doubles its context cost. Pass only the path plus the task-specific context. The subagent will load the manual itself in its own fresh context. Full dispatch rules and per-workflow detail live in references/review-workflow.md and references/improve-workflow.md.

When delegating, provide the subagent with: package path, data stream path, specific issues to fix (paste findings), sample data if relevant, and any constraints.

Data anonymization

All data committed must be fully anonymized — no real IPs, hostnames, emails, tokens, or org identifiers in any committed file. When fixing or adding test fixtures, mock responses, sample events, or documentation examples, verify all values are synthetic. Anonymize any real data found as part of the improvement pass.

References

• references/review-workflow.md — read-only review workflow (phases 1–4, mandatory checklists, output format)
• references/improve-workflow.md — full improvement workflow (analyze → prioritize → fix → re-validate → report)