agentleFS
buildfastwithaibuildfastwithai/gen-ai-experiments/skills/customer-finder-skill/customer-finder/SKILL.md

customer-finder

Skill790 starsChanged 4 months agoMITView on GitHub

Find and qualify evidence-backed potential first customers, early adopters, design partners, or beta users for a startup using recent public pain and buying signals. Use when Codex needs to analyze a product URL or idea, define an ideal customer profile, research public discussions and business pages, identify first-user prospects, rank lead fit and timing, prepare source-based outreach drafts, or create a shareable early-customer prospecting report without sending messages automatically.

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 18 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈18

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read references/research-framework.md before researching or scoring prospects.

    line 10
  2. Distinctive:

    Search current public sources for:

    line 23
  3. Distinctive:

    Use multiple query angles and source types.

    line 31
  4. Distinctive:

    Use public, intentionally shared professional or business information only.

    line 35
  5. Distinctive:

    Do not bypass login walls, paywalls, access controls, rate limits, or robots restrictions.

    line 36
  6. Distinctive:

    Do not use data brokers, leaked datasets, private groups, personal email discovery, phone enrichment, or sensitive personal information.

    line 37
  7. Distinctive:

    Do not infer protected traits or target people using health, financial hardship, political belief, sexuality, religion, or other sensitive …

    line 38
  8. Distinctive:

    Prefer companies, public professional profiles, public requests, and community posts relevant to the product.

    line 39
  9. Distinctive:

    Remove duplicates and weak matches.

    line 52
  10. Distinctive:

    Never claim that a prospect is interested, has consented, or will buy.

    line 54
  11. Distinctive:

    Write one short opener grounded only in the cited public context.

    line 59
  12. Distinctive:

    Avoid pretending to know the person, overstating familiarity, or mentioning unrelated personal details.

    line 60
  13. Distinctive:

    Do not send messages, submit forms, connect, follow, comment, or create CRM records unless the user separately requests and authorizes that …

    line 61
  14. Distinctive:

    Create a standalone HTML report unless the user explicitly requests chat-only output:

    line 75
  15. Very specific:

    Write structured JSON using references/report-artifact.md.

    line 77
  16. Distinctive:

    Verify prospect cards, source links, scores, patterns, outreach plan, and limitations.

    line 80
  17. Very specific:

    Use standard by default.

    line 92
  18. Distinctive:

    Prefer ten strong matches over a long generic lead list.

    line 97
  19. Distinctive:

    Keep outreach manual and respectful.

    line 100
  20. Distinctive:

    Treat the shortlist as a research hypothesis, not a customer database.

    line 101

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Customer Finder

Turn a startup URL or product description into a short, evidence-backed list of plausible first customers. Use public signals, preserve privacy, and distinguish a prospect from a confirmed buyer.

Read references/research-framework.md before researching or scoring prospects. Read references/report-artifact.md before creating the final report.

Workflow

1. Understand the product

  • Inspect the supplied URL, repository, landing-page copy, or product description.
  • Identify the product, outcome, buyer, user, price or buying motion, geography, and strongest use case.
  • Define one primary ICP, one adjacent ICP, pain triggers, positive signals, and disqualifiers.
  • Infer missing context when safe and label the inference. Ask one concise question only when ambiguity would materially change the search.

2. Build a public-signal search plan

Search current public sources for:

  • explicit tool or alternative requests
  • first-person descriptions of the target problem
  • manual workflows and repeated workaround complaints
  • migration, churn, or competitor-frustration signals
  • public company changes that create timing, such as hiring, launching, expanding, or adopting a relevant workflow

Use multiple query angles and source types. Prefer original pages over search snippets. Record the source URL, source type, publication date when visible, and the exact evidence supporting qualification.

3. Research safely

  • Use public, intentionally shared professional or business information only.
  • Do not bypass login walls, paywalls, access controls, rate limits, or robots restrictions.
  • Do not use data brokers, leaked datasets, private groups, personal email discovery, phone enrichment, or sensitive personal information.
  • Do not infer protected traits or target people using health, financial hardship, political belief, sexuality, religion, or other sensitive attributes.
  • Prefer companies, public professional profiles, public requests, and community posts relevant to the product.
  • Quote minimally and paraphrase by default. Link every material pain or timing signal.

4. Qualify and deduplicate

Score each prospect using the bundled framework:

  • pain strength
  • product fit
  • timing
  • public reachability
  • evidence quality

Remove duplicates and weak matches. A prospect without a cited pain, need, or timing signal is only a speculative fit and must not appear in the primary shortlist.

Never claim that a prospect is interested, has consented, or will buy. Label the output “potential customer based on public signals.”

5. Draft outreach, never send it

  • Recommend the most natural public or professional channel already associated with the source.
  • Write one short opener grounded only in the cited public context.
  • Avoid pretending to know the person, overstating familiarity, or mentioning unrelated personal details.
  • Do not send messages, submit forms, connect, follow, comment, or create CRM records unless the user separately requests and authorizes that action.

6. Produce the report

Lead with the most actionable evidence. Use this order:

  1. Verdict — whether the startup has reachable early-customer signals.
  2. ICP — buyer, job, trigger, and disqualifiers.
  3. Top prospect — strongest evidence-backed candidate and why now.
  4. Prospect shortlist — source, pain signal, fit score, stage, why now, channel, and opener.
  5. Repeated patterns — pains and triggers appearing across prospects.
  6. Seven-day outreach plan — a manual, low-volume validation sequence.
  7. Limits — missing evidence and what must be confirmed through real conversations.

Create a standalone HTML report unless the user explicitly requests chat-only output:

  1. Write structured JSON using references/report-artifact.md.
  2. Run scripts/generate_report.py <analysis.json> <report.html>.
  3. Save the report in the workspace outputs/ directory.
  4. Verify prospect cards, source links, scores, patterns, outreach plan, and limitations.
  5. Return a clickable absolute file link in the final response so it opens from Codex.

Modes

  • quick: Find and qualify up to five strong prospects.
  • standard: Find up to ten prospects across several public source types.
  • deep: Research up to twenty prospects and map repeated pain patterns.
  • design-partners: Prioritize users willing to test and give feedback over immediate buyers.
  • b2b: Prioritize companies, public business triggers, and relevant decision roles.
  • community: Prioritize public discussion and explicit request signals.

Use standard by default.

Quality bar

  • Link every prospect to at least one meaningful public signal.
  • Prefer ten strong matches over a long generic lead list.
  • Make uncertainty and stale evidence visible.
  • Personalize from the source, not from invented assumptions.
  • Keep outreach manual and respectful.
  • Treat the shortlist as a research hypothesis, not a customer database.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.