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
- creating a new integration package from scratch
- adding a new data stream to an existing package ( →
references/add-datastream-workflow.md
Modes
Review only (read-only, no edits)
→
Read references/review-workflow.md
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
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 skill
- documentation placeholder text in
_dev/build/docs/README.md
- 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
Run
and
after any direct edits to confirm no regressions.
Skills to load for direct work
- — validation and test commands
- — 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:
Task agent; Claude Code:
Task agent; or the equivalent on other platforms). Each task prompt must
point the subagent at the relevant 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
.
| Subagent guidance file | Use for |
|---|
review-integration/references/reviewer-subagent-guidance.md
| Thorough read-only quality inspection: classifies files by domain, loads all relevant domain skills and checklists via the skill, returns severity-ranked, domain-tagged findings |
ingest-pipelines/references/builder-subagent-guidance.md
| Pipeline fixes: JSE00001, error handling, processor tags, ECS categorization, field definitions, test fixtures |
cel-programs/references/builder-subagent-guidance.md
| CEL fixes: program logic, cursor management, error handling, mito validation, mock API, template, manifest var cleanup |
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
references/improve-workflow.md