process-leads

Files (1)

• SKILL.md

SKILL.md (first lines)

Process existing leads and qualify them against the user's saved ICP. This is a lead-cleaning and qualification workflow, not a LinkedIn search workflow.

Critical dashboard rule: lead pipeline movement is stored in the lead `stage` field, not the connection/message `status` field. Newly synced leads enter as `stage: "new"`. When a lead qualifies, move its `stage` from `new` to `qualified`.

Delegate to the **lead-gen** agent in **process-leads mode** with these constraints:

- Do not run LinkedIn people searches.
- Do not ask the user to re-enter ICP, role, industry, geography, company size, exclusions, pitch, or messaging setup.
- Use existing lead data for the first-pass screen, then deep research plausible leads before final qualification.
- Use `references/qualification-criteria.md` for scoring and decision rules.
- Use `references/storage.md` for all fetch and sync behavior.

## Step 1: Load Source Data

Resolve setup in this order:

1. Use the imported "Your Ideal Customer Profile" and onboarding config when available.
2. If `${CLAUDE_PLUGIN_DATA}/config.json` exists, fetch latest dashboard config via `references/api.md`, especially `icp`, `messaging`, `resources`, and `rate_limits`.
3. If dashboard config is missing, use local memory and `references/icp-template.md` as structure guidance.

Then load leads:

**If `${CLAUDE_PLUGIN_DATA}/config.json` exists (Pro plan):**
- Fetch latest new leads from the dashboard API using `references/api.md`: `/v1/gtm/leads?stage=new&page_size=100`.
- The dashboard API is the source of truth for current lead stage, status, notes, and user edits.
- Use browser-tab API fetches only. Do not use Bash, curl, Node, Python, or direct HTTP calls from the agent process.

**If `${CLAUDE_PLUGIN_DATA}/config.json` does NOT exist (Basic plan):**
- Load leads from agent memory.
- If spreadsheet sync is configured, use `references/storage.md` and `references/storage-spreadsheet.md` to read the current Leads tab before processing.
- If no leads are available, report the empty state and suggest running the lead discovery workflow.

## Step 2: Deduplicate and Protect Pipeline State

Deduplicate by normalized LinkedIn URL first, then by API `id` if present.

Never downgrade leads that are already in active or successful pipeline stages:

- `qualified`
- `approved`
- `connecting`
- `connected`
- `outreach_sent`
- `messaged`
- `responded`
- `meeting_booked`
- `closed_won`
- `closed_lost`

For these leads, add missing qualification fields only when safe. Do not reset their `stage` to `new`.

Do not re-add or reactivate records already marked:

- `skipped`
- `excluded`
- `stale`

## Step 3: Deep ICP Qualification

Score every processable lead with a two-pass workflow.

First, use existing fields only to immediately exclude clear non-fits:

- Saved exclusion industries, companies, personas, competitors, or "do not contact" notes.
- Clearly wrong roles or personas with no buying influence for the saved ICP.
- Companies visibly outside the ICP or product/pitch target with no contrary evidence.

Then research remaining plausible leads before assigning final stage or `icp_tier`:

- Visit the person's LinkedIn profile to confirm current title, role authority, company, location, and any relevant person-level signal.
- Visit the company LinkedIn page when available to confirm category/industry, size signals, geography, and exclusion risk.
- Use the company website only when it is clearly linked from LinkedIn or otherwise unambiguous. Do not guess domains.
- Treat discovery fields such as `company_research_summary` and `potential_high_lead` as hints only; verify them before final qualification.
- Stop researching a lead as soon as an exclusion or clear non-fit is confirmed.

For every processed lead, build `qualification_reason` from all available saved context and lead evidence:

- ICP fit: compare role/title against Tier 1 and Tier 2 roles, then check industry, geography, company size, and saved exclusions.
- Product/pitch fit: use the imported profile/pitch sections plus fetched `icp`, `voice`, `messaging`, `resources`, and any product outcome or pitch fields in dashboard config.
- Lead evidence: cite only facts available from the lead record, notes, source, discovery company summary, stored research, company, title, industry, location, LinkedIn profile, company LinkedIn page, or clearly identified company website.
- Uncertainty: if evidence is thin, say what is missing instead of inventing proof, urgency, budget, funding, buying intent, or product claims.

`qualification_reason` must be a compact 2-4 sentence paragraph, not a label. It must explain the decision enough that the user can understand why the lead was qualified, unqualified, or excluded without reopening the agent run.

Assign an ICP tier to every processed lead:

- `icp_tier: 1` = clear Tier 1 role plus strong company/industry/geography fit.
- `icp_tier: 2` = adjacent champion or partial ICP fit worth keeping.
- `icp_tier: 3` = unqualified lead that should not receive outreach.

Apply exclusion rules before positive scoring:

- Saved exclusion industries, companies, personas, competitors, or "do not contact" notes become `status: "excluded"`.
- Include the matched exclusion reason and evidence in `qualification_reason`.

Stage/status updates:

- Tier 1-2 leads in `new`, empty, or missing stage: set `stage: "qualified"` and add a proper `qualification_reason` covering ICP fit, product/pitch relevance, lead evidence, and any uncertainty. This is the required dashboard transition.
- Tier 1-2 leads already in a later/protected stage: keep the existing `stage`; only add/update `icp_tier`, notes, and `qualification_reason` when safe.
- Tier 1-2 leads may also set `status: "qualified"` when a status field is present, but do not rely on `status` for dashboard movement.
- Tier 3 leads: set `stage: "unqualified"` and `status: "unqualified"`; include a specific disqualification reason in `qualification_reason`.
- Excluded leads: set `stage: "excluded"` and `status: "excluded"`; include a specific exclusion reason in `qualification_reason`.

Preserve useful existing notes and keep the concise decision rationale in `qualification_reason` instead of overwriting user-written context.

Examples:

- Qualified: `Tier 1 fit: VP Sales at a SaaS company, matching the saved ICP role and target industry. The lead appears relevant to the product pitch because they likely own pipeline growth and outbound conversion, which aligns with the configured outcome. Evidence is limited to search-card fields, so outreach should validate current priorities before assuming budget or urgency.`
- Unqualified: `Unqualified: the title indicates an individual contributor rather than a buyer or champion from the saved ICP roles. The available company and industry fields do not connect this lead to the configured product pitch, and there is no stored research suggesting relevant ownership or intent.`
- Excluded: `Excluded: the lead matches the saved competitor exclusion. The company/name evidence indicates this account should not enter outreach, regardless of apparent role fit.`

## Step 4: Store and Sync Results

Always write results to persistent agent memory first.

Then sync using `references/storage.md`:

**Pro plan:**
- Sync updated lead records back to the dashboard API with type `leads`.

From Kasper-AI/gtm-kit-plugin, MIT.

More from Kasper-AI/gtm-kit-plugin