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