Deep research on an idea before writing a PRD. Explores existing solutions via web search, analyzes competitors, assesses technical feasibility, and optionally explores the codebase. Use when asked to "research this idea", "investigate this feature", "what already exists for X", "explore solutions for X", "do research before the PRD", "look into X", or /research. Outputs a structured research document at docs/research/{name}.md. Suggests running /prd-designer as the next step. Dependencies: WebSearch (optional).
73
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Deep research on an idea before committing to a PRD. Runs 4 dimensions in parallel: existing solutions, competitor analysis, technical feasibility, and codebase exploration.
Reference files:
references/research-template.md — output doc structurereferences/dimensions.md — 4 dimensions with guiding questionsAccept input in any form:
If the idea is too vague for meaningful research (no discernible problem or domain), ask 2–3 clarifying questions before proceeding. Do not proceed until you have enough to scope the research.
Detect codebase context. Set codebase_aware = true if .git exists in the working directory AND the idea references existing code, a repo, or a specific feature in the project.
Confirm understanding. Output a 2–3 sentence summary of the idea and ask: "Is this right, or should I adjust the scope before I start?"
Load references/dimensions.md for guiding questions per dimension.
Run all applicable dimensions. Where dimensions are independent, use sub-agents or parallel tool calls.
Dimension 1 — Existing Solutions Use WebSearch to find products, libraries, open-source projects, and browser/platform APIs that solve or overlap with the problem. Summarize the top 3–5 with a comparison table (name, description, pros, cons, relevance).
Dimension 2 — Competitor / Market Analysis Use WebSearch to examine how similar products in the space handle this. Identify the dominant pattern, what has been tried and failed, and where there is a genuine gap.
Dimension 3 — Technical Feasibility
Assess real constraints: API limits, platform restrictions, dependency availability, performance implications. If codebase_aware = true, also check how the current stack handles related concerns.
Dimension 4 — Codebase Exploration (only if codebase_aware = true)
Use Glob, Grep, and Read to map relevant modules, existing patterns, integration points, and potential conflicts. Identify reusable abstractions.
Degradation rules:
codebase_aware: skip Dimension 4 entirely.Compile all findings into docs/research/{kebab-name}.md using references/research-template.md:
codebase_aware = falseCreate docs/research/ if it doesn't exist.
Derive {kebab-name} from the idea/feature name (lowercase, hyphens, no special chars). If ambiguous, ask: "What should I name the research file?"
If research reveals the problem is already fully solved by an existing tool: flag it clearly at the top of Key Takeaways. Let the user decide whether to proceed.
Present a concise summary of findings — 3–5 bullets covering: what exists, what's feasible, what's novel, what's risky.
Ask: "Anything to add or correct before we move on?"
Suggest the next step:
"Run
/prd-designerto create a PRD from this research. Reference the research doc:docs/research/{kebab-name}.md"
66c7102
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.