Salesprompter

Docs that map the app, CLI, and extension as one system.

Public documentation for the Salesprompter contracts, workflows, and runtime behavior. This deployment is generated directly from the docs source in the CLI repository.

Source repository

Salesprompter is easiest to understand as one shared identity layer plus several execution surfaces.

System model

Salesprompter app
  -> owns user identity
  -> exposes CLI auth endpoints
  -> can issue direct CLI tokens when device flow is unavailable

Salesprompter CLI
  -> stores a local auth session
  -> reads and writes JSON artifacts
  -> queries BigQuery through the local bq CLI
  -> pushes scored leads into sync targets such as Instantly

Chrome extension
  -> should reuse the same user identity as the app
  -> should emit or consume the same account and lead contracts
  -> should preserve provenance when handing work back to the app or CLI

Responsibilities by surface

Surface Owns Should not own
App identity, session initiation, token issuance, backend verification warehouse-side business logic hidden from the CLI
CLI deterministic workflows, artifacts, audits, writeback SQL, provider routing a separate auth model
Chrome extension browser capture, context gathering, in-page assistance extension-only lead schemas or shadow auth

Core contracts

The current implementation makes a few contracts explicit:

  • Auth is shared across app, CLI, and extension.
  • Lead and account objects are stable JSON shapes validated with zod.
  • Provider behavior must declare whether output is real or fallback.
  • Domain-finder writes are separated from selection and audit stages.
  • BigQuery interaction happens locally through bq, not through the app backend.

Runtime boundaries

Auth boundary

The CLI talks to the app backend only for auth and identity verification. The required endpoints are documented in App and Auth Backend.

Warehouse boundary

Warehouse-heavy workflows such as leads:lookup:bq, queries:analyze:bq, leadlists:funnel:bq, and the domainfinder:*:bq commands execute through the locally installed bq CLI. The app is not proxying those queries for this repository.

Provider boundary

The current default providers are intentionally heuristic. They model the workflow shape without pretending to be verified enrichment or people-data providers. When a provider becomes real, it should keep the same JSON shape and flip mode to real.

Why the CLI matters

This repo is not a convenience wrapper around the app. It is a production integration surface for:

  • reproducible ICP definitions
  • explicit lead artifacts
  • warehouse-backed query generation
  • domain-selection logic with traceable writeback
  • dry-run and applied sync semantics

That is why the docs emphasize contracts, artifacts, and invariants instead of just command examples.