Update to Onsa

{
  "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.",
  "included_files": [],
  "name": "get-started",
  "skill_md_contents": "---\nname: get-started\ndescription: 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.\n---\n\n# Get started with Onsa\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\nOnsa finds real B2B prospects — people with LinkedIn profiles — scores each one 1–5 against an\nideal-customer profile with the reasoning written out, and keeps every search as a campaign.\n\n## Step 1 · Read the workspace before asking anything\n\nCall `list_next_steps` with no arguments and follow what it says. The usual cases:\n\n- **A search is already running** → say so, give its `jobId`, and go to Step 4 for that job. Do\n  not start a second search.\n- **New searches are blocked** (trial ended, allowance used up, no active subscription) → relay\n  that blocker in the tool's own words. Do not start a search, and do not offer any purchase or\n  upgrade. What the workspace already holds stays readable: offer to review its campaigns, leads\n  and replies (the `review-leads` skill) if it has any.\n- **The workspace has campaigns** → name the most useful one or two in a line each and ask\n  whether to continue one of them or start a new search.\n- **The workspace is new** → Step 2.\n\nIf the answer says it could not tell whether a search is running, say that, and ask before\nstarting one.\n\n## Step 2 · The two lines a search needs\n\nAsk in one message:\n\n> 1. Who do you want to reach? (the role, the kind of company, size, geography)\n> 2. Who should Onsa never include? (segments, geographies, company types — \"none\" is fine)\n\nAdd one line to that message: *\"Not sure yet? I can work it out with you from your past deals —\nincluding from your CRM, if one is connected here.\"* If the user takes that offer or answers\nvaguely (\"SMBs\", \"anyone who needs sales\"), run the `build-icp` skill. When it comes back with an\napproved profile and the user chose to search now, continue at Step 3 with that profile as the\nbrief — it is already approved, so do not read it back again.\n\nUse the user's own words. Do not invent an audience, and do not fill it in from what their company\nseems to sell: a search spends the workspace's prospect allowance, and a guessed brief spends it on\nthe wrong people. If a brief the user has not yet approved is already in this conversation, read it\nback in one line and get a yes before using it.\n\n## Step 3 · Start the search\n\nCall `find_leads` with the brief as `query` and the number of people asked for as `limit` — an\ninteger from 1 to 25 (default 5); for more, say so and run it at 25. `limit` is a target, not a\nspending cap: every lead that lands uses allowance. It returns a `jobId` at once; the search itself\nruns in the background, first leads usually within about 5 minutes.\n\n## Step 4 · Have the search report back\n\nWhere the host supports MCP events, subscribe this chat to both events for the `jobId`:\n\n- `leads_search.leads_found` — each batch of leads as it lands\n- `leads_search.finished` — the agent posted its report (`leads_delivered`) or ended without\n  leads (`no_leads`)\n\nOnly once the subscription succeeded, tell the user the chat will be told when the first leads are\nready and when the agent reports. Then call `fetch_leads` once with the `jobId`: anything that\nlanded before the subscription shows up there. Events replace polling and any periodic scheduled\ncheck.\n\nWhen an event arrives, call `fetch_leads` with the `jobId` and show the leads (Step 5). A batch can\nstill land after `finished`; it arrives as another `leads_found`.\n\nWhere the host has no events, or the subscription failed, follow `progress.note` in each\n`find_leads` / `fetch_leads` answer: it says whether the next call waits for leads or when to ask\nagain. Never tell the user no leads were found while the job reads `pending`.\n\n## Step 5 · Show the leads honestly\n\nFor each lead: `name`, `position`, `companyName`, and the 1–5 `score` with its `scoreExplanation`\nwhere Onsa returned them — say \"not scored yet\" rather than inventing one. Keep Onsa's words for the\nreasoning. Where the explanation or the search agent's report says something was approximated or\nnot verified, say so next to that lead rather than presenting it as fact. Never add facts about a\nperson that Onsa did not return.\n\nEnd with the `campaignUrl` so the user can see the campaign in Onsa.\n\n## Outreach\n\nConnecting LinkedIn and setting up a campaign's outreach happen once, in the Onsa web app at the\n`campaignUrl`; Onsa then writes drafts for the campaign's leads. Those drafts can be reviewed and\nrewritten here, and a single approved message can be queued with `send_outreach` — the\n`review-leads` skill covers how. Do not offer to send anything during first steps.\n"
}