Recipes

Open the graph playground and use its assistant. The prompts below are the canonical knowledge-base prompts. Each section identifier is also the fragment used by the assistant’s documentation link.

Read the response before acting. A graph-edit response previews ordered patches; it does not mutate the graph on submission. Use an individual patch’s Apply control or Apply all to commit the proposed edits. Undo and share use separate explicit action controls. Guidance-only answers do not change the graph. See assistant for the full response and application contract, and concepts for graph invariants.

add-node

Use this to extend a workflow one step at a time.

Prompt: add a transform node

The assistant proposes a node with a stable identity. The supported kinds are input, transform, branch, sink, and note; request the kind you need rather than treating every box as interchangeable. Inspect the proposed node, apply it, and then connect it as a separate editing step.

Adding a node is not execution of that node’s operation. A newly added node may still need a connection before the graph expresses the intended workflow.

connect-nodes

Use this when two existing steps need a directed connection.

Prompt: connect two nodes

Select two nodes to constrain the candidate pair, then inspect the proposed data wire. A source must be an input, transform, or branch; a target must be a transform, branch, or sink. A branch uses its yes output. With fewer than two selected nodes, the recipe searches the current graph, preferring selected nodes and then identifier order. Selection does not encode which node you clicked first, so review direction before applying. If no compatible new wire exists, the response explains that and proposes no connection.

Duplicate wires are not a way to express a second operation. An edge patch whose endpoint no longer exists is rejected with a reason rather than creating a dangling connection. See concepts for direction and handle rules.

validation-branch

Use this to show valid and invalid outcomes as separate routes.

Prompt: branch on validation

The proposal adds Validate input, Validation passed?, Accepted input, and Rejected input. The validator transform connects to the decision with a control edge; the branch’s yes output takes a data edge labelled valid, while no takes an error edge labelled invalid.

Select an existing input or transform as the preferred starting point. The recipe excludes nodes with assist- identifiers when choosing that anchor; if none is suitable it proposes a new Input data source. Apply the proposed nodes before their edges, or use Apply all. Inspect both outcomes after application.

This models a decision in the graph. It does not run an external validator or process real input data. The graph-validation recipe below checks graph structure, which is a different operation.

fan-out

Use this when one output should reach two independent destinations.

Prompt: fan out to two sinks

The assistant proposes Sink A and Sink B with one data edge to each. It anchors to an existing non-assist- input or transform, preferring a selected node; if none exists it proposes Input data. Inspect that source and both destinations, then apply nodes before edges or use Apply all. In the resulting graph, trace both outgoing connections from the shared source.

Fan-out is not conditional routing: two destinations share an output rather than receiving mutually exclusive true and false outcomes. Use the branch recipe when the decision matters.

branch-fan-out

Use this to combine validation, conditional routing, and distribution of accepted data.

Prompt: branch on validation then fan out to two sinks

The proposal starts with Validate input and Validation passed?. The yes path leads to a Fan out accepted data transform, which sends data to Sink A and Sink B; the no path leads to Rejected input. It uses the same selected-preferred, non-assist- input-or-transform anchor rule as the validation-branch recipe, creating Input data if needed. Review the full ordered proposal and apply nodes before edges, or use Apply all.

Do not confuse the accepted-data fan-out with the rejected-data route. This is a structural editing recipe, not evidence that data was validated or delivered to a service.

error-path

Use this to make a failure route visible instead of leaving it implicit.

Prompt: add an error path

The assistant proposes an Error review sink and an error-labelled edge. It prefers an existing non-assist- branch, using its no output; otherwise it chooses the input-or-transform anchor described above and uses out. Inspect the chosen source before applying, since selecting an ordinary transform does not override the preference for an existing branch.

Drawing an error path does not install retries, exception handling, or a dead-letter service. It records that path in the graph model.

auto-layout

Use this after editing when manual positions obscure the graph’s direction.

Prompt: auto layout left to right

The assistant previews deterministic layered positions. Apply the layout patch to change positions; use a top-to-bottom request when a vertical arrangement is more suitable. Compare the resulting arrangement with the same graph before deciding whether to retain it.

Layout changes coordinates, not the intended operations or connectivity. It is not a repair for invalid edges, and a visually tidy graph can still fail validation. See concepts for deterministic layout behavior.

validate-graph

Use this before interpreting a graph as a coherent workflow or after a group of edits.

Prompt: validate my graph

The assistant previews a structured report with ok, code, and message. Read the diagnostic, then apply the report to recheck the graph at that moment; no graph elements change. Correct the reported structural problem and validate the edited graph again.

A successful structural check is not a run of the workflow and does not establish the correctness of external services, data, or business rules. The exact checks are documented in concepts.

undo

Use this to return to the previous graph state retained by the craft editor.

Prompt: undo the last change

The assistant explains the requested action and exposes a separate explicit undo action. Use that control to invoke the editor’s history rather than expecting the prompt itself to change the graph.

Undo is bounded by the history available in the current editor. It is not a server-side revision archive or a way to recover an arbitrary earlier session.

share

Use this to create a link that carries the current graph through the editor’s share control.

Prompt: share this graph

The assistant offers a separate explicit share action. Activate it to use the craft editor’s bounded graph-link mechanism; inspect the generated link before sending it to someone else.

The prompt itself does not publish or transmit the graph. A graph link is not a collaborative workspace. The share codec requires a structurally valid graph and caps both the encoded base64url token and decoded JSON at 8,192 bytes; malformed, invalid, or oversized input returns share_invalid. Treat the graph data in a share link as data you are choosing to disclose.

custom-node

Use this to explore how a custom Svelte Flow renderer relates to the workflow node contract.

Prompt: show me a custom node

The assistant proposes a Custom transform node with operation: 'map' and expression: 'value => value', plus an explanation of the Svelte component and handle contract. Inspect and apply the node proposal, then compare its role and handles with the model described in concepts. The expression is stored configuration, not code executed by the assistant.

This does not generate, compile, or install a new Svelte component. It demonstrates the existing configurable node contract; adding a genuinely new renderer is source-code work.

scale

Use this to understand the boundaries that matter for larger graphs.

Prompt: how do I scale a large graph

The response is guidance about rendering and state management. It does not create a huge graph or run a benchmark. Use the scale demonstration described in demos for the app’s authored interactive example.

Keep graph size, visible rendering, state updates, and interaction cost distinct. An example’s node count is not a performance guarantee for every device or for arbitrary custom nodes.

theming

Use this to understand the app theme and Svelte Flow styling surface.

Prompt: how do I theme the canvas

The response explains the theme and Svelte Flow CSS variables. It is guidance-only: the assistant does not silently change global settings. Use the actual app controls or edit the relevant source styles when making a theme change.

A prose answer is not a saved preference or a generated stylesheet. Theme changes should preserve readable nodes, edges, selection indicators, and controls.

delete-selection

Use this when the selected graph elements are the ones you intend to remove.

Prompt: delete selected nodes

Select the relevant nodes or edges first. The assistant previews deletion of selected nodes, their incident edges, and selected edges. Inspect the proposed removal set, then apply it explicitly. With no selection it returns guidance and no delete patch; it does not guess elements from their names.

Removing a node also removes its incident connections so those wires do not survive as dangling edges. A selection-based request is not permission to clear the entire graph. Use recipes > undo if an applied deletion needs to be reversed within the editor’s available history.