LeadAce

LeadAce

Plugin autônomo de geração de leads para o Claude Code. Cria listas de prospects, executa divulgação outbound e itera sobre a estratégia — tudo sem intervenção manual.

Site: https://leadace.ai

Duas formas de executar. Use o serviço hospedado em app.leadace.ai (Plano gratuito — 5 divulgações/dia, planos pagos a partir de US$ 29/mês), ou auto-hospede o backend no seu próprio Cloudflare + Supabase. O plugin é o mesmo em ambos os casos — aponte-o para o MCP hospedado ou para o seu próprio.

Para Usuários

Pré-requisitos

• Claude Code
• Uma conta LeadAce em https://app.leadace.ai (Plano gratuito — sem cartão)
• Uma conta Gmail conectada — para envio de e-mails (concedida ao entrar com o Google, ou pelo banner "Conectar Gmail" no aplicativo web)
• Gmail MCP (integrado ao claude.ai) — para verificar respostas de e-mail
• claude-in-chrome MCP — para envio de formulários e DMs em SNS (formulários podem alternativamente usar qualquer outro MCP de automação de navegador que você mesmo configure, ex.: Playwright; DMs em SNS exigem claude-in-chrome)

Instalação

Uma linha no seu terminal:

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

Ou, de dentro de uma sessão do Claude Code em execução:

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

Para atualizar depois:

/plugin marketplace update
/plugin update leadace@leadace

Entrar no LeadAce

Na primeira vez que o plugin chama uma ferramenta do LeadAce, seu navegador abre para o login do Google (a mesma conta Google do aplicativo web). O token é armazenado em cache localmente para execuções subsequentes. Consulte plugin/README.md para detalhes e solução de problemas.

Uso

A maioria dos comandos usa o nome do seu projeto como primeiro argumento (escolhido durante o onboarding do /leadace); o próprio /leadace aceita uma pergunta livre ou URL da página inicial.

Projetos, prospects, registros de divulgação e documentos de estratégia ficam na nuvem — não há arquivos locais para gerenciar. Revise tudo no aplicativo web em https://app.leadace.ai.

Fluxo

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"]

Setas sólidas = o ciclo principal. Tracejadas = opcional / ocasional / wrapper. O /evaluate também consome a fatia tática do feedback de rejeição (solicitações de recontato, indicações de tomadores de decisão, clusters de indústria not_relevant) registrada pelo /check-responses — sem etapa separada do usuário.

Licença

O LeadAce é distribuído sob a Licença de Código Aberto LeadAce — um Apache 2.0 modificado com duas condições adicionais:

• Sem SaaS multi-tenant para terceiros sem uma licença comercial da SurpassOne Inc. Auto-hospedagem para sua própria organização é permitida.
• O logotipo e os direitos autorais do frontend devem ser preservados em qualquer implantação que exponha o console do LeadAce.

Serviço hospedado (nuvem)

• Plano gratuito: 1 projeto, 500 prospects, 5 ações de divulgação por dia (limite vitalício de 100)
• Planos pagos começam em US$ 29/mês. Gerencie sua assinatura pelo aplicativo web.

Auto-hospedagem

Consulte docs/self-host.md. A edição auto-hospedada roda no nível ilimitado — sem Stripe, sem limites. Para consultas sobre licença comercial, entre em contato com leo.uno@surpassone.com.

Para Desenvolvedores

Estrutura do repositório

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

• Convenções do plugin e o fluxo de trabalho de alteração de schema: CLAUDE.md
• Auto-hospedagem e desenvolvimento local: docs/self-host.md

Início rápido (desenvolvimento local)

Configuração única — copie os modelos de env:

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

Preencha as chaves do Supabase a partir do supabase status — ele as imprime assim que a stack local estiver em execução, então execute o make dev uma vez primeiro (ele inicia o Supabase), depois cole as chaves.

Para o login do Google na sua stack local, crie também um cliente OAuth do Google e exporte SUPABASE_AUTH_EXTERNAL_GOOGLE_CLIENT_ID / _SECRET no seu shell (via .envrc) antes do primeiro make dev — ele inicia o Supabase, que os lê do shell no momento da inicialização. Consulte docs/self-host.md → Desenvolvimento local. (Essas variáveis de shell controlam o login; as GOOGLE_CLIENT_ID / _SECRET em backend/.dev.vars são separadas — elas alimentam o envio do Gmail.)

Em seguida, inicie toda a stack com um único comando — Supabase, migrações, o seed mestre, os Workers de API/MCP e o frontend, tudo junto. Ctrl-C encerra os servidores de desenvolvimento (o Supabase permanece ativo para um reinício rápido; o make stop o interrompe):

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

Para executar em portas diferentes (ex.: uma está ocupada por outro servidor de desenvolvimento), copie dev.ports.env.example para dev.ports.env e defina as portas lá — o dev.sh reconfigura todas as URLs dependentes (e o login do Google continua funcionando). Os padrões permanecem inalterados quando o arquivo está ausente.

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

Verificações de pré-lançamento:

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

Atualizando dependências (pegadinha do lockfile)

O npm install com node_modules já presente pode remover dependências opcionais de outras plataformas (binários @emnapi/*, @img/sharp-*, esbuild) do package-lock.json (npm/cli#7961, npm 10.3+–11.x). O CI então executa o npm ci contra esse lockfile podado e falha com Missing: … from lock file. Isso afeta tanto o backend/ quanto o frontend/, e é o que faz os PRs de npm do Dependabot ficarem vermelhos.

Quando você alterar um package.json / package-lock.json (ou corrigir um PR do Dependabot), regenere o lockfile com o toolchain fixado do repositório — não no 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

Em seguida, faça commit do package-lock.json regenerado. Alterações apenas de código não precisam disso — o CI consome o lockfile commitado como está.