n8n workflow automation

**Judgement:** Strong, safety-focused skill for designing robust n8n workflows where reliability, auditability, and idempotency matter more than raw simplicity. **What it does well** - Produces detailed n8n workflow designs and, on request, importable JSON plus a runbook. - Enforces good engineering practices: clear triggers, defined data contracts, idempotency via dedup keys, retries with backoff, and explicit error branches. - Builds in observability (run IDs, status rows, audit logs) and “no silent failure” behavior, which is critical for compliance, finance, and operations use cases. - Supports human-in-the-loop review queues for failed items, enabling controlled reprocessing instead of blind retries. - Avoids embedding secrets, encourages least privilege, and refuses use cases that bypass security or hide audit trails. **Key risks / limitations** - Requires fairly precise inputs (intent, triggers, destinations, dedup strategy, credential approach); vague requests may result in back-and-forth clarification rather than an immediately usable workflow. - Focused exclusively on n8n; not useful if you need code-only or non-n8n automation. - The added logging and review queues can increase workflow complexity and runtime overhead, which may be overkill for simple, low-risk automations. **Best-fit scenarios** - Compliance, finance, or operational reporting workflows that must be auditable, idempotent, and failure-transparent. - Webhook or scheduled jobs where missing a run, duplicating records, or silently dropping data would be unacceptable. - Teams standardizing on n8n who want a consistent pattern for retries, logging, and human review across many workflows.