README.md

Patterns

Reusable workflow patterns. Each pattern is framework-agnostic at the level of intent, but the concrete implementation notes are usually framework-specific (currently mostly n8n).

A "pattern" is something that recurs across many workflows and is worth naming so the rest of the wiki can refer to it: "this workflow uses the chunked LLM call pattern with idempotent webhook ingress", and so on.

Currently documented

• Idempotent webhook ingress — handle the same external event arriving more than once.
• Chunked LLM call — process a long input by splitting it, calling an LLM per chunk, and merging.
• Bounded retry with backoff — wrap an unreliable HTTP call so transient failures don't dead-letter the workflow.
• Fan-out / fan-in — split a list, process items in parallel, gather results back.

Idempotent webhook ingress

When this applies. Any workflow whose trigger is a webhook from a system that does at-least-once delivery (Stripe, GitHub, Shopify, most queue-backed webhooks). The same event will sometimes arrive twice.

What to do.

1. Extract a stable event ID from the payload (e.g. event.id, delivery_id, x-event-id header).
2. Before doing anything with side effects, look the ID up in a small store (a database table, a Redis key, an n8n static-data map for low-volume cases).
3. If seen → return 200 immediately and exit. If not → record the ID, then proceed.
4. Make the rest of the workflow safe to re-run even if step 3 races (use upserts / conditional writes downstream).

Why. Returning 200 only after side effects complete is the most common cause of duplicate orders, duplicate emails, and duplicate ticket creation in webhook-driven automations.

Chunked LLM call

When this applies. Inputs that exceed the model's effective context window, or where a single huge prompt produces noticeably worse output than several smaller ones.

What to do.

1. Split the input on natural boundaries (paragraphs, headings, sentences) — not byte offsets.
2. Add an overlap of one boundary unit between chunks so cross-chunk references survive.
3. Call the LLM per chunk with the same system prompt and a shared task description.
4. Merge results with a final "stitcher" prompt that has access to the per-chunk outputs (not the raw input).

Why. Naively truncating input loses information silently. Splitting on byte offsets cuts mid-sentence and degrades extraction quality. The stitcher pass is what catches inconsistencies between chunks.

Bounded retry with backoff

When this applies. Any outbound HTTP call where transient failures (429, 502, 503, network blips) are normal.

What to do.

• Retry on 429 and 5xx; do not retry on 4xx other than 429.
• Cap total retries (e.g. 3). Unlimited retry turns a partial outage into a self-DoS.
• Use exponential backoff with jitter. No jitter → all clients retry simultaneously.
• After the cap, route to an error branch — log enough context to replay manually.

Why. "Just retry forever" is the single most common cause of self-inflicted outages downstream of a workflow library.

Fan-out / fan-in

When this applies. A list of N independent items each needs the same processing, and the per-item work has measurable latency (LLM calls, HTTP calls).

What to do.

1. Split the list into the per-item shape your framework wants.
2. Parallelise with a concurrency cap. Unbounded parallelism will hit rate limits or memory walls.
3. Collect partial successes — do not fail the whole batch on one item.
4. Emit a single merged result with per-item status, not a flat array that hides failures.

Why. Aggregate failure metrics ("3/100 items failed, here's which ones") are much more useful than a single boolean from a workflow that quietly dropped failed items.

---

This list is not complete. It is the starting set; more patterns will be added as they are extracted from the existing n8n collection during audits and from real failure cases.

Seed patterns from Expansion Pack V0

The generated workflows/generated/open-workflow-library-v0/ pack uses eight repeating patterns that are good candidates to promote into named wiki entries once they are reviewed:

• webhook-intake-validate — webhook → normalize → validate → forward / reject
• schedule-fetch-aggregate — cron → fetch → aggregate → branch on results → notify
• manual-sample-transform-store — manual → set sample → lookup → transform → store
• webhook-form-crm-create — webhook → normalize form → required-fields gate → CRM create → notify → respond
• schedule-digest-format — cron → list → filter/format → branch on non-empty → send digest
• webhook-enrich-score-branch — webhook → enrich → score → branch on threshold → merge → respond
• schedule-status-alert — cron → status check → branch on healthy/unhealthy → alert
• webhook-idempotent-action — webhook → idempotency key → skip duplicate / apply → respond

These are seed patterns. They have not yet been hand-written into full wiki entries with the structured format above. The expansion pack provides the corpus; the wiki entries still need to be curated by humans.