competitor-intel

竞争情报

借助 Nimble 的网络数据 API，实时掌握竞争情报。

用户请求：$ARGUMENTS

运行任何命令之前，请阅读 references/nimble-playbook.md，了解 Claude Code 的约束（无 shell 状态、禁止使用 &/wait、子 Agent 权限、沟通风格）。

---

说明

步骤 0：预检

按照 references/nimble-playbook.md 中的传输方式选择和标准预检流程执行：在会话开始时选择 CLI 或 MCP，然后并行运行标准预检调用（日期计算、今天、配置文件、记忆索引）。

根据结果：

• CLI 缺失或未设置 API 密钥 → 查看 references/profile-and-onboarding.md，然后停止
• 所有 nimble CLI 调用都要添加标记：nimble --client-source nimble-agent-skills <subcommand>。MCP 请求会在传输层进行归因——参见 references/nimble-playbook.md。
• 配置文件已存在 → 读取 ~/.nimble/memory/competitors/index.md，确认有哪些竞争对手文件以及它们最后更新的日期。如果索引不存在（首次运行或升级），则改为直接读取所有 ~/.nimble/memory/competitors/*.md 文件——索引只是优化手段，并非必需。然后加载与已知信号相关的竞争对手文件 （用于步骤 3 和 5 中的去重）。沿交叉引用（[[path/entity]] 链接）加载相关上下文。根据 references/nimble-playbook.md 中的智能日期窗口规则确定模式：
  • **完整模式：**首次运行，或距离上次运行已超过 14 天
  • **快速刷新：**距离上次运行不足 14 天
  • **当天重复运行：**如果 last_runs.competitor-intel 是今天，检查 ~/.nimble/memory/reports/competitor-intel-[today].md 是否已存在。如果存在，询问：“今天已经运行过。是否再次运行以获取最新数据？”不要静默地重复运行。
  • 跳转到步骤 2
• 配置文件不存在 → 步骤 1

**注意：**步骤 2（WSA 发现）在完成引导后、开始任何调研前运行。

步骤 1：首次运行引导（最多 2 个提示）

提示 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。 创建配置文件时，还要询问或推断每个竞争对手的域名以及用户所在行业的关键词。 完整的配置文件结构（company、含域名/类别的 competitors、industry_keywords、 integrations、preferences）请参见 references/profile-and-onboarding.md。

步骤 2：WSA 发现

针对每个竞争对手的域名和用户的域名，查找可用的 WSA：

nimble extract:templates list --limit 100  # then filter items for "{domain}"

每个域名各运行一次搜索，并行执行。根据结果筛选 entity_type 与 SERP 或 PDP 匹配的 WSA，优先选择 managed_by: "nimble"，并使用 nimble extract:templates get --extract-template-name {name} 验证每个 WSA。缓存本次运行发现的 WSA 名称和参数。在步骤 3–4 中，将发现的 WSA 与 nimble search 配合使用，以获取更丰富的数据。如果未找到 WSA，则仅使用 nimble search 继续执行。

步骤 3：研究用户的公司

使用 --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

步骤 4：并行研究各竞争对手（子 Agent）

阅读 references/competitor-agent-prompt.md，获取完整的 Agent 提示词模板。 遵循 references/nimble-playbook.md 中的子 Agent 启动规则 （bypassPermissions、每批最多 4 个、明确的 Bash 指令、失败时使用备用方案）。

使用 mode: "bypassPermissions" 启动 nimble-researcher Agent（agents/nimble-researcher.md）。 根据每个竞争对手的名称、域名、开始日期、记忆中的已知信号（在步骤 0 中加载），以及步骤 2 中发现的 WSA 名称，定制提示词模板，以便 Agent 用这些信息进行信息补充。

调用量估算与扩展执行： 启动 Agent 前，估算 API 调用总量：每个竞争对手约 6 次搜索 × N 个竞争对手 + 约 2 次行业搜索 + 内容提取。 对于 2 个或更多竞争对手（12 次或更多调用），告知 Agent 使用 extract-batch 批量提取网页，而不是逐条调用。有关层级选择，请参阅 references/nimble-playbook.md 中的扩展执行模式。

同时直接执行行业搜索（不通过子 Agent），使用业务档案中的 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

步骤 5：深度提取

提取需要验证日期或补充详细信息的信号。完整规则请参阅 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 月”“第三季度”）以及日期行。

步骤 5.5：信号验证

生成报告前，验证每条信号的新鲜度。完整流程请参阅 references/nimble-playbook.md →“信号日期验证”。

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

检查	结果	操作
EVENT_DATE 在新鲜度窗口内，且不在记忆中	NEW	纳入
EVENT_DATE 在窗口内，且更新了已知信号	UPDATED	作为更新纳入
EVENT_DATE 超出新鲜度窗口	STALE	丢弃——事件已过时，文章是新的
DATE_CONFIDENCE: LOW，且无法在步骤 4 中验证	UNCERTAIN	附注后丢弃

P1 佐证（强制要求）——任何 NEEDS_CORROBORATION: true 的 P1 信号，必须先获得佐证才能纳入报告。这是硬性门槛，而非建议。

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

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

查找一手来源（公司博客、新闻稿、官方文件）。如果一手来源显示事件日期超出新鲜度窗口，则重新分类为 STALE。 如果找不到一手来源，则重新分类为 UNCERTAIN 并丢弃。

丢弃规则：

• 事件日期超出新鲜度窗口 → STALE
• 仅来自衍生内容或聚合网站，且没有佐证的一手来源或主要媒体来源 → UNCERTAIN，除非通过提取验证，否则丢弃
• 内容明显描述过去的事件（例如“去年”“回到第三季度”“几个月前”等时间表述），且事件日期在窗口之外 → STALE

验证完成后，应只保留 NEW 和 UPDATED 信号。

步骤 6：分析与输出

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

• TL;DR——3-5 条 P1 信号，按时间从近到远排列，每条都标注日期和来源
• 按竞争对手分类——“近期”和“较早背景”小节、“他们的优势 vs. 你的优势”表格、“这意味着什么”（1-2 句话）
• 行业趋势——来自行业搜索的信号
• 贵公司动态——步骤 2 中的发布和新闻
• 跨竞争对手模式——趋同趋势
• 这对 [Company] 的意义——战略影响和建议行动

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

• 新信号——标注日期、竞争对手名称、优先级和可点击的来源 URL
• 暂无新动态——列出没有新信号的竞争对手
• 行动项——仅在需要关注时列出

核心规则：

• 每条信号都必须有经过验证的事件日期。只有在新鲜度窗口内发生的事件才符合新信号的条件——更早的事件属于背景信息。
• 仅纳入步骤 5.5 中分类为 NEW 或 UPDATED 的信号。STALE 和 UNCERTAIN 信号已被丢弃。
• 与 ~/.nimble/memory/competitors/*.md 中的内容去重——只呈现新的发现。
• 与其用无关内容凑数，不如说明“本期没有值得关注的动态”。
• P3 信号：简要提及，或在报告较长时省略。

步骤 7：保存并更新记忆

只保存通过步骤 5.5 验证的信号（分类为 NEW 或 UPDATED）。 不要将 STALE 或 UNCERTAIN 信号写入竞争对手记忆文件。

同时执行所有 Write 调用：

• 报告 → ~/.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 中的 wiki 更新模式：更新所有受影响实体文件在 index.md 中的行，并在 log.md 中追加本次运行的条目。

第 7.5 步：生成综合分析页面

如果本次运行中研究了 3 家或更多竞争对手，或者现有的 ~/.nimble/memory/synthesis/competitive-landscape.md 的来源时间戳已过时 （来源实体文件在生成后有所更新），则生成或刷新综合分析页面。

使用 nimble-analyst Agent（agents/nimble-analyst.md），并设置 mode: "bypassPermissions"，综合分析所有竞争对手文件中的模式。该 Agent 应读取所有 ~/.nimble/memory/competitors/*.md 文件，并按照 references/memory-and-distribution.md 中的格式生成 competitive-landscape.md——包括市场地图、功能对比、定价对比、关键模式和战略影响。使用 [[competitors/name]] 链接引用来源实体文件。

此外，将所有未解答的问题追加到 ~/.nimble/memory/backlog.md （例如，定价或融资等关键数据缺失的竞争对手）。

生成后，在 index.md 中添加综合分析页面条目。

第 8 步：分享与分发

始终提供分发选项——不要跳过此步骤。 按照 references/memory-and-distribution.md 中的说明检测连接器、执行分享流程并确保包含来源链接。

第 9 步：后续操作

• 深入了解某家竞争对手 → 执行更有针对性的搜索
• 跳过某家竞争对手 → 更新 preferences.skip_competitors
• 添加竞争对手 → 更新 competitors，创建记忆存根
• “看起来不错” → 完成

同类技能建议：

后续步骤：

• 运行 competitor-positioning，分析竞争对手如何在网上展示自己
• 运行 company-deep-dive，全面了解本报告中的任意一家竞争对手
• 如果你要与某家竞争对手的人员会面，运行 meeting-prep

---

Agent Teams 模式（双模式）

启动时检查：echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

团队模式（已设置标志）：启动完整的队友，而不是子 Agent：

• 负责人（你）：分配竞争对手，综合整理最终简报
• 每家竞争对手对应一名队友：使用 references/competitor-agent-prompt.md 和已发现的 WSA—— 队友发现重叠信号时可以互相发送消息
• 唱反调者（可选）：质疑研究结果，寻找盲点
• 负责人综合整理经过交叉验证的简报，提高结论置信度

单人模式（未设置标志）：使用第 3 步中的标准子 Agent 流程。

---

错误处理

有关标准错误表（缺少 API 密钥、429、401、结果为空、提取内容无效），请参阅 references/nimble-playbook.md。本技能特有的错误：

• 搜索返回 500： 不带 --focus 标志重试一次。如果仍然失败，则使用简化的查询重试 （缩短关键词，不使用日期筛选）。记录失败情况，但不要跳过该竞争对手。
• 搜索超时： 重试一次，然后跳过该调用并继续——与操作手册中的超时策略一致。