Builds durable multi-step automation on n8n, Temporal, Inngest, AWS Step Functions, or Azure Durable Functions with checkpointed steps, idempotency keys, and replay-safe activities. Trigger on Temporal, Inngest, n8n, Step Functions, durable execution, or crash-resistant background jobs. Do not use for Zapier/Make no-code zaps (zapier-make-patterns) or compensating-saga design (saga-orchestration).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Builds durable multi-step automation on n8n, Temporal, Inngest, AWS Step Functions, or Azure Durable Functions with checkpointed steps, idempotency keys, and replay-safe activities. Trigger on Temporal, Inngest, n8n, Step Functions, durable execution, or crash-resistant background jobs. Do not use for Zapier/Make no-code zaps (zapier-make-patterns) or compensating-saga design (saga-orchestration).
Workflow automation is the infrastructure that makes AI agents reliable. Without durable execution, a network hiccup during a 10-step payment flow means lost money and angry customers. With it, workflows resume exactly where they left off.
This skill covers the platforms (n8n, Temporal, Inngest, AWS Step Functions, Azure Durable Functions) and patterns (sequential, parallel, orchestrator-worker, event-driven, retry/recovery, scheduled) that turn brittle scripts into production-grade automation.
Key insight: The platforms make different tradeoffs. n8n optimizes for accessibility, Temporal for correctness, Inngest for developer experience. Pick based on your actual needs, not hype.
When to Use
Activate this skill when the user mentions or implies any of:
workflow or automation — designing, building, or debugging automated multi-step processes
n8n — visual/low-code workflow platform
temporal — mission-critical durable workflows
inngest — event-driven serverless workflows
step function — AWS or Azure state-machine workflows
background job or job queue — async task processing
scheduled task or cron — time-based recurring workflows
trigger — webhook, event, or schedule-based workflow initiation
Prerequisites
Runtime: Node.js 18+ for Inngest/Temporal TypeScript SDKs; Python 3.10+ for Temporal Python SDK
Windows host (primary): PowerShell 7+ recommended. Use forward slashes in cross-platform config files; use backslashes only in PowerShell-native commands
Platform access: At least one of: n8n self-hosted or cloud, Temporal Cloud or self-hosted server, Inngest account, AWS account with Lambda+Step Functions, Azure account with Durable Functions
No live secrets in output: Use YOUR_KEY placeholders for all API keys, tokens, and connection strings
[Schedule Trigger: Every day at 9:00 AM]
↓
[HTTP Request: Get Metrics]
↓
[Code Node: Generate Report]
↓
[Send Email: Report]
3. Apply Hard Rules for Production
These rules are non-negotiable for money or state-critical workflows. Violating them causes duplicate charges, lost data, or silent failures.
RULE 1: Always use idempotency keys for external calls
Durable execution replays workflows from the beginning on restart. If step 3 crashes and the workflow resumes, steps 1 and 2 run again. Without idempotency keys, external services don't know these are retries.
// Stripe example — ALWAYS include idempotency_keyawait stripe.paymentIntents.create({
amount: 1000,
currency: 'usd',
idempotency_key: `order-${orderId}-payment`
});
// Email example — check before sendingawait step.run("send-confirmation", async () => {
const alreadySent = awaitcheckEmailSent(orderId);
if (alreadySent) return { skipped: true };
returnsendEmail(customer, orderId);
});
// Database example — use upsertawait db.query(`
INSERT INTO orders (id, ...) VALUES ($1, ...)
ON CONFLICT (id) DO NOTHING
`, [orderId]);
Generate idempotency keys from stable inputs, not random values.
RULE 2: Break long workflows into checkpointed steps
A workflow that runs for 24 hours with one step per hour accumulates state for 24h. Workers have memory limits. Functions have execution time limits.
// WRONG — one long step, one checkpointawait step.run("process-all", async () => {
for (const item of thousandItems) {
awaitprocessItem(item);
}
});
// CORRECT — many small steps, checkpoint after eachfor (const item of thousandItems) {
await step.run(`process-${item.id}`, async () => {
returnprocessItem(item);
});
}
// For very long waits, use sleep (doesn't consume resources)await step.sleep("wait-for-trial", "14 days");
// Consider child workflows for long processesawait step.invoke("process-batch", {
function: batchProcessor,
data: { items: batch }
});
RULE 3: Always set timeouts on activities
External APIs can hang forever. Without timeout, your workflow waits forever.
RULE 4: No side effects outside step/activity boundaries
Workflow code runs on EVERY replay. Random IDs, current time, and direct API calls in workflow code break determinism.
// WRONG — side effects in workflow codeexportasyncfunctionorderWorkflow(order) {
const orderId = uuid(); // Different every replay!const now = newDate(); // Different every replay!await activities.process(orderId, now);
}
// CORRECT — side effects in activitiesexportasyncfunctionorderWorkflow(order) {
const orderId = await activities.generateOrderId();
const now = await activities.getCurrentTime();
await activities.process(orderId, now);
}
// ALSO CORRECT — Temporal sideEffect and workflow.now()import { sideEffect } from'@temporalio/workflow';
const orderId = awaitsideEffect(() =>uuid());
const now = workflow.now();
Safe in workflow code: Reading function arguments, simple calculations (no randomness), logging (usually).
RULE 5: Always use exponential backoff for retries
When a service is struggling, immediate retries make it worse. 100 workflows retrying instantly = 100 requests hitting a service that's already failing.
RULE 6: Store references, not large data, in workflow state
Workflow state is persisted and replayed. A 10MB payload is stored, serialized, and deserialized on every step. Some platforms have hard limits (Step Functions: 256KB).
Cause: Immediate retries on a struggling service make it worse.
Fix: See RULE 5 above. Always use exponential backoff with jitter.
MEDIUM: n8n Workflow Without Error Trigger
Symptoms: Workflow fails silently. Errors only visible in execution logs. No alerts, no recovery, no visibility.
Cause: n8n doesn't notify on failure by default. Without an Error Trigger node, production failures go unnoticed.
Fix: Every production n8n workflow needs: (1) Error Trigger node, (2) connected error handling chain (log → alert → ticket), (3) consider dead letter pattern with Redis/Postgres for failed jobs.
MEDIUM: Long-Running Temporal Activities Without Heartbeat
Symptoms: Activity timeouts even when work is progressing. Lost work when workers restart. Can't cancel long-running activities.
Cause: Temporal detects stuck activities via heartbeat. Without heartbeat, long activities appear hung.
Fix: See RULE 8 above. Add heartbeat() calls for any activity > 10 seconds. Set heartbeatTimeout.
Verification
Run these checks against any workflow code before considering it production-ready:
1. Idempotency Key Check
Check: Search all payment/external mutation calls for idempotency_key or equivalent.
