Ghl Clickup Task Builder

GHL ClickUp Task Builder

Transforma workflows de GHL en tareas estructuradas en ClickUp. Cada workflow se convierte en una tarea padre con contexto completo + subtareas atómicas donde cada subtarea = un nodo en el builder de GHL.

Modos de operación — verificación vs. from-scratch

La skill opera en dos modos según el contexto. Detectar el modo antes de empezar.

Modo A — Cliente existente / Adición a cuenta viva

Cuando se generan tareas para una cuenta GHL ya implementada y la tarea menciona pipelines, campos, asesores o calendarios que se asume que ya existen.

Pre-flight check obligatorio:

1. Leer references/ghl-api-capabilities.md — saber qué se puede crear vía API/MCP y qué requiere implementación manual.

2. Pullear el snapshot vivo (ver references/ghl-live-context-template.md):

   • mcp__ghl__opportunities_get-pipelines
   • mcp__ghl__locations_get-custom-fields
   • mcp__ghl__locations_get-location
   • GET /users/?locationId=... (REST)
   • GET /calendars/?locationId=... (REST)

3. Validar cada referencia por nombre contra el snapshot. Si el input menciona "Pipeline Residencial" o "campo Tipo de Cliente" o "asignar a Carlos", confirmá que existe antes de escribir la subtarea. Si no existe:

   • Avisar al usuario y ofrecer: (A) crear el recurso ahora, (B) corregir el nombre, (C) marcarlo como ⚠️ DEPENDENCIA FALTANTE.

Modo B — Cliente nuevo / Implementación desde cero

Cuando se está armando un cliente desde cero, o cuando el usuario pasa un mapeo previo de implementación, o cuando explicita "es un cliente nuevo / desde cero / cliente testeo".

No hace falta validar que las cosas existan — se crean como parte de la implementación.

1. Sí leer references/ghl-api-capabilities.md — para saber cuáles tareas son ejecutables vía API y cuáles son manuales (workflows, funnels, etc.).

2. No es necesario pullear el snapshot completo. Como mucho, leer el locations_get-location para confirmar timezone si la implementación incluye calendarios o mensajería con horarios.

3. Pipelines, custom fields, calendarios, stages, tags se crean como parte de las tareas de implementación. Marcar con 🔧 SETUP las que se ejecutan vía API antes que el WF.

Cómo detectar el modo

Clasificación de operaciones (en cualquier modo)

Por cada operación que la tarea propone:

• ✅ Automatizable vía API/MCP → puede ejecutarse desde la skill (ahora o en Fase 2)
• 🔧 SETUP previo → recursos a crear antes del WF (pipelines, fields, calendarios) — automatizables
• ⚠️ MANUAL → workflows, funnels, forms, configuraciones de Conversation AI, integraciones OAuth — el implementador lo arma a mano siguiendo la subtarea

Principio central: 1 subtarea = 1 acción atómica

El nombre de la subtarea ES la instrucción. La descripción tiene dos secciones fijas y obligatorias:

• ## Acción en GHL → qué configurar exactamente (tabla de campos y valores). Esto es lo que el implementador ejecuta.
• ## Contexto → por qué existe ese nodo, cómo se conecta con otros workflows, qué pasa antes y después. Esto es referencia, no instrucción.

❌ MAL — subtarea agrupada o sin estructura:

Nombre: ⚡ Acciones
Descripción: ACCIÓN 1 - Update Canal... ACCIÓN 2 - Update Área... ACCIÓN 3 - If/Else...

Nombre: Guard IF: Fecha de primer contacto está vacía
Descripción: Nodo IF. Si está vacío continúa, si no salta.
(sin separar qué hacer de por qué hacerlo)

✅ BIEN — subtarea atómica con secciones:

Nombre: Guard IF: Fecha de primer contacto está vacía

## Acción en GHL

| Campo GHL       | Valor                          |
|-----------------|-------------------------------|
| Action type     | IF / Else                     |
| Condition object| Contact                       |
| Field           | Fecha de primer contacto      |
| Operator        | is empty                      |
| Rama TRUE       | Continúa → nodo siguiente     |
| Rama FALSE      | Salta al nodo Crear oportunidad|

## Contexto

Protege contra re-entradas. Si el contacto ya existe en el CRM y
vuelve a escribir, este Guard evita pisar su fecha original de primer
contacto. Sin este nodo, los reportes de tiempo de conversión quedan
contaminados con fechas incorrectas.

Regla sobre qué va en cada sección:

Flujo de trabajo

Paso 1: Recibir el input

• Output de ghl-onboarding-mapper, descripción manual, o tarea existente a reescribir
• Si hay ambigüedad, preguntar antes de crear

Paso 2: Confirmar List ID

Si no se conoce: "¿List ID de ClickUp? Es el número al final de la URL de la lista."

Paso 3: Construir la tarea padre

Nombre: [LS01] Nombre o WF-001 · NOMBRE_CAPS

Descripción de la tarea padre con estas secciones:

Descripción — qué hace, por qué existe
Trigger — nombre exacto + canal/pipeline/etapa
Guards de entrada — IF de detención antes de cualquier acción (si aplica)
Lógica / Branches — resumen de If/Else (si aplica)
Dependencias — qué debe existir antes de activar
Orden de activación — si depende de otro WF activo primero

Paso 4: Descomponer en subtareas atómicas

Un nodo en GHL = una subtarea en ClickUp:

Guía de UI — Valores exactos por tipo de nodo

Interfaz de GHL en español. Usar estos términos exactos.

Update Contact Field

Tipo de acción: "Actualizar datos de campo"
→ Clickeá "Añadir Campo"
→ Dropdown campos: Standard Fields (arriba) / Custom fields (hacer scroll abajo)
→ Seleccionar: [nombre exacto del campo]
→ Valor:
   Dropdown → seleccionar: [valor exacto]
   Text     → escribir: [valor]
   Date     → ícono 🏷️ → Contact Created At (para "now")

If / Else

→ Clickeá "Añadir filtros"
→ Tipo: Contacto / Oportunidad
→ Campo: [nombre]
→ Condición: está vacío / es igual a / contiene / no está vacío
→ Valor: [si aplica]
Branch SÍ = condición cumplida
Branch NONE = no cumplida (equivale al Else)

Crear oportunidad (nueva — NO la deprecada)

⚠️ "Crear O Actualizar Oportunidad" está DEPRECADA (banner naranja). Usar "Crear oportunidad".
→ IN SECUENCIA → [pipeline]
→ IN SECUENCIA PASO → [etapa exacta]
→ Nombre → ícono 🏷️ → First Name + Last Name
→ Fuente → texto libre: "Widget Web" / "WhatsApp" / "Instagram"

Send Message

→ Canal: WhatsApp / SMS / Email
→ Tipo: Template aprobado / Mensaje libre
→ Texto: [mensaje exacto]
→ Usar ícono 🏷️ para insertar nombre: First Name

Wait

Wait fijo: duración en días/horas desde ejecución del paso
Wait Until Date: ícono 🏷️ → campo de fecha → + offset si aplica

Add/Remove Tag

→ Tag: [nombre exacto, sensible a mayúsculas/minúsculas]

Webhook → n8n

→ Acción: Webhook
→ URL: Custom Value con la URL del webhook de n8n
→ Método: POST
→ Body: incluir {{contact.id}} + campos necesarios

Variables con ícono 🏷️

⚠️ Círculo naranja en un bloque = campos incompletos. El WF no se puede publicar hasta resolverlos.

Referencias GHL

Lectura obligatoria al inicio de cualquier sesión (Pre-flight Check):

• references/ghl-api-capabilities.md — qué se puede crear/leer/actualizar vía API/MCP, schemas verificados, gotchas. Distingue automatizable (✅) vs manual (❌).
• references/ghl-live-context-template.md — qué snapshot pullear de la cuenta antes de proceder.

Lectura por tipo de tarea (capa workflow / UI builder):

Para workflows que mezclan triggers + acciones, leer ambos archivos de referencia antes de empezar.

Distinción importante entre los dos archivos de limitaciones:

• ghl-api-capabilities.md → "¿se puede hacer vía API/MCP?" (capa de automatización)
• ghl-limitations.md → "¿GHL lo soporta en absoluto, ni siquiera manualmente?" (capa de producto)

Cuando una funcionalidad no existe en GHL nativamente, usar el formato ⚠️ REVISAR de ghl-limitations.md. Cuando una funcionalidad existe pero no es automatizable vía API/MCP, usar ⚠️ MANUAL con la justificación de ghl-api-capabilities.md.

Estructura visual en ClickUp

Tarea padre — formato de descripción

## Descripción
[Qué hace el workflow y la lógica de negocio central. 2-4 líneas.]

## Trigger
[Nombre exacto del trigger + pipeline/canal/etapa si aplica.]

## Pipelines involucrados (si el WF mueve entre pipelines)
| Pipeline | Rol |
|---|---|
| `Nombre pipeline` | Origen / Destino / Temporal |

## Dependencias
- [Qué debe existir creado antes de activar este WF]
- [Otros workflows que deben estar activos primero]

## Estructura de nodos
| # | Tipo de nodo | Nombre de subtarea |
|---|---|---|
| 1 | Trigger | Trigger: ... |
| 2 | Guard IF | Guard IF: ... |
| 3 | Update Field | Update Field: ... |

Subtarea — formato de descripción

Cada subtarea tiene dos secciones fijas. Siempre en este orden:

## Acción en GHL

| Campo GHL | Valor |
|---|---|
| Action type | [nombre exacto del nodo en GHL] |
| [campo 1] | [valor 1] |
| [campo 2] | [valor 2] |
| Rama TRUE | [qué pasa si se cumple] |
| Rama FALSE | [qué pasa si no se cumple] |

## Contexto

[Por qué existe este nodo. Qué workflow lo precede o lo sigue.
Qué pasa si no se configura. Relación con otros WFs. 2-5 líneas.]

Para nodos IF/Else con dos caminos, agregar diagrama visual al final del Contexto:

¿[condición]?
    ├── SÍ → [acción rama TRUE]
    └── NO → [acción rama FALSE / STOP]

Ejemplo completo — [LS01] Widget Chat + UTM Capture

Tarea padre:

## Descripción
Captura contactos nuevos desde Widget Chat web. Extrae UTMs, clasifica
la fuente y crea la oportunidad inicial en el pipeline.

## Trigger
Contact Created. Sin filtros. Allow re-enrollment: OFF.

## Dependencias
- Pipeline Residencial B2C creado con etapa Contactos Recibidos
- Custom fields: Canal de primer contacto, Área de origen,
  Fecha de primer contacto, UTMs, Tipo de cliente

## Estructura de nodos
| # | Tipo | Subtarea |
|---|---|---|
| 1 | Trigger | Trigger: Contact Created |
| 2 | Update Fields | Update Fields: Canal + Área |
| 3 | Update Fields | Update Fields: UTM Source + Medium + Campaign + Content + Term |
| 4 | Guard IF | Guard IF: Fecha de primer contacto está vacía |
| 5 | Update Field | Update Field: Fecha de primer contacto = now (rama TRUE) |
| 6 | Create Opportunity | Crear oportunidad → Contactos Recibidos |
| 7 | Update Field | Update Field: Tipo de cliente = cliente_final |
| 8 | Assign | Assign to User: Round Robin asesores |

Subtareas (ejemplos con el formato correcto):

── Subtarea: Guard IF: Fecha de primer contacto está vacía

## Acción en GHL

| Campo GHL        | Valor                              |
|------------------|------------------------------------|
| Action type      | IF / Else                          |
| Condition object | Contact                            |
| Field            | Fecha de primer contacto           |
| Operator         | is empty                           |
| Rama TRUE        | Continúa → nodo 5 (setear fecha)   |
| Rama FALSE       | Salta → nodo 6 (Crear oportunidad) |

## Contexto

Protege contra re-entradas. Si el contacto ya existe en el CRM y vuelve
a escribir por el widget, sin este Guard IF se pisaría la fecha original
de primer contacto con la del re-ingreso, contaminando los reportes de
tiempo de conversión.

── Subtarea: Update Field: Tipo de cliente = cliente_final

## Acción en GHL

| Campo GHL   | Valor          |
|-------------|----------------|
| Action type | Actualizar datos de campo (Update Contact Field) |
| Field       | Tipo de cliente |
| Value       | cliente_final  |

## Contexto

Este campo es el trigger de SP01. Cuando GHL detecta que Tipo de cliente
pasó de vacío a tener un valor, SP01 arranca y asigna el asesor. Sin
este nodo SP01 nunca dispara.

⚠️ **Tipo de cliente es un campo de Contacto**, no de Oportunidad.
Usar "Actualizar datos de campo" (Update Contact Field), no "Update Opportunity Field".