El skill de flujos n8n: diseña automatizaciones que aguantan eventos duplicados y noches feas

La mayoría de los flujos de n8n funcionan la primera vez que le das a "Execute" y se rompen la primera vez que el mundo real los toca. Un webhook se dispara dos veces, una API devuelve un 503, un loop lee una página que no existe, y el lienzo que se veía terminado en el editor ahora pierde eventos en silencio o, peor, le cobra dos veces a alguien. Un skill de flujos n8n existe justo para diseñar pensando en ese segundo mundo desde el principio. Al terminar este artículo vas a tener un skill de Claude Code empaquetado que toma un disparador y un resultado en lenguaje natural, planea el grafo de nodos y deja armadas las cuatro cosas que separan un demo de una automatización que de verdad puedes dejar corriendo: dedup, reintentos, una ruta de error y una condición de parada.

Esto no va de reemplazar el editor visual. n8n es de verdad bueno para conectar integraciones rápido. Va de hacer que el modelo invierta sus palabras donde tú no lo harías: en las ramas de falla que te saltas porque la ruta feliz ya "funciona".

01 · Qué hace el skill realmente

El skill toma una automatización descrita ("cuando se envíe un Typeform, agrega una fila a Supabase y publica en Slack", "cada mañana trae los cargos de Stripe de ayer y manda un resumen por email") y produce un diseño, no un montón de nodos sueltos. En concreto te entrega:

1. El grafo de nodos: el disparador, los pasos y la forma de los datos que viajan entre ellos, descritos con suficiente detalle como para rearmarlo en el editor.
2. El JSON importable: un export de flujo de n8n que puedes soltar directo en tu instancia, con las referencias a credenciales como placeholders.
3. Las notas de confiabilidad: dónde va el chequeo de dedup, cuáles llamadas reintentan, qué hace la ruta de error y dónde para el loop, cada una amarrada a un nodo del grafo.

Lo que de verdad importa es el tercer entregable. Cualquiera arrastra un nodo Webhook hacia un nodo HTTP Request. El skill se gana el sueldo cuando insiste en que, antes de dar la ruta feliz por "lista", el webhook esté deduplicado, la llamada HTTP reintente en un 5xx y una falla te avise en vez de desaparecer. Diseña ese 80% aburrido del que nadie hace captura.

02 · Cuándo debe dispararse

El skill se dispara por la intención de automatizar un flujo entre sistemas, no por la palabra "n8n". Su descripción debe hacer que Claude lo use cada vez que la conversación se vuelve "cuando pase X, haz Y, después Z". Una buena redacción de disparo, puesta en la descripción del skill para que se active sin que nombres la herramienta:

---
name: n8n-workflow
description: >-
  Úsalo cuando el usuario quiere conectar una automatización entre
  sistemas: un handler de webhook, un job programado o una integración
  que reacciona a un evento y llama a uno o más servicios. Diseña el
  grafo de nodos de n8n con dedup, retry-con-backoff, una ruta de
  Error Trigger y una condición de parada del loop, y luego emite JSON
  importable. Se dispara con "cuando pase X haz Y", "en un horario",
  "webhook", "automatiza esto", "conecta A con B", "cada mañana/hora".
---

Las frases de la descripción son las que cargan el peso. "Cuando se envíe un formulario", "cada noche", "publica en Slack cuando", "sincroniza A con B" es como la gente describe una automatización antes de saber que es un flujo, así que esas son las frases que deben activar el skill. Fíjate que arranca con las funciones de confiabilidad, porque un skill que solo promete "te conecto tus apps" compite con el editor y pierde; uno que promete "te las conecto y manejo el webhook duplicado" está haciendo justo la parte que te saltarías.

No debe dispararse con un script de una sola vez, una transformación de datos que corre solo una vez, o una pregunta sobre cómo se comporta un flujo que ya existe. Eso no son automatizaciones duraderas, y meter n8n ahí solo agrega un servicio más que cuidar.

03 · Cómo funciona por dentro

El skill corre una secuencia fija, y el orden lo es todo: diseña el manejo de fallas antes de dar la ruta feliz por terminada, porque ese es el único orden que no deja que "funciona en el editor" se vuelva la línea de meta.

1. Fija el disparador y la condición de éxito

Primero define qué dispara el flujo (webhook, horario, evento de una app) y, sobre todo, qué significa "salió bien". "Agregar una fila" no es una condición de éxito; "existe una fila con esta clave de idempotencia, exactamente una vez" sí lo es. Esa definición es lo que protege cada red de seguridad que viene después.

2. Agrega el chequeo de dedup temprano

El primer nodo real después del disparador es una compuerta de deduplicación. Un webhook va a llegar más de una vez, los proveedores reintentan cuando la respuesta es lenta, y un 200 que llega después de que el emisor se rindió, para ellos parece una falla. Por eso el skill identifica cada evento con algo estable (un id de evento, una clave de idempotencia, un hash del contenido) y consulta un store antes de hacer cualquier trabajo.

// En un nodo Code, justo después del trigger Webhook.
// Rechaza duplicados ANTES de cualquier efecto (escritura en DB, cobro, email).
const key = $json.event_id ?? $json.idempotency_key;
if (!key) throw new Error("falta la clave de idempotencia, no se procesa");

// "seen" es un lookup en Supabase/Redis/static-data conectado como el siguiente nodo;
// aquí solo normalizamos y le pasamos la clave a ese chequeo.
return [{ json: { dedupKey: key, payload: $json } }];

3. Reintenta cada llamada externa con backoff

Cada nodo HTTP Request o de tercero recibe retry-on-fail con backoff exponencial, acotado a fallas transitorias (timeouts, 429, 5xx) y no a las permanentes (un 400 va a fallar igual diez veces, reintentarlo solo malgasta tiempo y rate limit). n8n expone esto por nodo; el skill lo configura a propósito en vez de dejar el default de "falla de inmediato".

4. Conecta un flujo Error Trigger

Un flujo Error Trigger aparte atrapa cualquier ejecución que falle y te avisa (un mensaje de Slack, un email, una fila en una tabla de incidentes) con el nombre del flujo y el nodo que falló. Sin él, una automatización rota falla hacia el vacío: el dashboard muestra un punto rojo que nadie está mirando, y te enteras cuando alguien pregunta por qué nunca le llegó su confirmación.

5. Dale a cada loop una parada firme

Cualquier loop (Split In Batches, un cursor de paginación, un retry de polling) recibe un techo explícito. Un loop descontrolado en n8n no solo se cuelga; puede golpear una API conectada hasta un bloqueo por rate limit o disparar costo real. La condición de parada es un máximo de iteraciones o un tope sensato de páginas, no un "hasta que no haya más datos" sin nada que cubra el caso de "¿y si siempre hay más datos?".

04 · Una invocación concreta

Así se ve usarlo de punta a punta. Tú describes la automatización en lenguaje natural; el skill devuelve un diseño y JSON importable.

Tú: "Cuando un cliente envíe el formulario de onboarding, crea su registro en Supabase y mándale un email de bienvenida. No me lo crees dos veces si lo envía dos veces."

El skill, después de fijar la condición de éxito:

FLUJO: onboarding-intake
Éxito: exactamente una fila de cliente + un email de bienvenida por envío.

[Webhook]  POST /onboarding   (responde 200 de inmediato)
   ↓
[Code: clave dedup = form_id] → rechaza si ya se vio   ← SEGURIDAD
   ↓
[Supabase: upsert por form_id] (insert idempotente)   ← SEGURIDAD
   ↓
[HTTP: API de email]  retry 3x, backoff 2s/4s/8s, solo 5xx+429 ← SEGURIDAD
   ↓
[Responde / registra éxito]

RUTA DE ERROR (flujo Error Trigger aparte):
  cualquier falla → Slack #ops con {flujo, nodo, error, form_id}

NOTAS:
- El Webhook responde antes de correr el trabajo para que el proveedor no reintente por culpa de un email lento.
- upsert (no insert) hace que un envío doble quede en un no-op, no en un duplicado.
- El email es la llamada más riesgosa (externa, inestable) → es la que lleva el retry.

Después emite el JSON del flujo con las credenciales como placeholders, y ahí se detiene. No lo despliega. Tú lo importas a tu n8n, conectas tus credenciales de Supabase y de email, disparas un envío de prueba (y después disparas el mismo otra vez para comprobar que el dedup aguanta), y solo entonces lo activas.

05 · Configuración y ajuste

Un par de ajustes cambian qué tan defensivo es el diseño. Mételos en las instrucciones del skill para que el comportamiento sea consistente de una corrida a otra:

• Store de dedup, dónde vive el chequeo de "¿ya vi esto?": una tabla de Supabase, Redis, o el static data de n8n para volumen bajo. Esto decide cómo se conecta el nodo de dedup y por cuánto tiempo se retienen las claves.
• Política de retry, el número de intentos por defecto y la curva de backoff, y cuáles códigos de estado cuentan como reintentables. Reintentos agresivos contra una API con rate limit empeoran el rate limit; ajústalo al servicio.
• Destino de errores, dónde se reportan las fallas: Slack, email, una tabla de incidentes, PagerDuty. Un Error Trigger que no avisa a ningún lado útil da lo mismo que no tener manejo de errores.
• Techo del loop, el máximo de iteraciones o el tope de páginas por defecto, para que un bug de paginación no termine en mil requests contra la API de otra persona.
• Momento de responder, si el webhook responde de inmediato (y hace el trabajo después) o solo tras el éxito. La respuesta inmediata evita que los reintentos del proveedor se acumulen; la respuesta diferida le da al que llama un estado real. Decídelo por flujo.

La configuración existe para que el skill calce con la forma de tus automatizaciones. Un formulario interno de poco tráfico y un webhook público que recibe miles de eventos por hora no necesitan el mismo store de dedup ni el mismo presupuesto de reintentos, y forzar el setup pesado en el tranquilo es puro trámite.

06 · Trampas

Los modos de falla aquí son específicos, y casi todos vienen de confiar en la palomita verde del editor.

• Que funcione una vez en el editor ≠ que funcione bajo carga. Un "Execute" manual corre un evento limpio contigo mirando. Producción manda duplicados, payloads malformados y 503s a las 3am sin nadie mirando. Diseña para el segundo caso o te lo vas a encontrar por las malas.
• Un webhook disparado dos veces va a procesar doble sin la compuerta de dedup. Este es el incidente más común de n8n: el proveedor reintentó, procesaste dos veces, y ahora hay dos cobros o dos emails. El chequeo de dedup no es un pulido opcional, es la diferencia entre idempotente y vergonzoso.
• Reintentar un error permanente solo malgasta tiempo. Acota los reintentos a fallas transitorias (timeouts, 429, 5xx). Un 400 o un 401 va a fallar idéntico en cada intento; reintentarlo retrasa el reporte del error real y quema rate limit.
• Un Error Trigger que no le avisa a nadie es puro teatro. Conéctalo a un canal que alguien de verdad lea. Una ejecución fallida que deja un punto rojo en un dashboard que nadie abre es exactamente igual de útil que no tener manejo de errores.
• Aprende a reconocer cuándo graduarlo a código real. n8n es buenísimo para validar una automatización rápido y para flujos que son en su mayoría nodos de fábrica. Cuando un flujo crece más allá de unos pocos nodos Code y lógica de ramificaciones de verdad, sale más barato mantenerlo como un servicio pequeño en tu repo (versionado, testeable, con diffs) que como un lienzo enorme donde cambiar la lógica significa hacer clic por veinte nodos. Constrúyelo en n8n para probar la idea; múdalo cuando se gane la mudanza.

Un skill de flujos n8n no va a volver la automatización a prueba de tontos. Nada lo hace. Lo que te da es que el trabajo de confiabilidad poco vistoso pasa al principio, por defecto, en vez de ser lo que descubres que te saltaste a las 2am. Diseña la ruta de error primero, prueba el duplicado, y ten clara la rampa de salida hacia código real.