eve-orchestration

Eve Orchestration

This skill explains how to orchestrate complex work in Eve Horizon by spawning child jobs, managing dependencies, and maximizing parallel execution while respecting depth limits.

Core Principles

1. Parent sets a target depth and passes it to children.
2. Each job decides its own decomposition based on scope and depth.
3. Parallelize by default when tasks can proceed independently.
4. Use relations to encode true dependencies, not preference.
5. Leaf jobs execute; parent jobs orchestrate and wait.
6. Orchestrators stay lightweight — dispatch work, don't accumulate it.

When to Orchestrate vs Execute Directly

Not every job needs decomposition. Use this heuristic:

• Execute directly when the work is atomic, self-contained, and fits comfortably in a single agent's context and capability. Examples: fix a single bug, write one document section, run a diagnostic check.
• Orchestrate when the work has independent sub-parts that benefit from parallelism, when the scope exceeds what a single agent should hold in context at once, or when different parts require different skills or tool access.
• Default to direct execution. Orchestration has overhead (job creation, waiting, resumption). Only decompose when parallelism or scope genuinely demands it.

Always Start With Context

Fetch the current job context before deciding anything:

eve job current --json
# or explicit
eve job current $EVE_JOB_ID --json

Use the context to confirm:

• job.depth (current depth)
• children (existing sub-jobs)
• relations (dependencies)
• blocked / waiting / effective_phase

Environment and IDs

Use the environment to avoid guessing identifiers:

• EVE_JOB_ID: current job
• EVE_PROJECT_ID: owning project
• EVE_ATTEMPT_ID: current attempt
• EVE_REPO_PATH: workspace path
• EVE_AGENT_ID: agent identifier (optional)

Depth Propagation

The parent decides the target depth and passes it to children (in the child description or data). Each child must read and honor the same target depth.