A guide that accompanies SKILL.md — pick the right skeleton pattern before placing any coordinates. Each pattern: when to use it, a minimal worked example (click a chip to watch the flow run), and a "Why this layout" section — the single most important part for applying it correctly to a different case, not just for copying the raw coordinates.
Which pattern to choose?
1 flow, with phases
A single process running from A to Z, but part of it is "live", the rest is "planned / not yet built" → Pattern 1.
2+ sources, 1 shared destination
Multiple methods/channels produce the same kind of result, then merge into 1 shared processing/review step → Pattern 2.
1 orchestrator, N subsystems
A central component calls back and forth with multiple independent systems, and the subsystems aren't directly related to each other → Pattern 3.
Has a pass/fail branch point
A condition decides which direction the flow continues in, each direction leading to a different outcome → Pattern 4.
Combining several patterns
Real diagrams usually NEST patterns — e.g. 2 sources converging (Pattern 2) into a step that then has a pass/fail branch (Pattern 4). Identify each piece and combine them, don't try to force everything into 1 mold.
1Linear multi-phase flow
Use this when there's 1 main flow but only part of it has been built — the rest is planned. Lay it out by row = phase (not by box type), each phase gets its own boxed-off region, region borders in a different color so "live" vs "planned" is distinguishable from a distance without reading any text. Real example: a data pipeline where phase 1 (ingest & storage) is live and phases 2–3 (enrichment, serving) are still planned.
Main flow
1 Source → Processing, 2 Processing → Storage, each pair has a parallel return direction
Phase transition
3 Only 1 direction — this is a progress dependency ("phase 2 waits for phase 1 to stabilize"), not a request/response, so it doesn't need a return direction
Planned branch
4 Drawn identically to the main flow but with dashed boxes + a "planned" label — don't use a different color for "not yet built", use the STROKE (dashed) instead so it doesn't stray from the semantic color palette
Why this layout
Stack phases by row (top/bottom), not by column — readers are used to reading "top before bottom", the same way they read text, so "phase 1 on top, phase 2 below" feels more natural than "left/right". Columns B/D line up so the phase-transition arrow is 1 straight vertical segment, not a detour.
2Multiple sources converging to one point
Use this when there are 2+ sources/methods producing the same kind of result, and they all merge into 1 shared processing/review step — e.g. 2 content-generation methods but only 1 moderation process. Stack the sources offset vertically (not lined up in the same row) so the converging lines form a natural funnel shape, instead of forcing 2 lines lined up into the same point. Real example: an AI auto-draft flow and a manual staff-authored flow, both merging into a shared "Finalize & publish" review step.
Source A
1 Enters Shared processing at the TOP anchor point on the left edge (y=130)
Source B
2 Enters the same left edge but at the BOTTOM anchor point (y=160) — doesn't coincide with Source A
Shared processing → Result
3 After merging, there's only 1 outgoing flow — no need to split by origin anymore
Why this layout
The 2 sources are offset top/bottom (not in the same row) so each converging line is a simple bent segment (L-shape), instead of 2 lines stacking on top of each other as they both approach the same point. Both enter the left edge of Shared processing (not the top edge) because the left edge makes use of the vertical gap between the 2 sources — the top edge would force one of the two lines to loop over the other box's roof.
3Central hub (orchestrator)
Use this when there's 1 central component calling back and forth with N independent systems, and the subsystems are NOT directly related to each other (unlike Pattern 2 — there, sources all flow into the same kind of result; here, each branch is a separate relationship with the hub). Place the hub at the dead center, each subsystem at exactly 1 of the 4 directions (top/bottom/left/right) so every branch is a straight axis-aligned line, with no branch needing to route around another.
Hub ↔ System 1
1 Each branch has its own color — don't reuse 1 color for all 4 branches even though they're all "hub calling out"
Hub ↔ System 2
2 Symmetric with the top branch through the hub's center
Hub ↔ System 3
3 Horizontal axis, doesn't cross the vertical axis because the hub sits at the center of both axes
Hub ↔ System 4
4 Symmetric with the left branch through the hub's center
Why this layout
Placing the hub at the center of all 4 axes is the ONLY way to make all 4 branches straight lines — any off-center position forces at least 1 branch to bend/route around. Beyond 4 subsystems, don't force in extra diagonal directions (gets messy) — switch to placing the hub near the top, with the subsystems arranged in a grid below it; each branch can still be a short bent line.
4Conditional branching
Use this when there's 1 decision point splitting the flow into 2+ different outcomes. No need to draw a diamond symbol (classic flowchart style) — just use a REGULAR BOX for the decision point, attach a "Pass"/"Fail" label (≤4 words) on each branching arrow to distinguish direction — keep the same shape vocabulary consistent with the rest of the diagram, don't mix in a new symbol.
Into the decision point
1 Has a return direction — the decision point may need to ask for more information
Pass branch
2 Has NO return direction — this is the END point of the flow, not a loop, so it doesn't need a return direction (state the reason explicitly, as the rule requires)
Fail branch
3 Also an end point, colored red because this branch needs a human to step in — red is used per its correct semantic meaning "checkpoint needing attention", not "error"
Why this layout
The 2 branches are symmetric across the decision point's horizontal axis — every branch has just 1 bend (horizontal→vertical→horizontal), neither branch is longer/more complex than the other despite different content, keeping a "2 equal choices" feel instead of accidentally implying one branch is "primary" and the other "secondary".