ghl-auto-implementer

Original：🇺🇸 English

Translated

Lee una URL o lista de ClickUp con tareas de implementación de GoHighLevel y ejecuta automáticamente las que sean automatizables vía API/MCP, dejando claras las que requieren implementación manual. Usar cuando el usuario pase un link de ClickUp y diga "ejecutá", "implementá", "auto-implementá", "auto-ejecutá", "corré las tareas en GHL", "hacé esto en GHL", o cuando el output de `ghl-task-builder` (alias `ghl-clickup-task-builder`) ya esté en ClickUp y se quiera dispararlo. Esta skill es complementaria — `ghl-task-builder` GENERA tareas, esta skill las EJECUTA.

4installs

Sourcegochiri/ghl-skills

Added on2026-04-29

NPX Install

npx skill4agent add gochiri/ghl-skills ghl-auto-implementer

SKILL.md Content

View Translation Comparison →

GHL Auto-Implementer

Esta skill recibe una URL o IDs de ClickUp con tareas de implementación de GoHighLevel y ejecuta las operaciones automatizables vía API/MCP. Las que no son automatizables (workflows, pipelines write con PIT, funnels, templates de Meta, etc.) las deja flaggeadas como manuales con instrucciones claras.

Inversión respecto a
ghl-task-builder
:

```
ghl-task-builder
```
→ genera tareas para que un humano las implemente
```
ghl-auto-implementer
```
→ toma las tareas y las implementa Claude

⚠️ Lectura obligatoria al arrancar

Antes de ejecutar cualquier operación, leer:

~/.claude/skills/ghl-task-builder/references/ghl-api-capabilities.md

— qué se puede ejecutar y qué no

```
references/parsing-guide.md
```
— cómo extraer la operación de cada subtarea
```
references/execution-protocol.md
```
— orden, idempotencia, manejo de errores, write-back

Si el manifesto de capabilities no está accesible, parar y avisar al usuario.

Cuándo activarse

Triggers explícitos:

"ejecutá las tareas de [URL]"
"implementá esto en GHL: [URL]"
"auto-ejecutá [list ID]"
"corré la lista de ClickUp"
"/ghl-execute"

Intent detection:

Usuario pasa una URL de ClickUp + verbo de ejecución
Usuario menciona una lista que ya tiene tareas generadas y quiere "que se hagan"

No activar:

Si el usuario está GENERANDO tareas (eso es
```
ghl-task-builder
```
)
Si la URL es de otro tool (no ClickUp)
Si el ClickUp aún no tiene subtareas con estructura
```
## Acción en GHL
```

Flujo de trabajo

Paso 1 — Parsear input

Detectar de la entrada del usuario:

Tipo	Patrón URL	Resolver con
Lista	`/v/l/li/<list_id>`	leer todas las tareas de la lista
Lista	`/list/<list_id>`	idem
Tarea	`/t/<task_id>`	leer la tarea + sus subtareas

Si el usuario pasa solo un ID numérico, asumir lista. Si dice "tarea X" o pasa un slug tipo

86ah5jrca

, asumir tarea.

Paso 2 — Leer las tareas con ClickUp MCP

Para una lista completa:

clickup_filter_tasks(list_id, include_subtasks=true)

Si la lista tiene >50 tareas, paginar.

Para una tarea con subtareas:

clickup_get_task(task_id, include_subtasks=true)

Capturar para cada subtarea:

id

,

name

,

markdown_description

o

description

,

status

Paso 3 — Clasificar cada subtarea

Por cada subtarea, leer la descripción y clasificar en uno de estos modos:

Marca / patrón en la descripción	Modo	Acción
`✅ Ejecutado vía API` o `✅ Hecho` (en el header)	YA HECHO	Skip — ya se ejecutó antes
`✅ API` / `Modo: ✅ Automatizable` / `🔧 SETUP` con operación API listada	EXECUTABLE	Mapear a operación + ejecutar
`⚠️ MANUAL` / `MANUAL builder` / `no automatizable vía API`	MANUAL	Skip + listar en reporte
`⚠️ DEPENDENCIA` (externo, ej: Meta)	EXTERNAL	Skip + listar en reporte
Sin marca clara	UNKNOWN	Preguntar al usuario o skip

Detalles de parsing en

references/parsing-guide.md

.

Paso 4 — Construir el plan de ejecución

Resumir y mostrar al usuario antes de ejecutar:

📋 Plan de ejecución para [Nombre lista o tarea padre]

Total subtareas leídas: N
✅ Ya hechas (skip): X
⚙️ A ejecutar vía API: Y
⚠️ Manuales (skip + reportar): Z
❓ Sin clasificar: W

Operaciones a ejecutar:
  1. Crear calendario "Cliente Testeo - Citas" → POST /calendars/
  2. Crear contacto "Test Lead" → POST /contacts/
  3. ...

¿Confirmás? [sí/ajustar/cancelar]

Default: confirmación por batch, no por tarea. Si hay >10 ejecutables o si hay alguna destructiva, pedir confirmación más explícita.

Paso 5 — Ejecutar en orden de dependencia

Orden recomendado (

references/execution-protocol.md

):

Setup base: custom fields, tags
Recursos estructurales: calendarios, snapshots
Datos de operación: contactos, oportunidades, conversaciones, mensajes
Vinculaciones: add tags a contactos, mover oportunidades, etc.

Por cada operación:

Idempotencia: verificar si ya existe el recurso (por nombre / email / etc.) — si existe, no duplicar
Llamar al MCP (preferido) o REST como fallback
Capturar el resultado: ID, URL, datos
Actualizar ClickUp:
- ```
clickup_update_task
```
  → status
```
complete
```
  , prepend
```
✅ Ejecutado vía API
```
  al description con IDs
- ```
clickup_create_task_comment
```
  → comment con detalles técnicos (ID, response, traceId)

Si una operación falla:

Capturar el error exacto
Marcar la subtarea con
```
❌ ERROR
```
+ detalles del error
No detener la ejecución del resto, salvo que el usuario haya pedido stop-on-error
Listar en el reporte final

Paso 6 — Write-back y reporte final

Al terminar:

Comment en la tarea padre (si existe) con resumen ejecutivo:

📊 Auto-Implementer report — [timestamp]
✅ Ejecutadas: 3 (calendar, contact, opportunity)
⚠️ Manuales: 7 (links a subtareas)
❌ Errores: 1 (subtarea X — razón)

Próximos pasos para el implementador humano: ...

Resumen al usuario en la conversación:
- Cuántas se ejecutaron, cuántas quedaron manuales, cuántas fallaron
- Para cada fallo: razón breve + cómo resolverlo
- Para cada manual: link directo a la subtarea
- Si se aprende algo nuevo (ej: nueva limitación de API): proponer actualizar
```
ghl-api-capabilities.md
```

Reglas de seguridad

Nunca ejecutar sin confirmación explícita. El plan se muestra primero, el usuario confirma, después se ejecuta.
Operaciones destructivas (DELETE) requieren confirmación adicional. No basta con "sí" al plan general — pedir un segundo "confirmá la eliminación de X".
No ejecutar tareas marcadas
⚠️ MANUAL
. Aunque parezca que se "podría" — la marca está por una razón documentada en el manifesto.
Idempotencia obligatoria. Antes de crear, leer si existe. Si existe, ofrecer: (A) actualizar, (B) crear duplicado, (C) skip.
Si el manifesto dice ❌, parar. No probar a "ver qué pasa". Las ❌ del manifesto son verificadas empíricamente.
Auditabilidad. Toda ejecución queda escrita en ClickUp como comment + status update — el usuario puede auditar después.

Operaciones soportadas (resumen)

Lectura completa en

~/.claude/skills/ghl-task-builder/references/ghl-api-capabilities.md

.

Ejecutables vía API/MCP:

Recurso	Operaciones	Vía
Calendarios	crear, actualizar, eliminar	REST `/calendars/`
Contactos	CRUD + tags	MCP `contacts_*`
Oportunidades	obtener, buscar, actualizar	MCP `opportunities_*`
Conversaciones / mensajes	enviar, buscar	MCP `conversations_*`
Email templates	crear, fetch	MCP `emails_*`
Blogs	CRUD posts, categorías, autores	MCP `blogs_*`
Social media	crear post, editar, listar	MCP `social-media-posting_*`
Pagos	leer órdenes, transacciones	MCP `payments_*`
Custom fields	leer (write probablemente PIT-restricted, verificar)	MCP `locations_get-custom-fields`
Location	leer info, custom fields	MCP `locations_*`

NO ejecutables (skip + reportar como manual):

Recurso	Razón
Workflows (crear/editar)	API no expuesta por GHL — requiere builder UI
Pipelines (crear/editar)	PIT restringido — `401` . Requiere OAuth Marketplace App
Funnels, formularios, surveys	API muy limitada
Conversation AI / Aurora bot	No expuesto
Templates de WhatsApp	Meta Business Manager (externo a GHL)
Configuración de dominios, SMTP, canales	No expuesto
OAuth integrations (Zoom, Stripe, etc.)	Requiere browser flow
Trigger links	No expuesto

Output style

Durante la ejecución:

Status updates conciso por cada operación:

[1/8] Creando calendar "Testeo"... ✅ Ee9O0qa...

Errores:

[3/8] ❌ Crear stage falló: 401 PIT no autoriza pipelines write — re-clasificada como MANUAL

Al final:

Tabla resumen
Lista de manuales con URLs directas a las subtareas
Lista de errores con causas y propuestas
Si aprendemos algo nuevo: "Sugiero actualizar el manifesto con: ..."

Cómo crece la skill

Cada vez que se descubre una limitación nueva durante una ejecución:

Documentarla en

~/.claude/skills/ghl-task-builder/references/ghl-api-capabilities.md

Agregarla a la lista de "NO ejecutables" si corresponde
Re-clasificar la subtarea en ClickUp del run actual

Cada vez que se ejecuta exitosamente una operación nueva (ej: primer POST de custom field):

Marcarla como ✅ verificada en el manifesto
Capturar el schema funcional (con sus gotchas)

Esto convierte cada ejecución en un evento de aprendizaje permanente.