Update to Dopia

{
  "description": "Turn a product URL into an evidence-backed prospect list. Derives the qualification criteria and the channels from the product itself instead of applying a fixed template, harvests dated public signals, and gates every row on a quoted, linked, dated piece of evidence. Produces a list plus a corpus of the buyer's own words. Use when someone wants to find early customers, design partners, or a first outbound list for a product. Does not write or send outreach.",
  "included_files": [
    {
      "relative_path": "references/artifact-schema.md",
      "size_in_bytes": 10702
    },
    {
      "relative_path": "references/channels.md",
      "size_in_bytes": 11591
    },
    {
      "relative_path": "references/derivation.md",
      "size_in_bytes": 9024
    },
    {
      "relative_path": "references/extraction.md",
      "size_in_bytes": 10104
    },
    {
      "relative_path": "references/gates.md",
      "size_in_bytes": 27047
    }
  ],
  "name": "find-prospects",
  "skill_md_contents": "---\nname: find-prospects\nargument-hint: <your product or company URL>\ndescription: Turn a product URL into an evidence-backed prospect list. Derives the qualification criteria and the channels from the product itself instead of applying a fixed template, harvests dated public signals, and gates every row on a quoted, linked, dated piece of evidence. Produces a list plus a corpus of the buyer's own words. Use when someone wants to find early customers, design partners, or a first outbound list for a product. Does not write or send outreach.\n---\n\n# Find prospects\n\nMost prospecting tools sell rows from a database: name, title, company, email.\nThose rows carry no date, no reason to talk, and no way to check whether they are\nstill true. This skill produces a different row: **a person, a dated public thing\nthey said or did, a link to it, and why that makes now the moment.** Every claim in\nthe output can be clicked back to its source.\n\n🔴 **The one standard everything else serves: every row must be someone who could\nplausibly pay for this product.** Not someone interesting, not someone who\ndescribed the problem well, not a company that merely fits the shape — someone\nwhose money could end up in the operator's account. That is the entire value\ndelivered, so it is the entire basis for judging the output.\n\nTwo things follow from it that are easy to skip. **Could pay means could pay at\nthe subject's own prices and on its own terms** — someone the subject's\npublished limits exclude, or whose whole need its free option already covers,\nis not a buyer however well they describe the problem. And **where the site\nshows that customers arrive through someone else**, the person who sends them is\nhow that money arrives, so they are worth finding by the same standard — in a\ngroup of their own, never mixed in with the buyers.\n\nTwo consequences run through every phase below. **A competitor is worth less than\nnothing** — their probability is zero and their presence makes the operator\ndistrust every other row, so no quality of evidence rescues one. And **how likely\nis not yours to decide** — a plausible buyer at low probability costs the\noperator one message, so rank by likelihood and let them draw their own line\nrather than cutting on their behalf.\n\nThe part that makes the output non-generic is **not** the searching. It is\nderiving *what to qualify on* from *what the product is worth*. Any skill that\nhardcodes a check only works for products that happen to share that check. Derive\nit; do not inherit it.\n\n## What this needs\n\nCapabilities, not specific tools. Use whatever the host provides.\n\n| Capability | Used for | If missing |\n|---|---|---|\n| Fetch a public web page | product teardown, company checks | the skill cannot run |\n| Web search | finding channels and posts | degrade to known registries only |\n| A browser the host provides | any page plain fetch cannot read, and every lane on a platform that carries people's identities — those are browser-first, not browser-as-fallback | **say in Phase 3 which derived lanes this kills and what is left**, then run the short version knowingly |\n| Write a local file | the report | print the report instead |\n| An artifact tool *(optional)* | publishing the list as a shareable page | stop after the local file |\n| A CRM tool *(optional)* | writing qualified rows as records | stop after the report |\n\n## Boundaries\n\n- **Prospecting only.** Do not draft, send, connect, comment, follow, or message.\n  The output is a list and a corpus. Judge this skill on list quality, never on\n  reply rate.\n- **Public sources.** Marketplace reviews, support forums, trade communities,\n  company websites — pages a person can open without an account. That is where\n  the evidence this skill needs actually lives.\n- **Never handle credentials, never defeat a login wall.** Do not ask for, accept,\n  store or type a password, and do not work around anything a site put in front\n  of its content to keep people out. If a page is gated, take another lane.\n- **If the host gives you a browser, it is a normal way to read a page, not a\n  last resort.** A browser extension or the host's own browser tools — when one\n  is available, use it the moment a plain fetch comes back empty or 403. Plenty\n  of ordinary public pages only render in a real browser: review sites and job\n  boards that build the page client-side.\n  Reaching for it needs no permission, and `references/extraction.md` has the\n  escalation. **Do not log a lane as \"not available\" when a browser is sitting\n  right there** — that is the most common way this skill under-delivers.\n- **Reading only, at human pace.** Never act on a platform on anyone's behalf: no\n  sending, connecting, following, commenting, or collecting at machine speed.\n  Automated collection conflicts with the terms of most platforms, and reading\n  inside a session someone already opened is the conservative end of that rather\n  than an exemption. Say in the output header when a browser was used.\n- 🔴 **The platforms that carry people's identities are browser work, and that is\n  the first choice rather than the fallback.** Where a platform is absent from\n  search results *and* forbids automated collection — the professional networks,\n  the microblogs, the big community sites mostly are both — read it in the\n  operator's own browser, at the pace a person reads, or do not run the lane.\n  Do not enumerate it with a fetcher on an interval you picked because it felt\n  polite: **the rate limit is not the rule, the terms are**, and a run that\n  discovers this by being throttled has already done the thing it should not\n  have. A fetcher is fine for a site's public feed or API; it is not a way into\n  a platform that publishes neither.\n\n  This is also simply the better lane. In the operator's own session you see\n  what they would see — their network, their logged-in search, the profile that\n  tells you whether this is the right person — and the identity these platforms\n  carry is the thing the whole list is short of. Say in Phase 3 which lanes this\n  makes browser-only, and if no browser was provided, say what the list cannot\n  contain because of it rather than substituting a keyword search that returns\n  lookalikes from other hosts.\n- **One question, maximum.** Ask the operator only if two readings of the product\n  would send you to completely different channels. Otherwise infer, and label the\n  inference.\n\n## Phase 1 — Take the product apart\n\nFrom the URL: the outcome sold, who signs versus who uses, the buying motion\nvisible on the page, the geography, the strongest use case. Read the pricing page\nand the docs if they exist.\n\n**Read the subject's own limits, because they draw the edge of who can buy.**\nEvery seller publishes some: what each paid tier is built for (its usage cap,\nits seat count, the size of customer it names), a minimum the intake form asks\nfor, who is eligible, where it is allowed or able to operate, what its customers\nmust already run. Write each one down with the page it came from, and mark it\nhard or soft. A **hard** limit is one the subject enforces — a required minimum\non a form, \"we do not accept\", a licence that names where it may operate. A\n**soft** one describes who usually buys — \"ideal for\", \"most of our clients\".\nHard limits set gate 3's band, and a row outside one is out. Soft limits only\norder the list.\n\nThen work out **the smallest customer the cheapest paid option is for**. Where\nthe product has a free tier, a free self-hosted edition or a trial that never\nends, the people whose whole need that covers are its audience and not the\nlist's: the band starts where a paid option is the one that fits. Where the site\nstates none of this, write that the band is inferred, and from what.\n\n**Read how customers reach the subject, as well as who pays.** Some businesses\nare sent most of their customers by someone who never pays them: an adviser who\nrecommends, an agent who introduces, a partner who resells or installs. The site\nsays so when it is true — a referral or partner programme, a page addressed to\nthe people who refer, testimonials written by them rather than by customers, a\nportal for them to log in to. When it does, those introducers are a second\npopulation, and Phase 2 derives a gate for them too. **When the site shows\nnothing of the kind there is no second list** — do not supply one from what you\nknow about the industry.\n\n**Read the customer list too — the logo wall, the case studies, the\ntestimonials.** The pattern in it is the most reliable thing Phase 1 produces:\nit is who actually buys, against which your ICP hypotheses are a guess. It also\ngives an exclusion list, though how much that is worth scales inversely with how\nmany customers the subject has — fourteen logos against a hundred thousand\ncustomers excludes nothing, and `references/gates.md` says what to do instead.\nAnd a customer that has just been acquired, renamed or taken over is not a cold\nrow but an expansion or a save, which belongs in its own group. What the list is\n*not* is buyer voice.\n\n**Write down what the subject can already see — but only where the site says so.**\nSome subjects sell into one concentrated market and watch it closely: customer\nlogos clustered in one region, offices there, the local trade press quoting them,\nthe same three conferences on the site. Rows from inside that concentration are\nones they may already know, and Phase 6 says what that does to the order.\n\n🔴 **This is a fact to read, never a fact to infer.** The evidence is the customer\nlist, the office locations, the press and events the site itself names. **When\nthat evidence is not on the site, write \"unknown\" and skip the demotion\nentirely.** Do not reach for the operator's language, the files open around you,\nthe workspace you are connected to, or anything else about the session — none of\nthat is public information about the product, and a run started from the same URL\nby anyone else would not see it. Inventing a home market invents a whole lane\nthat was never checked, and then reports it as a limitation, which reads as\ndiligence and is fiction. If it matters and the site is silent, this is a fair\nuse of the one question the skill is allowed to ask: which channels do you\nalready watch?\n\nWrite two ICP hypotheses. Each needs a pain statement **in the buyer's own words**\nand explicit disqualifiers.\n\n## Phase 2 — Derive the qualification criteria\n\nRead `references/derivation.md` and follow the chain:\n\n`product value → what must be true of a company for that value to land → the\npublicly observable proxy for that condition → the cheapest check for that proxy`\n\nThis phase outputs **the content of gate 4**. Gates 1, 2 and 5-7 are fixed. Gate 3\nis fixed in form, and its band is the one Phase 1 read off the subject's own\nlimits. Gate 4 is always derived, and it is the gate that decides whether the\nlist is any good. Write the derived chain into the report header so the operator\ncan argue with it.\n\nWhere Phase 1 found that customers arrive through introducers, run the chain a\nsecond time from their side: what sending a client here does for the\nintroducer, what must be true of an introducer for that to land, the proxy, the\ncheck. Introducer rows then pass every other gate exactly as buyer rows do —\ndated evidence, a verified domain, a route to a person — and gate 7 still bites:\nan introducer who does the subject's own work is a competitor, not a partner.\n`references/derivation.md` has the details.\n\n## Phase 3 — Derive the channels, and classify each\n\nRead `references/channels.md`. Two rules do most of the work:\n\n1. **Prefer sources where the qualification is already a structured field** over\n   sources where it must be inferred from prose. Search infers; registries read.\n2. **Label every channel a lead source or a corpus source.** Identity strength and\n   pain strength run opposite to each other; a channel rarely gives both.\n\n**Then probe each derived lane once, before committing to the plan.** One\nrequest per lane, asking only whether it can be read at all. Sites put up login\nwalls and bot walls on their own schedule, so a lane's reachability is a fact to\ndiscover on the day, never a fact to remember — and the surfaces that carry\nidentity are the ones most often gated.\n\nSay what the probe found in the output header: which lanes are live, which are\nbrowser-only (by gating or by terms), which need a browser the host has not\nprovided, and what the list therefore cannot contain.\nAn operator told this at the start can authorize a browser or accept a shorter\nlist; an operator told at the end has been handed a disappointment with an\nexplanation attached.\n\n## Phase 4 — Harvest\n\nRead `references/extraction.md` before the first fetch. Public pages go through\nplain fetching; session-gated and client-rendered pages go through the browser.\n**When a plain fetch fails, escalate to the browser and ask the operator to\nauthorize that domain** — escalation is roughly a third of all fetches, so it is a\nmain path, not an error branch.\n\nGive every lane a probe budget, and run the lanes in parallel where the host has\nsub-agents; `references/extraction.md` has both.\n\n**Budget for the yield, and say what the budget buys.** Candidates survive the\ngates at roughly one in ten — it has run between six and twelve in one across\nrecorded runs — so a list of fifteen rows needs to see something like a hundred\nand fifty candidates. Work out what the available budget can actually see before\nharvesting, and if that is short of what was asked for, say so then. A thin list\ndelivered without that sentence reads as \"there is nobody out there\", which is a\ndifferent and much more damaging claim than \"this is what an hour buys\".\n\nWhere the whole population is small — a few hundred licensed firms, one city's\nworth of a trade — the constraint is the universe rather than the budget. Then\nthe honest output is the short list *and* the size of the universe it came from,\nwhich is a finding in its own right.\n\nLog every query, including the ones that returned nothing.\n\n## Phase 5 — Gate, then score\n\nRead `references/gates.md`. Apply the eight hard gates in order, cheapest first,\nthen score survivors on six axes, reported separately. A row without a dated,\nlinked quote and without a working link never enters the list, however promising\nthe person looks. Never pad a list to reach a target count — a short honest list\nis the product.\n\n**Cut on category, rank on probability.** The gates answer one question: could\nthis ever be a customer? Peers, existing customers and wrong verticals are zero\nand they go, whatever their evidence looks like. Everything that clears that bar\nships, ordered by purchase likelihood, because the operator sets their own\nthreshold and cannot see what you removed. Cutting a real buyer for being a long\nshot is the quieter half of padding, and it costs them a customer rather than an\nemail.\n\nTwo things are category, not probability. **A row outside a hard limit** from\nPhase 1 is someone the subject would turn away, so it goes. And **a row whose own\nwords say they will not pay for this kind of thing** — they chose the free\noption, a self-hosted edition or a spreadsheet, and gave the price as the reason\n— carries evidence against buying, not for it. Its quote belongs in the corpus\nas an objection, and the row does not ship.\n\n**Then check the list against who actually pays.** People who talk in public\nskew small — the individual, the side project, the newest firm — so an\nevidence-first harvest drifts toward the vocal end of a market rather than the\npaying end. Lay the surviving rows against the paid tiers and the customer list\nfrom Phase 1. If most rows sit at or below the cheapest paid option while the\ncustomers sit well above it, the lanes found the wrong end. Go back to Phase 3\nfor lanes where the paying segment leaves a record — registries, filings, job\nposts, directories of firms that size — or, if the budget is spent, say in the\nheader what the list skews toward and why.\n\n**Gate 8 is the one that decides whether this was useful.** A row has to carry a\nroute to a human: a named person with their own profile or published address, or\nfailing that a real inbox or form the business publishes itself. A company domain\nis not a contact — it is the research the operator came here to avoid, handed\nback to them.\n\nExpect to spend real effort here, and expect it to be ordinary public pages: the\nsite's contact and about pages, the footer, and for a Shopify store the\nauto-generated `/policies/contact-information`, which is where an anonymous\nreviewer's shop is obliged to publish a real address. **Never guess an address\nfrom a pattern.** A row whose route cannot be found does not ship in the list;\nput it in a short \"needs a name\" section instead and say what is missing.\n\n## Phase 6 — Deliver\n\nWrite `prospects-<date>.md` containing:\n\n1. **Header** — the product read, both ICP hypotheses, the subject's limits with\n   the band they set and the page each came from, the derived chain and gate 4\n   verbatim (and the introducer chain, if there is one), and the platform-terms\n   note.\n2. **The list** — per person: name, profile link, company, domain, **how to reach\n   them and which page that was read off**, the evidence and whether it is the\n   buyer's words or a dated event, its date, its link, the lane, the six scores,\n   and one line of why now. The contact is not a footnote: it is the difference\n   between a list and a reading assignment, and it is what anything that comes\n   after this — a message, a record, a call — starts from.\n\n   **Order by purchase likelihood first, then by the axis the operator has least\n   visibility into.** They are paying for reach past what they can already see,\n   but they are paying for it in order to find someone who will buy — so a group\n   nobody will buy from does not lead just because it was hard to find. Where\n   rows would buy at clearly different sizes, likelihood and size order the list\n   together: a row likely to take the cheapest paid tier does not lead one a\n   little less likely to buy at ten times that. Put on each row the tier or deal\n   size you expect and what on the page you read it from. Evidence in the buyer's own words leads events either way,\n   and existing-customer rows are a different conversation, so they group apart.\n   So are introducer rows: they are asked for referrals, not a purchase, and\n   they come after the buyers.\n   Beyond that the axis depends on the subject:\n\n   - Where Phase 1 found evidence of a concentrated home market, that is the\n     axis: rows from the trade press they read every week go in a group that\n     says so, and do not lead. **Demoted still means delivered** — run the lane\n     and group it, do not quietly skip it, and if the budget forces you to cut\n     it, say that you cut it and what it would likely have held. **If almost\n     every row lands in that group, the channel derivation failed, not the\n     list** — go back to Phase 3.\n   - Where Phase 1 found no such evidence, or the subject sells to its whole\n     market at once, that axis does not exist and demoting by it would demote\n     everything. Use the gate-4 sub-result instead — who has nothing in place\n     versus who is running a competitor — which is what the operator cannot see\n     from outside.\n3. **The close calls, in two short sections the operator can overrule.**\n   - **Judged a peer.** Anyone gate 7 removed whose category sits next to the\n     operator's rather than on top of it. The gate is a rule of thumb about how\n     outreach will be read, and the operator knows their own neighbours; list\n     the name, what they sell and the one sentence that decided it.\n   - **Still listed, outside the window.** A signal that is demonstrably live but\n     older than gate 1 allows. Give its age in days and let them decide, rather\n     than dropping silently what may be the strongest fit on the page.\n\n   Both sections were invented by runs that needed them. Keep them short; a row\n   that belongs in the list belongs in the list.\n4. **The corpus** — quotes from corpus-source channels grouped by the pain they\n   express. This is the buyer's own vocabulary, and it is how you check whether\n   gate 4 was derived correctly.\n5. **Query log** — channel, exact query, candidates surfaced, candidates survived.\n   Mark the dead queries; they are how the next run improves.\n6. **Limits** — sample size, what was not verified, which rows are inferences.\n\n## Phase 7 — Offer the two things only a connected workspace can do\n\nThe list is delivered. Now say, in two lines, what can happen to it — because\nsomeone who typed a bare request has not been given the chance to want either,\nand both of these are things the operator would have to know the product to ask\nfor:\n\n1. **Records.** \"Want me to create Company and Contact records for these, with\n   the quote, its date and its source link on each one?\"\n2. **A page.** \"I can also publish this as a page with its own link — something a\n   teammate can open, or you can send to someone who was never in this\n   conversation.\"\n\nOffer only what is actually connected, and name the thing rather than the tool:\n\"create records\" and \"publish a page\", never \"call create_artifact\". Make the\noffer once, plainly, at the end. Do not ask twice and do not nag.\n\n**Then do it when they say yes, and do neither before that.** Writing records\ninto someone's workspace uninvited is the kind of thing that makes a person\nuninstall a plugin.\n\n### Publishing\n\nRead `references/artifact-schema.md` and follow it exactly. The field names there\nare a contract with a live renderer: a field spelled differently does not appear\non the page, and nothing warns you.\n\nCall the artifact tool with `kind` set to `prospect_list`, plus `title`,\n`subject_name`, `subject_url`, and `payload` as the structured object. Never pass\nHTML or markdown inside the payload. Relay the link it returns.\n\nTwo things worth repeating from the schema, because getting them wrong is\ninvisible until someone opens the page:\n\n- **Everything about how the run was done goes under `payload.provenance`** — the\n  derivation chain, the lanes, the query log, the per-row scores. The server\n  strips that key before the page is served. The reader came for people to talk\n  to, not for your method.\n- **Every id in a group's `row_ids` must exist in `rows`**, and a row no group\n  names is never rendered.\n- **`headline.facts` are facts about the people, never about the run.** How many,\n  what they have in common, what they are complaining about, how recent it is.\n  Claims that the work was thorough go in `verification`, which renders small at\n  the bottom next to the disclaimer.\n\n### Records\n\nCarry the evidence across: the quote, its date, its source link and the lane\nbelong on the record, not just the name and company. A row that arrives without\nits evidence is indistinguishable from a bought row a week later.\n\nRecords and artifacts are different things and one is not a substitute for the\nother. An artifact is a document about a moment; a record is a row someone will\nkeep editing. Publishing the artifact never creates records.\n\n## Extending this skill\n\nWhen a run teaches you something, write **the principle**, then the specifics as\nlabelled examples with the kind of buyer they came from. A rule that carries one\nrun's furniture — the sites it used, the job titles it searched, the thresholds\nit set — reads as a law and breaks on the next product. Three rules here have\nalready had to be rewritten for exactly that reason: a source ranking that held\nfor one occupation, an event shape that only exists at large employers, and an\nordering rule that assumed the operator sells outside their own market.\n\nThe test before adding a rule: **name the product it would be wrong for.** If\nnone comes to mind, the rule has not been thought through yet.\n\n## Failure modes that have actually happened\n\n- **Searching a problem keyword and harvesting vendors.** People who post about a\n  problem are usually selling the solution. On identity platforms, search events.\n- **Taking a quoted sentence as the speaker's own position.** On anything\n  threaded — forums, comment sections, reply chains — a comment often opens by\n  quoting the thing it is about and then argues *against* it. Lifting those words\n  attributes to a practitioner a complaint they were rebutting. Before quoting\n  from a thread, check whether the sentence is the commenter's or someone\n  else's: leading quotation marks, a `>` prefix, or a following sentence that\n  disagrees with what was just said.\n- **Mistaking fluency about the problem for need.** The clearest description of a\n  pain usually comes from whoever sells the cure. See gate 7.\n- **Harvesting a comment section whose author sells to the wrong audience.**\n  Commenters inherit the author's audience. Check who the author sells to first.\n- **Picking the community where the topic is discussed instead of the one the\n  buyer lives in.** A builders' forum is full of builders, not buyers.\n- **Letting a generic word poison a query.** A product name that is also an\n  ordinary word needs a context word bound to it.\n- **Treating a fetch failure as a dead lead.** It is a routing decision, not a verdict.\n- **Dressing an event up as a complaint.** When no one says anything in public,\n  a sentence gets lifted from a press release into the quote field and the row\n  now implies a grievance nobody has. Ship the event as an event.\n- **Quoting the subject's own testimonials back at them.** They wrote those. That\n  page is evidence of who buys, and a partial exclusion list — never buyer voice.\n- **Opening on the buyer's home market.** The local trade press is the easiest\n  lane to harvest and the one the operator reads every week, so it is the fastest\n  way to hand back work they had already done.\n- **Searching the words the product's marketing uses.** They are the category's\n  SEO keywords: the results are the subject, its competitors, and the template\n  libraries their content teams publish. Bind the work-words to a host, a role\n  title, or a regulated artefact name.\n"
}