name: competitor-research
description: Research 3–5 competitors for any product or feature. Returns positioning, pricing, key differentiators, gaps, and an unclaimed angle. Use when the user asks about competitors, market landscape, or competitive analysis.
Competitor Research
You research competitors yourself for the light, fast tasks (search and
homepage fetches), and you delegate the heavy work to specialist subagents:
pricing-fetcher — pricing extraction with WebFetch-first, Playwright-fallback
review-miner — distilling user sentiment from 10+ review pages
Workshop note: the split between "skill does it" and "subagent does it"
follows one rule: delegate work that is heavy, parallelizable, and returns
clean structured output. Light fetches stay in the skill. Heavy or
potentially-heavy work (Playwright at ~114K tokens, review-mining across
dozens of pages) gets its own context window.
Step 1 — Scope
Ask the user once:
"What product or feature are you researching? Who is it for?"
Skip if they already gave both. Cap at 2 clarifying questions max
(geography, segment, direct vs. adjacent). Don't run an interview.
Step 2 — Identify competitors
Use WebSearch by default. Look for:
- "best [category] tools 2025/2026"
- G2 / Capterra / Gartner category pages
- Reddit "alternatives to [known leader]" threads
Use mcp__brave-search__brave_web_search instead only when you need
strictly the last 12 months of results (e.g., a fast-moving category where
2-year-old listicles would be misleading). Brave's freshness parameter is
deterministic; WebSearch's recency is a soft preference. For most categories
the soft preference is fine.
Pick direct competitors (same buyer, same job-to-be-done). List them back
to the user briefly so they can correct the set before you go deep.
Step 3 — Per competitor (parallel work)
For each competitor, dispatch the following in a single message with multiple
tool calls so they run concurrently:
3a. Homepage — you do this yourself (WebFetch)
Fetch the homepage and extract:
- Hero headline (verbatim)
- Subhead (verbatim)
- Top 3 features in homepage order
- Stated differentiators (translated to plain English, not paraphrased into
marketing-speak)
This stays inline because homepage HTML is server-rendered for ~95% of
competitor sites — fast, light, and pollutes nothing.
3b. Pricing — delegate to pricing-fetcher subagent
Spawn one pricing-fetcher per competitor. It tries WebFetch first; falls
back to Playwright browser automation only if the page is JS-rendered.
Why this is delegated: Playwright sessions cost ~114K tokens each. Even
when only 1 in 3 competitors needs it, isolating that work in subagents keeps
the orchestrator's context lean and lets fetches run in parallel.
The subagent returns a structured pricing table plus a Method used field
(WebFetch / Playwright) — audit this field. If 4 of 5 competitors all used
Playwright, something's wrong with WebFetch and you should investigate before
trusting the data.
3c. Reviews — delegate to review-miner subagent
Spawn one review-miner per competitor. It searches across G2/Capterra/Reddit/
HN/ProductHunt/Trustpilot, distills patterns (≥3 confirming voices across ≥2
platforms = signal), and returns recurring strengths + weaknesses.
Why this is delegated: review pages are dense user-voice text — 10+ pages
per competitor. Doing it inline pollutes the orchestrator's context with raw
review snippets.
If a subagent returns "insufficient data," don't retry with the same prompt —
either accept the gap (and surface it in the final report) or hand the next
attempt a sharper, narrower question.
Step 4 — Synthesize per-competitor cards
Combine your homepage research with the two subagents' findings into exactly
6 bullets per competitor:
### [Competitor Name]
- **Positioning**: one sentence (their words, plain English)
- **Target customer**: who they're built for
- **Pricing**: tiers and price points, or "Not public"
- **Differentiators**: 2–3 things they do well
- **Weaknesses**: 1–2 recurring complaints from reviews/forums
- **Source date**: most recent source pulled (YYYY-MM)
Hard rules:
- 6 bullets exactly. If a bullet is empty, write "—" but keep the line.
- Pricing must cite a source URL inline if public.
- No marketing language in your translation.
Step 5 — Gap Analysis
Add this section verbatim:
### Gap Analysis
- **What no competitor does well**: [specific capability gap]
- **Where pricing is underserved**: [a tier or model nobody offers]
- **Unclaimed positioning angle**: [a frame nobody owns]
Each gap must be falsifiable — grounded in something a reader can verify.
"Better UX" is not a gap. "No competitor offers per-seat pricing under $10/mo
for teams under 5" is.
Step 6 — Close
End the report with exactly one line:
Based on this, which gap are you trying to own?
No summary. No "let me know if you want more." Just the question.
Tool selection cheat sheet
| Task | Default tool | Reach for MCP when... |
|---|
| Identify competitors | WebSearch | You need strict 12-month recency → brave_web_search |
| Fetch a homepage | WebFetch | (never — homepage is light) |
| Fetch a pricing page | pricing-fetcher subagent | (subagent decides internally whether Playwright is needed) |
| Mine reviews | review-miner subagent | (subagent decides internally — uses Brave's news/summarizer for specific cases) |
Default principle: built-in tools first, MCPs only when they offer
something built-ins can't.
Anti-patterns (do not do)
- ❌ Doing your own deep web searches once you've identified competitors —
delegate pricing and review work to the subagents
- ❌ Calling subagents sequentially per competitor instead of in parallel
- ❌ Reaching for
brave_web_search when WebSearch would have been fine
(this wastes Brave's free-tier budget)
- ❌ Invoking Playwright tools directly from the orchestrator — those calls
belong in the
pricing-fetcher subagent so the heavy context is isolated
- ❌ Accepting a
pricing-fetcher report where 4 of 5 competitors used
Playwright — investigate WebFetch first
- ❌ Adding a 7th bullet "for completeness"
- ❌ Inventing pricing because the public site is vague
- ❌ Listing every G2 complaint — only recurring patterns
- ❌ Writing a closing paragraph after the sharp question