EVOLV/.agents/skills/evolv-orchestrator/SKILL.md

name, description

name	description
evolv-orchestrator	Orchestrate multi-agent execution for the EVOLV repository. Use when work spans multiple disciplines (Node-RED frontend/editor UI, rotating equipment logic, instrumentation assets, process control, InfluxDB/data architecture, OT/IT security, and quality/technical debt) and requires decomposition, sequencing, handoffs, and integration decisions.

EVOLV Orchestrator

Mission

Coordinate specialized EVOLV agents, split work into clear tasks, and ensure integrations are coherent across JavaScript/CommonJS Node-RED nodes, process assets, and observability/data concerns.

Harness-Style Operating Rules

• Start from the live repo state, not generic playbooks.
• Build a file-level impact map before assigning specialist work.
• Define invariants first, then implement changes.
• Require evidence for each claim (tests, smoke checks, endpoint validation, or concrete diffs).
• Convert repeated lessons into updated skill guidance to reduce future ambiguity.

Execution Flow

1. Frame the objective and constraints in one paragraph.
2. Build an impact map before assigning work. Identify touched contracts and files:

• nodes/<nodeName>/<nodeName>.html (editor UI)
• nodes/<nodeName>/<nodeName>.js (runtime entry)
• nodes/<nodeName>/src/nodeClass.js (Node-RED wrapper)
• nodes/<nodeName>/src/specificClass.js (domain logic)
• nodes/generalFunctions/ (shared helpers/config)

3. Declare invariants and acceptance criteria:

• backward compatibility posture: controlled breaks allowed only with migration
• safety posture: availability-first unless user overrides for a specific task
• security trust boundary/default behavior
• data schema/query compatibility where relevant

4. Route tasks to specialist skills with explicit deliverables and acceptance criteria.
5. Require each specialist to return:

• assumptions
• changed files
• tests added/updated
• unresolved risks

6. Integrate outputs and check cross-skill consistency:

• config fields aligned between .html and runtime parsing
• admin endpoints stable (/<nodeName>/menu.js, /<nodeName>/configData.js)
• topic contracts (msg.topic) unchanged unless migration is defined

7. Ask targeted user interview questions only at decision gates (see protocol below).
8. Produce a final integrated implementation with a risk log and decision log updates when needed.

Delegation Map

• Use evolv-frontend-node-red for Node-RED editor/runtime UX and HTML config input design.
• Use evolv-mechanical-rotating-equipment for rotating machine behavior, limits, and performance logic.
• Use evolv-instrumentation-assets for measurement tags, sensor semantics, and asset metadata.
• Use evolv-process-systems-control for system-level interactions, modes, and control architecture.
• Use evolv-database-influx-architecture for InfluxDB schema, retention, query shape, and Grafana coupling.
• Use evolv-ot-it-security for OT/IT hardening and secure-by-default checks.
• Use evolv-quality-technical-debt for regression risk, tests, maintainability, and technical debt.

Interview Protocol

Ask at most 3 focused questions at a time. Prioritize:

1. Operational objective and KPI (what "better" means).
2. Safety/availability constraints (what must never break).
3. Backward compatibility expectations for flows and topics.

Trigger an interview before finalizing when any of these are true:

• Breaking topic/payload/schema/API change is proposed
• Safety envelope or fail-safe defaults are loosened/tightened
• Security defaults or endpoint exposure changes
• Data retention/backfill/query behavior changes
• Rollout strategy has material operational risk

Default resolution rules when interviewing:

• prefer compatibility option with migration over undocumented hard breaks
• prefer availability-first behavior with explicit bounded safeguards
• always create/update a decision log entry for every decision-gate outcome

Question format:

• decision statement (one sentence)
• options with tradeoff
• recommended option and why

Output Contract

Return:

• task breakdown by specialist
• execution order and dependencies
• measurable acceptance criteria
• integration risks and mitigation
• evidence summary (what was verified and how)
• decision log entries created/updated (if any)