market-finder

Market Finder

由 Nimble Web Search Agents 提供支持的市场情报。

用户请求：$ARGUMENTS

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

---

说明

步骤 0：预检

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

同时执行：

• mkdir -p ~/.nimble/memory/{reports,market-finder/checkpoints}
• 检查是否有现存检查点：ls ~/.nimble/memory/market-finder/checkpoints/ 2>/dev/null

根据结果：

• CLI 缺失或未设置 API 密钥 -> references/profile-and-onboarding.md，然后停止
• 为所有 nimble CLI 调用添加标签：nimble --client-source nimble-agent-skills <subcommand>。MCP 请求会在传输层进行归因——请参阅 references/nimble-playbook.md。
• 配置文件存在 -> 记录其中的行业关键词（如有）。应用 references/nimble-playbook.md 中的智能日期窗口规则。Market-finder 调整项：在快速刷新模式下，跳过信息补充，仅发现新的都市区。
• 没有配置文件 -> 没问题。Market-finder 无需引导设置。继续执行步骤 1。

步骤 1：解析请求并检测模式

解析 $ARGUMENTS 中的业务类型、地理位置、限定条件和模式检测。

模式检测

检查 $ARGUMENTS 中是否包含参考列表。阅读 references/audit-mode.md，了解完整的检测信号和解析规则。

信号	模式
Google Sheet URL、CSV 路径或包含 3 家以上企业的内嵌列表	审计
明确的审计表述（“审计我的列表”“与……对比”“差距分析”）	审计
未提供参考列表	发现（默认）

如果存在参考列表，但意图不明确，请询问：“你想让我根据最新发现结果审计你的列表，还是将其作为起点？”

如果检测到审计意图，但未提供参考列表，请询问：“你提到了审计——请提供你的列表（Google Sheet URL、CSV 文件路径或直接粘贴内容）。” 收到参考列表前，不要继续使用审计模式。

提取字段

字段	必填	来源
业务类型 / 垂直领域	是	用户输入（“牙医”“SaaS CRM 工具”）
地理位置	是（SaaS 除外）	用户输入（“佛罗里达州”“德克萨斯州奥斯汀”“全国”）
参考列表	仅审计模式	Google Sheet URL、CSV 路径或内嵌内容
筛选条件	可选	用户输入（“必须有网站”“10 条以上评论”）
输出偏好	可选	用户输入（“快速摘要”“完整数据集”）

如果 $ARGUMENTS 中的业务类型和地理位置都明确，请简短确认并继续：“正在寻找佛罗里达州的牙医……”（审计模式下则说：“正在根据佛罗里达州的牙医审计你的列表……”）

如果信息不完整或含糊不清，请提出一个综合问题（最多 2 次 AskUserQuestion 提问中的 1 次）：

使用 AskUserQuestion，最多提出 3 个问题：

1. 垂直领域——“哪类企业？”选项：医疗保健、SaaS/软件、餐饮/食品、法律/金融、汽车/家居服务、其他
2. 地理位置——“地理范围是什么？”（自由文本或：城市、州、地区、全国）
3. 深度——“快速扫描还是全面发现？”

跳过 $ARGUMENTS 中已回答的问题。

深度模式（决定每个步骤的工作量）：

深度	发现	信息补充	验证	分发
快速扫描	所有来源，1 轮	跳过（或仅处理排名前 5 项）	前 5 个实体	提供
全面	所有来源 + 备用重试	完整处理	所有实体	提供

步骤 2：行业检测与预设加载

阅读 references/vertical-presets.md，根据预设触发关键词匹配用户的业务类型。

匹配情况	操作
明确匹配	加载该预设的 WSA 路由和查询模式
部分匹配	确认：“这看起来属于医疗保健行业。使用医疗保健预设吗？”
无匹配	使用包含用户关键词的自定义预设
SaaS 匹配	切换到非地理流程（不进行地理网格划分）

记下预设指定的发现 WSA 和丰富数据 WSA。

步骤 3：地理范围界定

SaaS 行业跳过此步骤（无需地理信息）。

地理级别	网格划分策略
城市	单次查询，不划分网格
都会区	每个 WSA 执行一次查询
州	按该州排名前 5-10 的都会区划分网格
区域	按州划分网格，然后按每个州排名靠前的都会区划分
全国	按所有州划分网格，然后按每个州排名靠前的都会区划分

估算 API 调用次数： metros * discovery_wsas * (1 + enrichment_ratio)，其中 enrichment_ratio 约为 0.3。参照 references/nimble-playbook.md 中的规模化执行模式，选择执行级别（单次 / 批量 / 多批次 / 确认关卡）：

Estimated API calls: ~1,560 (50 states x 8 metros x 3 WSAs + enrichment)
This is a nationwide search. Proceed? [Y/n]

生成用于检查点的 slug：小写、以连字符分隔，并包含行业 + 地理范围 （例如，dentists-florida、saas-crm-tools、hvac-nationwide）。

步骤 4：检查是否存在检查点

参照 references/memory-and-distribution.md 中的检查点与恢复模式。

检查：cat ~/.nimble/memory/market-finder/checkpoints/{slug}/discovery.json 2>/dev/null

• 找到检查点 -> 提示：“找到之前的运行结果（{date} 时获取的 {N} 个实体）。 恢复并补齐缺失项，还是重新开始？”
• 未找到检查点 -> 继续步骤 5

步骤 5：WSA 发现与执行

5a：发现可用的 WSA

对于所选行业预设中的每个目标域，查找当前可用的 WSA：

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

同时运行这些搜索（每个目标域运行一次）。根据结果：

1. 按 entity_type 筛选（发现用 SERP，丰富数据用 PDP/Profile）
2. 优先选择 managed_by: "nimble" 而非 managed_by: "community"
3. 如果某个域没有找到 WSA，将其标记为使用 nimble search 作为回退
4. 如果任何域都没有找到 WSA，则全部改用 nimble search 搜索所有都会区

然后验证每个已发现 WSA 的输入参数：

nimble extract:templates get --extract-template-name {discovered_name}

缓存已发现的 WSA 名称和参数，供本次运行的其余步骤使用。

5b：地理发现（SaaS 以外的所有行业）

对于网格划分计划中的每个都会区，同时运行已发现的 WSA：

nimble extract:templates run --template {maps_wsa} --params '{...validated params...}'

nimble extract:templates run --template {yelp_wsa} --params '{...validated params...}'

仅当预设包含三级域名的 WSA，且主要域和次要域对该都会区合计返回的唯一结果少于 10 个时，才运行三级域名的 WSA。

根据步骤 3 的预估调用总数，参照 references/nimble-playbook.md 中的规模化执行模式选择执行级别。

5c：SaaS 发现（非地理）

SaaS 跳过 WSA 发现。运行 references/vertical-presets.md 中 SaaS 预设定义的两轮搜索查询：

• 第 1 轮——产品发现： G2、Capterra、综合搜索、ProductHunt、GitHub
• 第 2 轮——财务发现： Crunchbase、融资新闻、市场概况

两轮同时运行。第 2 轮至关重要——缺少此轮，融资和增长数据将会缺失或错误。

5d：回退

如果某个目标域没有找到 WSA，或者某个 WSA 在任何都会区执行失败：

nimble search --query "[type] in [metro]" --max-results 20 --search-depth lite

发现完成后：

1. 将所有结果解析为统一的实体列表
2. 按照 references/nimble-playbook.md 中的实体去重模式进行去重：place_id -> 域名 -> 模糊匹配名称 + 城市
3. 按实体跟踪 source_count（找到该实体的 WSA/来源数量）
4. 保存检查点：~/.nimble/memory/market-finder/checkpoints/{slug}/discovery.json

第 6 步：信息补充

使用第 5a 步发现的 WSA，为预设的目标领域进行信息补充。优先处理来源数量最多的实体。根据 references/nimble-playbook.md 中的 Scaled Execution 选择执行层级。

nimble extract:templates run --template {enrichment_wsa} --params '{...validated params...}'

只运行适用于当前垂直领域信息补充目标的 WSA（参见 references/vertical-presets.md）。对于缺少 WSA 所需 ID/URL 的实体，跳过处理。

保存检查点：~/.nimble/memory/market-finder/checkpoints/{slug}/enrichment.json

第 6b 步：财务核实（SaaS 垂直领域）

对于 SaaS 实体，报告融资信息前必须核实相关说法。没有来源时，绝不要标注公司的融资阶段。

对于排名靠前的结果中的每个实体（快速扫描取前 5 个，全面扫描则全部取用）：

nimble search --query "{company name} funding raised series" --max-results 5 --search-depth lite

• 找到来源： 使用有来源支持的金额和日期
• 未找到来源： 显示“未披露”——绝不要猜测“早期阶段”或“自力创业”

此步骤可防止发布未经核实的财务信息。此步骤很快（每个实体搜索一次，轻量深度），还能发现目录网站遗漏的近期融资轮次。

第 7 步：去重与评分

最终去重： 按照 references/nimble-playbook.md 中的实体去重模式，对所有阶段的结果执行最终去重。将多个来源中的字段合并到每个实体的单条记录中。

发现力度评分（因垂直领域而异，属于技能特定规则）：

地理类垂直领域（医疗保健、餐厅、法律、汽车/家居、自定义）：

等级	标准
高	3 个以上来源，或 2 个以上来源且评论数 > 50
中	2 个来源，或 1 个来源且评论数 > 10
低	仅 1 个来源，评论很少或没有

SaaS 垂直领域（融资与目录收录情况比评论数量更重要）：

等级	标准
高	已核实融资 > $10M，或 3 个以上目录来源，或 1000 条以上 G2 评论
中	已核实融资 < $10M，或 2 个来源，或 100 条以上 G2 评论
低	仅 1 个来源，无已核实融资，评论很少

显示格式：*** High、** Medium、* Low

第 7b 步：审计对比（仅限审计模式）

发现模式下跳过此步骤。

阅读 references/audit-mode.md，了解完整的匹配算法、规范化规则和输出模板。

1. 解析参考列表 — 检测格式（Google Sheet / CSV / 内联），提取记录，并按照 references/audit-mode.md 中的解析规则，将其规范化为 {name, domain, city, state, phone}
2. 按顺序运行三层匹配（域名 → 名称+城市 → 电话）。实体一旦在任一层匹配成功，即停止匹配。记录产生匹配的层级。
3. 为每个实体分类：
   • matched — 同时存在于参考列表和发现结果中
   • discovered_only — 由发现流程找到，不在参考列表中
   • reference_only — 在参考列表中，未被发现流程找到
4. 计算覆盖率 — matched / reference_count × 100

使用分类后的结果继续执行第 8 步。

第 8 步：输出

# Market Finder: [Business Type] in [Geography]
*Found [N] businesses | [Date] | Strength: [H] High, [M] Medium, [L] Low*

## Summary
- **Total discovered:** [N] unique businesses across [M] metros
- **Geographic breakdown:** [top 5 metros by count]
- **Source coverage:** [list each source used with entity counts]

## Top Results (High Strength)

| # | Name | Location | Rating | Reviews | Strength | Sources |
|---|------|----------|--------|---------|----------|---------|
| 1 | Acme Dental | Miami, FL | 4.8 | 312 | *** High | Maps, Yelp, BBB |
| 2 | WidgetCo Health | Orlando, FL | 4.6 | 89 | *** High | Maps, Yelp |
...

## All Results by Geography

### Miami, FL ([n] businesses)
[Table of businesses in this metro]

### Orlando, FL ([n] businesses)
[Table of businesses in this metro]
...

## What's Missing
[Data gaps: metros with low coverage, entities without websites, etc.]

SaaS 输出变体（垂直领域为 SaaS 时，以基于层级的分组替换“All Results by Geography”）：

## Players by Tier

### Pure-Play (dedicated to this vertical)
| # | Name | Domain | Funding | Key Metric | Strength | Sources |
...

### Adjacent (feature overlap from larger platforms)
| # | Name | Domain | Funding | Key Metric | Strength | Sources |
...

### Open Source
| # | Name | Repo | Stars | Key Metric | Strength | Sources |
...

来源链接为必填项。 每个实体必须至少有一个可点击的来源 URL（Google Maps 链接、Yelp 商家页面、网站、BBB 资料页、G2 页面或 GitHub 仓库）。

审计输出变体（审计模式下，以审计输出替换上方的发现输出）： 使用 references/audit-mode.md 中的审计输出模板。主要部分包括：含覆盖率的摘要、匹配表、仅发现表（扩展候选项）、仅参考表（覆盖缺口）以及“这意味着什么”解读。

第 9 步：保存到记忆

同时执行所有 Write 调用：

发现模式：

• 报告 -> ~/.nimble/memory/reports/market-finder-{slug}-{date}.md
• 实体数据 -> ~/.nimble/memory/market-finder/{slug}/entities.json

审计模式：

• 报告 -> ~/.nimble/memory/reports/market-finder-audit-{slug}-{date}.md
• 结构化数据 -> ~/.nimble/memory/market-finder/{slug}/audit-{date}.json （包含全部三个类别及匹配元数据）

两种模式都适用：

• 个人资料 -> 更新 ~/.nimble/business-profile.json 中的 last_runs.market-finder （仅当个人资料存在时）
• 遵循 references/memory-and-distribution.md 中的 Wiki 更新模式：更新所有受影响实体文件在 index.md 中的行，并为本次运行追加一条 log.md 记录。
• 清理检查点（完整运行）或保留检查点（部分运行）

第 10 步：分享与分发

务必提供分发选项——不要跳过此步骤。 按照 references/memory-and-distribution.md 执行连接器检测、分享流程和来源链接强制要求。

Notion：将完整结果表作为带日期的子页面。 Slack：仅分享 TL;DR、总数和排名前 10 的实体。

第 11 步：后续操作

发现模式的后续操作：

• “详细介绍一下 #N” -> 显示该实体的完整详情
• “按 [criteria] 筛选” -> 重新筛选现有结果
• “扩展到 [new geography]” -> 添加都市区并重新运行发现
• “导出为 CSV” -> 根据 entities.json 生成 CSV
• “对全部实体运行信息补全” -> 将信息补全扩展到排名靠前的实体之外
• “根据我现有的清单进行审计” -> 使用本次运行的结果切换到审计模式
• “看起来不错” -> 完成

审计模式的后续操作：

• “将仅发现的条目导出为 CSV 以便联系？” -> 导出扩展候选项的 CSV
• “调查仅参考列表中的缺漏？” -> 针对 reference_only 条目执行定向搜索
• “对新发现的实体运行 company-deep-dive？” -> 对 discovered_only 执行深入研究
• “使用不同的地理区域重新运行？” -> 根据新区域审计同一清单
• “看起来不错” -> 完成

同系列技能建议：

后续步骤：

• 对此清单中的任意企业运行 company-deep-dive，获取完整的 360 度概况
• 运行 competitor-positioning，比较该市场的主要参与者
• 运行 local-places，结合社交信息补全和地图进行街区级发现

---

子 Agent 策略

对于大型任务，nimble extract:templates batch 会在服务端处理 WSA 并行执行（参见 references/nimble-playbook.md 中的 Scaled Execution）。子 Agent 适用于准备批量输入和处理结果，而非执行单个 WSA 调用。

在以下情况下使用 nimble-researcher Agent（agents/nimble-researcher.md）：

• 为大型地理区域构建都市区查询列表（每个州一个 Agent）
• 并行处理批量结果并去重

遵循 references/nimble-playbook.md 中的子 Agent 启动规则 （bypassPermissions，批次最多 4 个，失败时使用备用方案）。

---

Agent Teams 模式（双模式）

启动时检查：echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

团队模式（已设置标志）：为并行阶段启动队友：

• 发现队友： 跨都市区批次运行所有发现 WSA
• 信息补全队友： 为排名靠前的实体运行信息补全 WSA
• 负责人（你）：协调、确定范围、去重、评分并生成输出

单人模式（未设置标志）：按第 5 至第 8 步的标准顺序流程执行。

---

错误处理

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

• 未找到 WSA： 静默跳过，依靠其他发现来源。记录哪些 WSA 不可用。
• 搜索 500/超时： 不带 --focus 标志重试一次。如果仍然失败，则使用简化后的查询重试。记录失败，但不要跳过整个搜索类别——部分数据总比没有好。
• 都市区没有结果： “在 [都市区] 中未找到 [类型]。跳至下一个都市区。”不要因为一个都市区没有结果就中止整个任务。
• 业务类型不明确：“你指的是 [选项 A] 还是 [选项 B]？”（例如，“诊所”可能指医疗、牙科或法律服务）
• SaaS 且指定了地理区域： 如果所选预设不支持地理分区，则将其作为搜索限定条件提供。
• 参考列表解析失败： 如果 Google Sheet 提取结果无效或 CSV 格式错误，请用户直接粘贴数据。
• 参考列表为空： 如果解析后的列表中没有有效记录，请发出警告，并提供切换到发现模式的选项。
• 未找到匹配项： 如果三层匹配都没有找到任何匹配项，请如实报告——0% 的覆盖率也是有效且有参考价值的结果。