suede-competitor-profiling

Files (6)

• CARD.md
• SKILL.md
• openai.yaml · agents/
• evals.json · evals/
• templates.md · references/
• tool-reference.md · references/

SKILL.md (first lines)

# Suede AI Competitor Profiling Skills

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

## Compatibility

An agent with web access and local file writing for raw captures and profiles. Optional SEO providers are used only when already available; their absence leaves those measurements unknown.

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

From JasonColapietro/suede-creator-skills, MIT.

More from JasonColapietro/suede-creator-skills