/suede-competitor-profiling

name: suede-competitor-profiling
description: "Suede AI competitive-intelligence discipline: evidence-backed profiles of positioning, pricing, messaging, product, proof, reviews, organic search footprint, and AI answer visibility, built from current public URLs with raw captures saved and fact, inference, and unknowns kept separate. Use when researching named competitors or refreshing a structured view of the competitor set. NOT FOR: publishing comparison or alternative pages (use suede-competitors), internal sales battle cards (use suede-sales-enablement), or deciding pricing changes (use suede-pricing)."
metadata:
  version: 2.1.0

Suede AI Competitor Profiling

Use this competitive-intelligence playbook to turn current public evidence into structured profiles with fact, inference, and unknowns kept separate.

Initial Assessment

Check for `.agents/product-marketing.md` (or `.claude/product-marketing.md`, or the legacy `product-marketing-context.md`) and read it if present: your own positioning and ICP decide which competitors are actually comparable and which dimensions are worth profiling, and they are usually already written down there.

Then work the intake list under Task-Specific Questions below. If the user gave URLs and the context file covers the rest, proceed without asking.

---

Saving Raw Data

Before synthesizing the profile, persist all raw page captures, SEO inputs, and review evidence to disk so they can be re-read, audited, or reused without repeating provider requests or manual collection.

**Directory layout** (relative to project root):

competitor-profiles/
├── raw/
│   └── <competitor-slug>/
│       └── <YYYY-MM-DD>/
│           ├── scrapes/    # one .md file per captured page (homepage.md, pricing.md, ...)
│           ├── seo/        # one .json or .csv file per authorized metric source
│           └── reviews/    # one .md or .json file per review source (g2.md, capterra.md, ...)
├── <competitor-slug>.md    # final synthesized profile
└── _summary.md             # cross-competitor summary

Rules:

• `<competitor-slug>` is lowercase, hyphenated (e.g. `responsehub`, `safe-base`)
• `<YYYY-MM-DD>` is the date the data was pulled: supports re-running and diffing snapshots over time
• Save each browser, manual, or authorized-fetch page capture as raw markdown

to `scrapes/<page-name>.md`

• Save each authorized SEO response or user-supplied export to

`seo/<source-name>.<json|csv>`

• Save each review source to `reviews/<source>.md` (cleaned text) or `.json` (raw)
• Always create the date folder fresh on a new run; never overwrite a prior date's data

The synthesized profile (`<competitor-slug>.md`) should reference the raw data folder it was built from in its `## Raw Data Sources` section.

---

Research Process

Phase 1: Public-Site Evidence

For each competitor URL, capture key public pages to extract positioning, features, pricing, and messaging.

**Availability gate:** Inspect the tools currently exposed in the session before selecting an acquisition method. A named connector is usable only when it is actually available, connected to the intended account when applicable, authorized for this task, and its current schema has been read. Do not invent a tool call from the examples below.

If no mapping or page-fetch tool is available, use a browser-neutral/manual fallback: open the public site, follow its primary navigation, inspect its public sitemap or search results when accessible, record the exact URLs and access date, and capture only evidence visible to the user. Respect access controls, site terms, robots directives where applicable, and rate limits.

**When the gate blocks you**: a source needs an account you were not given, a platform is not connected, a site's terms or robots directives put a page out of bounds, or the user wants a dossier published or sent onward without having authorized it, halt in four parts:

1. Stop. Do not collect the blocked source or publish the dossier. 2. Name the blocker in one line ("G2 reviews for <competitor> require a signed-in account; this session has no authorized G2 connection"). 3. Offer 2-4 options (proceed without that source and mark the fields `not collected`; the user supplies an export; the user authorizes the connection; substitute a permitted source). 4. Wait for the answer. Do not pick one and continue.

Step 1: Map the site

If a current authorized connector exposes a site-map or crawl capability, use its documented schema to discover the site structure. For example, some Firecrawl connections expose a `firecrawl_map` operation, but that name is not guaranteed. Otherwise build the URL list through the manual fallback.

available map capability or manual navigation → verified competitor URLs

From the map, identify and prioritize these page types:

• Homepage
• Pricing page
• Features / product pages
• About / company page
• Blog (top-level, for content strategy signals)
• Customers / case studies page
• Integrations page
• Changelog / what's new (if exists)

Step 2: Capture key pages

If a current authorized connector exposes single-page fetch or extraction, use its documented schema on each identified URL. For example, some Firecrawl connections expose `firecrawl_scrape`. Otherwise open each public page and capture the relevant visible text manually.

available page-fetch capability or browser/manual capture → page evidence

Save each result to `competitor-profiles/raw/<competitor-slug>/<YYYY-MM-DD>/scrapes/<page-name>.md` before extracting fields.

Extract from each page:

| Page | What to Extract | |------|----------------| | **Homepage** | Headline, subheadline, value proposition, primary CTA, social proof claims, target audience signals | | **Pricing** | Tiers, prices, feature breakdown per tier, billing options, free tier/trial details, enterprise pricing signals | | **Features** | Feature categories, key capabilities, how they describe e