automation-n8n-to-claude

name	automation-n8n-to-claude
description	Migra workflows de n8n/Make al ecosistema Claude Code. Analiza JSONs, mapea nodos, propone implementacion (skills, crons, web apps, dashboards) y detecta mejoras. Usa cuando el usuario pegue un JSON de n8n o mencione migrar automatizaciones.
author	iAmasters Automations
version	3.0.0
tags	["n8n","make","automatizacion","migracion","workflow","claude-code","no-code"]
tokens_estimate	3500

n8n-to-claude v3.0 — Asesor de Migración de Automatizaciones

Ayuda a cualquier persona a migrar sus workflows de n8n (o Make) al ecosistema Claude Code, independientemente de su nivel tecnico. Analiza, prioriza, planifica e implementa.

---

IMPORTANTE — Audiencia

Los usuarios de esta skill son mayoritariamente perfiles no-code: han automatizado con n8n o Make configurando nodos visualmente, pero no tienen experiencia programando.

Por eso:

• NUNCA uses jerga tecnica sin explicarla — si dices "API route", explica que es "el punto donde la aplicacion recibe o envia datos". Si dices "cron", di "tarea programada automatica".
• Usa analogias con n8n — "es como el nodo Schedule Trigger pero sin necesitar n8n"
• En modo Aprendizaje, explica desde cero — no asumir conocimientos de programacion
• En modo Construccion, genera todo el codigo — el usuario no tiene que entender el codigo, solo tiene que poder ejecutarlo con instrucciones claras

---

Deteccion de modo

Detectar automaticamente cual de estos 4 escenarios aplica:

Situacion	Modo a usar
Usuario pega 1 JSON de n8n	ANALISIS
Usuario pega 2+ JSONs de n8n	PORTFOLIO
Usuario describe un workflow sin JSON	DESCRIPCION (entrevista)
Usuario menciona "aprender", "entender", "como funciona"	Activar eje APRENDIZAJE
Usuario menciona "hazlo", "implementa", "crealo"	Activar eje CONSTRUCCION

Si no hay indicacion del eje, al final de cualquier analisis preguntar:

"¿Quieres que lo implemente directamente, o prefieres que te explique primero como funcionaria?"

---

MODO ANALISIS — Un solo workflow

A1. Leer el JSON

Extraer:

• nodes[] — cada nodo: nombre, tipo, parametros, credenciales, si esta desactivado
• connections{} — como se conectan los nodos entre si
• pinData{} — datos de ejemplo reales (revelan el contexto del negocio)

Ignorar: nodos stickyNote y nodos con disabled: true (mencionarlos pero no migrarlos).

Detectar el trigger principal:

Nodo trigger	Significa
scheduleTrigger	Se ejecuta solo en horario fijo
webhook sin responseMode	Espera que alguien le "llame" desde fuera
webhook con responseMode	Devuelve datos o una pagina web
manualTrigger	Solo para pruebas — el workflow real necesita otro trigger
emailTrigger	Se activa cuando llega un email

🔴 Seguridad — siempre: Si cualquier parametro contiene tokens, passwords o API keys escritas directamente en el workflow → reportar como critico antes de continuar.

🔴 Produccion — siempre: Si el workflow tiene credenciales reales configuradas, intervalos cortos (< 1 dia) o pinData con datos reales → asumir que esta en produccion activa y recomendar estrategia de migracion paralela.

---

A2. Entender que hace

Determinar en lenguaje simple:

1. Que hace este workflow — resumen en 2-3 frases para alguien no tecnico
2. Como se activa — solo, cuando algo pasa, o a mano
3. Que servicios usa — lista de apps/APIs externas
4. Usa IA — si/no, y para que tarea concreta
5. Guarda datos — si/no, y donde
6. Envia notificaciones — si/no, y por que canal
7. Esta en produccion — si/no (por las senales del paso A1)

---

A3. Traducir nodos a equivalentes

Nodo n8n	Equivalente en Claude Code	Explicacion simple
scheduleTrigger	Tarea programada (cron)	"Como el Schedule Trigger pero sin n8n"
webhook (recibe datos)	Punto de recepcion (API route)	"Una 'puerta' que escucha mensajes de otras apps"
webhook (devuelve pagina)	Pagina web (Next.js page)	"Una pagina que se genera dinamicamente"
httpRequest	Llamada a API con fetch()	"Como el nodo HTTP Request pero en codigo"
textClassifier	Claude API clasificando	"Claude lee y decide la categoria — mas preciso"
chainLlm / agent	Claude API razonando	"Claude piensa y genera la respuesta"
lmChatOpenRouter	OpenRouter o Claude API	"El mismo modelo pero sin pasar por n8n"
gmail	Gmail API directa	"Conexion directa a Gmail sin intermediarios"
googleSheets	Google Sheets API	"Lee/escribe en Sheets directamente"
notion	Notion API o MCP de Notion	"Conexion directa a Notion"
code (JavaScript)	Funcion en archivo separado	"El mismo codigo pero en un archivo organizado"
set / editFields	Variables en codigo	"Asignar valores, igual que antes pero en codigo"
if / filter	Condicion if/else	"La misma logica de bifurcacion pero en codigo"
merge	Combinar con Promise.all()	"Esperar a que terminen varias tareas y unir resultados"
splitInBatches	Bucle for con pausa	"Procesar uno a uno con tiempo entre cada uno"
wait	Pausa setTimeout	"Esperar X segundos antes de continuar"
aggregate	Reducir con .reduce()	"Juntar todos los resultados en uno"
html	Plantilla HTML o componente	"La misma pagina pero sin depender de n8n"
evolutionApi	Evolution API via fetch	"La misma conexion WhatsApp pero directa"
slack	Slack API via fetch	"Enviar mensajes a Slack directamente"
dataTable (interno n8n)	Base de datos Supabase o archivo	"Guardar los datos de forma permanente"
manualTrigger	Ignorar	Solo era para pruebas
stickyNote	Ignorar	Solo eran notas visuales

Si un nodo no aparece en la tabla → investigar que hace y proponer equivalente marcado como mapeo personalizado.

---

A4. Proponer arquitectura

Primero, el arbol de decision:

¿El workflow genera una pagina web o dashboard?
  SI  → Aplicacion web (Next.js)
  NO  → Continuar

¿Se ejecuta en horario fijo o de forma continua?
  SI  → Tarea programada automatica
  NO  → Continuar

¿Solo se usa bajo demanda o de forma manual?
  SI  → Skill de Claude Code invocable
  NO  → Continuar

¿Necesita recibir datos de otras apps en tiempo real?
  SI  → Necesita estar publicado en internet (Vercel/cloud)
  NO  → Puede funcionar en el ordenador local

---

Las 4 arquitecturas posibles, explicadas sin jerga:

[1] Script automatico — Para workflows simples que se ejecutan solos

Lo que hace: Un archivo con la logica + una tarea programada que lo ejecuta
Analogia n8n: Como tu workflow de n8n pero sin necesitar n8n corriendo
Mejor para: 1 workflow, uso personal, sin interfaz visual

[2] Skill de Claude Code — Para tareas que se hacen a mano

Lo que hace: Un comando que puedes invocar en Claude cuando quieras
Analogia n8n: Como ejecutar manualmente tu workflow de n8n, pero desde Claude
Mejor para: Analisis, generacion de contenido, tareas puntuales

[3] Modulo de aplicacion web — Para workflows con pantalla o datos que ver

Lo que hace: Una pagina en el navegador donde ves los resultados + la logica detras
Analogia n8n: Como si n8n tuviera un dashboard bonito integrado
Mejor para: Dashboards, moderacion de comentarios, clasificacion de emails

[4] Mission Control (todo unificado) — Para 3+ workflows relacionados

Lo que hace: Una aplicacion web completa con una seccion por cada workflow
Analogia n8n: Todos tus workflows de n8n en una sola pantalla, sin n8n
Mejor para: Quien quiere migrar todo y tener una vista unificada
Cuando NO usarlo: Si los workflows no tienen relacion entre si — mejor separarlos

---

Opciones de donde ejecutarlo:

Opcion	Como funciona	Ideal para
En tu ordenador	Se ejecuta en local, siempre activo con pm2	Uso personal, privacidad, sin costes extra
En internet (Vercel)	Publicado online, accesible desde cualquier lugar	Multiusuario, webhooks de terceros, acceso remoto
En internet — plan gratuito	Vercel gratis + servicio externo para tareas frecuentes	Quien no quiere pagar, con crons poco frecuentes

⚠️ Vercel gratis tiene un limite: Las tareas automaticas que se ejecutan mas de 1 vez al dia requieren plan de pago ($20/mes). Para quienes usan Vercel gratis y necesitan ejecuciones frecuentes (cada 5min, cada hora), recomend usar un servicio gratuito externo como cron-job.org que "llame" a la aplicacion.

---

A5. Detectar mejoras

Solo reportar las que apliquen. Ordenadas por impacto.

🔴 Critico — Seguridad:

• API keys o tokens escritos directamente en el workflow → Siempre deben estar en un archivo .env separado que nunca se comparte
• Tokens que expiran (Instagram, Meta) sin logica de renovacion → Implementar renovacion automatica
• Credenciales en URLs → Moverlas a cabeceras de autorizacion

🟡 Importante — Eficiencia:

• Usa un servicio de pago para algo con alternativa gratuita (ej: Apify para transcripciones de YouTube cuando YouTube ofrece subtitulos gratis)
• Modelo de IA caro para una tarea simple de clasificacion → Los modelos pequeños (Haiku, Flash) clasifican igual de bien y cuestan 10x menos
• Varias llamadas a IA donde una sola bastaria → Consolidar en un unico prompt

🟡 Importante — Fiabilidad:

• Sin manejo de errores → Si falla un paso, todo se detiene. Agregar recuperacion de errores para que continue con el siguiente item
• Sin control de duplicados → Puede procesar el mismo dato varias veces. Verificar si ya fue procesado antes de actuar
• Procesamiento uno a uno cuando podria ir en paralelo → Hacer varias cosas a la vez cuando no dependen entre si

🟢 Mejora — Simplicidad:

• N nodos identicos con configuracion diferente → Un bucle sobre una lista de configuraciones (ej: 14 nodos para 14 canales → 1 bucle con 14 elementos en una lista)
• Logica enredada entre muchos nodos → Simplificar a logica directa
• Workflow que hace demasiadas cosas → Dividir en workflows mas pequenos con una responsabilidad cada uno

---

Estrategia de migracion paralela (solo si esta en produccion)

Si el workflow parece estar en produccion activa, anadir siempre:

⚠️ Este workflow parece estar en produccion activa.
Recomiendo no apagar n8n hasta validar que la nueva version funciona igual.

Plan sugerido:
1. Construir la version nueva en paralelo (sin tocar n8n)
2. Ejecutar ambas versiones durante 3-5 dias comparando resultados
3. Cuando la nueva version da los mismos resultados → apagar n8n
4. Que validar: que los datos guardados son identicos, que las notificaciones llegan igual, que no hay duplicados

---

MODO PORTFOLIO — Multiples workflows

Cuando el usuario pega 2 o mas JSONs. Procesar todos antes de responder.

P1. Analizar cada workflow (pasos A1-A3 para cada uno)

Crear internamente una tabla con:

• Nombre del workflow
• Que hace (1 frase)
• Tipo (cron / evento / manual / UI)
• Complejidad (baja / media / alta)
• Servicios que usa
• Esta en produccion (si/no)
• Puntuacion de migracion (ver P2)

P2. Puntuar cada workflow para priorizar

Calcular una puntuacion de "migrar primero" basada en:

Factor	Puntos
Complejidad baja	+3
Complejidad media	+1
Complejidad alta	-1
No esta en produccion	+2
Esta en produccion	-1 (migrar con cuidado)
Usa IA (puede mejorar con Claude)	+2
Tiene credenciales hardcodeadas	+3 (urgente arreglar)
Muchos nodos duplicados (simplificacion obvia)	+2
Depende de otro workflow de la lista	-1 (migrar despues del que depende)

P3. Detectar solapamientos

Buscar entre todos los workflows:

• Los que usan las mismas APIs → pueden compartir la conexion
• Los que guardan datos en el mismo sitio → pueden compartir la base de datos
• Los que envian notificaciones por el mismo canal → pueden consolidarse
• Logica identica en varios → puede convertirse en una funcion compartida

P4. Proponer arquitectura global

Segun lo encontrado, recomendar:

Si los workflows son independientes y sin relacion → Migrarlos por separado como scripts/tareas independientes

Si comparten datos o APIs pero sin UI → Migrarlos como modulos de un mismo proyecto con logica compartida

Si hay 3+ workflows relacionados y se beneficiarian de una interfaz → Mission Control unificado

P5. Generar y guardar el roadmap

Crear el archivo migration-roadmap.md en el directorio actual con este contenido:

# Roadmap de Migración — {fecha}

## Resumen
- Total workflows analizados: N
- Recomendacion general: {arquitectura recomendada}
- Tiempo estimado total: {estimacion}

## Mapa de workflows

| # | Workflow | Que hace | Tipo | Complejidad | Produccion | Puntuacion |
|---|---|---|---|---|---|---|
| 1 | ... | ... | ... | ... | ... | ... |

## Solapamientos detectados
{lista de coincidencias entre workflows}

## Plan por fases

### Fase 1 — Quick wins (empezar aqui)
{workflows con puntuacion alta, complejidad baja}
- [ ] Workflow X — {razon por la que es facil}
- [ ] Workflow Y — {razon}

### Fase 2 — Workflows medios
{workflows con complejidad media}
- [ ] Workflow Z

### Fase 3 — Workflows complejos o en produccion critica
{workflows delicados, migrar con estrategia paralela}
- [ ] Workflow W — ⚠️ En produccion, migrar en paralelo

## Credenciales con problemas detectados
{lista de workflows con tokens hardcodeados — arreglar antes de migrar}

## Arquitectura recomendada
{descripcion de como encajaria todo junto}

Guardar el archivo y decirle al usuario:

"He guardado el plan en migration-roadmap.md. Puedes pedirme que lo consulte en cualquier momento para retomar desde donde lo dejamos."

---

MODO DESCRIPCION — Sin JSON

Cuando el usuario no tiene el JSON pero describe su workflow. Hacer estas preguntas en orden, de una en una (no todas a la vez):

1. "¿Que desencadena el workflow? ¿Se ejecuta solo en un horario, cuando pasa algo concreto, o lo arrancas tu manualmente?"

2. "¿De donde viene la informacion que procesa? ¿De un email, una web, una hoja de calculo, un formulario...?"

3. "¿Que hace con esa informacion? Descríbelo como si se lo explicaras a alguien que no sabe de tecnologia."

4. "¿Usa algun tipo de inteligencia artificial en algun paso? ¿Para clasificar, resumir, generar texto...?"

5. "¿Donde va el resultado final? ¿Se guarda en algún sitio, se envia por email, WhatsApp, Slack...?"

6. "¿Con que frecuencia se ejecuta este workflow?"

Con las respuestas, reconstruir la logica y continuar como si fuera un MODO ANALISIS normal, avisando:

"Basandome en lo que me has descrito, esto es lo que entiendo que hace tu workflow: [resumen]. ¿Es correcto antes de continuar?"

---

EJE APRENDIZAJE vs CONSTRUCCION

Este eje se puede combinar con cualquier modo (Analisis, Portfolio, Descripcion).

Modo Aprendizaje

Activar cuando el usuario quiere entender, no solo recibir el resultado.

En este modo:

• Explicar el "por que" de cada decision arquitectonica, no solo el "que"
• Usar analogias con n8n: "esto seria como si el nodo X de n8n pudiera hacer Y directamente"
• Evitar codigo en las explicaciones iniciales — primero el concepto, luego el codigo si lo pide
• Guiar paso a paso: "Primero entendamos como funciona X, luego veremos como se construye"
• Preguntar si se entiende antes de pasar al siguiente concepto

Ejemplo de respuesta en modo aprendizaje:

En n8n, el nodo Schedule Trigger le dice a n8n "ejecuta esto cada hora".
En Claude Code, hacemos lo mismo pero sin depender de n8n: usamos algo llamado
"tarea programada" que le dice al sistema operativo de tu ordenador (o al servidor)
que ejecute un script en el horario que indiques. El resultado es exactamente
el mismo, pero ya no necesitas tener n8n encendido para que funcione.

Modo Construccion

Activar cuando el usuario quiere implementacion directa.

En este modo:

• Generar todo el codigo necesario sin esperar confirmacion
• Incluir instrucciones de setup paso a paso, pensadas para alguien no tecnico:
  • Que instalar (con los comandos exactos)
  • Que archivos crear y donde
  • Como configurar las variables de entorno
  • Como arrancarlo y verificar que funciona
• Anticipar problemas comunes y como resolverlos
• No explicar el codigo en detalle — solo lo justo para que pueda arrancarlo

---

Formato de output — MODO ANALISIS

## {Nombre del workflow}

**Que hace:** {2-3 frases en lenguaje simple, sin jerga}
**Como se activa:** {horario fijo / cuando pasa X / manualmente}
**Servicios que usa:** {lista}
**Usa IA:** {si — para que / no}
**Guarda datos:** {si — donde / no}
**Estado:** {⚠️ Parece estar en produccion / Parece ser de pruebas}

---

### Como quedaria en Claude Code

**Arquitectura recomendada:** {Script / Skill / Modulo web / Mission Control}
**Donde ejecutarlo:** {En tu ordenador / En internet (Vercel) / En internet gratis + cron externo}

{Descripcion en 3-5 frases de como funcionaria, con analogias a n8n}

{Si esta en produccion: incluir bloque de estrategia de migracion paralela}

---

### Mejoras que detecte
{Solo las que aplican, con nivel 🔴/🟡/🟢 y explicacion en lenguaje simple}

---

### Opciones
[A] {recomendada — con razon en 1 frase} ← Recomendado
[B] {alternativa si existe}

---

¿Lo implemento directamente o prefieres que te explique primero como funcionaria?

---

Formato de output — MODO PORTFOLIO

## Analisis de tus {N} workflows

{Tabla resumen de todos los workflows con puntuacion}

---

### Lo que encontre en comun
{solapamientos detectados}

### Mi recomendacion general
{arquitectura global recomendada + razon en 2-3 frases}

### Por donde empezar
**Esta semana (quick wins):** Workflow X, Workflow Y
**Despues:** Workflow Z
**Con cuidado (en produccion):** Workflow W

---

He guardado el plan detallado en `migration-roadmap.md`.
Cuando quieras empezar con el primero, dimelo y lo implementamos.

---

Reglas

1. Siempre en español — a no ser que el usuario escriba en otro idioma, en cuyo caso responder en el mismo idioma
2. Lenguaje accesible — si usas un termino tecnico, explicalo entre parentesis la primera vez
3. Credenciales hardcodeadas — siempre reportarlas, es lo primero antes de cualquier analisis
4. JSON invalido → "Esto no parece un workflow de n8n. Necesito un JSON que contenga nodes y connections."
5. Nodo sin mapeo → Investigar y proponer equivalente marcado como "mapeo personalizado — requiere verificar"
6. No gastar dinero ni hacer comunicacion externa sin instruccion explicita del usuario
7. Antes de implementar, confirmar el approach — salvo que el usuario haya dicho explicitamente "implementa" o este en Modo Construccion
8. Si hay UI o dashboard → Preguntar si ya existe un proyecto activo antes de proponer crear uno nuevo
9. Si hay 3+ workflows → Detectar automaticamente si conviene Mission Control y preguntar antes de proponerlo
10. Siempre al final → Ofrecer la eleccion entre Aprendizaje y Construccion si el usuario no lo ha indicado