suede-prospecting

Files (10)

• CARD.md
• SKILL.md
• openai.yaml · agents/
• evals.json · evals/
• b2b-prospecting.md · references/
• compliance.md · references/
• data-sources.md · references/
• demand-signals.md · references/
• local-prospecting.md · references/
• saas-prospecting.md · references/

SKILL.md (first lines)

# Suede AI Prospecting Skills

## Compatibility

Works from supplied URLs, exports, or source text; live sourcing needs an authorized browser or research connector. No enrichment service is bundled.

For a concrete input, expected handoff, and failure check, read
[the worked handoff](references/worked-handoff.md).

Suede AI Prospecting turns an approved ICP into a source-backed, scored lead sheet
across B2B SaaS, general B2B, local business, and early demand-signal motions.
Every candidate carries qualification evidence, disqualification logic, and a
compliance-aware handoff before outreach begins.

```
IRON LAW: every row carries a source URL and the date it was captured,
or it does not ship. No exceptions, no "verify later," no placeholder rows.
```

That single rule is what makes the downstream GDPR / CAN-SPAM lineage real. A row
without it is not a low-confidence lead: it is not a lead.

## Before Starting

**Check for product marketing context first:**
If `.agents/product-marketing.md` exists (or `.claude/product-marketing.md`, or the legacy `product-marketing-context.md` filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

## Pick the Branch

Prospecting motions differ enough that the workflow forks at intake. Pick **one** branch based on who the user is selling to:

| Branch | Sell to | What "qualified" looks like | Possible sources after access and terms checks |
|--------|---------|----------------------------|-----------------------------------------------|
| **SaaS** | Other SaaS companies / digital businesses | ICP fit + tech stack match + growth signals (funding, hiring, product velocity) | Public company sites, directories, developer sources, or licensed data available to the user |
| **B2B** | Non-SaaS B2B (services, manufacturers, enterprises, mid-market) | Industry + size + geographic fit + buying signals (trigger events, vendor changes) | Public company records, industry directories, or licensed business data available to the user |
| **Local SMB** | Local small businesses (shops, gyms, restaurants, clinics, salons, services) | Active business + website status + proximity + decision-maker access | Public business sites and manually reviewed listings allowed by their terms |
| **Demand-signal** | Early-stage: first customers, design partners, or beta users | A cited public pain, demand, or timing signal, not just firmographic fit | Public forums, reviews, issues, posts, jobs, and launch records reachable with current authorized tools or manual review |

Before using any named platform or vendor, discover what is currently callable,
authenticated, authorized, and permitted by its terms. If no research connector
or browser is available, give the user a manual source checklist and work from
URLs, exports, screenshots, or source text they provide.

If the user describes a hybrid motion (e.g., "SMBs that are also SaaS"), pick the dominant branch and pull in qualification signals from the other. If the user is early-stage and needs their *first* customers or design partners (evidence of demand over list coverage), use the **Demand-signal** branch.

For the branch-specific deep dives:
- **SaaS** → see [references/saas-prospecting.md](references/saas-prospecting.md)
- **B2B** → see [references/b2b-prospecting.md](references/b2b-prospecting.md)
- **Local SMB** → see [references/local-prospecting.md](references/local-prospecting.md)
- **Demand-signal** (find your first customers) → see [references/demand-signals.md](references/demand-signals.md)

---

## Shared Framework (all branches)

Every prospecting engagement follows the same five phases. Tools and qualification signals change per branch; the phases don't.

### Phase 1: Define the ICP

Pull from `product-marketing.md` if available. Otherwise, gather:

1. **Firmographic fit**: industry, company size, revenue band, geography, business model
2. **Technographic fit** (SaaS branch): what tools they already use, what they're missing
3. **Buying signal**: why now? (trigger event, funding, hiring, new initiative, dissatisfaction with current vendor, recent move/expansion)
4. **Decision-maker profile**: role, seniority, what they care about
5. **Disqualifiers**: what makes a prospect a clear "skip"

Output the ICP as a one-paragraph statement plus a checklist of pass/fail criteria. Don't move to discovery without this.

### Phase 2: Build the candidate list (discovery)

Start at 2-3x the requested output count, adjusted down for thin source access or
review capacity. Expand only when the observed disqualification rate shows another
batch is needed, and cap expansion at 3 rounds. At the cap, stop sourcing: report
the disqualification rate you observed and hand back a narrower ICP proposal
rather than grinding through more sources.

- **SaaS / B2B**: cross-check material claims across available first-party,
  public, or licensed sources. Named vendors are candidates only after access,
  freshness, terms, and cost checks.
- **Local SMB**: use an authorized research connector or manual public-source
  review, then cross-check listing claims against the business's own site or
  another current source.

A smaller evidence-complete list is preferable to padding the output with
unverified candidates. Don't start qualification until every candidate has its
source URL captured.

### Phase 3: Qualify each candidate

Score every candidate against the ICP checklist. Add **evidence** (a source URL or two) for each qualification: never assert without backing.

**Confidence levels** (used across all branches):
- **High**: confirmed by at least two independent sources or official business page
- **Medium**: one credible source plus consistent search evidence
- **Low**: incomplete or ambiguous evidence: flag what remains uncertain

For email contacts, discover whether an authorized validator is callable and
read its current result semantics before use. If none is available, label the
address `unverified`, keep it out of send-ready exports, and provide a
user-operated validation checklist. Never claim that validation guarantees
delivery. Don't move to scoring until every candidate carries a confidence level.

### Phase 4: Score and prioritize

Apply this rubric for the **SaaS, B2B, and Local SMB** branches. The **Demand-signal** branch scores differently: 0–100 demand-fit, not Hot/Warm/Cold. See [references/demand-signals.md](references/demand-signals.md).

| Score | Definition |
|-------|------------|
| **Hot** | ICP fit (passes the full Phase 1 ICP checklist) + clear buying signal + decision-maker accessible + verified contact |
| **Warm** | ICP fit + softer or older signal + contact verifiable |
| **Cold** | Loose ICP fit OR no clear signal OR contact unverified |
| **Skip** | Disqualifier hit (out of ICP, closed business, duplicate, irrelevant, low confidence) |

Branch-specific signals refine the scoring: see each reference file. Let the
evidence determine the number in each label; never force a Hot/Warm/Cold quota.
No row leaves this phase labeled Hot without both a buying signal and a verified
contact: downgrade it to Warm instead.

From JasonColapietro/suede-creator-skills, MIT.

More from JasonColapietro/suede-creator-skills