workflow-architect
Design production-grade n8n workflows from requirements. Use this skill whenever the user wants to build, design, architect, or plan an n8n workflow or automation — including phrases like "build me a
SKILL.mdskills/workflow-architect/SKILL.md
GitHubn8n Workflow Architect
You are designing a production n8n workflow, not a demo. The workflow must survive real data, real failures, and real volume.
Core principles (apply every time)
Real node names, not guesses. n8n is strict about capitalization and spacing. Use
Google SheetsnotGooglesheets.HTTP RequestnotHttpRequest.Webhooknotwebhook trigger. If unsure, say so — don't invent.Expression syntax is
={{ $json.field }}. The leading=marks the whole field as an expression. Without it, n8n treats the value as a literal string. This is the #1 hallucination source.Every external call needs an error branch. Wrap API calls in an
IFor usecontinueOnFail: true+ a downstreamIFthat checks{{ $json.error }}. Never assume third parties don't fail.Idempotency by default. If the workflow could be retriggered (webhook, cron, polling), include a checkpoint — a MySQL/Postgres lookup on a natural key, or a
Google Sheetsrow check. Reference themysql-checkpointingskill for the pattern.Sub-workflows for reuse. If logic exceeds ~8 nodes or is called from multiple places (e.g., error handling, notifications), extract into an
Execute Workflowsub-workflow.
Workflow design process
Follow these steps in order. Skipping steps produces demo-quality output.
Step 1: Clarify the trigger
Ask (or infer) exactly ONE trigger type:
| Trigger | Use when |
|---|---|
Webhook |
External system pushes events (Stripe, Meta, custom APIs) |
Schedule Trigger |
Recurring jobs (daily reports, hourly polls) |
Manual Trigger |
Admin-triggered, testing |
Form Trigger |
User-facing intake |
Chat Trigger |
Conversational agents |
Execute Workflow Trigger |
Called by another workflow |
Webhooks in production need: signature verification (HMAC), idempotency key extraction, and a 200 response within 3s (use Respond to Webhook early, process async).
Step 2: Map the happy path
Draft the node sequence as a numbered list BEFORE writing JSON. Each node gets:
- Node type (exact n8n name)
- Purpose (one sentence)
- Key config (the one or two parameters that matter)
Example:
1. Webhook (POST /stripe-events) — receives Stripe events
2. Code — verify HMAC signature against STRIPE_SIGNING_SECRET header
3. IF — branch on signature valid
4. Respond to Webhook — return 200 immediately (no payload)
5. MySQL — SELECT from processed_webhooks WHERE event_id = {{ $('Webhook').item.json.body.id }}
...
Step 3: Add error paths
For EACH external call node, answer:
- What failure modes exist? (timeout, 4xx, 5xx, rate limit, malformed response)
- What's the recovery? (retry with backoff, fallback vendor, dead-letter queue, alert)
Common patterns:
- Retry with backoff:
Waitnode (exponential: 2^n seconds) → loop back viaExecute Workflowcalling itself with a retry counter - Fallback vendor:
IFon error → alternative vendor node (e.g., WhatsApp fails → Twilio SMS) - Dead letter: Error →
MySQLinsert intofailed_jobstable with payload + error message
Step 4: Wire the LLM steps correctly
If using LLMs (Claude, OpenAI, Groq), reference the chain-llm-pattern skill for multi-step reasoning. Key rules:
- Use the LangChain nodes (
AI Agent,Basic LLM Chain,Information Extractor) for structured outputs, NOT rawHTTP Requestto the LLM API — the LangChain nodes handle JSON parsing, retries, and token accounting. - For JSON outputs, use
Information Extractorwith an explicit schema, not "please return JSON" in a system prompt. - Set
maxTokensexplicitly — n8n defaults can silently truncate. - Pin an example input during development (right-click node → "Pin Data") so downstream nodes have stable schemas to build against.
Step 5: Output
Produce the workflow as valid n8n workflow JSON. Structure:
{
"name": "Workflow Name",
"nodes": [...],
"connections": {...},
"settings": { "executionOrder": "v1" }
}
Every node needs id (UUID), name (unique in workflow), type (exact n8n type), typeVersion (integer), position ([x, y]), and parameters (node-specific config).
Use typeVersion: 1 as a safe default unless you know a newer version is required.
For connections, main is the default output — branching nodes (IF, Switch) have multiple output indices.
If the user asked for a description rather than importable JSON, produce a clean numbered list matching Step 2 format and offer to generate JSON.
Anti-patterns to refuse
Do NOT produce workflows that:
- Store credentials inline (always use n8n credential references:
{{ $credentials.apiKey }}) - Poll an API every minute when a webhook exists
- Use
Functionnodes for logic that has a purpose-built node (e.g.,Split In Batches,Merge,Item Lists) - Return raw LLM output to end users without validation
- Assume a list/array is always populated (always handle empty arrays)
When the user's request is vague
Don't guess — ask ONE consolidated clarifying question covering:
- Trigger source + frequency
- External services involved
- What happens on failure (silent drop? alert? retry?)
- Data destination
One question, not five. Move fast.
Reference files
references/node-catalog.md— curated list of battle-tested nodes for common tasksreferences/expressions-cheatsheet.md— n8n expression syntax, common patterns, gotchas