competitor-intel

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Competitor Intelligence

竞争情报

Real-time competitive intelligence powered by Nimble's web data APIs.

User request: $ARGUMENTS

Before running any commands, read

references/nimble-playbook.md

for Claude Code constraints (no shell state, no

wait

, sub-agent permissions, communication style).

由Nimble网络数据API驱动的实时竞争情报。

用户请求：$ARGUMENTS

在运行任何命令之前，请阅读

references/nimble-playbook.md

了解Claude Code的限制（无shell状态、无

wait

、子代理权限、沟通风格）。

Instructions

操作说明

Step 0: Preflight

步骤0：预检查

Run the preflight pattern from

references/nimble-playbook.md

(5 simultaneous Bash calls: date calc, today, CLI check, profile load, index.md load).

From the results:

CLI missing or API key unset →
```
references/profile-and-onboarding.md
```
, stop
Profile exists → read
```
~/.nimble/memory/competitors/index.md
```
to identify which competitor files exist and their last-updated dates. If the index doesn't exist (first run or upgrade), fall back to reading all
```
~/.nimble/memory/competitors/*.md
```
directly — the index is an optimization, not a gate. Then load the relevant competitor files for known signals (used for dedup in Steps 3 + 5). Follow cross-references (
```
[[path/entity]]
```
links) to load related context. Determine mode using smart date windowing from
```
references/nimble-playbook.md
```
:
- Full mode: first run OR last run > 14 days ago
- Quick refresh: last run < 14 days ago
- Same-day repeat: if
```
last_runs.competitor-intel
```
  is today, check if a report already exists at
```
~/.nimble/memory/reports/competitor-intel-[today].md
```
  . If so, ask: "Already ran today. Run again for fresh data?" Don't silently re-run.
- Skip to Step 2
No profile → Step 1

Note: Step 2 (WSA Discovery) runs after onboarding but before any research.

执行

references/nimble-playbook.md

中的预检查流程（5个同时进行的Bash调用：日期计算、今日日期、CLI检查、配置文件加载、index.md加载）。

根据结果：

CLI缺失或API密钥未设置 → 参考
```
references/profile-and-onboarding.md
```
，停止操作
配置文件存在 → 读取
```
~/.nimble/memory/competitors/index.md
```
，确定已有的竞品文件及其最后更新日期。如果索引不存在（首次运行或升级），则直接读取所有
```
~/.nimble/memory/competitors/*.md
```
文件——索引只是优化手段，而非必要条件。然后加载已知信号的相关竞品文件（用于步骤3和5中的去重）。遵循
```
references/nimble-playbook.md
```
中的智能日期窗口规则确定模式：
- 完整模式：首次运行或上次运行已超过14天
- 快速刷新模式：上次运行距今不足14天
- 当日重复运行：如果
```
last_runs.competitor-intel
```
  是今日，请检查
```
~/.nimble/memory/reports/competitor-intel-[today].md
```
  是否已存在报告。如果存在，请询问：“今日已运行过一次。是否重新运行以获取最新数据？”请勿静默重新运行。
- 跳至步骤2
无配置文件 → 步骤1

注意：步骤2（WSA发现）在完成入职流程后、任何调研之前执行。

Step 1: First-Run Onboarding (2 prompts max)

步骤1：首次运行入职流程（最多2个提示）

Prompt 1 — ask in plain text (NOT AskUserQuestion with options):

"What's your company's website domain? (e.g., acme.com)"

Verify — make two Bash calls simultaneously:

nimble search --query "[domain]" --include-domain '["[domain]"]' --max-results 3 --search-depth lite

nimble search --query "[domain] company" --max-results 5 --search-depth lite

Prompt 2 — confirm company + choose competitor method (use AskUserQuestion):

I found that [Company] ([domain]) is [brief description]. Is this right? And how should I find your competitors?

Yes — find competitors for me

Yes — I'll list them myself

Wrong company — let me clarify

If "find competitors", make three Bash calls simultaneously:

nimble search --query "[Company] competitors" --max-results 10 --search-depth lite

nimble search --query "[Company] vs" --max-results 10 --search-depth lite

nimble search --query "[Company] alternatives" --max-results 5 --search-depth lite

Propose the list. Once the user confirms, create the profile and start Steps 2+3. When creating the profile, also ask for or infer each competitor's domain and the user's industry keywords. See

references/profile-and-onboarding.md

for the full profile schema (company, competitors with domains/categories, industry_keywords, integrations, preferences).

提示1 — 用纯文本询问（不要使用带选项的AskUserQuestion）：

“你的公司网站域名是什么？（例如：acme.com）”

验证——同时进行两个Bash调用：

nimble search --query "[domain]" --include-domain '["[domain]"]' --max-results 3 --search-depth lite

nimble search --query "[domain] company" --max-results 5 --search-depth lite

提示2 — 确认公司信息并选择竞品查找方式（使用AskUserQuestion）：

我发现**[Company]**（[domain]）是[简要描述]。信息正确吗？以及我应该如何查找你的竞争对手？

是 — 帮我查找竞争对手

是 — 我自己列出竞争对手

公司信息错误 — 让我说明

如果选择“帮我查找竞争对手”，同时进行三个Bash调用：

nimble search --query "[Company] competitors" --max-results 10 --search-depth lite

nimble search --query "[Company] vs" --max-results 10 --search-depth lite

nimble search --query "[Company] alternatives" --max-results 5 --search-depth lite

提出竞品列表。一旦用户确认，创建配置文件并开始步骤2和3。创建配置文件时，还需询问或推断每个竞品的域名以及用户所在行业的关键词。完整的配置文件架构（公司信息、带域名/分类的竞品、行业关键词、集成、偏好）请参考

references/profile-and-onboarding.md

。

Step 2: WSA Discovery

步骤2：WSA发现

For each competitor domain and the user's domain, discover available WSAs:

bash

nimble agent list --search "{domain}" --limit 20

Run one search per domain simultaneously. From the results, filter for WSAs with

entity_type

matching SERP or PDP, prefer

managed_by: "nimble"

, and validate each with

nimble agent get --template-name {name}

. Cache discovered WSA names + params for the run. Use discovered WSAs alongside

nimble search

in Steps 3-4 for richer data. If no WSAs found, continue with

nimble search

alone.

针对每个竞品域名和用户公司域名，发现可用的WSA：

bash

nimble agent list --search "{domain}" --limit 20

每个域名同时运行一次搜索。从结果中筛选

entity_type

匹配SERP或PDP的WSA，优先选择

managed_by: "nimble"

的，并通过

nimble agent get --template-name {name}

验证每个WSA。缓存本次运行中发现的WSA名称和参数。在步骤3-4中，将发现的WSA与

nimble search

结合使用以获取更丰富的数据。如果未找到WSA，仅使用

nimble search

继续操作。

Step 3: Research the User's Company

步骤3：调研用户公司

Use

--include-domain

to avoid noise from generic company names. Make two Bash calls:

nimble search --query "product updates OR changelog OR releases" --include-domain '["[company-domain]"]' --start-date "[start-date]" --max-results 5 --search-depth lite

nimble search --query "[UserCompany] news" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

Fallback if < 3 results:

nimble search --query "blog" --include-domain '["[company-domain]"]' --max-results 5 --search-depth lite

使用

--include-domain

避免通用公司名称带来的干扰。进行两个Bash调用：

nimble search --query "product updates OR changelog OR releases" --include-domain '["[company-domain]"]' --start-date "[start-date]" --max-results 5 --search-depth lite

nimble search --query "[UserCompany] news" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

如果结果少于3条的备用方案：

nimble search --query "blog" --include-domain '["[company-domain]"]' --max-results 5 --search-depth lite

Step 4: Parallel Research Per Competitor (sub-agents)

步骤4：针对每个竞品的并行调研（子代理）

Read

references/competitor-agent-prompt.md

for the full agent prompt template. Follow the sub-agent spawning rules from

references/nimble-playbook.md

(bypassPermissions, batch max 4, explicit Bash instruction, fallback on failure).

Spawn

nimble-researcher

agents (

agents/nimble-researcher.md

) with

mode: "bypassPermissions"

. Customize the prompt template with each competitor's name, domain, start-date, known signals from memory (loaded in Step 0), and any discovered WSA names from Step 2 so agents can use them for enrichment.

Call estimation & Scaled Execution: Before launching agents, estimate total API calls: ~6 searches per competitor × N competitors + ~2 industry searches + extractions. For 2+ competitors (12+ calls), tell agents to use

extract-batch

for page extractions instead of individual calls. See the Scaled Execution pattern in

references/nimble-playbook.md

for tier selection.

Also run industry searches directly (not in sub-agents), using

industry_keywords

from the business profile:

nimble search --query "[industry_keyword] AI agents OR automation" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

nimble search --query "[industry_keyword] regulation OR compliance OR pricing" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

完整的代理提示模板请阅读

references/competitor-agent-prompt.md

。遵循

references/nimble-playbook.md

中的子代理生成规则（bypassPermissions、最多批量4个、明确的Bash指令、失败时的备用方案）。

生成

nimble-researcher

代理（

agents/nimble-researcher.md

），设置

mode: "bypassPermissions"

。为每个竞品的名称、域名、起始日期、内存中的已知信号（步骤0中加载）以及步骤2中发现的WSA名称自定义提示模板，以便代理可以使用这些信息进行数据补充。

调用估算与规模化执行：在启动代理之前，估算总API调用次数：每个竞品约6次搜索 × N个竞品 + 约2次行业搜索 + 提取操作。如果有2个及以上竞品（12次及以上调用），告知代理使用

extract-batch

进行页面提取，而非单独调用。规模化执行模式的层级选择请参考

references/nimble-playbook.md

中的相关内容。

同时直接运行行业搜索（不在子代理中运行），使用业务配置文件中的

industry_keywords

：

nimble search --query "[industry_keyword] AI agents OR automation" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

nimble search --query "[industry_keyword] regulation OR compliance OR pricing" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

Step 5: Deep Extraction

步骤5：深度提取

Extract signals that need date verification OR richer detail. See

references/nimble-playbook.md

→ "Signal Date Validation" → "Verification Budget" for the full rules.

Must extract:

All P1 signals (funding, M&A, leadership) — need confirmed details AND date verification
Any signal with
```
DATE_CONFIDENCE: LOW
```
— event date needs verification from page content
Any signal where
```
SOURCE_TYPE: DERIVATIVE
```
— confirm the event date from the actual page content

Extract if useful:

P2 signals where the snippet lacks a date or key detail

Skip: P3 signals with

DATE_CONFIDENCE: HIGH

Make one Bash call per URL, all simultaneously:

nimble extract --url "https://..." --format markdown

For extraction failures, follow the fallback in

references/nimble-playbook.md

When reading extracted content, determine the actual event date from the article body (not just the page header date). Look for: explicit dates tied to the event, temporal language ("last September", "in Q3"), and datelines.

提取需要日期验证或更丰富细节的信号。完整规则请参考

references/nimble-playbook.md

→ "Signal Date Validation" → "Verification Budget"。

必须提取：

所有P1信号（融资、并购、领导层变动）——需要确认的细节和日期验证
任何
```
DATE_CONFIDENCE: LOW
```
的信号——事件日期需要从页面内容中验证
任何
```
SOURCE_TYPE: DERIVATIVE
```
的信号——从实际页面内容中确认事件日期

如有帮助则提取：

片段缺少日期或关键细节的P2信号

跳过：

DATE_CONFIDENCE: HIGH

的P3信号。

每个URL同时进行一次Bash调用：

nimble extract --url "https://..." --format markdown

提取失败时，请遵循

references/nimble-playbook.md

中的备用方案。

读取提取的内容时，从文章正文中确定实际事件日期（不只是页面标题中的日期）。查找：与事件关联的明确日期、时间性语言（“去年9月”、“第三季度”）和新闻导语。

Step 5.5: Signal Validation

步骤5.5：信号验证

Before building the report, validate every signal's freshness. See

references/nimble-playbook.md

→ "Signal Date Validation" for the full pattern.

For each signal from Step 3, classify it:

Check	Result	Action
EVENT_DATE within freshness window + not in memory	NEW	Include
EVENT_DATE within window + updates a known signal	UPDATED	Include as update
EVENT_DATE outside freshness window	STALE	Drop — old event, new article
DATE_CONFIDENCE: LOW + couldn't verify in Step 4	UNCERTAIN	Drop with note

P1 corroboration (mandatory) — any P1 signal with

NEEDS_CORROBORATION: true

MUST be corroborated before it can enter the report. This is a hard gate, not a suggestion.

For each flagged P1, run:

nimble search --query "[Company] [event summary]" --max-results 5 --search-depth lite

Look for the primary source (company blog, press release, official filing). If the primary source dates the event outside the freshness window, reclassify as STALE. If no primary source is found, reclassify as UNCERTAIN and drop.

Drop rules:

Event date is outside the freshness window → STALE
Only sourced from derivative/aggregator sites with no corroborating primary or major outlet → UNCERTAIN, drop unless verified via extraction
Content clearly describes a past event (temporal language like "last year", "back in Q3", "months ago") with event date outside the window → STALE

After validation, you should have a clean list of NEW and UPDATED signals only.

在生成报告之前，验证每个信号的时效性。完整模式请参考

references/nimble-playbook.md

→ "Signal Date Validation"。

针对步骤3中的每个信号进行分类：

检查项	结果	操作
事件日期在时效窗口内且未在内存中	新增	纳入报告
事件日期在窗口内且更新了已知信号	更新	作为更新内容纳入
事件日期在窗口外	过时	丢弃——旧事件，新文章
日期可信度低且步骤4中无法验证	不确定	丢弃并备注

P1信号佐证（强制要求）——任何

NEEDS_CORROBORATION: true

的P1信号必须经过佐证才能纳入报告。这是硬性要求，而非建议。

针对每个标记的P1信号，运行：

nimble search --query "[Company] [event summary]" --max-results 5 --search-depth lite

查找主要来源（公司博客、新闻稿、官方文件）。如果主要来源显示事件日期在时效窗口外，则重新分类为过时。如果未找到主要来源，则重新分类为不确定并丢弃。

丢弃规则：

事件日期在时效窗口外 → 过时
仅来源于衍生/聚合网站，无主要来源或主流媒体佐证 → 不确定，除非通过提取验证否则丢弃
内容明确描述过去的事件（时间性语言如“去年”、“第三季度”、“几个月前”）且事件日期在窗口外 → 过时

验证后，你将得到仅包含新增和更新信号的清晰列表。

Step 6: Analysis & Output

步骤6：分析与输出

Full mode (first run or > 14 days since last) — structured briefing:

TL;DR — 3-5 P1 signals, most recent first, every one dated with source
Per competitor — "Recent" and "Older Context" subsections, "Where They Win vs. Where You Win" table, "What This Means" (1-2 sentences)
Industry Trends — signals from industry searches
Your Company Update — releases/news from Step 2
Cross-Competitor Patterns — converging trends
What This Means for [Company] — strategic implications + suggested actions

Quick refresh mode (last run < 14 days) — short format:

New Signals — dated, with competitor name, priority, and clickable source URL
Nothing New — list competitors with no new signals
Action Items — only if something requires attention

Core rules:

Every signal MUST have a verified event date. Only events that happened within the freshness window qualify as new signals — older events are background context.
Only include signals classified as NEW or UPDATED in Step 5.5. STALE and UNCERTAIN signals have already been dropped.
Deduplicate against
```
~/.nimble/memory/competitors/*.md
```
— only surface NEW findings.
Say "nothing notable this period" rather than padding with fluff.
P3 signals: mention briefly or omit if report is long.

完整模式（首次运行或上次运行已超过14天）——结构化简报：

摘要 — 3-5个P1信号，按最新顺序排列，每个信号都标注日期和来源
按竞品分类 — “近期动态”和“过往背景”子章节、“他们的优势 vs 你的优势”表格、“这意味着什么”（1-2句话）
行业趋势 — 行业搜索得到的信号
你的公司更新 — 步骤2中的发布/新闻信息
跨竞品模式 — 趋同趋势
对[Company]的意义 — 战略影响 + 建议行动

快速刷新模式（上次运行距今不足14天）——简短格式：

新信号 — 标注日期、竞品名称、优先级和可点击的来源URL
无新动态 — 列出无新信号的竞品
行动项 — 仅当有需要关注的内容时列出

核心规则：

每个信号必须有经过验证的事件日期。只有在时效窗口内发生的事件才有资格作为新信号——旧事件仅作为背景信息。
仅纳入步骤5.5中分类为新增或更新的信号。过时和不确定的信号已被丢弃。
与
```
~/.nimble/memory/competitors/*.md
```
中的内容去重——仅展示新发现。
如果本期无重要内容，请说明“本期无显著动态”，不要填充无关内容。
P3信号：简要提及，若报告过长则省略。

Step 7: Save & Update Memory

步骤7：保存与更新内存

Only persist signals that passed Step 5.5 validation (classified as NEW or UPDATED). Do not write STALE or UNCERTAIN signals to competitor memory files.

Make all Write calls simultaneously:

Report →
```
~/.nimble/memory/reports/competitor-intel-[date].md
```
(save the full briefing, not a summary — this is the local source of truth)
Per competitor → append validated signals to
```
~/.nimble/memory/competitors/[name].md
```
(use the format documented in
```
references/memory-and-distribution.md
```
). Add
```
[[path/entity]]
```
cross-references for relationships discovered during research (e.g., key people →
```
[[people/name]]
```
, related competitors →
```
[[competitors/name]]
```
).

Profile → update

last_runs.competitor-intel

~/.nimble/business-profile.json

Follow the wiki update pattern from
```
references/memory-and-distribution.md
```
: update
```
index.md
```
rows for all affected entity files, append a
```
log.md
```
entry for this run.

仅保留通过步骤5.5验证的信号（分类为新增或更新）。请勿将过时或不确定的信号写入竞品内存文件。

同时执行所有写入调用：

报告 →
```
~/.nimble/memory/reports/competitor-intel-[date].md
```
（保存完整简报，而非摘要——这是本地的权威来源）
按竞品分类 → 将验证后的信号追加到
```
~/.nimble/memory/competitors/[name].md
```
（使用
```
references/memory-and-distribution.md
```
中记录的格式）。为调研过程中发现的关系添加
```
[[path/entity]]
```
交叉引用（例如，关键人物 →
```
[[people/name]]
```
，相关竞品 →
```
[[competitors/name]]
```
）。

配置文件 → 更新

~/.nimble/business-profile.json

中的

last_runs.competitor-intel

遵循
```
references/memory-and-distribution.md
```
中的维基更新模式：更新所有受影响实体文件的
```
index.md
```
行，为本次运行追加
```
log.md
```
条目。

Step 7.5: Synthesis Page Generation

步骤7.5：生成综合页面

If 3+ competitors were researched in this run, OR the existing

~/.nimble/memory/synthesis/competitive-landscape.md

has stale source timestamps (source entity files were updated since generation), generate or refresh the synthesis page.

Use the

nimble-analyst

agent (

agents/nimble-analyst.md

) with

mode: "bypassPermissions"

to synthesize patterns across all competitor files. The agent should read all

~/.nimble/memory/competitors/*.md

files and produce a

competitive-landscape.md

following the format in

references/memory-and-distribution.md

— market map, feature comparison, pricing comparison, key patterns, and strategic implications. Cite source entity files with

[[competitors/name]]

links.

Also append any unanswered questions to

~/.nimble/memory/backlog.md

(e.g., competitors where key data like pricing or funding is missing).

After generating, update

index.md

with the synthesis page entry.

如果本次运行调研了3个及以上竞品，或者现有的

~/.nimble/memory/synthesis/competitive-landscape.md

的来源时间戳已过时（来源实体文件自生成后已更新），则生成或刷新综合页面。

使用

nimble-analyst

代理（

agents/nimble-analyst.md

），设置

mode: "bypassPermissions"

，综合所有竞品文件中的模式。代理应读取所有

~/.nimble/memory/competitors/*.md

文件，并按照

references/memory-and-distribution.md

中的格式生成

competitive-landscape.md

——市场图谱、功能对比、定价对比、关键模式和战略影响。使用

[[competitors/name]]

链接引用来源实体文件。

同时将未解答的问题追加到

~/.nimble/memory/backlog.md

（例如，缺少定价或融资等关键数据的竞品）。

生成后，更新

index.md

中的综合页面条目。

Step 8: Share & Distribute

步骤8：分享与分发

Always offer distribution — do not skip this step. Follow

references/memory-and-distribution.md

for connector detection, sharing flow, and source links enforcement.

务必提供分发选项——请勿跳过此步骤。连接器检测、分享流程和来源链接强制要求请遵循

references/memory-and-distribution.md

。

Step 9: Follow-ups

步骤9：后续操作

Go deeper on a competitor → more focused searches
Skip a competitor → update
```
preferences.skip_competitors
```
Add a competitor → update
```
competitors
```
, create memory stub
"Looks good" → done

Sibling skill suggestions:

Next steps:
Run
competitor-positioning
to analyze how competitors present themselves online
Run
company-deep-dive
for a full 360 profile on any competitor from this report
Run
meeting-prep
if you're meeting with someone at a competitor

深入调研某个竞品 → 更聚焦的搜索
跳过某个竞品 → 更新
```
preferences.skip_competitors
```
添加竞品 → 更新
```
competitors
```
，创建内存存根
“看起来不错” → 完成

相关技能建议：

下一步操作：
运行
competitor-positioning
分析竞争对手在网上的自我定位
运行
company-deep-dive
获取本报告中任意竞品的完整360度概况
如果要与竞品人员会面，运行
meeting-prep

Agent Teams Mode (Dual-Mode)

代理团队模式（双模式）

Check at startup:

echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

Team mode (flag set): Spawn full teammates instead of sub-agents:

Lead (you): Assign competitors, synthesize the final briefing
One teammate per competitor: Uses
```
references/competitor-agent-prompt.md
```
with discovered WSAs — teammates can message each other when they find overlapping signals
Devil's Advocate (optional): Challenges findings, looks for blind spots
Lead synthesizes a cross-validated briefing with higher confidence

Solo mode (flag not set): Standard sub-agent flow from Step 3.

启动时检查：

echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

团队模式（已设置标志）：生成完整的团队成员而非子代理：

负责人（你）：分配竞品任务，合成最终简报
每个竞品对应一名团队成员：使用带已发现WSA的
```
references/competitor-agent-prompt.md
```
——团队成员发现重叠信号时可相互沟通
魔鬼代言人（可选）：质疑发现，寻找盲点
负责人合成交叉验证后的简报，可信度更高

单模式（未设置标志）：步骤3中的标准子代理流程。

Error Handling

错误处理

See

references/nimble-playbook.md

for the standard error table (missing API key, 429, 401, empty results, extraction garbage). Skill-specific errors:

Search 500: Retry once without
```
--focus
```
flag. If still failing, retry with a simplified query (shorter terms, no date filter). Log the failure but don't skip the competitor.
Search timeout: Retry once, then skip that call and continue — consistent with the playbook's timeout policy.

标准错误表（缺失API密钥、429、401、空结果、提取无效内容）请参考

references/nimble-playbook.md

。本技能特定错误：

搜索500错误：不使用
```
--focus
```
标志重试一次。如果仍然失败，使用简化查询（更短的术语、无日期筛选）重试。记录失败但不要跳过该竞品。
搜索超时：重试一次，然后跳过该调用继续操作——与手册中的超时政策一致。",