Invocation
Workflow
Establish the domain
Identify the space the user wants ideas in. Extract any constraints (tech stack, budget, solo founder, geography) and previously killed ideas. Write these to
gap-finder-state.md in the current working directory. This file tracks killed ideas to prevent re-proposing.Generate a batch of 5 ideas
Each idea must be concrete and specific to the domain — not a category, but a product with named features. Draw from at least 3 different angles per batch.Bad: “A developer tool”
Good: “A CLI that takes a
package.json and returns a dependency upgrade plan with breaking-change warnings by cross-referencing changelogs”Run the kill chain on every idea
Execute all 6 validation checks from
VALIDATION.md. Search the web for each check. Kill on the first fatal failure — do not soften failures into “could work with modifications.”Kill reasons are specific and one-sentence — not “didn’t seem viable.”Record killed ideas
Append every killed idea and its specific kill reason to
gap-finder-state.md. This prevents re-proposing the same idea or the same structural mechanism under a new name.Present survivors immediately
When an idea passes all 6 checks, present it immediately — do not wait for 3 survivors. Each survivor is shown with full evidence: search results, competitor count, differentiation, pain point scenario, and monetisation path.
Widen on saturation
If 2 consecutive batches have 0 survivors AND more than 80% died at Check 1 (competitors), the current sub-space is saturated. Do NOT stop. Instead: note the saturated sub-space in the state file, then expand — go more niche, go adjacent, change the target user, change the business model, or combine two domains.
After every 5 dead batches, radically pivot: change the domain, the target user, the business model, or the geography. The answer exists — keep looking.
Self-review checklist
Before delivering results, verify all of the following:- Every proposed idea was searched on at least 3 relevant sources (e.g., npm + Smithery + GitHub for dev tools; App Store + ProductHunt + Google for apps)
- Every killed idea has a specific, one-sentence kill reason
- Every survivor has competitor search evidence showing fewer than 2 direct competitors, or a clear documented differentiation from existing ones
- Every survivor answers “what recurring pain point does this solve?” with a concrete user scenario
- Every survivor has a realistic monetisation or growth path in one sentence
- No survivor is something trivially solved by existing free tools or LLMs without external data
- At least 3 batches were generated (15+ ideas evaluated)
- Each idea is specific — names concrete features or tools, not just a category
- Killed ideas are tracked in
gap-finder-state.mdto prevent re-proposing
Golden rules
1. Search before you pitch
1. Search before you pitch
Never present an idea without first searching for existing implementations. Every idea gets 3+ web searches across relevant platforms. “I believe there aren’t competitors” is not evidence — show the search results.
2. Kill fast, document why
2. Kill fast, document why
The moment an idea fails any validation check, kill it. Record the specific kill reason. Do not soften failures.
3. Recurring pain or death
3. Recurring pain or death
If the pain point occurs less than weekly for the target user, the idea is dead. Quarterly pain is not a business. Daily frustration is.
4. Existing solution already works is fatal
4. Existing solution already works is fatal
If a free, widely-adopted tool already solves this well enough, the idea is dead. “Ours would be slightly better” is not a gap — it’s a feature request on the existing tool.
5. Never stop until survivors are found
5. Never stop until survivors are found
There is no batch limit. When obvious ideas die, get weirder. When a sub-space is crowded, move to an adjacent one. Validate kill chains in parallel — each idea’s checks are independent.
6. Concrete features, not categories
6. Concrete features, not categories
“A developer tool” is not an idea. Name the specific mechanism, the specific user, and the specific pain point.
7. No resurrections
7. No resurrections
Once an idea is killed, it stays dead. Do not re-propose killed ideas with minor variations. If “Postgres optimizer” is dead, “MySQL optimizer” dies for the same structural reason.
8. Evidence over intuition
8. Evidence over intuition
Every claim about market size, competitor count, or user demand must be backed by a search result or concrete data point.
Reference files
| File | Contents |
|---|---|
GENERATION.md | How to generate idea batches, the idea template, angle diversity requirements |
VALIDATION.md | The 6-check kill chain with search strategies and pass/fail criteria |
SURVIVOR-FORMAT.md | Output format for surviving ideas with required evidence sections |