competitor-analysis

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Competitor Analysis

竞品分析

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.

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

json

"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

$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):

All web searches: use
```
browse cloud search
```
. NEVER WebSearch.
All page fetches: use
```
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.
All research output: subagents write one markdown file per competitor to
```
{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.

Report compilation: use

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.

URL deduplication:

node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor

Subagents must use ONLY the Bash tool.
Main agent NEVER reads raw discovery JSON batch files.

CRITICAL — Minimize permission prompts:

Subagents MUST batch ALL file writes into a SINGLE Bash call using chained heredocs.
Batch ALL searches and ALL fetches into single Bash calls via
```
&&
```
chaining.

分析用户的竞品。使用Browserbase Search API进行竞品发现，并采用四维度的计划→调研→整合模式进行信息补充，最终输出包含概览、单竞品深度剖析、功能/价格对比矩阵、按时间排序的提及动态的HTML报告。

必填项：需配置

BROWSERBASE_API_KEY

环境变量，且已安装

browse

CLI工具（执行

npm install -g browse

）。

首次运行设置：首次运行时，系统会提示你批准

browse cloud fetch

、

browse cloud search

、

cat

、

mkdir

、

sed

等命令。为每个命令选择**"Yes, and don't ask again for: browse cloud fetch:*"**（或等效选项）。若要永久批准，可将以下内容添加到

~/.claude/settings.json

中的

permissions.allow

字段：

json

"Bash(browse:*)", "Bash(bunx:*)", "Bash(bun:*)", "Bash(node:*)",
"Bash(cat:*)", "Bash(mkdir:*)", "Bash(sed:*)", "Bash(head:*)", "Bash(tr:*)", "Bash(rm:*)"

路径规则：在Bash中始终使用完整的字面路径——禁止使用

或

$HOME

。仅解析一次主目录并全局使用该路径。构建subagent提示词时，将

{SKILL_DIR}

替换为完整的字面路径。

输出目录：所有输出内容均保存至

~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}/

。该目录包含每个竞品对应的

.md

文件，以及生成的HTML视图和CSV文件。

重要提示——工具限制（适用于主Agent和所有subagent）：

所有网页搜索：使用
```
browse cloud search
```
。禁止使用WebSearch。
所有页面抓取：使用
```
browse cloud fetch --allow-redirects
```
（默认返回markdown格式；若需要原始HTML，添加
```
--format raw
```
参数，然后通过
```
sed ... | tr -s ' \n'
```
提取文本）。禁止使用WebFetch。响应限制为1MB——对于JS密集型页面，改用
```
browse get markdown
```
（需先执行
```
browse open <url> --remote
```
）。
所有调研输出：subagent需使用bash heredoc将每个竞品的调研内容写入单独的markdown文件，路径为
```
{OUTPUT_DIR}/{competitor-slug}.md
```
。禁止使用Write工具或
```
python3 -c
```
命令。文件格式可参考
```
references/example-research.md
```
。

报告编译：执行

node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open

——一步生成

index.html

、

competitors/*.html

、

matrix.html

、

mentions.html

、

results.csv

文件，并自动打开概览页面。

URL去重：执行

node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor

。

subagent仅允许使用Bash工具。
主Agent禁止读取原始的发现JSON批量文件。

重要提示——最小化权限提示：

subagent必须通过链式heredoc将所有文件写入操作批量处理为单次Bash调用。
通过
```
&&
```
链式调用，将所有搜索和抓取操作批量处理为单次Bash调用。

Pipeline Overview

流程概述

Follow these 8 steps in order. Do not skip or reorder.

User Company Research — Deeply understand the user's company, produce
```
precise_category
```
+
```
category_include_keywords
```
+
```
exclusion_list
```
Depth Mode + Seed Input — Choose depth, accept optional seed competitor URLs
Discovery (3 parallel waves) — Wave A (alternatives), Wave B (precise category), Wave C (comparison-page graph via "X vs Y" title parsing)
Gate —
```
scripts/gate_candidates.mjs
```
fetches each candidate's hero text (via
```
browse cloud fetch
```
) and drops wrong-category URLs
Confirm enrichment set with the user — Present PASS / UNKNOWN / rejected-brand-matches via
```
AskUserQuestion
```
. 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)
Deep Enrichment (5 subagents per competitor in deep/deeper modes) — Marketing, Discussion, Social, News, Technical — each lane a separate subagent writing to
```
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.
Screenshots —
```
capture_screenshots.mjs
```
via the
```
browse
```
CLI captures a 1280×800 homepage hero per competitor
HTML Report — Overview + per-competitor (with embedded hero screenshot + Battle Card card) + matrix + mentions views

请按以下8个步骤依次执行，不得跳过或调整顺序。

用户公司调研——深入了解用户公司，生成
```
precise_category
```
（精准分类）+
```
category_include_keywords
```
（分类包含关键词）+
```
exclusion_list
```
（排除列表）
深度模式 + 初始输入——选择调研深度，接收可选的初始竞品URL
竞品发现（3轮并行）——A轮（替代产品）、B轮（精准分类）、C轮（通过解析"X vs Y"标题提取对比页面图谱）
筛选门控——
```
scripts/gate_candidates.mjs
```
通过
```
browse cloud fetch
```
获取每个候选竞品的核心文本，剔除不符合分类的URL
与用户确认待调研竞品集合——通过
```
AskUserQuestion
```
展示通过/未知/已排除的品牌匹配结果。用户勾选真实竞品，并补充未被发现的竞品。跳过此步骤会造成资源浪费，因为调研成本高昂（25个subagent × 深度预算），且门控机制并非完美（JS密集型首页、Cloudflare验证、语义变体标语均可能导致误判）
深度调研（深度/超深度模式下，每个竞品对应5个subagent）——营销、讨论、社交、新闻、技术维度，每个维度由独立的subagent负责并写入
```
partials/
```
目录；随后由
```
merge_partials.mjs
```
整合内容。在深度/超深度模式下，步骤5c事实核查完成后，新增第6个维度——战斗卡片合成，生成基于引用证据的单竞品雷区/异议处理话术/沟通脚本。
截图——通过
```
browse
```
CLI执行
```
capture_screenshots.mjs
```
，为每个竞品截取1280×800像素的首页核心区域截图
HTML报告——包含概览+单竞品详情（嵌入首页截图+战斗卡片）+对比矩阵+提及动态视图

Step 0: Setup Output Directory

步骤0：设置输出目录

bash

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

bash

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:

bash

rm -f "$OUTPUT_DIR"/*.md && rm -rf "$OUTPUT_DIR"/partials "$OUTPUT_DIR"/screenshots

bash

OUTPUT_DIR=~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}
mkdir -p "$OUTPUT_DIR"

将

{company_slug}

替换为用户公司名称（小写，连字符分隔），

{YYYY-MM-DD}

替换为当前日期。将完整的字面路径

{OUTPUT_DIR}

传递给所有subagent。

清理之前运行留下的发现批量文件：

bash

rm -f /tmp/competitor_discovery_batch_*.json

重新运行必须从干净的
$OUTPUT_DIR
开始。

compile_report.mjs

会读取目录中所有

{slug}.md

文件，而

merge_partials.mjs

仅覆盖当前集合中的竞品文件——不会删除新调研集合中已移除的旧竞品文件。由于目录按日期命名，同一天内使用不同竞品集合重新运行会导致概览、矩阵、CSV和截图中存在过时的竞品信息。需使用新目录或先清理之前的单竞品文件：

bash

rm -f "$OUTPUT_DIR"/*.md && rm -rf "$OUTPUT_DIR"/partials "$OUTPUT_DIR"/screenshots

Step 1: User Company Research

步骤1：用户公司调研

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
```
:
- marketing — tagline, positioning, pricing tiers, features, integrations, open-source components (SDK repos + licenses), regions offered, compliance (SOC 2 / HIPAA / trust portal URL)
- technical — REST + streaming API support (with docs URLs), SDK languages, MCP server URL, neural vs keyword retrieval modes, reranking / highlights / live-crawl specifics, published uptime SLA (actual %, not status page), third-party retrieval-quality benchmarks
- discussion, social, news — optional in quick mode, recommended in deep+ See
```
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

此步骤定义了"竞品"的基准，同时为步骤5b的对比矩阵提供

userCompany

行的验证数据。

规则：用户公司需获得与竞品相同的5维度调研深度。禁止凭记忆填充

userCompany

信息——错误信息会传递给用户团队。在某次基于搜索API的运行中（用户公司为Exa，日期2026-04-23），跳过此步骤导致对比矩阵错误宣称Exa拥有"已发布的正常运行时间SLA"（实际上没有公开的数字SLA，仅提供状态页面），并将其MIT许可的Python SDK标记为

open-source: false

（该仓库地址为github.com/exa-labs/exa-py，已确认许可证为MIT）。这两个错误都会在"你的优势"卡片中被当作虚假的护城河。

流程：

向用户询问其公司名称或URL。
检查是否存在已有档案：查看
```
{SKILL_DIR}/profiles/{company-slug}.json
```
。若存在，加载档案并与用户确认："我有你在{researched_at}的档案，是否仍然准确？"——若用户确认是，跳至步骤2，但仍需运行部分维度的调研，以便对比矩阵合成时有最新的功能证据。该档案格式与
```
company-research
```
共享（结构相同）。若用户已在
```
company-research/profiles/
```
下保存档案，可将其复制到本技能的profiles目录，无需重新调研。
对用户公司执行完整的5维度调研——与步骤5中的竞品调研模式完全相同。针对每个维度，启动仅使用Bash的subagent，将内容写入
```
{OUTPUT_DIR}/partials/{user-slug}.{lane}.md
```
：
- marketing（营销）——标语、定位、定价层级、功能、集成、开源组件（SDK仓库+许可证）、服务区域、合规认证（SOC 2 / HIPAA / 信任门户URL）
- technical（技术）——REST+流API支持（含文档URL）、SDK语言、MCP服务器URL、神经检索vs关键词检索模式、重排序/高亮/实时抓取细节、已发布的正常运行时间SLA（实际百分比，而非状态页面）、第三方检索质量基准
- discussion（讨论）、social（社交）、news（新闻）——快速模式下可选，深度+模式下推荐执行具体子问题可参考
```
references/research-patterns.md
```
  →"Self-Research（自我调研）"。每个发现必须引用URL。
对用户公司的部分文件运行
```
merge_partials.mjs
```
——生成
```
{OUTPUT_DIR}/{user-slug}.md
```
，这是步骤5b读取
```
userCompany
```
标记的标准数据源。
整合为档案：公司、产品、现有客户、竞品（初始列表）、使用场景、precise_category（精准分类）、category_include_keywords（分类包含关键词）、exclusion_list（排除列表）。无需包含ICP（理想客户画像）——本技能不需要此信息。
- ```
precise_category
```
  ：一句话描述分类，例如"面向Agent的AI网页搜索API，支持神经+关键词检索"。避免使用"工具"/"平台"等模糊词汇。
- ```
category_include_keywords
```
  ：8-15个直接竞品营销内容（核心文案或标题）中可能包含的短语，需涵盖语义变体。
- ```
exclusion_list
```
  ：表示不同分类的短语——用于门控机制排除误判的竞品（例如
```
antidetect browser
```
  、
```
scraping api
```
  、
```
screenshot api
```
  、
```
residential proxy
```
  ）。具体格式和示例可参考
```
references/research-patterns.md
```
  →"Synthesis Output（整合输出）"中的Exa案例。
将档案+用户公司的
```
.md
```
文件展示给用户确认。获得确认后方可继续。

保存已确认的档案至

{SKILL_DIR}/profiles/{company-slug}.json

。

Step 2: Depth Mode + Seed Input

步骤2：深度模式 + 初始输入

Ask clarifying questions via

AskUserQuestion

with checkboxes:

Known competitors? Text area for URLs/names (optional — discovery will find more).
Depth mode?
- ```
quick
```
  — marketing surface only, many competitors, ~2-3 tool calls each
- ```
deep
```
  — + external signal (mentions, reviews, news), ~5-8 tool calls each
- ```
deeper
```
  — + public benchmarks + strategic diff vs user's company, ~10-15 tool calls each
Target count? Rough number of competitors to research (e.g., 10 / 20 / 50).

This 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

通过

AskUserQuestion

向用户询问以下澄清问题（带复选框）：

已知竞品？ 文本框用于输入URL/名称（可选——发现流程会找到更多竞品）。
深度模式？
- ```
quick
```
  （快速）：仅调研营销表层，覆盖更多竞品，每个竞品约2-3次工具调用
- ```
deep
```
  （深度）：+外部信号（提及、评论、新闻），每个竞品约5-8次工具调用
- ```
deeper
```
  （超深度）：+公开基准+与用户公司的战略差异，每个竞品约10-15次工具调用
目标数量？ 待调研竞品的大致数量（例如10/20/50）。

这是唯一的用户交互步骤。完成后，将静默执行直至报告生成。

模式	单竞品调研内容	适用场景
`quick`	仅维度1（首页+定价）	快速扫描约30-50个竞品
`deep`	维度1+2	约15-25个竞品，包含外部信号
`deeper`	全部4个维度（+基准+战略差异）	约5-15个竞品，获取完整情报

Step 3: Discovery (3 parallel waves)

步骤3：竞品发现（3轮并行）

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
2-3 queries composed from the most distinctive tokens (e.g.
```
"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)

After the searches, run
```
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:

Issue 3 parallel
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.

After all waves complete:

bash

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

Filter
```
/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.
For
```
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.
Merge with user-provided seed URLs. Dedup by hostname →
```
/tmp/competitor_candidates.txt
```
.

公式：每轮执行

ceil(target_count / 20)

次查询。需超量发现约3倍的竞品，因为门控机制会剔除约40-60%的候选。

基于搜索API运行的评估显示，三轮发现是互补的——跳过任何一轮都会遗漏真实竞品：

A轮——通用替代产品（范围广；聚合器噪音多，后续会过滤）

```
"alternatives to {user_company}"
```
```
"{user_company} competitors"
```

B轮——精准分类（使用档案中的

precise_category

）

直接使用
```
"{precise_category}"
```
2-3个由最具辨识度的词汇组成的查询（例如
```
"web search api for ai agents"
```
、
```
"retrieval API for LLMs"
```
）

C轮——对比页面图谱（精准度最高）

```
"{user_company} vs"
```

"{seed1} vs"

、

"{seed2} vs"

、

"{seed3} vs"

（种子来自档案中的

competitors

列表）

搜索完成后，运行
```
scripts/extract_vs_names.mjs
```
解析结果标题中的"X vs Y"模式——这能独特地发现未作为URL结果出现的竞品。

流程:

在单次消息中发起3个并行的
browse cloud search
Bash调用（每轮一个）——不使用subagent。每个Bash调用通过
```
&&
```
链式执行其2-4个查询。具体示例可参考
```
references/workflow.md
```
→"Discovery — parallel Bash, not subagents（发现——并行Bash，不使用subagent）"。对于6-12次
```
browse cloud search
```
调用的工作量，subagent过于笨重。

所有轮次完成后：

bash

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
```
——移除博客文章、新闻、AI工具目录（seektool.ai、respan.ai、agentsindex.ai、toolradar.com、aitoolsatlas.ai、vibecodedthis.com等）、评论聚合器（g2.com、capterra.com）、数据库（crunchbase.com、tracxn.com）以及用户自身的域名。完整的噪音域名列表可参考
```
references/workflow.md
```
。
对于
```
vs_names
```
中已解析出
```
domain
```
的条目，添加其URL；对于未解析的名称，可选择性执行
```
browse cloud search "{name}" --num-results 3
```
并选择排名第一的根域名。
与用户提供的初始竞品URL合并，按主机名去重→生成
```
/tmp/competitor_candidates.txt
```
。

Step 4: Gate (category-fit filter)

步骤4：门控（分类匹配筛选）

Drop candidates whose marketing identifies them as a different category before enrichment burns tool calls on them.

bash

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.

在调研消耗工具调用前，剔除那些营销内容显示属于不同分类的候选竞品。

bash

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

门控机制通过

browse cloud fetch --allow-redirects --format raw

获取每个候选竞品的首页，提取前800个可见文本字符，并根据位置进行分类：标题中包含排除关键词→拒绝；标题中包含包含关键词→通过；混合标题→取核心200字符判断；否则进入未知状态。

基于搜索API运行的评估：12个混合候选中，7个真实竞品全部通过，4个错误分类的全部被拒绝，1个已知混合边缘案例被拒绝。

Step 4.5: Confirm enrichment set with the user

步骤4.5：与用户确认待调研竞品集合

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:

JS-heavy homepages (e.g. Tavily, Firecrawl) —
```
browse cloud fetch
```
returns near-empty text, so keyword matching has nothing to match on → REJECT or UNKNOWN
Cloudflare challenge pages (e.g. Perplexity) — title becomes "Just a moment..." → no category signal
Semantic variants — "search foundation" / "retrieval backbone" don't lexically match a list centered on "search API"
Domain ambiguity —
```
brave.com
```
(the browser) vs
```
api-dashboard.search.brave.com
```
(the actual API product) can confuse classification

The user almost always has domain knowledge the skill lacks. Ask them.

Process — the main agent:

Read
```
/tmp/competitor_gated.jsonl
```
and group rows:
- PASS bucket: everything with status=PASS.
- UNKNOWN bucket: status=UNKNOWN (fetch failed — always surface, these are the silent misses).
- Rejected-brand bucket: top ~10 REJECT rows whose title mentions a well-known brand pattern (e.g. contains the token from a user-supplied seed list, or appears frequently in the Wave C "X vs Y" graph).
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.

此步骤为必填项。不得仅因门控机制运行完成就跳过调研确认。

调研成本高昂：5个竞品×5个维度subagent=25个subagent，约10-15分钟耗时，约300次

browse cloud

调用。在错误的集合上运行会浪费所有资源。门控机制也存在已知的盲区：

JS密集型首页（例如Tavily、Firecrawl）——
```
browse cloud fetch
```
返回近乎空的文本，关键词匹配无内容可匹配→拒绝或未知
Cloudflare验证页面（例如Perplexity）——标题变为"Just a moment..."→无分类信号
语义变体——"search foundation"/"retrieval backbone"与以"search API"为核心的列表在词汇上不匹配
域名歧义——
```
brave.com
```
（浏览器）vs
```
api-dashboard.search.brave.com
```
（实际API产品）可能导致分类混淆

用户几乎总是拥有技能所不具备的领域知识，需向用户确认。

流程——主Agent：

读取
```
/tmp/competitor_gated.jsonl
```
并分组：
- 通过桶：所有status=PASS的条目。
- 未知桶：status=UNKNOWN的条目（抓取失败——必须展示，这些是潜在的遗漏）。
- 已排除品牌桶：约10个标题提及知名品牌模式的REJECT条目（例如包含用户提供的初始列表中的词汇，或频繁出现在C轮"X vs Y"图谱中）。
向用户展示这些分组，每个分组对应一个表格，包含URL+标题+拒绝原因（针对已排除条目）。
使用
```
AskUserQuestion
```
提供三个桶中所有候选的复选框列表，以及一个自由文本的"添加更多"字段。提示词需明确：
"以下是门控筛选出的候选，加上一些不确定的条目。请勾选你所在领域的真实竞品，并粘贴我遗漏的URL（逗号分隔）。调研将仅针对勾选的集合执行。"
将确认后的集合写入
```
/tmp/competitor_enrichment_set.txt
```
（每行一个URL）。这是步骤5的输入——而非
```
/tmp/competitor_passed.txt
```
。

若用户未回复或明确表示"直接运行"，则默认使用

/tmp/competitor_passed.txt

，但需在聊天中警告此次运行可能会因错误分类的候选而浪费预算。

Exa测试（2026-04-24）：门控自动通过了101个候选中的22个，但遗漏了Tavily（通用标题）、Jina AI（语义不匹配——"search foundation"）、Firecrawl（JS密集型抓取失败）和Perplexity（Cloudflare验证）。这四个都是真实的直接竞品，此步骤可捕获它们。

Step 5: Deep Enrichment

步骤5：深度调研

Two modes. See

references/workflow.md

for prompt templates and wave management. See

references/research-patterns.md

for the lane-by-lane methodology.

分为两种模式。提示词模板和批量管理可参考

references/workflow.md

。各维度方法可参考

references/research-patterns.md

。

Quick mode — single subagent per batch

快速模式——每批次一个subagent

Input:
```
/tmp/competitor_enrichment_set.txt
```
(user-confirmed set from Step 4.5), ~8 competitors per subagent.
One subagent runs Lane A only (marketing surface). 2-3 tool calls each.
Writes directly to
```
{OUTPUT_DIR}/{slug}.md
```
.

输入：
```
/tmp/competitor_enrichment_set.txt
```
（步骤4.5中用户确认的集合），每个subagent处理约8个竞品。
一个subagent仅运行A维度（营销表层）。每个竞品2-3次工具调用。
直接写入
```
{OUTPUT_DIR}/{slug}.md
```
。

Deep / Deeper mode — 5 subagents PER competitor (parallel lane fan-out)

深度/超深度模式——每个竞品对应5个并行subagent（维度并行展开）

For each competitor, launch 5 parallel subagents, one per lane:

A. Marketing (
```
marketing
```
): pricing, features, positioning, integrations, customers, team, funding, HQ. Owns canonical frontmatter.

B. Discussion (

discussion

): Reddit, HN, forums, Dev.to, Hashnode. Broad queries beyond

site:

— also

"{competitor}" review 2026

"{competitor}" issues OR problems

"{competitor}" discussion

C. Social (
```
social
```
): LinkedIn posts, YouTube videos, Twitter/X. Snippets only — do NOT fetch.
D. News & Comparisons (
```
news
```
): TechCrunch, Verge, VentureBeat, Forbes, Businesswire, Substack, blog reviews. Every mention needs a date.
E. Technical & Benchmarks (
```
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.

针对每个竞品，启动5个并行subagent，每个维度一个：

A. Marketing（营销）：定价、功能、定位、集成、客户、团队、融资、总部。负责标准前置内容。
B. Discussion（讨论）：Reddit、HN、论坛、Dev.to、Hashnode。使用广泛的查询，而非仅
```
site:
```
——例如
```
"{competitor}" review 2026
```
、
```
"{competitor}" issues OR problems
```
、
```
"{competitor}" discussion
```
。
C. Social（社交）：LinkedIn帖子、YouTube视频、Twitter/X。仅提取片段——禁止抓取完整内容。
D. News & Comparisons（新闻与对比）：TechCrunch、Verge、VentureBeat、Forbes、Businesswire、Substack、博客评论。每个提及需包含日期。
E. Technical & Benchmarks（技术与基准）：GitHub基准仓库/PR、性能文章。写入基准数据+技术发现。

每个维度的预算：深度模式=5-8次工具调用，超深度模式=10-15次工具调用。 **在单次Agent工具消息中启动所有竞品×维度的subagent。**例如10个竞品×5个维度=50个并行Agent调用，一次性发起。不得按竞品或维度分批发起——并行执行可将耗时压缩至最慢的单个Agent的耗时（约3-5分钟）。某次实际运行中，按5轮每轮10个调用分批发起耗时25分钟，而并行发起仅耗时5分钟；请勿分批执行。

每个subagent将部分内容写入

{OUTPUT_DIR}/partials/{slug}.{lane}.md

。

重要提示：需将用户公司名称、产品和核心功能原样传递给每个subagent的提示词，以便技术维度进行战略差异分析。需将完整的字面路径

{OUTPUT_DIR}

传递给每个subagent。

Merge partials → canonical per-competitor file

合并部分内容→标准单竞品文件

After all subagents for all competitors complete:

bash

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.

所有竞品的所有subagent完成后：

bash

node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}

将每个竞品的5个部分内容合并为一个

{OUTPUT_DIR}/{slug}.md

文件——去重后的提及内容（按日期降序排序）、去重后的基准数据、合并后的发现、来自营销维度的标准前置内容。

Synthesize the comparison matrix (write

matrix.json

)

合成对比矩阵（写入

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:

json

{
  "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.

subagent以散文形式写入
key_features
和
integrations
，而非竖线分隔的原子功能标签。因此，简单的竖线分割会导致每个竞品的内容是独立的大段文本，无重叠——渲染后的矩阵会呈现无用的对角线。

主Agent通过在所有竞品间合成共享分类体系并写入

{OUTPUT_DIR}/matrix.json

来解决此问题。

compile_report.mjs

会自动检测该文件，并据此渲染矩阵，而非使用竖线分割的原始内容。

流程——主Agent：

读取所有
```
{slug}.md
```
文件，包括步骤1生成的用户公司文件
{user-slug}.md
。用户公司作为矩阵中的第0个竞品——需以相同的严谨性处理。
生成12-20个原子化的功能列表——每个功能必须是竞品具备或不具备的是非命题（例如"MCP服务器"、"SOC 2"、"站点爬虫"、"重排序器"）。避免句子长度的功能描述。避免仅单个竞品具备的功能。
生成10-20个集成列表（框架、市场、SDK语言）。
针对每个公司（包括用户公司），根据其
```
.md
```
文件中的调研数据，将每个分类条目映射为
```
true
```
/
```
false
```
。**每个标记必须可追溯到带有引用URL的调研发现要点。**如果用户公司的文件显示"exa-py MIT许可（github.com/exa-labs/exa-py）"，则开源功能标记为
```
true
```
，并以该URL为来源。若未提及，则标记为
```
false
```
。

将结果写入

{OUTPUT_DIR}/matrix.json

，格式如下：

json

{
  "category": "AI search APIs",
  "features": [{ "name": "Web Search API", "description": "..." }, ...],
  "integrations": [{ "name": "LangChain" }, ...],
  "userCompany": {
    "name": "Exa",
    "winningSummary": "Exa的护城河是其自研神经索引和集成的Research API——集合中没有其他厂商在语义/嵌入原生检索原语的同时提供多步骤Agent化研究端点。它也是唯一捆绑爬虫产品的提供商，并且在SDK语言覆盖广度上与SerpAPI持平。",
    "losingSummary": "Exa在运营透明度上落后于竞品——SerpAPI、Serper和Tavily都发布了每小时吞吐量SLA，而Exa缺少SerpAPI、Serper和You.com都提供的专属新闻端点。与5个竞品中的4个相比，Exa还缺少图片/视觉搜索功能。",
    "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
为必填项。概览页面会渲染两张卡片——"{用户公司}的优势"和"{用户公司}的劣势"。从自我调研档案（步骤1）中填充

userCompany.features

和

userCompany.integrations

。若无此字段，这两张卡片将无法渲染。

写入顺序（两次传递——解决以下明显的顺序矛盾）。在此步骤（5b）中，写入

userCompany

和所有竞品的所有

features

integrations

单元格，以及草稿版

winningSummary

losingSummary

。草稿仅用于告知步骤5c的事实核查员哪些主张是高风险的（优先核查摘要中提及的单元格）。步骤5c根据验证证据修改单元格后，重写两个摘要，使文本仅反映经过事实核查的单元格。上述JSON格式为最终的核查后对象。

强烈建议填写
userCompany.winningSummary
/
losingSummary
（分析师风格的散文，每部分2-4句话）。填写后，卡片会以段落形式渲染，而非项目符号列表——更像简报而非电子表格。若未填写，卡片会退化为包含优势/劣势项及其他竞品情况的项目符号列表。

若跳过此步骤，矩阵视图会退化为使用原始竖线分割的内容（无法进行原子化对比），且战略摘要无法渲染。请勿跳过。

Fact-check the matrix — spot-check the high-stakes cells (default)

对比矩阵事实核查——抽查高风险单元格（默认）

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:
- Anything claimed as a moat in
```
winningSummary
```
- Anything claimed as a gap in
```
losingSummary
```
- Compliance (SOC 2, HIPAA, ISO 27001, GDPR)
- Open-source license claims (MIT / Apache 2.0 / AGPL — observed wrong on a competitor's SDK)
- Published uptime SLA (status page ≠ SLA)
Across competitors, only the cells that drive the win/loss summary:
- For each "Winning" claim, verify the user has it AND verify the competitors don't.
- For each "Losing" claim, verify the named competitors do have it.
- Compliance + license + SLA across all competitors (high-trust, frequently wrong).
Do NOT verify:
- Universal table-stakes (REST API, JSON responses, Python SDK, API-key auth) — every search API has these.
- ```
false
```
  cells with no claim being made (no moat lost or won).
- Integration cells unless they appear in the win/loss summary.

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.

不得仅依赖分类传递的结果信任高风险单元格。这是基于散文的LLM推理，会产生虚假的护城河。在2026-04-23的搜索API运行中观察到：matrix.json宣称SOC 2是用户公司独有的；但验证显示其他三个竞品也拥有SOC 2 Type II认证。

但核查所有单元格是另一种错误。7家公司×33个维度的矩阵有231个单元格。2026年4月的搜索API运行在核查到111+次工具调用时陷入停滞——subagent持续核查在该分类中普遍存在的基础单元格（REST API、JSON响应、Python SDK）。

默认模式=抽查，而非全面核查。仅核查会显著改变战略叙事的单元格。

启动一个仅使用Bash的事实核查subagent（硬预算25次调用），仅针对以下高风险维度：

所有
userCompany.features
和
userCompany.integrations
单元格（用户自身的护城河——这些会直接进入"你的优势"文本）。典型情况：17+16=33个单元格，但大多数是显而易见的（你自己的产品）。重点关注：
- ```
winningSummary
```
  中宣称的任何护城河
- ```
losingSummary
```
  中宣称的任何差距
- 合规认证（SOC 2、HIPAA、ISO 27001、GDPR）
- 开源许可证主张（MIT/Apache 2.0/AGPL——曾在竞品SDK上出现错误）
- 已发布的正常运行时间SLA（状态页面≠SLA）
跨竞品，仅核查影响胜负摘要的单元格：
- 对于每个"优势"主张，验证用户公司具备该功能且竞品不具备。
- 对于每个"劣势"主张，验证提及的竞品具备该功能。
- 所有竞品的合规+许可证+SLA（高信任度，经常出错）。
无需核查：
- 普遍存在的基础功能（REST API、JSON响应、Python SDK、API密钥认证等）——每个搜索API都具备这些功能。
- 未提出主张的
```
false
```
  单元格（无得失的护城河）。
- 集成单元格，除非出现在胜负摘要中。

你是矩阵抽查subagent。预算：所有单元格总计25次browse cloud调用。
达到预算后停止并返回已有结果——部分核查比阻塞整个流程更好。

工具规则：仅使用Bash。browse cloud search + browse cloud fetch。记录调用次数；达到25次即停止。

优先级顺序（高风险优先——按顺序处理直至预算耗尽）：
1. 出现在userCompany.winningSummary或losingSummary中的每个单元格
2. 用户公司+所有竞品的合规单元格（SOC 2、HIPAA、ISO 27001）
3. 所有竞品的开源/可自托管+许可证单元格
4. 用户公司+摘要中提及的竞品的定价层级（$X/月、/小时）
5. 融资/员工估算字段（仅当摘要中引用时）

跳过：
- 普遍存在的单元格（REST API、JSON响应、Python SDK、API密钥认证等）
- 未提出主张的`false`单元格
- 摘要中未提及的集成矩阵单元格

每个被核查的单元格：
- 若为`true`——找到一个来源URL（文档、信任门户、GitHub LICENSE等）。
- 若为`false`——执行一次针对性的browse cloud搜索。仅根据第一方证据修改标记。

输出：在`matrix.json`中为已核查的单元格添加`sources: { "Feature": "https://..." }`（其他单元格保持不变）。将修改记录写入`{OUTPUT_DIR}/matrix_fact_check.md`，包含每个修改+URL+引用证据。返回报告："spot-check: 已核查N个单元格，修改M个，已使用B/25预算"。

全面核查模式（可选，较慢）：若用户明确要求"全面事实核查"或用于高风险交付物（董事会演示文稿、新闻稿），将预算设置为80次调用并核查所有非普遍存在的单元格。默认模式为抽查。

subagent完成后，重新读取matrix.json，重新编译，并向用户展示

matrix_fact_check.md

的差异。经过抽查的摘要比未核查的更可信——且仅需3-5分钟即可完成，不会阻塞流程。

Step 5d: Battle Card synthesis (deep/deeper only, after Step 5c)

步骤5d：战斗卡片合成（仅深度/超深度模式，步骤5c之后）

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:

bash

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.

依赖步骤5c中经过事实核查的matrix.json。这是销售赋能维度。针对每个竞品，启动一个仅使用Bash的合成subagent（不进行新的

browse cloud

调用），读取所有5个现有部分内容+用户合并后的

.md

文件+经过事实核查的

matrix.json

，生成基于引用证据的单竞品雷区/异议处理话术/沟通脚本。

提示词模板：

references/battle-card-subagent.md

（针对每个竞品替换

{COMPETITOR_SLUG}

{COMPETITOR_NAME}

{USER_COMPANY_NAME}

{USER_WINNING_SUMMARY}

）。格式规范：

references/battle-card.md

。

输出：

{OUTPUT_DIR}/partials/{slug}.battle.md

，包含

## Battle Card

章节。

完成此维度后需重新运行合并操作。步骤5的合并操作在战斗部分内容生成之前执行，因此合并后的

{slug}.md

文件不包含这些内容。重新运行：

bash

node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}

将每个

{slug}.battle.md

合并到对应的

{slug}.md

文件中（

merge_partials.mjs

已支持

battle

维度）。

compile_report.mjs

会从

{slug}.md

中读取

## Battle Card

章节，并在单竞品HTML页面上渲染为带有品牌风格的卡片。跳过此重新合并步骤，战斗卡片将不会出现在报告中。

此维度仅进行合成的原因——战斗卡片必须基于步骤5c已验证的事实。允许subagent进行新的

browse cloud

搜索会重新引入事实核查步骤旨在解决的虚假护城河问题。subagent的对抗性自我检查会明确拒绝无法追溯到输入部分要点或

sources

支持的矩阵单元格的主张。

并行性：每个竞品对应一个subagent，全部在单次Agent工具消息中发起（合成速度快，每个subagent约3-5次Bash调用）。快速模式下跳过此步骤——调研深度不足以支撑可信的战斗卡片。

Step 6: Screenshots

步骤6：截图

Capture a homepage hero screenshot per competitor:

bash

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.

为每个竞品截取首页核心区域截图：

bash

node {SKILL_DIR}/scripts/capture_screenshots.mjs {OUTPUT_DIR} --mode remote

使用

browse

CLI（需执行

npm install -g browse

）。

--mode

参数选择浏览器会话：

remote

（默认）使用Browserbase会话——最适合受保护/反爬虫的首页，也是无本地Chrome时的唯一选项；

local

使用本地机器上的Chrome。脚本会在每个

browse

命令中传递对应的

--remote

--local

参数，无需单独进行环境配置步骤。每个竞品的PNG截图保存至

{OUTPUT_DIR}/screenshots/{slug}-hero.png

。步骤7的编译操作会自动将首页截图嵌入每个单竞品HTML页面。

耗时：每个竞品约10-20秒。5个竞品约60秒。

Step 7: HTML Report

步骤7：HTML报告

Generate all views + CSV (opens overview in browser):
bash
```
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 spreadsheet
Present a chat summary:

undefined

生成所有视图+CSV（自动在浏览器中打开概览页面）：
bash
```
node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open
```
生成以下内容：
- ```
{OUTPUT_DIR}/index.html
```
  ——概览：包含标语、定价摘要、核心功能、战略差异的竞品表格
- ```
{OUTPUT_DIR}/competitors/{slug}.html
```
  ——单竞品深度剖析（所有章节）
- ```
{OUTPUT_DIR}/matrix.html
```
  ——功能/价格对比矩阵
- ```
{OUTPUT_DIR}/mentions.html
```
  ——按时间排序的动态流，包含来源类型标签+客户端筛选功能
- ```
{OUTPUT_DIR}/results.csv
```
  ——扁平化电子表格
在聊天中展示总结：

undefined