From safe-browser
Discovers and researches competitors using Browserbase Search API, then generates an HTML report with overview, deep dives, feature/pricing matrix, and mentions feed.
How this skill is triggered — by the user, by Claude, or both
Slash command
/safe-browser:competitor-analysisThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Analyze a user's competitors. Uses Browserbase Search API for discovery and a 4-lane Plan→Research→Synthesize pattern for enrichment — outputting an HTML report with overview, per-competitor deep dives, a side-by-side feature/pricing matrix, and a chronological mentions feed.
LICENSE.txtreferences/battle-card-subagent.mdreferences/battle-card.mdreferences/example-research.mdreferences/report-template.htmlreferences/research-patterns.mdreferences/workflow.mdscripts/capture_screenshots.mjsscripts/compile_report.mjsscripts/extract_vs_names.mjsscripts/gate_candidates.mjsscripts/list_urls.mjsscripts/md_utils.mjsscripts/merge_partials.mjsscripts/package.jsonAnalyze a user's competitors. Uses Browserbase Search API for discovery and a 4-lane Plan→Research→Synthesize pattern for enrichment — outputting an HTML report with overview, per-competitor deep dives, a side-by-side feature/pricing matrix, and a chronological mentions feed.
Required: BROWSERBASE_API_KEY env var and the browse CLI installed (npm install -g browse).
First-run setup: On the first run you'll be prompted to approve browse cloud fetch, browse cloud search, cat, mkdir, sed, etc. Select "Yes, and don't ask again for: browse cloud fetch:*" (or equivalent) for each. To permanently approve, add these to your ~/.claude/settings.json under permissions.allow:
"Bash(browse:*)", "Bash(bunx:*)", "Bash(bun:*)", "Bash(node:*)",
"Bash(cat:*)", "Bash(mkdir:*)", "Bash(sed:*)", "Bash(head:*)", "Bash(tr:*)", "Bash(rm:*)"
Path rules: Always use full literal paths in Bash — NOT ~ or $HOME. Resolve the home directory once and use it everywhere. When building subagent prompts, replace {SKILL_DIR} with the full literal path.
Output directory: All output goes to ~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}/. This directory contains one .md file per competitor plus the generated HTML views and CSV.
CRITICAL — Tool restrictions (applies to main agent AND all subagents):
browse cloud search. NEVER WebSearch.browse cloud fetch --allow-redirects (returns markdown by default; add --format raw if you need the original HTML, then pipe through sed ... | tr -s ' \n' to extract text). NEVER WebFetch. 1 MB response limit — fall back to browse get markdown (after browse open <url> --remote) for JS-heavy pages.{OUTPUT_DIR}/{competitor-slug}.md using bash heredoc. NEVER use the Write tool or python3 -c. See references/example-research.md for the file format.node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open — generates index.html, competitors/*.html, matrix.html, mentions.html, results.csv in one step and opens overview.node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor.CRITICAL — Minimize permission prompts:
&& chaining.Follow these 8 steps in order. Do not skip or reorder.
precise_category + category_include_keywords + exclusion_listscripts/gate_candidates.mjs fetches each candidate's hero text (via browse cloud fetch) and drops wrong-category URLsAskUserQuestion. User ticks the real ones, adds any the discovery missed. Skipping this step is wasteful because enrichment is expensive (25 subagents × depth budget) and the gate is imperfect (JS-heavy homepages, Cloudflare challenges, semantic-variant taglines)partials/; then merge_partials.mjs consolidates. In deep/deeper modes, Step 5d adds a 6th Battle Card synthesis lane AFTER Step 5c fact-check completes — produces per-competitor Landmines / Objection Handlers / Talk Tracks grounded in cited evidence.capture_screenshots.mjs via the browse CLI captures a 1280×800 homepage hero per competitorOUTPUT_DIR=~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}
mkdir -p "$OUTPUT_DIR"
Replace {company_slug} with the user's company name (lowercase, hyphenated) and {YYYY-MM-DD} with today's date. Pass {OUTPUT_DIR} as a full literal path to every subagent.
Clean up discovery batch files from prior runs:
rm -f /tmp/competitor_discovery_batch_*.json
Re-runs must start from a clean $OUTPUT_DIR. compile_report.mjs ingests every {slug}.md in the directory, and merge_partials.mjs only overwrites the slugs in the current set — it never deletes ones dropped from a new enrichment set. Since the directory is keyed by date, a same-day re-run with a different competitor set would leave stale competitors in the overview, matrix, CSV, and screenshots. Either use a fresh directory or clear the prior per-competitor files first:
rm -f "$OUTPUT_DIR"/*.md && rm -rf "$OUTPUT_DIR"/partials "$OUTPUT_DIR"/screenshots
This step sets the baseline for what "competitor" means AND produces the verified data the Step 5b matrix will use for the userCompany row.
Rule: The user's company gets the same 5-lane research depth as competitors. Do NOT fill userCompany in matrix.json from memory — it will ship false claims to the user's own team. On a search-API run (user company Exa, 2026-04-23), skipping this step produced a matrix that claimed Exa had a "published uptime SLA" (there is no numeric public SLA — only a status page) and marked its MIT-licensed Python SDK as open-source: false (the repo is github.com/exa-labs/exa-py, LICENSE confirmed MIT). Both errors would have surfaced in the "Where you're winning" card as fabricated moats.
Process:
Ask the user for their company name or URL.
Check for an existing profile at {SKILL_DIR}/profiles/{company-slug}.json. If it exists, load it and confirm with the user: "I have your profile from {researched_at}. Still accurate?" — if yes, skip to Step 2 BUT still run the partial-lane enrichment below so matrix synthesis has fresh feature evidence.
The profile format is shared with company-research (same shape). If a user already has a profile saved under company-research/profiles/, you may copy it into this skill's profiles directory rather than re-researching.
Run the full 5-lane enrichment on the user's company — identical to the competitor pattern in Step 5. For each lane, spawn a Bash-only subagent that writes to {OUTPUT_DIR}/partials/{user-slug}.{lane}.md:
references/research-patterns.md → "Self-Research" for sub-questions. Each finding MUST cite a URL.Run merge_partials.mjs on the user's partials too — produces {OUTPUT_DIR}/{user-slug}.md, the canonical source Step 5b reads from for userCompany flags.
Synthesize into a profile: Company, Product, Existing Customers, Competitors (seed list), Use Cases, precise_category, category_include_keywords, exclusion_list. Do NOT include ICP — this skill doesn't need it.
precise_category: one sentence describing the category. e.g., "AI web search API for agents with neural + keyword retrieval". Avoid vague words like "tools" / "platform".category_include_keywords: 8-15 phrases a direct competitor's marketing would likely contain (hero or title). Include semantic variants.exclusion_list: phrases that indicate a different category — used by the gate to reject false positives (e.g. antidetect browser, scraping api, screenshot api, residential proxy).
See references/research-patterns.md → "Synthesis Output" for the exact format and Exa as a worked example.Present the profile + the user-company .md to the user for confirmation. Do not proceed until confirmed.
Save the confirmed profile to {SKILL_DIR}/profiles/{company-slug}.json.
Ask clarifying questions via AskUserQuestion with checkboxes:
quick — marketing surface only, many competitors, ~2-3 tool calls eachdeep — + external signal (mentions, reviews, news), ~5-8 tool calls eachdeeper — + public benchmarks + strategic diff vs user's company, ~10-15 tool calls eachThis is the ONLY user interaction. After this, execute silently until the report is ready.
| Mode | Research per competitor | Best for |
|---|---|---|
quick | Lane 1 only (homepage + pricing) | Scanning ~30-50 competitors fast |
deep | Lanes 1+2 | ~15-25 competitors with external signal |
deeper | All 4 lanes (+ benchmarks + strategic diff) | ~5-15 competitors with full intel |
Formula: ceil(target_count / 20) queries per wave. Over-discover ~3x because the gate drops ~40-60%.
Evaluation on a search-API run shows all three waves are additive — skip any and you lose real competitors:
Wave A — Generic alternatives (broad; heavy aggregator noise, filtered out later)
"alternatives to {user_company}""{user_company} competitors"Wave B — Precise category (uses precise_category from the profile)
"{precise_category}" verbatim"web search api for ai agents", "retrieval API for LLMs")Wave C — Comparison-page graph (highest precision)
"{user_company} vs""{seed1} vs", "{seed2} vs", "{seed3} vs" (seeds from the profile's competitors list)scripts/extract_vs_names.mjs to parse "X vs Y" patterns from result titles — this uniquely surfaces competitors that don't appear as URL hits.Process:
browse cloud search Bash calls (one per wave) in a SINGLE message — NOT subagents. Each Bash call chains its 2-4 queries with &&. See references/workflow.md → "Discovery — parallel Bash, not subagents" for the exact recipe. Subagents are too heavy for a workload of 6-12 browse cloud search calls.node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor > /tmp/competitor_urls.txt
node {SKILL_DIR}/scripts/extract_vs_names.mjs /tmp --prefix competitor \
--seed "{user_company},{seed1},{seed2},{seed3}" \
> /tmp/competitor_vs_names.jsonl
/tmp/competitor_urls.txt — remove blog posts, news, AI-tool directories (seektool.ai, respan.ai, agentsindex.ai, toolradar.com, aitoolsatlas.ai, vibecodedthis.com, etc.), review aggregators (g2.com, capterra.com), databases (crunchbase.com, tracxn.com), user's own domain. See references/workflow.md for the full noise-domain list.vs_names entries that have a resolved domain, add them. For unresolved names, optionally run browse cloud search "{name}" --num-results 3 and pick the top root domain./tmp/competitor_candidates.txt.Drop candidates whose marketing identifies them as a different category before enrichment burns tool calls on them.
cat /tmp/competitor_candidates.txt \
| node {SKILL_DIR}/scripts/gate_candidates.mjs \
--include "{profile.category_include_keywords joined with commas}" \
--exclude "{profile.exclusion_list joined with commas}" \
--concurrency 6 \
> /tmp/competitor_gated.jsonl
grep '"status":"PASS"' /tmp/competitor_gated.jsonl \
| node -e 'require("fs").readFileSync(0,"utf-8").split("\n").filter(Boolean).forEach(l => { try { console.log(JSON.parse(l).url); } catch {} })' \
> /tmp/competitor_passed.txt
The gate fetches each candidate's homepage via browse cloud fetch --allow-redirects --format raw, extracts the first 800 chars of visible text, and classifies position-aware: exclude in <title> → REJECT; include in <title> → PASS; hybrid title → hero200 tiebreak; otherwise fall through.
Evaluated on a search-API run with 12 mixed candidates: 7/7 real competitors passed, 4/4 wrong-category rejected, 1 known-hybrid edge case rejected.
This step is mandatory. Do NOT skip to enrichment just because the gate ran.
Enrichment is expensive: 5 competitors × 5 lane-subagents = 25 subagents, ~10-15 minutes of wall clock, ~300 browse cloud calls. Running it on the wrong set wastes all of that. The gate also has known blind spots:
browse cloud fetch returns near-empty text, so keyword matching has nothing to match on → REJECT or UNKNOWNbrave.com (the browser) vs api-dashboard.search.brave.com (the actual API product) can confuse classificationThe user almost always has domain knowledge the skill lacks. Ask them.
Process — the main agent:
Read /tmp/competitor_gated.jsonl and group rows:
Present the buckets to the user, one table per bucket, with URL + title + reason (for rejects).
Use AskUserQuestion with a checkbox list of all candidates across the three buckets, plus a free-text "add more" field. The prompt should be explicit:
"Here are the gate's picks plus a few it was unsure about. Tick the ones that are real competitors in your space, and paste any URLs I missed (comma-separated). Enrichment will run on ONLY the ticked set."
Write the confirmed set to /tmp/competitor_enrichment_set.txt (one URL per line). This is the input for Step 5 — not /tmp/competitor_passed.txt.
If the user doesn't respond or explicitly says "just run it", fall back to /tmp/competitor_passed.txt as-is, but warn in chat that the run may waste budget on wrong-category hits.
Exa test, 2026-04-24: gate auto-passed 22 of 101 candidates but missed Tavily (generic title), Jina AI (semantic mismatch — "search foundation"), Firecrawl (JS-heavy fetch failure), and Perplexity (Cloudflare challenge). All four are real direct competitors. This step catches them.
Two modes. See references/workflow.md for prompt templates and wave management. See references/research-patterns.md for the lane-by-lane methodology.
/tmp/competitor_enrichment_set.txt (user-confirmed set from Step 4.5), ~8 competitors per subagent.{OUTPUT_DIR}/{slug}.md.For each competitor, launch 5 parallel subagents, one per lane:
marketing): pricing, features, positioning, integrations, customers, team, funding, HQ. Owns canonical frontmatter.discussion): Reddit, HN, forums, Dev.to, Hashnode. Broad queries beyond site: — also "{competitor}" review 2026, "{competitor}" issues OR problems, "{competitor}" discussion.social): LinkedIn posts, YouTube videos, Twitter/X. Snippets only — do NOT fetch.news): TechCrunch, Verge, VentureBeat, Forbes, Businesswire, Substack, blog reviews. Every mention needs a date.technical): GitHub benchmark repos/PRs, performance posts. Writes Benchmarks + technical Findings.Budget per lane: deep = 5-8 tool calls, deeper = 10-15. Launch ALL competitor × lane subagents in a SINGLE Agent tool message. For 10 competitors × 5 lanes = 50 parallel Agent calls in one message. Do NOT split into batches per competitor or per lane — wall clock collapses to the slowest single agent (~3-5 min). Splitting into 5 rounds of 10 cost 25 minutes of wall clock vs 5 minutes parallel on a real measured run; do not do it.
Each subagent writes a partial to {OUTPUT_DIR}/partials/{slug}.{lane}.md.
Critical: Pass the user's company name, product, and key features verbatim into every subagent prompt so the technical lane can do strategic diffing. Pass the full literal {OUTPUT_DIR} path to every subagent.
After all subagents for all competitors complete:
node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}
Unions the 5 partials per competitor into one {OUTPUT_DIR}/{slug}.md — dedup'd Mentions (sorted by date desc), dedup'd Benchmarks, merged Findings, canonical frontmatter from the marketing lane.
matrix.json)Subagents write key_features and integrations as prose, not as pipe-separated atomic feature labels. So a naive |-split axis becomes one-blob-per-competitor with no overlap — the rendered matrix shows a useless diagonal.
The main agent fixes this by synthesizing a shared taxonomy across competitors and writing {OUTPUT_DIR}/matrix.json. compile_report.mjs auto-detects this file and renders the matrix from it instead of from the pipe split.
Process — main agent:
Read ALL {slug}.md files, INCLUDING the user's company file {user-slug}.md produced in Step 1. The user is competitor #0 for matrix purposes — treat with identical rigor.
Produce a canonical list of 12-20 atomic features — each must be a yes/no proposition a competitor either has or doesn't (e.g. "MCP server", "SOC 2", "Site crawler", "Reranker"). Avoid sentence-length features. Avoid features only one competitor has.
Produce a canonical list of 10-20 integrations (frameworks, marketplaces, SDK languages).
For each company INCLUDING THE USER, map each taxonomy entry to true / false based on the enrichment data in their .md file. Every flag must be traceable to a Research Findings bullet with a cited URL. If the user's file says "exa-py MIT-licensed (github.com/exa-labs/exa-py)", the Open-source feature is true with that URL as the source. If not mentioned, leave false.
Write the result to {OUTPUT_DIR}/matrix.json in this shape:
{
"category": "AI search APIs",
"features": [{ "name": "Web Search API", "description": "..." }, ...],
"integrations": [{ "name": "LangChain" }, ...],
"userCompany": {
"name": "Exa",
"winningSummary": "Exa's moats are its first-party neural index and the integrated Research API — no one else in the set ships a semantic/embeddings-native retrieval primitive alongside a multi-step agentic research endpoint. It's also the only provider with a crawler product bundled in, and ties with SerpAPI on breadth of SDK language coverage.",
"losingSummary": "Exa trails competitors on operational transparency — SerpAPI, Serper, and Tavily all publish hourly throughput SLAs, and Exa lacks a dedicated news endpoint that SerpAPI, Serper, and You.com all ship. Image/visual search is also missing vs 4 of 5 competitors.",
"features": { "Web Search API": true, "Site crawler": true, ... },
"integrations": { "LangChain": true, ... }
},
"competitors": {
"tavily": {
"features": { "Web Search API": true, "Site crawler": true, ... },
"integrations": { "LangChain": true, "Databricks Marketplace": true, ... }
},
"serpapi": { "features": {...}, "integrations": {...} }
}
}
userCompany is required. The overview page renders two cards — "Where {user} is winning" and "Where {user} is losing". Populate userCompany.features and userCompany.integrations from the self-research profile (Step 1). Without this field those two cards don't render.
Write order (two passes — this resolves the apparent ordering tension below). In this step (5b) write all features / integrations cells for userCompany and every competitor, plus a draft winningSummary / losingSummary. The drafts exist only to tell the Step 5c fact-checker which claims are high-stakes (it prioritizes cells named in the summaries). After Step 5c flips cells on verified evidence, rewrite the two summaries so the prose reflects only fact-checked cells. The JSON shape above shows the finalized post-fact-check object.
userCompany.winningSummary / losingSummary are strongly preferred (analyst-style prose, 2-4 sentences each). When present, the cards render as paragraphs instead of bulleted lists — reads like a briefing, not a spreadsheet. If absent, the cards fall back to a bulleted list of winning/losing items with who-else-has-it.
If this step is skipped, the matrix view falls back to the raw pipe-split axis (useless for atomic comparison) and the strategic summary doesn't render. Do not skip.
Do not trust the taxonomy pass alone for high-stakes cells. It is LLM inference from prose and will hallucinate moats. Observed during a search-API run (2026-04-23): matrix.json claimed SOC 2 was unique to the user's company; verification showed three of the other competitors also have SOC 2 Type II.
But verifying every cell is the opposite mistake. A 7-company × 33-axis matrix has 231 cells. The Apr 2026 search-API run got stuck at 111+ tool calls in fact-check before interrupt — the subagent kept going on table-stakes cells (REST API, JSON responses, Python SDK) that are universal in the category.
Default = spot-check, not full sweep. Only verify cells that meaningfully change the strategic narrative.
Launch a single fact-check subagent (Bash-only) with a hard 25-call budget that targets ONLY these high-stakes axes:
Every userCompany.features and userCompany.integrations cell (the user's own moats — these go straight into "Where you're winning" prose). Typical: 17 + 16 = 33 cells, but most are obvious (your own product). Focus on:
winningSummarylosingSummaryAcross competitors, only the cells that drive the win/loss summary:
Do NOT verify:
false cells with no claim being made (no moat lost or won).You are a matrix spot-check subagent. Budget: 25 browse cloud calls TOTAL across all cells.
Stop and return what you have when you hit the budget — partial fact-check is
better than blocking the rest of the pipeline.
TOOL RULES: Bash ONLY. browse cloud search + browse cloud fetch. Count your calls; stop at 25.
PRIORITY ORDER (highest-stakes first — work down until budget):
1. Every cell that appears in userCompany.winningSummary or losingSummary
2. Compliance cells (SOC 2, HIPAA, ISO 27001) for user + every competitor
3. Open-source / self-hostable + license cells across all competitors
4. Pricing tier numbers ($X/mo, /hr) for user + competitors named in summaries
5. Funding / employee_estimate fields (only if cited in summaries)
Skip:
- Universal cells (REST API, JSON responses, Python SDK, API-key auth, etc.)
- `false` cells where no claim is being made
- Integration matrix cells unless they appear in summaries
For each cell verified:
- If `true` — find one source URL (docs, trust portal, GitHub LICENSE, etc).
- If `false` — one targeted browse cloud search. Flip ONLY on first-party evidence.
Output: matrix.json with `sources: { "Feature": "https://..." }` on the
verified cells (other cells stay as-is). Cells-changed log to
{OUTPUT_DIR}/matrix_fact_check.md with each flip + URL + quoted evidence.
Report back: "spot-check: N cells verified, M flipped, B/25 budget used".
Full-sweep mode (opt-in, slower): if the user explicitly says "full fact check" or for a high-stakes deliverable (board deck, press release), set the budget to 80 calls and verify every non-universal cell. Default is spot-check.
After the subagent completes, re-read matrix.json, recompile, and surface matrix_fact_check.md delta to the user. The summary is much more trustworthy with spot-check than without — and ships in 3-5 minutes instead of stalling the pipeline.
Depends on fact-checked matrix.json from Step 5c. This is a sales-enablement lane. For each competitor, launch a Bash-only synthesis subagent (no new browse cloud calls) that reads all 5 existing partials + the user's merged .md + fact-checked matrix.json, and produces per-competitor Landmines / Objection Handlers / Talk Tracks grounded in cited evidence.
Prompt template: references/battle-card-subagent.md (substitute {COMPETITOR_SLUG} / {COMPETITOR_NAME} / {USER_COMPANY_NAME} / {USER_WINNING_SUMMARY} per competitor). Format spec: references/battle-card.md.
Output: {OUTPUT_DIR}/partials/{slug}.battle.md with a ## Battle Card section.
Re-run the merge after this lane completes. The Step 5 merge ran before the battle partials existed, so the consolidated {slug}.md files don't contain them yet. Re-run:
node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}
This unions each {slug}.battle.md into its consolidated {slug}.md (the battle lane is already handled by merge_partials.mjs). compile_report.mjs reads the ## Battle Card section from {slug}.md and renders it as a brand-accented card on the per-competitor HTML page. Skip this re-merge and the battle cards never appear in the report.
Why this lane is synthesis-only — battle cards must be grounded in facts that already survived Step 5c. Letting the subagent do fresh browse cloud searches would reintroduce the hallucinated-moat problem the fact-check step exists to prevent. The subagent's adversarial self-check explicitly rejects claims not traceable to an input partial bullet or a sources-backed matrix cell.
Parallelism: 1 subagent per competitor, all in one Agent-tool message (synthesis is fast, ~3-5 Bash calls per subagent). Skip this step in quick mode — there isn't enough research depth to ground the cards credibly.
Capture a homepage hero screenshot per competitor:
node {SKILL_DIR}/scripts/capture_screenshots.mjs {OUTPUT_DIR} --mode remote
Uses the browse CLI (npm install -g browse). The --mode flag selects the browser session: remote (default) drives a Browserbase session — best for protected/bot-detecting homepages and the only option without local Chrome; local uses Chrome on your machine. The script passes the corresponding --remote / --local flag on each browse command, so there is no separate environment-config step to run. Writes one PNG per competitor to {OUTPUT_DIR}/screenshots/{slug}-hero.png. The compile step in Step 7 auto-embeds the hero on each per-competitor HTML page.
Cost: ~10-20s per competitor. ~60s for 5 competitors.
Generate all views + CSV (opens overview in browser):
node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open
Produces:
{OUTPUT_DIR}/index.html — overview: competitor table with tagline, pricing summary, key features, strategic diff{OUTPUT_DIR}/competitors/{slug}.html — per-competitor deep dive (all sections){OUTPUT_DIR}/matrix.html — side-by-side feature/pricing matrix{OUTPUT_DIR}/mentions.html — chronological feed with source-type pills + client-side filter{OUTPUT_DIR}/results.csv — flat spreadsheetPresent a chat summary:
## Competitor Analysis Complete
- **Competitors researched**: {count}
- **Depth mode**: {mode}
- **Mentions collected**: {total mentions} across {source types count} source types
- **Public benchmarks found**: {count}
- **Opened in browser**: ~/Desktop/{company_slug}_competitors_{date}/index.html
| Competitor | Positioning | Pricing | Key Features | Strategic Diff |
|------------|-------------|---------|--------------|----------------|
| Rival Co | AI-native web search API | $99/mo entry | semantic search, reranking, crawler | Similar retrieval; cheaper entry |
npx claudepluginhub browserbase/skills --plugin browseAnalyzes competitor landscape and creates SEO-optimized comparison pages, battle cards, SWOT analyses, and positioning maps using structured research frameworks.
Analyzes competitors in real-time using Bright Data web scraping to uncover pricing, features, reviews, hiring, and strategy. Useful for market research and competitive analysis.
Analyzes competitors via interactive questioning and 4 specialized agents, producing competitive matrices, SWOT analyses, gap analyses, battlecards, strategies, and optional charts.