Skip to main content
Finds viable ideas through adversarial generation-and-kill cycles. Generates batches of 5 candidates, validates every idea against real market data using a 6-check kill chain, documents kill reasons, and loops until 3 survivors emerge. There is no batch limit — the skill keeps generating until it finds viable ideas. Use this skill when you want to brainstorm ideas, find market gaps, identify business opportunities, figure out what to build, or find underserved niches. Works for SaaS, open source, MCP servers, apps, tools, APIs, or any product category.

Invocation

/gap-finder [domain or market space]
Examples:
/gap-finder MCP servers for developer tools
/gap-finder mobile apps for independent nurses
/gap-finder open-source data pipeline tools

Workflow

1

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.
2

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”
3

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.”
4

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.
5

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.
6

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.
7

Loop until 3 survivors

Continue generating, validating, and recording until 3 ideas survive all 6 checks. After 3 survivors, write the final ranked summary.

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.md to prevent re-proposing

Golden rules

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.
The moment an idea fails any validation check, kill it. Record the specific kill reason. Do not soften failures.
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.
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.
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.
“A developer tool” is not an idea. Name the specific mechanism, the specific user, and the specific pain point.
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.
Every claim about market size, competitor count, or user demand must be backed by a search result or concrete data point.

Reference files

FileContents
GENERATION.mdHow to generate idea batches, the idea template, angle diversity requirements
VALIDATION.mdThe 6-check kill chain with search strategies and pass/fail criteria
SURVIVOR-FORMAT.mdOutput format for surviving ideas with required evidence sections