find-gaps
Skill11 starsChanged 31 days agoMITView on GitHub
Surface research gaps in the wiki and propose a plan to fill them. Reads an idea overview's "Still to validate" lines, "What we do not know" entries, and "Next moves," then proposes targeted research questions tagged by strategy (ask the user, do web research, or both). Use when the user wants to find gaps, deepen an idea, or says "what should I research next" / "what's missing" / "find gaps". For executing web research on a specific question, use `/research-deep` instead.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- conjurer-rich/skillstheir own version, first seen Oct 25, 2026
- preetamnath/agent-skillstheir own version, first seen Apr 24, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- preetamnath/agent-skills★ 4same name
- conjurer-rich/skills★ 1same 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.
In this repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- founder-profileSkill
- grill-meSkill
- new-ideaSkill
- onboardingSkill
- research-deepSkill
- wiki-lintSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Read the wiki first: Start with the idea overview, then its deep-dive notes.
≈ “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
Convert the wiki's existing open questions into a concrete research plan. Don't invent new questions — start from what the idea overview already flags as unvalidated, then group, prioritize, and propose a strategy for each.
Read the wiki first. Start with the idea overview, then its deep-dive notes. Pull every "Still to validate" line, every "What we do not know" entry, and every numbered move under "Next moves." Skip questions the wiki already answers — those are noise.
Cluster each gap by research strategy:
- Ask the user. Things only the user knows — domain experience, network, prior conversations, direct buyer access, founder-fit detail.
- Web research. Things that should be in public sources — competitor pricing, regulatory deadlines, named partners, market sizing, dated triggers.
- Hybrid. Things that need a user hint to find the right web target ("is there a Texas DIR equivalent in your actual market?").
Propose the plan as a numbered list. For each item, name the question, the strategy, the wiki section it would feed, and rough effort (one search vs. deep dive). Lead with questions that would flip the verdict — fatal-flaw checks first, decoration last. If a question is decorative (would not change the verdict either way), say so and recommend dropping it.
Confirm scope with the user before executing:
- Which questions to pursue this round (don't over-batch).
- Time range for web research (e.g., "since 2024", "all time").
- Depth (one search → one note vs. multiple search rounds → comprehensive note).
- Whether to run web items in parallel via
/research-deep.
Hand off. For web items, invoke /research-deep with the confirmed questions. For user-question items, surface them inline one at a time and capture the answers — short answers go directly into the relevant Still to validate line in the Notion wiki page; longer answers may warrant a new raw source page under Notion raw/<idea-slug>/.
Tie every proposed question to a specific wiki claim it would confirm or kill (e.g. "this would test the 60%-selector-drift bank-case figure"). Don't propose research the user could answer in two minutes. If a "Still to validate" line hedges, sharpen the question before researching it.
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.