GHL Skills

Two complementary Claude Code skills for implementing GoHighLevel automations end-to-end. Built empirically — every API limitation documented here was discovered by hitting it.

Quick install

npx skills add Gochiri/GHL-skills

This installs both skills to your local agent directories (Claude Code, Antigravity, Cursor, Codex, OpenClaw, etc.).

What's in here

🏗️ ghl-task-builder

Generates structured ClickUp tasks for GHL implementations. Each workflow becomes a parent task with atomic subtasks where 1 subtask = 1 node in the GHL workflow builder.

Two operating modes:

• Mode A (existing client): validates pipelines, custom fields, users, calendars against the live account before generating tasks. Flags missing dependencies.
• Mode B (new client / from-scratch): skips verification, generates the full setup as the implementation roadmap.

🤖 ghl-auto-implementer

Reads a ClickUp URL and executes what's automatable via API/MCP. Marks the rest as manual with clear reasons.

• Plan → confirm → execute pattern
• Idempotent (won't duplicate existing resources)
• Continue-on-error with full audit trail
• Writes results back to ClickUp (status, comment, IDs)
• Updates the capabilities manifest when new limitations are discovered

The two skills are complementary: ghl-task-builder GENERATES, ghl-auto-implementer EXECUTES.

Architecture

[Onboarding call / mapping / spec]
            │
            ▼
   ghl-task-builder  ──▶  ClickUp list with structured subtasks
            │
            ▼
   ghl-auto-implementer  ──▶  GHL API/MCP execution + manuals flagged
            │
            ▼
   [Resources created in GHL + report of what's left for humans]

What's automatable vs manual (verified empirically)

✅ Automatable via PIT (Private Integration Token) on REST or MCP:

• Calendars (CRUD)
• Contacts (CRUD + tags)
• Opportunities (read, search, update — create likely OK)
• Conversations / messages (send, search, read)
• Email templates
• Blogs (posts, categories, authors)
• Social media posts
• Custom fields (read; write probably PIT-restricted)
• Location info

❌ NOT automatable (verified — these are hard limits):

• Workflows — no public create API (any token type)
• Pipelines write — 401 with PIT. Architectural restriction, not a scope issue. Requires OAuth Marketplace App token.
• Funnels, forms, surveys
• Conversation AI / Aurora bot configuration
• WhatsApp templates (those live in Meta Business)
• OAuth integrations (Zoom, Stripe, Google) — require browser flow
• Domain / SMTP / channel configuration

This split means roughly 30% of typical GHL implementations are automatable; 70% (mostly workflows) remain manual. The skills are honest about this and don't pretend otherwise.

Discovered gotchas

These are baked into the skills' reference files:

1. Pipeline write requires OAuth, not PIT. POST/PUT /opportunities/pipelines returns 401 "not authorized for this scope" even with opportunities.write enabled in the PIT.
2. PUT is destructive (replace, not merge). Sending a partial body wipes unspecified fields. Always GET → modify → PUT the full body.
3. Calendar meetingLocationType is NOT at root. Must go inside each teamMembers[] entry. Returns 422 "should not exist" otherwise.
4. Calendar openHours.daysOfTheWeek takes one day per entry, not arrays. [1,2,3,4,5] returns 422 "must be a valid day of week". Use 5 entries with [1], [2], etc.
5. API field typos to respect: appoinmentPerSlot, appoinmentPerDay (without the second "t" — that's how the API spells them).

Full list in ghl-task-builder/references/ghl-api-capabilities.md.

Skill files

ghl-task-builder/
├── SKILL.md
└── references/
    ├── ghl-api-capabilities.md      ← API/MCP capabilities matrix (verified)
    ├── ghl-live-context-template.md ← what to fetch from a live account
    ├── ghl-actions-reference.md     ← workflow actions (UI builder)
    ├── ghl-triggers-reference.md    ← workflow triggers (UI builder)
    ├── ghl-conversation-ai-reference.md ← Aurora bot specifics
    └── ghl-limitations.md           ← native GHL limitations (UI/product layer)

ghl-auto-implementer/
├── SKILL.md
└── references/
    ├── parsing-guide.md             ← how to read each ClickUp subtask
    └── execution-protocol.md        ← order, idempotency, errors, write-back

Requirements

• A GoHighLevel sub-account with a Private Integration Token (PIT)
• ClickUp workspace + API access
• Claude Code (or any agent that supports the skills format)
• The user's environment must have .mcp.json configured for both ghl and clickup MCP servers

Triggering the skills

ghl-task-builder activates on:

• "subir workflows a ClickUp"
• "registrar tareas de implementación GHL"
• "convertir este mapeo en tareas"
• Output of an onboarding mapper

ghl-auto-implementer activates on:

• "ejecutá las tareas de [ClickUp URL]"
• "implementá esto en GHL"
• "auto-ejecutar"
• Any URL like https://app.clickup.com/.../list/... paired with an execution verb

Contributing / extending

The skills grow by accumulation. Every time a new limitation is discovered:

1. Document it in ghl-api-capabilities.md with the exact error, payload, and trace
2. Update the relevant skill's classification logic
3. Commit with a clear message

Every time a new operation is verified working:

1. Move from 📖 (documented but not verified) to ✅ (verified)
2. Capture the working schema with any quirks

License

MIT — do whatever, just don't blame us if Meta rejects your WhatsApp template.