graph-orchestratorlisted

# Graph Orchestrator Most multi-step plans are written as chains because that's how people narrate work, not because the steps actually depend on each other. A chain of ten steps where only three real dependencies exist wastes time, and worse, it burns context linearly, so quality degrades toward the end. This skill turns a request into a dependency graph first, then executes it in phases. The graph is a *planning* artifact, but it also decides who executes each node: work you do inline, and work you dispatch to parallel subagents when the environment provides them. What the graph buys you is knowing which work can fan out, which must wait, where results need to be consolidated before they overflow, and which single node needs a human's sign-off. ## The core move: the dependency audit This is the part that matters most. Everything else follows from it. For every pair of steps you were about to sequence, ask one question: > **Does step B literally read the output of step A?** If B only needs the *same inputs* A had, they are independent. If B needs A's *result*, there's a real edge. People systematically over-connect. "Analyze the auth module and then analyze the payments module" has no edge. The word "then" is narration. "Analyze the auth module and then write a report on it" has a real edge. Work through the list explicitly rather than eyeballing it: ``` Step: Summarize each of 40 support tickets Reads prior output? No, each ticket is independent input → parall