How Salesprompter Works | Salesprompter Docs

Most users can skim this page. It explains how the parts of Salesprompter fit together without dropping you into internal implementation details.

Salesprompter is easiest to understand as one shared sign-in layer plus several ways to work.

System model

Salesprompter app
  -> owns user identity
  -> starts and manages sessions
  -> can issue CLI access when browser login is unavailable

Salesprompter CLI
  -> stores a local auth session
  -> reads and writes portable workflow files
  -> runs repeatable targeting and lead workflows
  -> pushes qualified leads into downstream tools when configured

Chrome extension
  -> uses the same user identity as the app
  -> captures browser context when that helps the workflow
  -> hands work back to the app or CLI without losing context

Responsibilities by surface

Surface	Owns	Should not own
App	identity, session start, workspace access, shared settings	a separate parallel sign-in system
CLI	repeatable workflows, inspectable outputs, reviewable sync steps	a separate auth model
Chrome extension	browser capture, context gathering, in-page assistance	extension-only lead records or shadow auth

Shared product rules

The product follows a few simple rules across every surface:

Auth is shared across app, CLI, and extension.
Workflow steps produce outputs you can inspect.
Lead and account data should stay consistent as work moves between surfaces.
Provider behavior must declare whether output is real or fallback.
Writes into downstream tools should stay reviewable before they are applied.

Runtime boundaries

Auth boundary

The CLI talks to the app for sign-in and identity verification. If browser login is unavailable, teams can use a CLI token from the app instead.

Workflow boundary

The CLI owns repeatable workflow execution. The app owns identity and shared workspace context. The extension owns browser-side capture and in-page assistance.

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

The CLI matters because it gives teams a repeatable way to:

reproducible ICP definitions
explicit lead artifacts
generate, enrich, and score leads in visible steps
preview sync operations before applying them

That is why the docs emphasize inspectable workflow steps instead of opaque automation.