{"id":77988,"plugin_id":"plugin_asdk_app_6ad841c2ce60819183cfc7876215511d","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-03T06:12:37.501Z","digest":"3254d6ac2b0a396525da5af1b9f62c6ab2e49c329de0812d09b70e26069c9c10","against":null,"payload":{"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\").","included_files":[],"name":"find-leads","skill_md_contents":"---\nname: find-leads\ndescription: 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\").\n---\n\n# Find leads\n\n> 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.\n\nA search spends the workspace's prospect allowance, so the query is agreed before it runs, and the\nresults are shown with what Onsa actually established about each person.\n\n## Step 1 · New search or an existing campaign?\n\n- \"More like these\", \"try another region\", \"stop including X\" → the campaign already exists: use\n  `continue_campaign` with that campaign's id. A new `find_leads` would split it into a separate\n  campaign with its own profile.\n- `continue_campaign` steers what the campaign looks for **next**. It removes nothing: leads\n  already found, and outreach already queued for them, stay. Say so when the user asks to drop\n  people, and point them to the campaign in the Onsa app to remove them.\n- Otherwise → a new search, Step 2.\n\nIf you do not know which campaigns exist, `list_campaigns` tells you. If the user has not used Onsa\nin this conversation yet, `list_next_steps` first: it says whether a search is already running or\nnew searches are blocked.\n\n## Step 2 · Restate the brief as a query, and get a yes\n\nWrite back, in one short block:\n\n```\nSEARCHING FOR\n  people:     <titles, including the variants that mean the same job>\n  companies:  <industry · size · geography · other observable traits>\n  excluding:  <what the user ruled out>\n```\n\nThen add one line for each requirement Onsa cannot see directly on a company or a profile — for\nexample a budget, a tool the company uses internally, or an intent to buy. Say it will be judged\nfrom indirect evidence, or left for the first conversation. A requirement nothing can show is a\nwish, not a filter.\n\nAsk for a yes or corrections. Skip the question only if the user already said to just run it, or\napproved this same brief moments ago in the `build-icp` skill.\n\nIf the user cannot describe who they want in a sentence or two, or wants the profile worked out\nfrom their past deals or a connected CRM, run the `build-icp` skill first.\n\n## Step 3 · Run it\n\n`find_leads` with the agreed query and the requested number as `limit` — an integer from 1 to 25\n(default 5); for more, say so and run it at 25. `limit` is a target, not a spending cap: every lead\nthat lands uses allowance. Or `continue_campaign` with the steer. Both return a `jobId`\nimmediately and run in the background.\n\nRead the answer before going on. A `billingWarning` goes to the user as written. A continuation\ncan answer without starting new work — for example when the steer only changed settings, or was\nalready answered — and its answer says so; do not re-send the same steer, and do not replace it\nwith `find_leads`.\n\n## Step 4 · Be told, don't watch\n\nWhere the host supports MCP events, subscribe this chat to `leads_search.leads_found` and\n`leads_search.finished` for the `jobId`. Only once that succeeded, tell the user the chat will hear\nabout the first leads and the agent's report; do not set up a periodic check. Then call\n`fetch_leads` once — anything that landed before the subscription shows up there. On each event,\ncall `fetch_leads` with the `jobId`. A batch can still land after `finished`.\n\nWithout events, or if the subscription failed, follow `progress.note` in the `find_leads` answer\nand in each `fetch_leads` answer — it says whether the next call waits for leads or when to ask\nagain. A job reads `pending` while it is still searching; never tell the user no leads were found\nwhile it is pending.\n\n## Step 5 · Present the leads with their evidence\n\nA table: `name`, `position`, `companyName`, `score` (1–5) and what the `scoreExplanation`\nestablishes — \"not scored yet\" where either is missing. Beside it, what is **not** established:\nanything the explanation or the search agent's report calls approximated, estimated or unverified,\nand any contradiction between a lead's own fields (for example a `position` and a `headline` that\ndisagree). Onsa's reasoning stays in Onsa's words; add no fact about a person that Onsa did not\nreturn.\n\nClose with the `campaignUrl`, and one line on what the user can do next: grow the campaign\n(`continue_campaign`), or review the people and drafts (the `review-leads` skill).\n\n## When the search ends without leads\n\n`leads_search.finished` with `no_leads`, or a `stalled` status, usually carries the search agent's\nown answer in `agentMessage` — often a question about the brief. Relay it, and offer to re-run with\nthe answer folded into the query. When there is no `agentMessage`, say the search ended without\nleads and without an explanation, and send the user to the `campaignUrl`.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}