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.
In this repository9 other files it gives its agents.
- crazy-ecommerce-builderSkill
- html-game-generatorSkill
- landing-page-generatorSkill
- launchauditSkill
- premium-ui-revampSkill
- react-screenshot-recreatorSkill
- startupblueprintSkill
- talking-avatarSkill
- test-strengthSkill
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
- Distinctive: line 10
Read references/research-framework.md before researching or scoring prospects.
- Distinctive: line 23
Search current public sources for:
- Distinctive: line 31
Use multiple query angles and source types.
- Distinctive: line 35
Use public, intentionally shared professional or business information only.
- Distinctive: line 36
Do not bypass login walls, paywalls, access controls, rate limits, or robots restrictions.
- Distinctive: line 37
Do not use data brokers, leaked datasets, private groups, personal email discovery, phone enrichment, or sensitive personal information.
- Distinctive: line 38
Do not infer protected traits or target people using health, financial hardship, political belief, sexuality, religion, or other sensitive …
- Distinctive: line 39
Prefer companies, public professional profiles, public requests, and community posts relevant to the product.
- Distinctive: line 52
Remove duplicates and weak matches.
- Distinctive: line 54
Never claim that a prospect is interested, has consented, or will buy.
- Distinctive: line 59
Write one short opener grounded only in the cited public context.
- Distinctive: line 60
Avoid pretending to know the person, overstating familiarity, or mentioning unrelated personal details.
- Distinctive: line 61
Do not send messages, submit forms, connect, follow, comment, or create CRM records unless the user separately requests and authorizes that …
- Distinctive: line 75
Create a standalone HTML report unless the user explicitly requests chat-only output:
- Very specific: line 77
Write structured JSON using references/report-artifact.md.
- Distinctive: line 80
Verify prospect cards, source links, scores, patterns, outreach plan, and limitations.
- Very specific: line 92
Use standard by default.
- Distinctive: line 97
Prefer ten strong matches over a long generic lead list.
- Distinctive: line 100
Keep outreach manual and respectful.
- Distinctive: line 101
Treat the shortlist as a research hypothesis, not a customer database.
≈ “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.
Files
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:
- Verdict — whether the startup has reachable early-customer signals.
- ICP — buyer, job, trigger, and disqualifiers.
- Top prospect — strongest evidence-backed candidate and why now.
- Prospect shortlist — source, pain signal, fit score, stage, why now, channel, and opener.
- Repeated patterns — pains and triggers appearing across prospects.
- Seven-day outreach plan — a manual, low-volume validation sequence.
- Limits — missing evidence and what must be confirmed through real conversations.
Create a standalone HTML report unless the user explicitly requests chat-only output:
- Write structured JSON using
references/report-artifact.md. - Run
scripts/generate_report.py <analysis.json> <report.html>. - Save the report in the workspace
outputs/directory. - Verify prospect cards, source links, scores, patterns, outreach plan, and limitations.
- 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.
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
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.

