| name | graph |
| description | Graph engineering for parallel task execution: convert a task, PRD, SPEC, or issue set into a dependency graph (DAG), layer it into supersteps, then implement each independent node concurrently with subagents โ each node runs /goal โ /review-it โ /ship-it in an isolated git worktree, with a fan-in barrier between waves. Triggers on: graph, graph engineering, build a graph, task graph, dependency graph, DAG, parallel implement, ๅนถๅๅฎ็ฐ, ๅนถ่กๅฎ็ฐ, ไปปๅกๅพ, ๆไปปๅกๅๆๅพ, fan-out fan-in, superstep, dynamic workflow. |
| user-invocable | true |
| allowed-tools | ["Bash(git:*)","Bash(gh:*)","Bash(cat:*)","Bash(mkdir:*)","Bash(grep:*)","Bash(python3:*)"] |
graph โ Task/PRD to Parallel Execution Graph
Turn a task (or PRD / SPEC / issue set) into a directed acyclic graph of work units, layer it into supersteps (waves), and implement each wave's independent nodes concurrently using subagents. Each node runs the full /goal โ /review-it โ /ship-it pipeline inside its own git worktree, so parallel nodes never clobber each other's working tree. Between waves, a fan-in barrier merges results and re-plans the next wave.
This is the parallel sibling of /loop-it. /loop-it is strictly sequential (one worktree, one issue at a time). /graph fans out every independent node in a wave at once.
Mental Model (borrowed from LangGraph / graph engineering)
| Concept | Here |
|---|
| Node | One implementable unit of work (an issue / subtask) |
| Edge | A dependency: B depends on A โ edge A โ B |
| Superstep / wave | A set of nodes whose deps are all satisfied โ run concurrently |
| Fan-out | Dispatch one subagent per node in the current wave |
| Fan-in (barrier) | Wait for all nodes in the wave before starting the next |
| State channel | .graph_state โ shared checkpoint, rewritten between waves (resume source) |
| Live tracker | graph.html โ Claude-style light-theme dashboard, re-rendered from .graph_state at every checkpoint |
| Dynamic re-plan | After a wave, revise the graph if new work/deps emerged |
Core principle: Independent nodes in the same wave have no shared state and no ordering dependency, so they can run in true parallel. Dependencies define the only ordering. Everything else runs at once.
Overview
Input (task / PRD / SPEC / issues)
โ
โผ
1. Decompose into nodes โโโโโโโโโโบ nodes = {id, title, deps, criteria, scope}
โ
โผ
2. Build DAG + validate โโโโโโโโโโบ detect cycles, orphan deps
โ
โผ
3. Topological layering โโโโโโโโโโบ waves = [[n1,n2,n3], [n4,n5], [n6]]
โ
โผ
4. Render graph + confirm with user
โ
โผ (write .graph_state + graph.html โ open graph.html to watch live)
โโโโโโโโโโโโโ per wave (superstep) โโโโโโโโโโโโโ
โ โ
โ FAN-OUT: 1 subagent per node (parallel) โ
โ each subagent, in its own git worktree: โ
โ /goal (inline implement) โ /review-it โ
โ โ /ship-it โ
โ โ
โ FAN-IN barrier: wait for ALL nodes โ
โ integrate, update .graph_state โ
โ re-render graph.html โ
โ re-plan next wave if graph changed โ
โ โ
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
โ
โผ
All waves done โ final summary
Step 1: Locate & Decompose Input
Accept any of: a free-form task description, a PRD/SPEC file, or an existing issue set (GitHub / local .md / iCafe).
- PRD/SPEC โ reuse
/to-issues decomposition rules (one node per User Story; split large, merge tiny).
- Existing issues โ each issue is a node; parse dependencies from issue bodies (
Depends on: #3, Dependencies: #3, #5).
- Free-form task โ break into the smallest independently-shippable units yourself.
Each node MUST have:
Node #N
title: short imperative title
deps: [list of node ids] or []
criteria: acceptance criteria (checklist) โ how the subagent knows it's done
type: backend | frontend | fullstack | ui | infra | docs
scope_hint: which files/dirs this node is expected to touch (for conflict analysis)
scope_hint matters: two nodes with no dependency edge but overlapping file scope are not truly independent โ see Step 3.
Step 2: Build the DAG & Validate
Construct edges from deps. Then validate:
| Check | Action on failure |
|---|
Cycle (A โ B โ A) | Print โ ๏ธ ๅพช็ฏไพ่ต: #A โ #B. Break by node id order, warn user, ask to confirm or fix. |
Dangling dep (#7 depends on #99, no such node) | Print warning, drop the phantom edge. |
| Scope collision (two dep-free nodes edit same files) | Add a soft edge to serialize them (lower id first), OR flag for user. Never let two parallel worktrees fight over the same files. |
Hot-file exception: A shared wiring file that nearly every node must touch (e.g. router.go, main.go, mod.rs, a DI container, an __init__ re-export) does NOT count as a scope collision โ treating it as one would serialize the entire graph into a chain. For such files, assume append-only edits merge cleanly, and prefer one of: (a) designate a single node that owns wiring and have others expose a registration hook, or (b) do a tiny follow-up "wire everything" node in the last wave. Reserve the collision rule for nodes that edit the same logic in the same file (e.g. two handlers rewriting the same function).
Step 3: Topological Layering into Waves
Compute waves via Kahn's algorithm:
- Wave 0 = all nodes with
deps == [] and no scope collision among themselves.
- Remove wave-0 nodes; Wave 1 = nodes whose deps are now all satisfied.
- Repeat until all nodes placed.
- Within a wave, if two nodes edit the same logic in the same file (real collision, per the hot-file exception in Step 2), push the higher-id one to the next wave. Bare wiring-file overlap does not trigger this.
ID conventions (used consistently): lower id wins โ cycles break by lowest id first (Step 2), and scope collisions serialize with the lower id first (higher id deferred to the next wave).
Print the layered plan:
๐ Graph: 6 nodes, 3 waves
Wave 0 (parallel ร3): #1 db schema #2 config loader #3 logging util
Wave 1 (parallel ร2): #4 API handler (deps #1) #5 CLI flags (deps #2)
Wave 2 (parallel ร1): #6 integration (deps #4,#5)
Max parallelism: 3 subagents in Wave 0.
Also emit a Mermaid diagram for the user:
```mermaid
graph LR
n1[#1 db schema] --> n4[#4 API handler]
n2[#2 config loader] --> n5[#5 CLI flags]
n3[#3 logging util]
n4 --> n6[#6 integration]
n5 --> n6
```
Wait for user confirmation before dispatching any subagent. Let them adjust nodes, deps, or the max-parallelism cap.
Step 4: Pre-flight Checks
Before the first wave (same spirit as /loop-it):
git rev-parse --is-inside-work-tree
git status --porcelain
git branch --show-current
git ls-remote --heads origin
gh auth status
Any hard failure โ print the error and stop. Confirm a max concurrency cap with the user (default 3โ4 parallel subagents; more risks rate limits and review noise).
Then initialize the state channel + live tracker (do this once, right after the plan is confirmed and before the first fan-out):
cat > .graph_state <<'JSON'
{ "version": 1, "task": "...", "repo": "owner/repo",
"waves": [[1,2,3],[4,5],[6]], "current_wave": 0,
"nodes": { "1": {"title":"...","deps":[],"status":"pending","wave":0}, ... } }
JSON
grep -qxF '.graph_state' .gitignore || printf '.graph_state\ngraph.html\n' >> .gitignore
python3 skills/graph/scripts/render_graph_html.py .graph_state graph.html
Tell the user: open graph.html in a browser โ it auto-refreshes every 5s, so it tracks execution live (waves, node statuses, progress bar, and a Mermaid DAG colored by status). Re-run the render command at every checkpoint (see Step 5b) to push updates.
Step 5: Execute Wave by Wave (fan-out โ fan-in)
For each wave, in order:
5a. FAN-OUT โ one subagent per node, in parallel
Dispatch all nodes of the wave in a single response (multiple Agent/subagent calls in one message = concurrent). Each subagent works in its own git worktree so parallel file edits never collide:
git worktree add -b feat/node-{N}-{slug} ../.graph-worktrees/node-{N} main
Each subagent receives a self-contained prompt (it does NOT inherit orchestrator context):
You are implementing ONE node of a task graph, working in an ISOLATED git worktree.
Worktree: ../.graph-worktrees/node-{N} (already created on branch feat/node-{N}-{slug})
Node #{N}: {title}
Type: {type}
Scope: {scope_hint} โ stay within these files; do not touch other nodes' scope
Acceptance criteria (all must pass):
- [ ] {criterion 1}
- [ ] {criterion 2}
Context (deps already merged into main, pull first):
{summaries of dependency nodes' outputs, or the referenced PRD/SPEC excerpt}
Your pipeline (run all three, in order):
1. IMPLEMENT (inline /goal): read the node + any referenced PRD/SPEC, read adjacent
code, implement to satisfy EVERY acceptance criterion, run build + tests + lint
(e.g. go build ./... && go vet ./... && go test ./...). Iterate until all green.
2. REVIEW (/review-it): run code review on your changes, apply accepted findings,
re-run focused tests, repeat until review is clean (max 2 rounds).
3. SHIP (/ship-it): commit (message references the node/issue), push branch,
create PR, merge, close the issue.
Constraints:
- Work ONLY inside your worktree. Do NOT edit files outside {scope_hint}.
- Do NOT try to call `goal` via the Skill tool (it's a UI command, not a skill) โ
"implement" means you write the code yourself. /review-it and /ship-it ARE skills.
- If you cannot satisfy a criterion, STOP and report what's blocking โ don't fake it.
Return: node id, PASS/FAIL, PR/commit refs, files changed, and โ if you discovered new required work or a dependency the graph didn't capture โ a `NEW_WORK:` line describing it (title + which nodes it blocks). Emit `NEW_WORK: none` if there's nothing.
Why worktrees, not branches alone: /goal mutates the working tree. Two subagents editing the same checkout would corrupt each other. A worktree per node gives each its own filesystem checkout on its own branch โ that's what makes the wave genuinely parallel and safe.
5b. FAN-IN โ barrier, integrate, re-plan
Wait for every subagent in the wave to return (BSP barrier โ the next wave cannot start until this one commits). Then:
- Read each subagent's summary. Mark node
shipped or failed.
git checkout main && git pull โ dependency outputs are now on main for the next wave.- Remove finished worktrees:
git worktree remove ../.graph-worktrees/node-{N} (keep failed ones for investigation).
- Write checkpoint to
.graph_state, then re-render the tracker:
python3 skills/graph/scripts/render_graph_html.py .graph_state graph.html (the open graph.html picks it up on its next auto-refresh).
- Dynamic re-plan (LangGraph-style conditional edge): scan each subagent's
NEW_WORK: line. If any is not none, add the new node(s)/edge(s) and re-layer the remaining nodes before starting the next wave. Show the user the delta.
- If any node in the wave failed, mark all nodes that depend on it as
blocked and skip them (their inputs aren't ready).
Proceed to the next wave.
State File: .graph_state (+ live tracker graph.html)
.graph_state lives at the repo root and must be in .gitignore. It's the single source of truth: checkpoint it after every wave so a crash resumes at the wave boundary, and re-render graph.html from it so the browser dashboard stays live. graph.html is a derived view โ never hand-edit it; regenerate it from .graph_state.
{
"version": 1,
"updated_at": "2026-07-21T10:30:00Z",
"task": "Add user auth",
"repo": "owner/repo",
"waves": [[1, 2, 3], [4, 5], [6]],
"current_wave": 1,
"nodes": {
"1": { "title": "db schema", "deps": [], "status": "shipped", "branch": "feat/node-1-db-schema", "pr": 43, "wave": 0 },
"2": { "title": "config loader", "deps": [], "status": "shipped", "wave": 0 },
"3": { "title": "logging util", "deps": [], "status": "failed", "wave": 0, "error": "test TestLog failed", "attempts": 2 },
"4": { "title": "API handler", "deps": [1], "status": "in_progress", "wave": 1 },
"6": { "title": "integration", "deps": [4, 5], "status": "blocked", "wave": 2, "reason": "depends on #3 (failed)" }
}
}
Status values: pending | in_progress | shipped | failed | blocked | skipped. Each node carries title + deps so graph.html can draw the DAG and cards straight from the checkpoint.
Render the tracker any time with:
python3 skills/graph/scripts/render_graph_html.py .graph_state graph.html
On resume: read .graph_state, skip shipped, ask about failed (retry/skip), re-derive remaining waves, and re-render graph.html.
Safety Guards
- Worktree isolation is mandatory โ never run two parallel
/goal sessions in the same checkout.
- Fan-in barrier is mandatory โ never start wave N+1 before every node in wave N returns and merges.
- Scope collisions serialize โ dep-free nodes touching the same files go in different waves.
- Never skip /review-it before
/ship-it.
- Cap concurrency โ default 3โ4; more invites rate limits and merge contention.
- Never force-push to main. Each node ships via its own branch/PR.
- Failed node blocks its dependents โ don't ship on top of unmet inputs.
- Max retries per node โ reuse
/loop-it's error classes; don't loop forever.
- Confirm the plan before the first fan-out.
Common Mistakes
| Mistake | Fix |
|---|
| Dispatching subagents in separate responses | One response, multiple calls = parallel. Separate = sequential. |
| No worktree โ parallel edits corrupt the tree | One git worktree per node. |
| Two "independent" nodes edit the same file | Add a soft edge; put them in different waves. |
| Starting the next wave before all nodes merge | Enforce the fan-in barrier. |
| Over-decomposing into 20 trivial nodes | Merge tiny units; a node should be a meaningful shippable unit. |
| Ignoring a failed node's dependents | Mark them blocked, skip them. |
Relationship to Other Skills
/prd โ /prd-to-spec โ /to-issues โโฌโโบ /loop-it (sequential: one node at a time)
โโโบ /graph (parallel: whole wave at once)
โ
each node: inline /goal โ /review-it โ /ship-it (in its own worktree)
/to-issues โ decomposition rules reused for building nodes./loop-it โ sequential counterpart; use it when nodes heavily share files or serial safety matters./graph โ this skill; use it when the DAG has genuine parallelism (independent subsystems)./review-it, /ship-it โ real skills each node's subagent invokes.
