LeadAce

LeadAce

Plugin autónomo de generación de leads para Claude Code. Crea listas de prospectos, ejecuta prospección saliente y itera sobre la estrategia — todo sin intervención manual.

Sitio web: https://leadace.ai

Dos formas de ejecutarlo. Usa el servicio alojado en app.leadace.ai (plan gratuito — 5 prospecciones al día, planes de pago desde $29/mes), o auto-aloja el backend en tu propio Cloudflare + Supabase. El plugin es el mismo en ambos casos — apúntalo al MCP alojado o al tuyo propio.

Para Usuarios

Requisitos previos

• Claude Code
• Una cuenta de LeadAce en https://app.leadace.ai (plan gratuito — sin tarjeta)
• Una cuenta de Gmail conectada — para enviar correos (se otorga al iniciar sesión con Google, o mediante el banner "Conectar Gmail" en la aplicación web)
• Gmail MCP (integrado en claude.ai) — para revisar respuestas de correo
• claude-in-chrome MCP — para envío de formularios y mensajes directos de SNS (los formularios pueden usar alternativamente cualquier otro MCP de automatización de navegador que configures tú mismo, p. ej. Playwright; los mensajes directos de SNS requieren claude-in-chrome)

Instalación

Una línea en tu terminal:

claude plugin marketplace add aitit-inc/leadace && claude plugin install leadace@leadace

O, desde una sesión de Claude Code en ejecución:

/plugin marketplace add aitit-inc/leadace
/plugin install leadace@leadace

Para actualizar más tarde:

/plugin marketplace update
/plugin update leadace@leadace

Iniciar sesión en LeadAce

La primera vez que el plugin llama a una herramienta de LeadAce, tu navegador se abre para iniciar sesión con Google (la misma cuenta de Google que en la aplicación web). El token se guarda en caché localmente para ejecuciones posteriores. Consulta plugin/README.md para detalles y solución de problemas.

Uso

La mayoría de los comandos toman el nombre de tu proyecto como primer argumento (elegido durante la incorporación de /leadace); /leadace en sí toma una pregunta libre o la URL de la página de inicio.

Los proyectos, prospectos, registros de prospección y documentos de estrategia viven en la nube — no hay archivos locales que gestionar. Revisa todo en la aplicación web en https://app.leadace.ai.

Flujo

flowchart TD
  LA["/leadace<br/>onboard · setup · strategy"] --> P{add prospects}

  P -- web search --> BL["/build-list"]
  P -- CSV / Excel --> IP["/import-prospects"]
  P -- reuse tenant --> MP["/match-prospects"]

  BL --> OB["/outbound"]
  IP --> OB
  MP --> OB

  OB --> CR["/check-responses"]
  CR --> EV["/evaluate"]
  EV -- next round --> P

  CR -. PMF signals .-> CF["/check-feedback"]
  CF -. revisit strategy .-> LA

  DC["/daily-cycle<br/>check + outbound + build, one shot"]
  SC["/setup-cron<br/>OS schedule"] --> DC
  DC -. replaces manual loop .-> P

  DEL["/delete-project"]

Flechas sólidas = el bucle principal. Discontinuas = opcional / ocasional / envoltorio. /evaluate también consume la parte táctica de los comentarios de rechazo (solicitudes de recontacto, referencias de tomadores de decisiones, not_relevant clústeres de industria) registrados por /check-responses — sin paso de usuario separado.

Licencia

LeadAce se publica bajo la Licencia de Código Abierto de LeadAce — un Apache 2.0 modificado con dos condiciones adicionales:

• Sin SaaS multi-tenant para terceros sin una licencia comercial de SurpassOne Inc. El auto-alojamiento para tu propia organización está bien.
• El logotipo y los derechos de autor del frontend deben conservarse en cualquier implementación que exponga la consola de LeadAce.

Servicio alojado (nube)

• Plan gratuito: 1 proyecto, 500 prospectos, 5 acciones de prospección al día (límite de 100 de por vida)
• Los planes de pago comienzan en $29/mes. Gestiona tu suscripción desde la aplicación web.

Auto-alojamiento

Consulta docs/self-host.md. La edición auto-alojada funciona en el nivel ilimitado — sin Stripe, sin límites. Para consultas sobre licencias comerciales, contacta a leo.uno@surpassone.com.

Para Desarrolladores

Estructura del repositorio

plugin/                          # Claude Code plugin
├── .claude-plugin/plugin.json   # Manifest
├── .mcp.json                    # MCP server config (uses LEADACE_MCP_URL)
├── skills/                      # Slash commands (each directory has SKILL.md)
├── scripts/fetch_url.py         # Local web fetch helper
└── references/                  # Shared reference docs
backend/                         # API + MCP servers (Cloudflare Workers, Hono, Drizzle)
frontend/                        # Web app (SvelteKit, Cloudflare Pages)
docs/                            # Project-wide docs (deploy runbook, self-host, architecture)
docker-compose.yml               # Bare Postgres for non-Supabase local dev

• Convenciones del plugin y flujo de trabajo de cambios de esquema: CLAUDE.md
• Auto-alojamiento y desarrollo local: docs/self-host.md

Inicio rápido (desarrollo local)

Configuración única — copia las plantillas de entorno:

cp backend/.dev.vars.example backend/.dev.vars
cp frontend/.env.example frontend/.env

Completa las claves de Supabase desde supabase status — las imprime una vez que la pila local está en ejecución, así que ejecuta make dev primero (inicia Supabase) y luego pega las claves.

Para el inicio de sesión con Google en tu pila local, también crea un cliente OAuth de Google y exporta SUPABASE_AUTH_EXTERNAL_GOOGLE_CLIENT_ID / _SECRET en tu shell (a través de .envrc) antes del primer make dev — inicia Supabase, que los lee desde el shell al arrancar. Consulta docs/self-host.md → Desarrollo local. (Estas variables de shell controlan el inicio de sesión; los GOOGLE_CLIENT_ID / _SECRET en backend/.dev.vars son separados — alimentan el envío de Gmail.)

Luego inicia toda la pila con un comando — Supabase, migraciones, la semilla maestra, los Workers de API/MCP y el frontend, todo junto. Ctrl-C detiene los servidores de desarrollo (Supabase permanece activo para un reinicio rápido; make stop lo detiene):

make dev          # or: ./scripts/dev.sh

Para ejecutar en puertos diferentes (p. ej. si uno está ocupado por otro servidor de desarrollo), copia dev.ports.env.example a dev.ports.env y configura los puertos allí — dev.sh reconfigura cada URL dependiente (y el inicio de sesión con Google sigue funcionando). Los valores predeterminados no cambian cuando el archivo no está presente.

npx supabase start                      # Auth + Postgres on ports 54321/54322
cd backend
npm install
npm run db:migrate
npx tsx scripts/seed-master-documents.ts

npm run dev:api                         # API → http://localhost:8787
npm run dev:mcp                         # MCP → http://localhost:8788  (separate terminal)

cd ../frontend
npm install
npm run dev                             # → http://localhost:5273

Comprobaciones previas al lanzamiento:

cd backend && npm run typecheck
cd frontend && npm run check

Actualización de dependencias (problema del archivo de bloqueo)

npm install con node_modules ya presente puede podar dependencias opcionales de otras plataformas (binarios @emnapi/*, @img/sharp-*, esbuild) de package-lock.json (npm/cli#7961, npm 10.3+–11.x). Luego CI ejecuta npm ci contra ese archivo de bloqueo podado y falla con Missing: … from lock file. Esto afecta tanto a backend/ como a frontend/, y es lo que hace que las PR de npm de Dependabot se pongan en rojo.

Cuando cambies un package.json / package-lock.json (o repares una PR de Dependabot), regenera el archivo de bloqueo con la cadena de herramientas fijada del repositorio — no en Docker:

nvm use                 # node 22 (repo .nvmrc) — matches CI
cd backend              # or cd frontend
rm -rf node_modules     # removing this first is what avoids the prune
npm install --no-audit --no-fund

Luego confirma el package-lock.json regenerado. Los cambios solo de código no necesitan esto — CI consume el archivo de bloqueo confirmado tal como está.