LeadAce

LeadAce

Agente de vendas outbound autônomo no seu navegador. Cria listas de prospects, escreve e envia um e-mail por empresa a partir da sua própria caixa de entrada, e melhora sua estratégia a cada resposta e rejeição.

Site: https://leadace.ai

Duas formas de executar. Use o serviço hospedado em app.leadace.ai (plano gratuito — 30 prospects, planos pagos a partir de US$ 49/mês), ou self-host o backend no seu próprio Cloudflare + Supabase. O aplicativo web e o plugin opcional do Claude funcionam da mesma forma em ambos.

Para Usuários

Começando

1. Entre com o Google em app.leadace.ai (plano gratuito — sem cartão). O LeadAce pede permissão para enviar pelo seu Gmail e ler sua caixa de entrada, para capturar as respostas.
2. Cole seu site no chat. O Ace propõe quem abordar e como abordá-los. Altere o que quiser e aprove.
3. Leia os primeiros rascunhos. Nada é enviado até você aprovar, e o que você aprovar sai da sua própria caixa de entrada.

O e-mail roda inteiramente no aplicativo web: pesquisa, escrita, envio e coleta de respostas rodam no servidor. Agende o ciclo diário pelo chat ou nas configurações do projeto. Outras contas do Google e caixas SMTP são adicionadas nas configurações da conta.

Plugin Claude (opcional)

O plugin, para Claude Cowork ou Claude Code, executa o mesmo trabalho a partir de uma sessão do Claude e adiciona um navegador: envia as mensagens de formulário de contato e DMs de redes sociais que o aplicativo web deixa para você enviar manualmente. Funciona nos mesmos projetos que o aplicativo web.

Pré-requisitos

• Claude Cowork (no aplicativo Claude Desktop) ou Claude Code, em um plano Anthropic Pro ou Max — verificado no macOS
• Uma conta LeadAce em https://app.leadace.ai (plano gratuito — sem cartão)
• Uma conta Gmail conectada — para envio de e-mail (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
• Um navegador, apenas para canais de navegador — formulários de contato rodam no navegador integrado do Cowork ou em qualquer MCP de automação de navegador que você configurar (ex.: Playwright); DMs de redes sociais e verificação de respostas em redes sociais exigem Claude no Chrome. Uma execução agendada alcança o navegador apenas enquanto o Claude Desktop estiver aberto, com o navegador padrão escolhido previamente

Instalação

No Claude Desktop: Personalizar → Plugins → Adicionar de um repositório → aitit-inc/leadace → Instalar → Conectores → Conectar, depois Personalizar → Conectores → LeadAce → Conectar e entrar com o Google.

Ou uma linha no seu terminal (Claude Code):

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 chamar uma ferramenta do LeadAce, seu navegador abre para entrar com o Google (a mesma conta Google do aplicativo web). O token é armazenado em cache localmente para execuções subsequentes. Veja 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. Execute-os em uma sessão do Cowork (a aba Cowork, não Chat — o /daily-cycle executa subagentes, que o Chat não consegue iniciar) ou no Claude Code.

Projetos, prospects, registros de contato 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/>daily schedule"] --> DC
  DC -. replaces manual loop .-> P

  DEL["/delete-project"]

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

Licença

O LeadAce é distribuído sob a Licença Open Source do LeadAce — uma Apache 2.0 modificada com duas condições adicionais:

• Sem SaaS multi-tenant para terceiros sem uma licença comercial da SurpassOne Inc. Self-hosting para sua própria organização é permitido.
• Logo e copyright do frontend devem ser preservados em qualquer implantação que exponha o console do LeadAce.

Serviço hospedado (nuvem)

• Plano gratuito: 30 prospects (vitalício), 1 projeto, 1 caixa de entrada, 500 prospects armazenados.
• Planos pagos começam em US$ 49/mês para 100 prospects por mês. Um prospect conta uma vez, quando a primeira mensagem é enviada a ele; follow-ups são gratuitos. Gerencie sua assinatura pelo aplicativo web.

Self-host

Veja docs/self-host.md. A edição self-hosted roda no nível ilimitado — sem Stripe, sem limites. Para consultas sobre licença comercial, contate leo.uno@surpassone.com.

Para Desenvolvedores

Estrutura do repositório

plugin/                          # Claude Code plugin
├── .claude-plugin/plugin.json   # Manifest
├── .mcp.json                    # MCP server config
├── 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 Worker + static assets)
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 mudança de schema: CLAUDE.md
• Self-hosting 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 de supabase status — ele as imprime assim que a stack local estiver rodando, então execute make dev uma vez primeiro (ele inicia o Supabase) e depois cole as chaves.

Para o login com 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 as lê do shell no momento da inicialização. Veja 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.)

Depois, 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 reinício rápido; make stop o interrompe):

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

Para rodar 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 com Google continua funcionando). Os padrões ficam 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)

npm install com node_modules já presente pode remover dependências opcionais de outras plataformas (binários @emnapi/*, @img/sharp-*, esbuild) de package-lock.json (npm/cli#7961, npm 10.3+–11.x). O CI então executa npm ci contra esse lockfile podado e falha com Missing: … from lock file. Isso afeta tanto backend/ quanto 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), regere o lockfile sob o toolchain fixado do repositório — não em Docker:

nvm use                 # node 24 (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

Depois, faça commit do package-lock.json regenerado. Mudanças apenas de código não precisam disso — o CI consome o lockfile commitado como está.