flow

name	flow
description	Plan and run a dependency-aware lionagi DAG through `flow.submit`, including dry runs and reactive follow-up capacity. Use when work has stages, dependencies, parallel branches, or a final synthesis step.
allowed-tools	["Bash","Read","Write","Glob","Grep"]

Running a Dependency DAG

Use flow.submit when tasks have dependency edges or workers should be able to discover follow-up work during execution. Use fanout for a fixed set of independent perspectives.

Required call sequence

Ask for the catalog first, in its own call, and confirm flow.submit is available:

mcp__plugin_orchestrate_lion__request(help=true)

For a prompt-driven flow with no playbook, fetch the exact schema and fingerprint:

mcp__plugin_orchestrate_lion__request(help="flow.submit")

If args names a playbook, instead ask with the exact same spelling because the schema and fingerprint vary by playbook:

mcp__plugin_orchestrate_lion__request(help={"verb": "flow.submit", "playbook": "feature"})

Never combine help and ops. Put schema_fingerprint beside args, not inside it.

Worked example

First plan only. The prompt limits the initial DAG to four assignments while max_ops: 6 reserves capacity for up to two reactive follow-ups:

mcp__plugin_orchestrate_lion__request(ops=[
  {"op": "flow.submit",
   "args": {
     "query": ["claude"],
     "prompt": "Create at most four initial assignments to analyze an API migration, propose a plan, and independently verify it. Preserve remaining capacity for follow-up work discovered by the workers.",
     "max_ops": 6,
     "reactive": "all",
     "with_synthesis": true,
     "dry_run": true
   },
   "schema_fingerprint": "<fingerprint from help=\"flow.submit\">"}
])

The dry run is a background job. Read its returned run_id with job.status and job.output. Confirm the planned assignment count leaves headroom, then resubmit the same op without dry_run:

mcp__plugin_orchestrate_lion__request(ops=[
  {"op": "flow.submit",
   "args": {
     "query": ["claude"],
     "prompt": "Create at most four initial assignments to analyze an API migration, propose a plan, and independently verify it. Preserve remaining capacity for follow-up work discovered by the workers.",
     "max_ops": 6,
     "reactive": "all",
     "with_synthesis": true
   },
   "schema_fingerprint": "<fingerprint from help=\"flow.submit\">"}
])

The second response returns a new run_id, not the final answer. Poll it and retrieve output:

mcp__plugin_orchestrate_lion__request(ops=[
  {"op": "job.status", "args": {"run_id": "<run_id>"}}
])

mcp__plugin_orchestrate_lion__request(ops=[
  {"op": "job.output", "args": {"run_id": "<run_id>"}}
])

job.list finds recent runs, and job.kill stops one by run_id.

Reactive budget

For a nonzero max_ops, reactive spawn capacity is max_ops - initial assignment count. The planner and reactive spawns share that one budget; there is no separate reservation parameter. If the dry-run plan already contains max_ops assignments, follow-ups have zero capacity. Tighten the requested initial plan or raise max_ops before execution.

With max_ops: 0, the CLI leaves the initial plan uncapped and applies its separate default reactive-spawn ceiling. Prefer an explicit total when cost needs to be predictable.

Multiple outer MCP ops run in order, but a failure returns ok=false without stopping its siblings. Check every op's ok field.

Checkout-local alternative

Inside a lionagi checkout with li on PATH:

li o flow claude "Create at most four initial assignments to analyze an API migration." \
  --max-ops 6 --reactive all --with-synthesis --dry-run