Workflow-Verzweigungen
Definiert Start, Abschluss und Zusammenführung bedingter oder paralleler Workflow-Pfade ohne endloses Warten und gegenseitiges Überschreiben.
branching-parallelism-joins
Entdecke, wie der Skill hilftWann ist der Skill hilfreich?
Nutze ihn bei optionalen Zweigen, gleichzeitigen Schritten oder unklaren Abschlussregeln einer Zusammenführung.
Wobei hilft er dir?
- Unterscheidet exklusive, inklusive und parallele Verzweigungen.
- Wartet nur auf tatsächlich aktivierte Zweige.
- Trennt Zweigausgaben und definiert Zusammenführung sowie Fehlerregeln.
Das könntest du fragen
Baue einen Freigabeablauf, dessen Zusammenführung ohne optionale Rechtsprüfung weiterläuft. Starte einen Antrag mit niedrigem und einen mit hohem Wert. Der erste wartet nur auf Finanzen, der zweite auf alle tatsächlich aktivierten Zweige.
Ausführliche Dokumentation
Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.
Weniger anzeigen
Branching, Parallelism & Joins
Use this skill when designing or implementing decision nodes, multi-branch conditions, parallel fan-out/fan-in (AND/OR), dead-path elimination, and branch data merging in workflows.
Explicit Split Semantics (Van der Aalst Control-Flow Patterns)
Never leave branching behavior implicit. Every split node must declare its exact evaluation mode:
- Exclusive Choice (
XOR-Split/Switch/If-Else):- Evaluates ordered conditions deterministically (e.g., top-to-bottom priority) and activates exactly one outgoing branch.
- Always require or explicitly define a
default/elsebranch so an unmatched condition never leaves a run silently stuck with zero active tokens.
- Parallel Split (
AND-Split/Fork):- Activates all outgoing branches concurrently, giving each branch an isolated execution context.
- Multi-Choice (
OR-Split/ Inclusive Split):- Evaluates predicates for each outgoing port and activates the non-empty subset of branches whose predicates evaluate to
true(falling back to a declared default branch if none match).
- Evaluates predicates for each outgoing port and activates the non-empty subset of branches whose predicates evaluate to
Explicit Join Synchronization & Dead-Path Elimination (DPE)
A downstream join node must never guess how many incoming branches it should wait for:
- Simple Merge (
XOR-Join): Expects exactly one incoming branch from a mutually exclusive split; mark unchosen sibling branches asskipped. - Synchronizing
AND-Join(Wait All): Waits until every incoming branch reachessucceeded(or aborts/fails according to the declared failure policy:fail_fastvs.wait_all_then_report). - Synchronizing
OR-Join+ Dead-Path Elimination:- When an upstream
XOR-SplitorOR-Splitdoes not choose branch $B$, propagate askipped(dead-path) status down $B$ so downstreamOR-Joinnodes wait only for the branches that were actually activated, preventing permanent deadlocks.
- When an upstream
- First-Completed / Discriminator (
Wait Any / N-of-M):- Advances as soon as $K$ branches succeed, and explicitly cancels or marks the remaining in-flight sibling branches according to configuration.
Branch Output Scoping & Conflict-Free Merging
- Namespace step outputs by
nodeId(steps[nodeId].output) or require an explicit merge mapping at the join node so parallel branches never overwrite shared mutable variables through race conditions.
Checklist
- Does every conditional split define deterministic evaluation order and an explicit
default/elsepath? - Does every join node explicitly specify
XOR(one),AND(all active), orN-of-Msynchronization plus failure behavior? - Does Dead-Path Elimination mark unchosen branches
skippedso downstream joins never deadlock waiting for them? - Are parallel branch outputs isolated by
nodeIdor merged deterministically without shared-variable races?
Enthaltene Dateien 1
SKILL.md
