Competitor Research

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

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