LeadAce

Autonomes Plugin zur Lead-Generierung für Claude Code. Erstellt Prospect-Listen, führt Outbound-Maßnahmen aus und optimiert die Strategie – alles völlig ohne manuelles Eingreifen.

Website: https://leadace.ai

Zwei Möglichkeiten, es zu betreiben. Nutze den gehosteten Dienst unter app.leadace.ai (Kostenloser Tarif – 5 Outreach-Aktionen pro Tag, kostenpflichtige Tarife ab 29 $/Monat) oder hoste das Backend selbst auf deiner eigenen Cloudflare- und Supabase-Infrastruktur. Das Plugin ist in beiden Fällen dasselbe – richte es entweder auf das gehostete MCP oder auf dein eigenes aus.

Für Nutzer

Voraussetzungen

• Claude Code

• Ein LeadAce-Konto unter https://app.leadace.ai (Kostenloser Tarif – keine Kreditkarte)

• Ein verbundenes Gmail-Konto – zum Senden von E-Mails (wird bei der Anmeldung mit Google oder über das Banner „Connect Gmail“ in der Web-App gewährt)

• Gmail MCP (in claude.ai integriert) – zum Prüfen von E-Mail-Antworten

• claude-in-chrome MCP – für Formularübermittlung und SNS-DMs (für Formulare kannst du alternativ jedes andere Browser-Automation-MCP verwenden, das du selbst konfigurierst, z. B. Playwright; SNS-DMs erfordern claude-in-chrome)

Installation

Eine Zeile in deinem Terminal:

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

Oder aus einer laufenden Sitzung von Claude Code heraus:

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

Für spätere Updates:

/plugin marketplace update
/plugin update leadace@leadace

Bei LeadAce anmelden

Beim ersten Aufruf eines LeadAce-Tools durch das Plugin öffnet sich dein Browser für die Google-Anmeldung (dasselbe Google-Konto wie in der Web-App). Das Token wird für spätere Ausführungen lokal zwischengespeichert. Details und Fehlerbehebung findest du in plugin/README.md.

Verwendung

Die meisten Befehle erwarten deinen Projektnamen als erstes Argument (festgelegt während des /leadace-Onboardings); /leadace selbst nimmt eine frei formulierte Frage oder eine Homepage-URL entgegen.

Projekte, Prospects, Outreach-Protokolle und Strategiedokumente liegen in der Cloud – es gibt keine lokalen Dateien zu verwalten. Alles kannst du in der Web-App unter https://app.leadace.ai einsehen.

Ablauf

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

Durchgezogene Pfeile = Hauptschleife. Gestrichelt = optional / gelegentlich / Wrapper. /evaluate verarbeitet außerdem den taktischen Teil des Ablehnungsfeedbacks (Recontact-Anfragen, Entscheider-Empfehlungen, not_relevant-Branchencluster), das von /check-responses erfasst wird – kein separater Benutzerschritt erforderlich.

Related MCP server: swarmix-mcp

Lizenz

LeadAce wird unter der LeadAce Open Source License veröffentlicht – einer modifizierten Apache-2.0-Lizenz mit zwei zusätzlichen Bedingungen:

• Kein Multi-Tenant-SaaS für Dritte ohne kommerzielle Lizenz von SurpassOne Inc. Selbst-Hosting für die eigene Organisation ist in Ordnung.

• Frontend-Logo und Urheberrechtshinweis müssen bei jeder Bereitstellung, die die LeadAce-Konsole zugänglich macht, erhalten bleiben.

Gehosteter Dienst (Cloud)

• Kostenloser Tarif: 1 Projekt, 500 Prospects, 5 Outreach-Aktionen pro Tag (100 Gesamtlimit)

• Kostenpflichtige Tarife beginnen bei 29 $/Monat. Verwalte dein Abonnement in der Web-App.

Selbst hosten

Siehe docs/self-host.md. Die selbst gehostete Edition läuft im unbegrenzten Tarif – kein Stripe, keine Limits. Bei Anfragen zu kommerziellen Lizenzen wende dich an leo.uno@surpassone.com.

Für Entwickler

Repository-Struktur

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

• Plugin-Konventionen und der Workflow für Schema-Änderungen: CLAUDE.md

• Self-Hosting und lokale Entwicklung: docs/self-host.md

Schnellstart (lokale Entwicklung)

Einmalige Einrichtung – die Env-Vorlagen kopieren:

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

Trage die Supabase-Schlüssel aus supabase status ein – sie werden ausgegeben, sobald der lokale Stack läuft. Führe also zuerst einmal make dev aus (es startet Supabase) und füge dann die Schlüssel ein.

Für die Google-Anmeldung an deinem lokalen Stack musst du außerdem einen Google-OAuth-Client erstellen und SUPABASE_AUTH_EXTERNAL_GOOGLE_CLIENT_ID / _SECRET in deiner Shell exportieren (über .envrc) bevor du das erste Mal make dev ausführst: Es startet Supabase, das diese Werte beim Start aus der Shell liest. Siehe docs/self-host.md → Lokale Entwicklung. (Diese Shell-Variablen steuern die Anmeldung; die GOOGLE_CLIENT_ID / _SECRET in backend/.dev.vars sind davon getrennt – sie sind für das Senden von Gmail zuständig.)

Starte dann den gesamten Stack mit einem einzigen Befehl – Supabase, Migrationen, den Master-Seed, die API-/MCP-Worker und das Frontend, alles zusammen. Mit Strg-C beendest du die Dev-Server (Supabase bleibt für einen schnellen Neustart aktiv; make stop stoppt es):

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

Um andere Ports zu verwenden (falls z. B. einer von einem anderen Dev-Server belegt ist), kopiere dev.ports.env.example nach dev.ports.env und trage die Ports dort ein – dev.sh aktualisiert alle abhängigen URLs entsprechend (und die Google-Anmeldung funktioniert weiter). Wenn die Datei nicht vorhanden ist, bleiben die Standardwerte unverändert.

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

Pre-Release-Checks:

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

Abhängigkeiten aktualisieren (Stolperfalle bei Lockfiles)

npm install kann bei bereits vorhandenem node_modules optionale Abhängigkeiten anderer Plattformen (@emnapi/*, @img/sharp-*, esbuild-Binärdateien) aus package-lock.json entfernen (npm/cli#7961, npm 10.3+–11.x). CI führt dann npm ci gegen diese bereinigte Lockfile aus und schlägt mit Missing: … from lock file fehl. Das betrifft sowohl backend/ als auch frontend/ und ist der Grund, warum Dependabots npm-PRs rot werden.

Wenn du package.json / package-lock.json änderst (oder einen Dependabot-PR reparierst), generiere die Lockfile unter der im Repository festgeschriebenen Toolchain neu – nicht in 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

Übernimm anschließend die neu generierte package-lock.json in deinen Commit. Reine Code-Änderungen erfordern das nicht – CI verwendet die eingecheckte Lockfile so, wie sie ist.