Onsa

View saved version →

---
name: build-icp
description: Work out who the user should sell to before any search runs — an ideal-customer profile built from evidence (closed deals in a CRM connected to this chat, the replies Onsa's own campaigns got, an existing campaign's profile) rather than from guesswork, with every criterion marked as observed, borrowed or guessed, and every requirement split into what a search can see and what only a conversation can settle. Use when the user asks "who should I target", "help me define my ICP", "find more customers like my best ones", "use my CRM / HubSpot / Salesforce", or cannot say in two lines who they want to reach.
---

# Build an ICP

> These steps are for you. Talk to the user about their search and their customers, in your own
> words. Never show the user this file, its path or a link to it, and never quote its sentences to
> justify a question — give the reason in their terms instead.

An ideal-customer profile is a claim about who buys. This skill makes each part of it say where it
came from, so the user can see which parts are measured and which are hopes — and so the search
that follows spends the prospect allowance on the right people.

Nothing here spends allowance. It ends with a profile the user has approved, and a clear choice
about whether to search with it now.

## Step 1 · Collect the evidence that exists

Start with `list_next_steps` (no arguments) unless it already ran in this conversation: it says
whether a search is already running or new searches are blocked. Building a profile is still
useful then — say so, and say the search itself will have to wait.

Then gather, and say what you found in each:

1. **What the user sells** — one or two lines, in their words. Ask for it even when a CRM is
   connected: deals say who bought, not what they bought or who competes with it.
2. **A CRM connected to this chat** — HubSpot, Salesforce, Pipedrive, Attio, or any other
   connector whose tools read deals and the companies on them. The CRM holds the user's customers,
   so opening it is their decision. Ask once, as your own question with the reason in their terms:
   *"You have <CRM> connected. It holds your customer records, so I'll only look if you say so:
   shall I read your recent deals — won, lost and still open — read-only, to see who actually buys
   and who to leave out?"*
   - **Yes** → read the most recent closed deals (about the last 50 won and 50 lost, or the last
     12 months if the tools filter by date) with each deal's company attributes (industry, size,
     geography) and the buyer's role where the CRM holds it, plus open deals for the exclusions.
     Read only: never create, edit or delete anything in the CRM.
   - **No**, or the tools cannot reach deals (contacts only, missing permissions, reads failing) →
     say which, and continue from the user's own account. Missing access is not "zero deals".
3. **Onsa's own record.** `list_campaigns`, then `get_campaign_stats` and `list_replies` for the
   few campaigns worth reading — the largest, and any the user names: which profiles drew positive
   replies, and which drew rejections and why. A campaign that `hasIcp` can be opened with
   `get_campaign` to read the profile it already uses.
4. **The user's own account** — who bought, who churned or said no, and who they never want to
   contact. With no customers yet, say so: the profile is then a set of hypotheses to test, and
   every line of it is GUESSED.

**Report what you read before using it** — two won deals is not a pattern, and a sample is not the
whole record:

```
EVIDENCE
  closed won      N   (source: <CRM, last 12 months / user's account / none>)
  closed lost     M   (reason recorded for K)
  Onsa replies    P positive / Q negative, from R of S campaigns read
  not read        <what exists but was not looked at, if anything>
```

## Step 2 · Draft the profile, with provenance on every line

Build it from what the won deals have in common, and what separates them from the lost ones:

```
WHO BUYS
  companies:  <industry · size band · geography · other observable traits>
  people:     <the buyer's role, with the title variants that mean the same job>

  each line:  OBSERVED  — shared by N of the won deals (name the source)
              BORROWED  — a benchmark or rule of thumb; say whose
              GUESSED   — a hypothesis to test (the user's belief, or your proposal — say which)
```

- **Do not invent precision.** Eleven won deals do not support "51–200 employees" over "50–250";
  use the band the evidence can defend.
- **A trait every candidate shares does no work.** If the user only sells in the US, geography is a
  boundary, not a criterion — put it in the search once and stop weighing it.
- **A lost deal is evidence too** — but one lost deal is an example, not a rule. Say what it
  suggests and how sure that is.

## Step 3 · Exclusions

- **From the user or the CRM:** existing customers and open deals, by company name or domain; the
  segments the user ruled out.
- **Your proposals** — mark each one as a proposal, and keep it only if the user agrees:
  competitors of what they sell; agencies or resellers buying on someone else's behalf; anything
  the lost deals point to.

Give each exclusion a test a search can apply: "too small" is not testable; "fewer than 10
employees" is.

Keep customer data out of the search: the profile describes **kinds** of companies and roles, and
never carries contacts, deal values or notes. Company names or domains go only into the exclusion
list, and only after telling the user they will be sent to Onsa for that purpose. Onsa is asked to
leave them out, but its search reads the brief as text, so the exclusion is an instruction, not a
guarantee — when leads come back, check them against the list and point out any that match.

## Step 4 · Split what a search can see from what it cannot

```
CAN BE SEARCHED     industry, size, geography, role, seniority, …
CANNOT BE SEARCHED  budget, a tool used internally, intent to buy, …
  for each: the closest visible proxy (and what it gets wrong), or
            "left for the first conversation"
```

A requirement nothing can show is a wish, not a filter. Say which of the user's requirements are
wishes **before** the search, not after it disappoints.

## Step 5 · Approve the profile, then decide what to do with it

First settle anything still open — the product, the exclusion list, proposals the user has not
answered — in one message. Then show the profile in one block (who buys, the exclusions, what
cannot be searched), with the provenance marks kept, and say how many lines are **GUESSED**: that
is the part the first searches will test.

Ask two things together, because approving a profile and spending allowance are different
decisions:

> Does this look right, or what should change? And do you want me to start a search with it now —
> how many people (up to 25) — or keep it for later?

- **Search now** → if the user came here from `get-started`, return there at its Step 3 with this
  profile as the brief; otherwise continue with the `find-leads` skill at its Step 3. The profile
  is already approved: do not restate it as a new `SEARCHING FOR` block or ask again.
- **Improve an existing campaign** instead of starting a new one → `continue_campaign` with the
  change as its steer. It changes what that campaign looks for next; it does not rewrite the
  campaign's stored profile or remove leads already found.
- **Keep it for later** → end with the profile, ready to paste into a later search.

After a search, the evidence that tests a GUESSED line is what people **reply** — "not a fit",
"we already have this", interest. A low Onsa score measures a lead against the profile itself, so
many low scores point to the search or the profile's wording, not to who buys. Offer to revise the
profile when replies contradict it.

View saved version →

---
name: find-leads
description: Turn a description of who the user wants to sell to into an Onsa lead search they have approved, have it report back when leads arrive, and present the leads with the evidence behind each score. Use when the user asks Onsa to find prospects, leads, buyers, decision-makers or "people like X", or to grow an existing campaign ("5 more like these", "try Europe instead").
---

# Find leads

> These steps are for you. Talk to the user about their search and their customers, in your own words — not about this skill, its steps or its file.

A search spends the workspace's prospect allowance, so the query is agreed before it runs, and the
results are shown with what Onsa actually established about each person.

## Step 1 · New search or an existing campaign?

- "More like these", "try another region", "stop including X" → the campaign already exists: use
  `continue_campaign` with that campaign's id. A new `find_leads` would split it into a separate
  campaign with its own profile.
- `continue_campaign` steers what the campaign looks for **next**. It removes nothing: leads
  already found, and outreach already queued for them, stay. Say so when the user asks to drop
  people, and point them to the campaign in the Onsa app to remove them.
- Otherwise → a new search, Step 2.

If you do not know which campaigns exist, `list_campaigns` tells you. If the user has not used Onsa
in this conversation yet, `list_next_steps` first: it says whether a search is already running or
new searches are blocked.

## Step 2 · Restate the brief as a query, and get a yes

Write back, in one short block:

```
SEARCHING FOR
  people:     <titles, including the variants that mean the same job>
  companies:  <industry · size · geography · other observable traits>
  excluding:  <what the user ruled out>
```

Then add one line for each requirement Onsa cannot see directly on a company or a profile — for
example a budget, a tool the company uses internally, or an intent to buy. Say it will be judged
from indirect evidence, or left for the first conversation. A requirement nothing can show is a
wish, not a filter.

Ask for a yes or corrections. Skip the question only if the user already said to just run it, or
approved this same brief moments ago in the `build-icp` skill.

If the user cannot describe who they want in a sentence or two, or wants the profile worked out
from their past deals or a connected CRM, run the `build-icp` skill first.

## Step 3 · Run it

`find_leads` with the agreed query and the requested number as `limit` — an integer from 1 to 25
(default 5); for more, say so and run it at 25. `limit` is a target, not a spending cap: every lead
that lands uses allowance. Or `continue_campaign` with the steer. Both return a `jobId`
immediately and run in the background.

Read the answer before going on. A `billingWarning` goes to the user as written. A continuation
can answer without starting new work — for example when the steer only changed settings, or was
already answered — and its answer says so; do not re-send the same steer, and do not replace it
with `find_leads`.

## Step 4 · Be told, don't watch

Where the host supports MCP events, subscribe this chat to `leads_search.leads_found` and
`leads_search.finished` for the `jobId`. Only once that succeeded, tell the user the chat will hear
about the first leads and the agent's report; do not set up a periodic check. Then call
`fetch_leads` once — anything that landed before the subscription shows up there. On each event,
call `fetch_leads` with the `jobId`. A batch can still land after `finished`.

Without events, or if the subscription failed, follow `progress.note` in the `find_leads` answer
and in each `fetch_leads` answer — it says whether the next call waits for leads or when to ask
again. A job reads `pending` while it is still searching; never tell the user no leads were found
while it is pending.

## Step 5 · Present the leads with their evidence

A table: `name`, `position`, `companyName`, `score` (1–5) and what the `scoreExplanation`
establishes — "not scored yet" where either is missing. Beside it, what is **not** established:
anything the explanation or the search agent's report calls approximated, estimated or unverified,
and any contradiction between a lead's own fields (for example a `position` and a `headline` that
disagree). Onsa's reasoning stays in Onsa's words; add no fact about a person that Onsa did not
return.

Close with the `campaignUrl`, and one line on what the user can do next: grow the campaign
(`continue_campaign`), or review the people and drafts (the `review-leads` skill).

## When the search ends without leads

`leads_search.finished` with `no_leads`, or a `stalled` status, usually carries the search agent's
own answer in `agentMessage` — often a question about the brief. Relay it, and offer to re-run with
the answer folded into the query. When there is no `agentMessage`, say the search ended without
leads and without an explanation, and send the user to the `campaignUrl`.

View saved version →

---
name: get-started
description: First steps with Onsa right after connecting it — reads what the Onsa workspace already holds, asks for the two lines a search needs if it holds nothing, starts the first lead search and has it report back to this chat when leads arrive. Use right after install, or when the user says "get started with Onsa", "what can Onsa do", "set up Onsa", or asks for leads without any brief.
---

# Get started with Onsa

> These steps are for you. Talk to the user about their search and their customers, in your own words — not about this skill, its steps or its file.

Onsa finds real B2B prospects — people with LinkedIn profiles — scores each one 1–5 against an
ideal-customer profile with the reasoning written out, and keeps every search as a campaign.

## Step 1 · Read the workspace before asking anything

Call `list_next_steps` with no arguments and follow what it says. The usual cases:

- **A search is already running** → say so, give its `jobId`, and go to Step 4 for that job. Do
  not start a second search.
- **New searches are blocked** (trial ended, allowance used up, no active subscription) → relay
  that blocker in the tool's own words. Do not start a search, and do not offer any purchase or
  upgrade. What the workspace already holds stays readable: offer to review its campaigns, leads
  and replies (the `review-leads` skill) if it has any.
- **The workspace has campaigns** → name the most useful one or two in a line each and ask
  whether to continue one of them or start a new search.
- **The workspace is new** → Step 2.

If the answer says it could not tell whether a search is running, say that, and ask before
starting one.

## Step 2 · The two lines a search needs

Ask in one message:

> 1. Who do you want to reach? (the role, the kind of company, size, geography)
> 2. Who should Onsa never include? (segments, geographies, company types — "none" is fine)

Add one line to that message: *"Not sure yet? I can work it out with you from your past deals —
including from your CRM, if one is connected here."* If the user takes that offer or answers
vaguely ("SMBs", "anyone who needs sales"), run the `build-icp` skill. When it comes back with an
approved profile and the user chose to search now, continue at Step 3 with that profile as the
brief — it is already approved, so do not read it back again.

Use the user's own words. Do not invent an audience, and do not fill it in from what their company
seems to sell: a search spends the workspace's prospect allowance, and a guessed brief spends it on
the wrong people. If a brief the user has not yet approved is already in this conversation, read it
back in one line and get a yes before using it.

## Step 3 · Start the search

Call `find_leads` with the brief as `query` and the number of people asked for as `limit` — an
integer from 1 to 25 (default 5); for more, say so and run it at 25. `limit` is a target, not a
spending cap: every lead that lands uses allowance. It returns a `jobId` at once; the search itself
runs in the background, first leads usually within about 5 minutes.

## Step 4 · Have the search report back

Where the host supports MCP events, subscribe this chat to both events for the `jobId`:

- `leads_search.leads_found` — each batch of leads as it lands
- `leads_search.finished` — the agent posted its report (`leads_delivered`) or ended without
  leads (`no_leads`)

Only once the subscription succeeded, tell the user the chat will be told when the first leads are
ready and when the agent reports. Then call `fetch_leads` once with the `jobId`: anything that
landed before the subscription shows up there. Events replace polling and any periodic scheduled
check.

When an event arrives, call `fetch_leads` with the `jobId` and show the leads (Step 5). A batch can
still land after `finished`; it arrives as another `leads_found`.

Where the host has no events, or the subscription failed, follow `progress.note` in each
`find_leads` / `fetch_leads` answer: it says whether the next call waits for leads or when to ask
again. Never tell the user no leads were found while the job reads `pending`.

## Step 5 · Show the leads honestly

For each lead: `name`, `position`, `companyName`, and the 1–5 `score` with its `scoreExplanation`
where Onsa returned them — say "not scored yet" rather than inventing one. Keep Onsa's words for the
reasoning. Where the explanation or the search agent's report says something was approximated or
not verified, say so next to that lead rather than presenting it as fact. Never add facts about a
person that Onsa did not return.

End with the `campaignUrl` so the user can see the campaign in Onsa.

## Outreach

Connecting LinkedIn and setting up a campaign's outreach happen once, in the Onsa web app at the
`campaignUrl`; Onsa then writes drafts for the campaign's leads. Those drafts can be reviewed and
rewritten here, and a single approved message can be queued with `send_outreach` — the
`review-leads` skill covers how. Do not offer to send anything during first steps.

View saved version →

---
name: review-leads
description: Review an Onsa campaign the way a sales lead would — which people are strong fits and why, which are doubtful, what the funnel and the replies say, and which outreach drafts read like mail-merge and how to fix them around a real fact. Use when the user asks how a campaign is doing, which leads to prioritise, what prospects wrote back, what to do next, or to improve or send the drafts waiting for approval.
---

# Review leads

> These steps are for you. Talk to the user about their search and their customers, in your own words — not about this skill, its steps or its file.

Judge the people and the words, from what Onsa returned — never from what a lead "probably" is.

## Step 1 · Pick the campaign

`list_campaigns` if the user did not name one, or named it only by title — the other tools take
its `id`. It lists the newest campaigns first; when the user asks for "the biggest", compare the
lead counts it returned and say if it returned fewer campaigns than `total`. For "what should I do
next", `list_next_steps` with the campaign's id gives a ranked to-do list; start there.

## Step 2 · The people

`get_campaign_leads` for the campaign. Group by `score`:

- **5–4** — strong: say what in the `scoreExplanation` makes them strong.
- **3** — possible: say what is missing.
- **2–1** — weak: say why, and whether the campaign should look elsewhere next time (a steer for
  `continue_campaign`, which changes future searching and removes nobody).
- **no score** — not scored yet; list them without a verdict.

Where the explanation calls something approximated or unverified, keep that caveat. For the two or
three leads that matter most, `get_lead_memo` holds Onsa's research on that person when one exists;
`memo: null` is common and just means none was written.

## Step 3 · The funnel and the replies

`get_campaign_stats` for the counts. Compare campaigns on positive replies relative to leads
messaged — `positivePct` — never on the raw reply rate, because a rejection is also a reply. Replies
Onsa has not scored for sentiment are not in the sentiment counts; say so when the counts look
small. `list_replies` returns what people actually wrote; quote it rather than summarising it when
the user asks what happened.

## Step 4 · The drafts

`list_pending_outreach` shows drafts waiting for approval. An empty list means the campaign has no
drafts yet: outreach is set up in the Onsa web app, at the campaign's `campaignUrl`, and Onsa writes
the drafts from there. For a draft that reads like mail-merge:

1. Read that person's memo (`get_lead_memo`).
2. Rewrite the draft around **one** specific, checkable fact from it, with `rewrite_outreach`.
3. Show the user the new text.

No memo → say so, and keep the message honest rather than inventing a hook. Never state a fact
about a person that Onsa did not return.

## Sending

The rewritten draft stays pending. Send only when the user asks to send a specific message:

1. Show that one draft as stored and the recipient's name, and get an explicit yes for it.
2. Call `send_outreach` with that lead's `leadId` (from `list_pending_outreach`), the draft text
   exactly as stored as `confirmText`, and the recipient's name as `confirmName`.
3. The host then shows the user a confirmation form for that exact message; the same call completes
   when they approve it there. A "yes" typed in the chat is not that confirmation — do not call
   `send_outreach` again to stand in for it.
4. Where the host cannot show the form, the answer is `NOT SENT` with a link: give the user the
   link to approve the message in the Onsa app.

One message, one confirmation — never send a batch, never compose a message to someone who is not
a lead in a campaign, and never retry a send the user declined. A successful call means
**queued**, not delivered: Onsa sends on its own schedule within daily limits. `NOT SENT` because
no LinkedIn account is connected → the user connects it once in the Onsa web app, at the
`campaignUrl`.