---
name: ghl-auto-implementer
description: 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.
---

# 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`):
1. **Setup base:** custom fields, tags
2. **Recursos estructurales:** calendarios, snapshots
3. **Datos de operación:** contactos, oportunidades, conversaciones, mensajes
4. **Vinculaciones:** add tags a contactos, mover oportunidades, etc.

Por cada operación:
1. **Idempotencia:** verificar si ya existe el recurso (por nombre / email / etc.) — si existe, no duplicar
2. **Llamar al MCP** (preferido) o REST como fallback
3. **Capturar el resultado:** ID, URL, datos
4. **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:

1. **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: ...
   ```

2. **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

1. **Nunca ejecutar sin confirmación explícita.** El plan se muestra primero, el usuario confirma, después se ejecuta.

2. **Operaciones destructivas (DELETE) requieren confirmación adicional.** No basta con "sí" al plan general — pedir un segundo "confirmá la eliminación de X".

3. **No ejecutar tareas marcadas `⚠️ MANUAL`.** Aunque parezca que se "podría" — la marca está por una razón documentada en el manifesto.

4. **Idempotencia obligatoria.** Antes de crear, leer si existe. Si existe, ofrecer: (A) actualizar, (B) crear duplicado, (C) skip.

5. **Si el manifesto dice ❌, parar.** No probar a "ver qué pasa". Las ❌ del manifesto son verificadas empíricamente.

6. **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:
1. Documentarla en `~/.claude/skills/ghl-task-builder/references/ghl-api-capabilities.md`
2. Agregarla a la lista de "NO ejecutables" si corresponde
3. 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):
1. Marcarla como ✅ verificada en el manifesto
2. Capturar el schema funcional (con sus gotchas)

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