competitor-positioning

竞争对手定位分析

借助 Nimble 的网络数据 API，开展以营销为重点的竞争定位分析。 专为需要了解竞争对手如何展现自身的营销团队打造——包括信息传达、价值主张、内容主题、定价，以及这些内容如何随时间变化。

输出是营销简报，而非信号流。每条洞察都应回答： “这对我们的信息传达和定位意味着什么？”

用户请求：$ARGUMENTS

参数解析——运行任何操作前，先确定要执行的任务：

• 无参数 → 运行完整工作流（在第 2 步确认范围）
• 竞争对手名称（例如“Exa，Tavily”）→ 只研究这些对象，跳过范围确认
• “battlecard [competitor]” → 使用记忆中的现有快照，直接跳转到下方的战斗卡片生成
• “delta” / “what changed” → 无论时间间隔如何，都强制进入增量模式

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

---

指令

步骤 0：预检

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

根据结果：

• CLI 缺失或未设置 API key → references/profile-and-onboarding.md，然后停止
• 为所有 nimble CLI 调用添加标签：nimble --client-source nimble-agent-skills <subcommand>。MCP 请求在传输层进行归因——参见 references/nimble-playbook.md。
• 配置文件已存在 → 从以下两个来源加载先前数据：
  • ~/.nimble/memory/positioning/*.md — 先前的定位快照（用于步骤 4 和 5 中的增量检测）
  • ~/.nimble/memory/competitors/*.md — competitor-intel 运行产生的业务信号（用于了解定位变化背后的原因，例如，发生在信息传达转向之前的一轮融资或领导层变动） 确定模式：
  • **完整快照：**首次运行，或没有先前的定位数据，或上次运行距今超过 14 天
  • **增量模式：**上次运行距今不足 14 天——只呈现发生变化的内容
  • **同日重复运行：**如果 last_runs.competitor-positioning 的日期是今天，检查是否存在报告 ~/.nimble/memory/reports/competitor-positioning-[today].md。如果存在，询问：“今天已经运行过。要重新运行以获取最新数据吗？”不要在用户不知情的情况下重新运行。
  • 跳转到第 2 步
• 配置文件不存在 → 第 1 步

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

此技能与 competitor-intel 共用竞争对手列表。如果配置文件已存在竞争对手，则完全跳过引导。

如果配置文件不存在，请遵循 references/profile-and-onboarding.md 完成完整的引导流程。此处创建的配置文件和竞争对手列表将在所有业务技能之间共用。

步骤 2：确认范围

如果 $ARGUMENTS 已指定竞争对手，则使用这些对象并跳过此步骤。

否则，检查配置文件中有多少个竞争对手：

• 4 个或更少 → 全部继续，无需确认

• 超过 4 个 → 询问用户要重点分析哪些对象（使用 AskUserQuestion）：

  你已跟踪 [N] 个竞争对手。要我分析哪些？

  • 全部 [N] 个（约 [3-5 × N] 个 Nimble API 积分，约 [N × 2] 分钟）
  • [类别 A]：[名称]（根据配置文件中的 category 分组）
  • [类别 B]：[名称]
  • 让我选择 — 我会列出具体对象

接受自然语言表达：“只看 AI 搜索相关的” → 根据配置文件中的类别确定对象。

这样可避免在用户当前不关注的竞争对手上浪费 API 积分和时间。每个竞争对手约需 3-5 个 Nimble API 积分（1 次 map + 3-4 次 extract + 2-3 次 search）。

第 3 步：WSA 发现

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

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

同时为每个域名运行一次搜索。筛选 SERP/PDP WSA，优先选择 managed_by: "nimble"，并使用 nimble extract:templates get --extract-template-name {name} 验证。 缓存发现的名称和参数。在第 5 步中将它们传递给竞争对手 Agent，以获取更丰富的提取结果。 如果没有找到 WSA，则继续使用 nimble search/extract/map。

第 4 步：捕捉用户自身的定位（基准）

在分析竞争对手之前，先捕捉用户自身的定位，作为信息传递矩阵的基准。

首先，发现网站结构，以确定要提取的正确页面：

nimble --transform "links.#.url" map --url "https://[company-domain]" --sitemap only --limit 200

从返回的 URL 中，找出功能/产品页面和定价页面（查找包含 /features、/product、/platform、/pricing、/plans 的路径）。

然后，同时提取关键页面（主页以及 map 找到的页面）：

• nimble extract --url "https://[company-domain]" --format markdown → 主页信息传递、标语、主视觉文案、行动号召
• nimble extract --url "[features-page-url]" --format markdown → 功能页面的结构和重点（如果 map 未找到匹配项，则跳过）
• nimble extract --url "[pricing-page-url]" --format markdown → 定价结构和套餐命名（如果 map 未找到匹配项，则跳过）

如果页面提取结果无用，注明“页面无法访问”并继续—— 有一部分基准信息总比没有好。

第 5 步：针对每个竞争对手开展并行研究（子 Agent）

阅读 references/positioning-agent-prompt.md，了解完整的 Agent 提示词模板。 遵循 references/nimble-playbook.md 中关于启动子 Agent 的规则 （bypassPermissions、每批最多 4 个、明确的 Bash 指令、失败时的回退方案）。

调用次数估算与规模化执行： 启动 Agent 之前，估算 API 调用总数： 每个竞争对手约需 1 次 map + 3 次提取 + 3 次搜索，即约 7 × N 次调用（另加 第 3 步的基准调用）。对于 2 个或更多竞争对手（14 次或更多调用），告知 Agent 对页面提取使用 extract-batch，而非单独调用。有关层级选择，请参阅 references/nimble-playbook.md 中的规模化执行模式。

对于范围内的每个竞争对手，启动一个通用子 Agent，并设置 mode: "bypassPermissions"，同时内嵌 references/positioning-agent-prompt.md 中的提示词。根据每个竞争对手的名称、域名、起始日期、从记忆中加载的上次定位快照（在 第 0 步加载），以及第 3 步中发现的任何 WSA 名称自定义提示词，以获取更丰富的数据。

不要使用 agents/nimble-researcher.md——该 Agent 仅用于原始数据收集，并明确禁止分析；但此技能需要进行解读（识别受众信号、比较定位快照、评估结构影响）。

每个 Agent 负责完成一个竞争对手的整个研究流程：

1. 使用 nimble map 发现网站的实际页面结构
2. 提取主页、功能页面和定价页面（使用发现的 URL）
3. 搜索并提取近期博客文章（深入分析 2-3 篇）
4. 分析社会认同（案例研究、推荐语）
5. 与之前的快照对比，找出变化

Agent 将返回一份结构化的定位快照——完整输出格式请参阅提示词模板。无需单独提取博客文章；Agent 会负责处理。

如果 Agent 提取的博客内容较少（提取的文章少于 2 篇），可选择在主上下文中使用 Agent 搜索结果中的 URL 提取其他文章。

回退方案： 如果 Agent 完全失败，则使用相同的提示词模板步骤，在主上下文中直接运行提取。

Step 6: 分析与输出

面向营销团队组织所有内容。使用他们熟悉的术语：信息层级、声量份额、竞争对手作战卡素材、内容日历影响。

分析 Agent 结果中的博客内容时，请关注：

• 反复出现的叙事 — 这家公司反复讲述什么故事？
• 受众定位 — 帖子面向开发者、高管还是从业者？
• 竞争对手提及 — 他们会点名竞争对手，还是围绕某个类别进行定位？
• SEO 模式 — 标题和小标题瞄准哪些关键词？
• 内容成熟度 — 原创研究、思想领导力，还是泛泛的操作指南？

完整快照模式（首次运行或距离上次运行超过 14 天）：

• 营销团队速览 — 提炼 3-5 条关键定位洞察，说明营销团队应采取的行动，并为每条洞察指出具体影响（例如：“竞争对手 X 将标语从面向开发者转向面向企业 — 请考虑我们的信息传递是否仍有差异化”）

• 信息传递矩阵 — 构建对比表，针对所有竞争对手（包括贵公司）列出标语、主要 CTA、价值主张、目标受众和定价模式。标语和 CTA 使用原文引述。

• 各竞争对手 — 定位概况：

  • 网站结构信号（存在哪些页面、缺少哪些页面、有哪些子域名）
  • 首页信息传递分析（标语、主视觉区、CTA、价值主张）
  • 功能页面分析（强调什么、差异化主张）
  • 定价定位（模式、层级策略、企业版信号）
  • 内容策略（博客主题、发布频率、受众、内容类型）
  • 社会认同策略（展示哪些客户、重点突出哪些成果）

• 内容差距分析 — 竞争对手发布了哪些你们没有发布的内容：

  • 他们覆盖而你们没有覆盖的主题
  • 他们使用的内容形式（案例研究、基准测试、ROI 计算器）
  • 他们在内容中面向的受众群体

• 定位空白 — 没有竞争对手强势占据的信息传递角度：

  • 尚未被占据的价值主张
  • 服务不足的受众群体
  • 叙事空白

• 建议行动 — 为营销团队提供具体、可执行的后续步骤（例如：“为竞争对手 X 新推出的企业定位起草反向信息传递”，“优先制作面向 [segment] 的案例研究 — 已有 3 个竞争对手占据这一领域”）

增量模式（距离上次运行不足 14 天）— 仅报告变化：

• 变化内容 — 按竞争对手列出每项变化的前后对比：

  • “标语：‘[old]’ → ‘[new]’”
  • “新增功能类别：[name]”
  • “定价模式从 [old] 转变为 [new]”
  • “出现新的博客主题：[topic]（过去 2 周发布了 3 篇文章）”

• 没有变化 — 列出定位没有变化的竞争对手

• 营销影响 — 说明这些变化对团队优先事项的影响

核心规则：

• 每项主张都必须链接到来源页面。
• 与 ~/.nimble/memory/positioning/*.md 中的内容进行去重 — 在增量模式下，仅报告真正的新变化。
• 若“未检测到定位变化”，请直接如实说明，不要用空话凑内容。
• 标语、CTA 和价值主张均使用原文引述 — 不要改述。

WSA 信息增强： 如果在 Step 3 中发现了 WSA，Agent 应结合 nimble map/nimble extract 获取更丰富的页面数据。

步骤 7：保存并更新记忆

同时执行所有写入调用：

• 报告 → ~/.nimble/memory/reports/competitor-positioning-[date].md （保存完整简报，而非摘要——这是本地唯一可信来源）

• 每个竞争对手 → 按照 references/positioning-snapshot-format.md 中的格式，将定位快照保存到 ~/.nimble/memory/positioning/[name].md。在 History 部分追加一条带日期的记录，以便后续运行检测发生了哪些变化以及何时发生。添加 [[competitors/name]] 交叉引用，将定位快照链接到竞争对手情报文件。

• 个人资料 → 更新 ~/.nimble/business-profile.json 中的 last_runs.competitor-positioning

• 遵循 references/memory-and-distribution.md 中的 wiki 更新模式：更新所有受影响实体文件在 index.md 中的行，并在 log.md 中追加本次运行的记录。

步骤 8：分享与分发

始终提供分发选项——不要跳过此步骤。 遵循 references/memory-and-distribution.md 中的连接器检测、分享流程和 来源链接强制要求。营销团队尤其能从共享的 Notion 页面中受益，他们可在定位研讨会和内容规划会议中参考这些页面。

战斗卡生成

由 "battlecard [competitor]" 参数触发，也可作为后续请求触发。

输入： 从 ~/.nimble/memory/positioning/[name].md 读取该竞争对手的定位快照，并从最新的 报告中读取用户自己的基准信息。如果快照不存在（或已过时超过 14 天），则先为该竞争对手运行步骤 4-5，然后返回这里。

输出格式：

# Battlecard: [Your Company] vs [Competitor]
## As of [date]

### Competitor Overview
- Tagline: [verbatim]
- Primary CTA: [verbatim]
- Target audience: [who their messaging speaks to]
- Pricing model: [type and entry price if known]

### Their Key Claims
[List each value prop / differentiator they emphasize, verbatim with source URL]

### Our Counter-Positioning
[For each claim above: our response, proof points, and messaging angle]

### Feature Comparison
| Capability | Us | Them | Advantage |
|---|---|---|---|

### Where They Win (acknowledge honestly)
[Areas where their positioning is stronger or they have genuine advantages]

### Where We Win
[Our unique advantages, with evidence]

### Objection Handling
| Prospect Says | Respond With |
|---|---|

### Recommended Talking Points
[3-5 concise talking points for sales/marketing conversations]

---

步骤 9：后续操作

• 生成战斗卡，针对某个竞争对手 → 运行上文的战斗卡生成流程
• 针对某个竞争对手的特定声明起草反制信息 → 提出替代角度和佐证要点
• 比较内容日历 → 将你的发布节奏与竞争对手的发布频率进行对比
• 深入了解某个竞争对手 → 提取更多页面（关于、招聘、合作伙伴、案例研究）
• 跟踪新的竞争对手 → 更新 competitors，创建定位快照
• 跳过某个竞争对手 → 更新 preferences.skip_competitors
• “看起来不错” → 完成

同级技能建议：

后续步骤：

• 运行 competitor-intel，了解商业信号（融资、招聘、产品发布）
• 运行 company-deep-dive，全面了解任意竞争对手
• 如果你要与竞争对手的某位成员会面，请运行 meeting-prep

---

Agent Teams 模式（双模式）

启动时检查：echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

团队模式（已设置标志）：

• 使用带有 name: 参数的 Agent 工具，以便通过名称寻址队友
• 队友可以使用 SendMessage 分享发现的跨竞争对手规律 （例如：“本月有两家竞争对手都转向了按使用量计费”）
• 所有竞争对手队友返回后，创建一名 营销分析师 队友， 并将所有发现作为输入，专门分析内容差距和定位空白领域——这能将数据收集与战略分析分开
• 主 Agent 汇总并形成经过交叉验证的最终营销简报

单人模式（未设置标志）：

• 使用标准的即发即弃子 Agent（不使用 SendMessage 和 name:）
• Agent 返回后，所有分析都在主上下文中进行

---

错误处理

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

• 搜索返回 500： 不带 --focus 标志重试一次。如果仍然失败，则使用简化查询重试（缩短关键词，不使用日期筛选）。记录失败，但不要跳过竞争对手。
• 搜索超时： 重试一次，然后跳过该调用并继续——这与操作手册的超时策略一致。
• 页面提取失败（404/垃圾信息）： 地图步骤应通过先发现实际 URL 来避免大多数 404。如果提取仍然失败，请注明“页面无法访问”并继续——部分数据胜过没有数据。
• 地图结果为空： 有些网站会阻止访问站点地图。改为直接提取首页，并尝试猜测常见路径（/features、/pricing、/blog）。
• 博客结果为空： 有些公司没有博客。请注明“未检测到活跃博客”，并改为侧重基于页面的定位分析。