agentsclimarketplace

First customer finder

Skill mahesh-tws/first-customer-finder-claude/first-customer-finder

A Claude skill that finds evidence-backed potential first customers from recent public signals.

Install
npx -y skills add mahesh-tws/first-customer-finder-claude --skill first-customer-finder

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turns a startup URL, repo, or product idea into a qualified, evidence-backed shortlist of potential first customers using recent PUBLIC signals only -- demand, pain, workaround, switching, and timing signals found via web research. Defines the ideal customer profile, scores fit and timing, links every prospect to its public source, drafts respectful source-based outreach openers, and builds a polished standalone HTML report. Never sends outreach automatically and never enriches private contact data. Use this whenever the user asks to find first customers, potential customers, design partners, early adopters, prospects, or leads, or wants a customer-discovery / prospecting report for a startup, product, or pilot program -- even if they don't use the word "prospecting."

SKILL.md

8.0 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

First Customer Finder

Core principle

A prospect list is only as good as the evidence behind it. Every primary prospect must trace back to something they (or their company) actually, publicly said or did -- a forum post, a review, a job listing, a conference talk, a public GitHub issue -- with a link and a date. This skill never invents a plausible-sounding prospect from a demographic guess, and never treats "this company is probably in the target market" alone as a qualification. Public evidence of pain, demand, or timing is the bar.

This skill relies entirely on public web research (Claude's built-in web search/fetch) -- it does not scrape private data, use contact-enrichment services, or access anything behind a login wall. That's a hard boundary, not a style choice; see "Hard rules" below.

Modes

  • quick -- up to 5 strong prospects, fastest turnaround
  • standard (default) -- up to 10 prospects across several source types
  • deep -- up to 20 prospects plus repeated-pattern analysis across them
  • design-partners -- prioritizes people publicly describing the problem who seem likely to give product feedback, not just buy
  • b2b -- prioritizes companies and public business triggers (funding, hiring, expansion, migration) over individuals
  • community -- prioritizes explicit public requests and discussion threads (people asking "does anyone know a tool for X")

If the user doesn't specify a mode, default to standard and say so.

Workflow

1. Understand the product

Read the URL, repo, or description the user gave you. Identify: what problem it solves, for whom, and what the natural buying trigger looks like (a workaround failing, a compliance deadline, team growth past some threshold, a competitor's tool becoming a pain point, etc.). If given a bare URL, web_fetch it before doing anything else -- don't guess at the product from its name.

2. Define the ideal customer profile (ICP)

Use references/icp-framework.md. Produce:

  • Primary ICP -- who benefits most, has the pain acutely, and can plausibly buy or adopt soon
  • Adjacent ICP -- a secondary profile worth including if primary prospects run thin
  • Disqualifiers -- traits that make someone a bad fit despite surface similarity (wrong company size, no budget authority, problem already solved internally, etc.)

State this explicitly to the user before researching -- it's the filter everything downstream depends on, and it's worth a sanity check if the product description was thin.

3. Research public signals

Use references/signal-types.md for the five signal categories (demand, pain, workaround, switching, timing) and where to look for each. Search broadly, then narrow: forums and communities relevant to the ICP, review sites (G2/Capterra/TrustRadius-style pages for adjacent or competing tools), public job postings (a hiring push for a relevant role is a timing signal), engineering/product blogs, GitHub issues/discussions, conference talk listings, public social posts, press releases and funding news, and public RFPs/tenders for B2B or public-sector targets.

Scale search volume to the mode: quick/design-partners need fewer, targeted searches; deep needs broad coverage across most source types in signal-types.md. Every candidate prospect needs a specific piece of public evidence attached before it advances to scoring -- not just "seems like a fit."

4. Qualify and score

Use references/scoring-rubric.md for the fit score (0-5) and timing score (0-5) definitions. Score every prospect that survived step 3 with real evidence. Drop anyone who doesn't clear the disqualifiers from step 2, regardless of how good the signal looked.

5. Draft outreach openers -- draft only, never send

One draft opener per primary prospect, written per references/outreach-guidelines.md: reference the specific public thing they said or did, keep it short and respectful, no manufactured urgency, no personal information beyond what's professionally public. These are drafts for the user to review and send themselves -- this skill never sends a message, email, or DM on its own, under any mode, regardless of how the request is phrased.

6. Build the report

Assemble the evidence into a JSON structure matching the schema documented at the top of scripts/build_report.py, then run:

python3 scripts/build_report.py --data prospects.json --out outputs/first-customer-report.html

This renders references/report-template.html deterministically rather than hand-writing HTML fresh each time -- keeps formatting consistent and avoids broken markup on a report the user will actually open and click through.

7. State limitations plainly

Every report closes with a limitations section: sample size, how recent the signals are, which source types you didn't get to (if mode-limited), and the explicit reminder that these are hypotheses grounded in public signals -- not confirmed customers, and not a guarantee anyone buys.

Output

outputs/first-customer-report.html   -- the polished, standalone report
outputs/first-customer-report.json   -- the underlying evidence data

Report contents, in order: early-customer verdict, primary ICP and disqualifiers, highest-confidence prospect, full evidence-backed shortlist, fit/timing scores, source links and signal dates, draft outreach openers, repeated pain patterns (deep mode), a seven-day manual outreach plan, and research limitations.

Hard rules

  • Never send outreach automatically. Drafting an opener is in scope; sending an email, DM, or connection request is not -- that stays a separate, explicit action the user takes themselves, consistent with needing the user's clear go-ahead before anything gets sent on their behalf.
  • Never enrich private contact data. No personal emails, phone numbers, home addresses, or anything from a paid enrichment/data-broker service. Only use what's already publicly published in a professional context (company site, public post, public listing, public filing).
  • Never fabricate a prospect or a signal. If evidence is thin, exclude the prospect rather than padding the count to hit the mode's target number. A shortlist of 4 solid prospects beats 10 with 6 weak guesses.
  • Every primary prospect needs a working source link and a signal date. No "someone online said..." without a URL attached.
  • Don't compile sensitive personal data (health, religion, immigration status, etc.) even if it's technically publicly discoverable -- it's irrelevant to B2B fit and a needless privacy risk to carry into a report.
  • Prospects are hypotheses, not verified buyers. Say so in the report; don't let scoring language ("qualified," "high-confidence") imply more certainty than public signals can support.

Reference files

  • references/icp-framework.md -- how to build the primary/adjacent ICP and disqualifiers
  • references/signal-types.md -- the five signal categories and where to look for each
  • references/scoring-rubric.md -- fit score and timing score definitions
  • references/outreach-guidelines.md -- how to draft respectful, source-based openers
  • references/report-template.html -- the HTML template scripts/build_report.py renders into

What ships with it: 7 files

22.6 KB alongside SKILL.md, 1 of them executable

references/

scripts/

Gives 0 of the 12 instructions most sales audience skills give in ~1.6k tokens

Counted across 401 of the 401 authors here whose files we hold, read 2026-08-07

  • read product marketing context before asking questionsin 21 of 401, across 11 files
  • acknowledge competitor strengths honestlyin 18 of 401, across 7 files
  • start every page with a summaryin 15 of 401, across 4 files
  • Use a single, low-friction call to actionin 15 of 401, across 7 files
  • create a single source of truth for each competitorin 14 of 401, across 3 files
  • Make each follow-up email add new valuein 11 of 401, across 5 files
  • Cut any sentence that does not drive a replyin 10 of 401, across 4 files
  • Tie personalization directly to the problemin 10 of 401, across 4 files
  • write paragraph comparisons for each dimensionin 9 of 401, across 3 files
  • link between related competitor pagesin 9 of 401, across 3 files
  • Keep subject lines short and lowercasein 9 of 401, across 3 files
  • Define ideal customer profile from top customersin 9 of 401, across 3 files

Said here and by no other author read

  • fetch the URL before researching the product
  • state the ideal customer profile before researching
  • attach specific public evidence to every prospect
  • score every surviving prospect for fit and timing
  • drop prospects failing the disqualifiers
  • draft one outreach opener per prospect

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.