find-idea
Skill2 starsChanged 42 days agoMITView on GitHub
Find or sharpen a startup product idea by mining the internet for evidence that real people are already paying to escape a specific pain. Use when the user has no idea yet and wants somewhere to start, when the user has an idea that is still vague and needs sharpening or narrowing, or when the user says "find me a startup idea" / "what should I build" / "brainstorm product ideas" / "is anyone actually paying for this" / "help me find a niche". Runs upstream of phase 0 of the solo-sdlc pipeline and hands a shortlist to product-critic at phase 1.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Latifox/find-me-saastheir own version, first seen Sep 6, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- Latifox/find-me-saas★ 10same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
If a candidate did not come out of something somebody actually wrote, it does not go in the shortlist — no matter how good it sounds.
- Distinctive: line 29
All three are wins. Say which one happened, bluntly.
- Very specific: line 31
Run market-first. Do not interview the user about their skills, budget or audience — if they volunteered constraints, honour them.
- Very specific: line 116
Read references/screening.md in full, then apply it: the willingness-to-pay ladder, the competition shapes, the solo+AI kill flags, the …
- Very specific: line 128
When phase 1 later returns GO, the scan moves into docs/business/ beside the validation.
- Distinctive: line 143
Default 2–3. One is a fine answer.
- Distinctive: line 152
No quote, no idea: Every candidate traces to ≥3 fetched, dated, quoted records from ≥2 lanes.
- Very specific: line 165
Do not do
product-critic's job: No TAM model, no full unit economics, no risk register, no verdict.
≈ “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
find-idea — evidence first, idea second
Most idea brainstorming runs backwards. It invents plausible products, then goes looking for support. A language model is extremely good at the inventing half, which is exactly the problem: the output is fluent, confident, and indistinguishable from a real finding.
This skill runs the other direction. Collect dated, quoted, linked complaints from real people first. Cluster them. An idea is only ever allowed to exist as the answer to a cluster. If a candidate did not come out of something somebody actually wrote, it does not go in the shortlist — no matter how good it sounds.
The target is a pain that (a) many people have, (b) somebody is already paying to escape, and (c) is either unserved, badly served, or newly serveable. Not a pain nobody has addressed — an untouched market is usually untouched because it is not a market.
Two modes
Detect from what the user said; ask one question only if genuinely unclear.
- Cold start — no idea at all. Start by choosing hunting grounds, not ideas.
- Fog — an idea exists but is vague. Take it as a search hypothesis, not a conclusion. The usual outcome is that the idea survives narrowed to a segment it wasn't aimed at, splits into sharper variants, or dies while the search surfaces the real pain next door. All three are wins. Say which one happened, bluntly.
Run market-first. Do not interview the user about their skills, budget or audience — if they
volunteered constraints, honour them; otherwise let the evidence decide and let
product-critic test founder fit at phase 1.
Workflow
1 · Frame the search
Cold start — pick 3–5 hunting grounds. A hunting ground is not an idea; it is a specific occupation or workflow where all three hold:
- Money already moves — the people there have budgets, invoices, or salaries attached.
- They complain in public — there is a searchable board, sub, or review corpus. A profession that only talks in private Slacks cannot be mined and cannot be sold to either.
- It is boring — unglamorous enough that funded teams skip it. Glamour attracts capital, capital attracts competition, and one person loses that race.
Bias toward operational back-office work, regulated paperwork, trades and field services, niche professional practices, and long-tail plugin ecosystems. Pick grounds that don't overlap so the lanes don't return the same thing four times.
Fog — decompose the user's idea into: problem · who has it · mechanism · why now. Turn each blank or shaky one into a search question. Then hunt the problem, never the solution — searching for the product they imagined only ever finds competitors.
Show the grounds or the search questions in three lines and let the user redirect once. This is a checkpoint, not a gate — proceed if they say nothing useful. Redirecting is cheap here and expensive after the fan-out.
2 · Fan out — four scouts, one lane each, in parallel
Spawn four subagents concurrently. Each owns one lane and returns evidence records only — no ideas, no recommendations, no synthesis. Give every scout this prompt shape:
You are scout for LANE <n> of a market-evidence sweep. Read <skill>/references/sources.md,
YOUR LANE SECTION ONLY, plus "Evidence record schema" and "Source hygiene".
Hunting grounds: <list> (fog mode: search questions instead)
Return 8-15 evidence records in the exact schema. Rules:
- Every record needs a real URL you actually fetched, a date from the page, and a verbatim
quote of <=40 words. Never invent a URL. Unfetchable page -> write FETCH FAILED.
- Records only. If you catch yourself proposing a product, stop and go back to searching.
- Report the queries you ran, including the ones that returned nothing.
- Get the `pays` tier right - it decides whether this survives.Web search and fetch are mandatory. Use a browsing or scraping skill (/browse, /scrape) if
one is installed — review sites and pricing pages often need a real browser. The Hacker News
Algolia API returns dated JSON and is worth scripting rather than scraping.
Run the scouts cheap. Fetching a page, pulling a quote out of it and filling in a fixed schema is not intelligence-sensitive work, and this step spawns more subagents than the rest of the pipeline combined. If the harness lets you choose, give every scout a faster/cheaper tier and a low reasoning setting; the same goes for the fetch-heavy half of step 4. Keep the judgment — clustering in step 3, reading the competition shape, scoring in step 5 — on whatever the session is already running. Downgrading those is how a shortlist turns into slop.
3 · Cluster
Group records by job to be done, not by tool or by industry. "Reconcile payouts against orders every month" is a cluster; "Shopify apps" is not.
Drop any cluster with fewer than 3 records or drawn from fewer than 2 lanes. A cluster living entirely in lane 1 is people being annoyed, which is not a business.
Name each surviving cluster in the customer's own vocabulary, lifted from the quotes.
4 · Verify — one pass per surviving cluster, in parallel
This is where confident nonsense dies. For each cluster, a subagent confirms:
- Competitors — who exists, at what price, taken from the actual pricing page, quoted
and dated. Then the shape (see
references/screening.md§2). - The wedge, quantified — if the shape is "crowded but badly reviewed", count it: how many sub-4-star reviews name the same axis, out of how many.
- The why-now — a date, or it does not exist.
- Platform risk — if the idea rides a platform, read that platform's public roadmap and changelog. Building a line item on someone's roadmap is building it for them, free.
- Every quote from step 2 — re-fetch a sample. A single fabricated citation invalidates the run; catching it here costs minutes, catching it at phase 1 costs credibility.
5 · Score and cut
Read references/screening.md in full, then apply it: the willingness-to-pay ladder, the
competition shapes, the solo+AI kill flags, the default-reject patterns, and the scorecard.
Hard gates beat totals. A cluster with no T1/T2 payment evidence does not reach the shortlist, however loud the complaining. Below 14/24, or any axis at zero, or any unresolved kill flag → graveyard, with the reason recorded.
6 · Write it up
Copy templates/idea-scan.md to <scratch>/idea-scan-YYYY-MM-DD.md and fill it in.
Scratch means a working directory outside any repo — do not git init, do not create a
project. A repo is the artifact of deciding to build, and nothing has been decided yet.
When phase 1 later returns GO, the scan moves into docs/business/ beside the validation.
The graveyard section is not filler. It is what stops the next run re-walking the same forty dead clusters, and it is the evidence that the shortlist was subtracted rather than invented.
7 · Present and hand off
Show 2–3 candidates plus the graveyard summary. Then stop — picking is the human's call, and nothing downstream should start on its own.
Handoff is /solo-sdlc:validate <the pitch paragraph>, which spawns product-critic for the
real attack at phase 1. On GO, the pipeline continues at phase 0 triage.
How many candidates
Default 2–3. One is a fine answer. Zero is a fine answer — fill in Nothing cleared the gates, report what the evidence actually said, and propose the next hunting grounds. More than three only when a ground was unusually rich, and cap at five.
Padding the list is the single most expensive failure available here, because the cost is not tokens — it is the weeks the human spends building the filler.
Hard rules
- No quote, no idea. Every candidate traces to ≥3 fetched, dated, quoted records from ≥2 lanes. Writing an idea you did not read in somebody's complaint means deleting it.
- Never fabricate a URL, a price, a review count, or a date.
FETCH FAILEDand "could not verify" are acceptable results. An invented citation is not, and it survives into every downstream artifact where it is far more expensive to catch. - Somebody must already be paying. Money to a competitor, money to a human, or hours from a role that controls a budget. "I'd pay for this" is a sentence, not evidence.
- An empty market is a red flag until explained. Invoke one of the four legitimate
explanations in
references/screening.md§2, with evidence, or send it to the graveyard. - A why-now that is "AI can do this now" is not a why-now. Everyone has that enabler, which is why those spaces close within a quarter. Date it or drop it.
- Report the empty lanes. A lane that found nothing is a finding about the market, and hiding it makes a thin sweep look thorough.
- Do not do
product-critic's job. No TAM model, no full unit economics, no risk register, no verdict. Broad and shallow here; deep and adversarial there, on one idea, at phase 1. - Do not write code, scaffold, or create a repo. This runs upstream of everything.
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.

