# Subagent Dag Orchestration

Use when delegated work breaks into several tasks that agents on the roster can carry out.

- Repository: https://github.com/EverMind-AI/Raven (5958 stars)
- Category: Testing
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add EverMind-AI/Raven --skill subagent-dag-orchestration -g -a claude-code -y`
Codex: `npx skills add EverMind-AI/Raven --skill subagent-dag-orchestration -g -a codex -y`
Cursor: `npx skills add EverMind-AI/Raven --skill subagent-dag-orchestration -g -a cursor -y`
Gemini CLI: `npx skills add EverMind-AI/Raven --skill subagent-dag-orchestration -g -a gemini-cli -y`

## Description

Use when delegated work breaks into several tasks that agents on the roster can carry out. The host's role decides what to delegate; this skill decides how to group that work. A DAG node dispatches to a roster agent, including the generic agent, and cannot call the host's tools. Choose from the tool's `subagent` parameter enum -- agent names on ordinary turns, worker labels when a Worker Table is bound. The roster describes underlying capabilities. Reading a brief or checking task status is host coordination, not a reason to create graph nodes. Before dispatching tasks one at a time, test three things: are two or more tasks independent (they can run at once), does a task hand its result to the next (a graph wires that handoff with no turn of yours in between), do the tasks want different specialists (the roster closes the tool list). If any of the three holds, orchestrate the whole task as one run_subagent_dag call. A step whose result decides what runs next is a decision node: give it routes, and guard what follows with when, all in one graph. Iteration is graphs in series, one graph per round, driven by you.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Sub-Agent DAG Orchestration

## When to use

The trigger is **delegated work that breaks into several tasks**.

The host's role decides what to delegate; this guide decides how to group the work.
A DAG node dispatches to an agent on the roster, including `Raven-General`; it cannot
call the host's tools. Choose from that tool's `subagent` parameter enum: agent names
on ordinary turns, worker labels when a Worker Table is bound. A worker label selects
the underlying agent together with that worker's brief. The roster describes the
underlying agents' capabilities; its names are not dispatch values on a worker turn.
The host's own coordination calls, such as reading a brief or
checking task status, are not delegated tasks and do not need a graph just because
there are several of them.

For the delegated tasks, test three things before dispatching them one at a time:

- **Independence**, can two or more steps run at the same time? Independent nodes are
  scheduled concurrently, up to the shared sub-agent cap
  (`max_concurrent_subagents`, `spawn` draws on the same allowance).
- **Handoff**, does a step hand its result to the next one? A node's output is written
  to a file the downstream node reads, and the graph wires that handoff itself. A `spawn`
  can hand its result on too, it takes a `node_id` and a later task names it the same way
  a node does, but only across a turn of yours; a graph needs none.
- **Specialism**, do the steps want different sub-agents? The roster at the end of
  the tool list says what each agent is for. When a Worker Table is bound, the
  `subagent` parameter also describes each worker's brief; choose a label that fits.

If any of the three holds, express the whole task as **one** `run_subagent_dag` call
rather than dispatching sub-agents one at a time. Persistence is not one of the reasons:
every node's prompt and output is written to disk, and so is every `spawn`'s.

The rest: https://github.com/EverMind-AI/Raven/blob/HEAD/raven/memory_engine/skills/subagent-dag-orchestration/SKILL.md