local-places

本地地点

由 Nimble Web Search Agents 和网页数据 API 提供支持的位置智能。

用户请求：$ARGUMENTS

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

---

说明

步骤 0：预检

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

同时执行：

• mkdir -p ~/.nimble/memory/{reports,local-places/checkpoints}
• 检查是否存在已有检查点：ls ~/.nimble/memory/local-places/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 中的智能日期窗口确定模式：
  • 完整模式： 首次运行，或距上次运行超过 14 天
  • 快速刷新： 距上次运行不到 14 天（跳过社交信息补充，仅为新地点查找评论）
  • 当天重复运行： 如果 last_runs.local-places 是今天，检查 ~/.nimble/memory/reports/local-places-*[today].md 中是否已有报告。如果有，询问：“今天已搜索过该区域。要重新运行以获取最新数据吗？”不要静默地重新运行。
  • 跳至步骤 1
• 无配置文件 -> 没关系。本地地点无需引导设置。继续步骤 1。

步骤 1：解析请求并提出初始问题

解析 $ARGUMENTS，提取地点类型和位置。提取：

字段	必需	来源
地点类型	是	用户输入（“咖啡店”“健身房”“餐厅”）
位置	是	用户输入（“威廉斯堡”“奥斯汀市中心”“帕克斯洛普”）
筛选条件	可选	用户输入（“评价好”“营业到很晚”“便宜”）
输出偏好	可选	用户输入（“地图”“列表”“指南”）

如果 $ARGUMENTS 中的地点类型和位置都明确，请简短确认后继续：“正在搜索布鲁克林威廉斯堡的咖啡店……”

如果信息不完整或有歧义，请用纯文本提出一个合并问题：

“你在找哪类地点？在哪个位置？（例如，‘威廉斯堡的咖啡店’或‘奥斯汀市中心附近的健身房’）”

如果用户已提供两项信息，但你想进一步确定搜索范围，请使用 AskUserQuestion（计入最多 2 次提问）：

你希望搜索多全面？

• 快速浏览——Google Maps 和 Yelp 的热门结果（约 20 个地点）
• 全面搜索——完整发现 + 社交信息补充 + 评论（约 50 个以上地点）
• 深度探索并附地图——上述所有内容 + 可交互的社区地图

步骤 2：消除位置歧义

在调用任何 API 之前，先确认位置，避免浪费搜索资源。

需要消除歧义的情况：

• 位置名称在多个城市或州都存在（例如，“Williamsburg”可能指纽约州布鲁克林，也可能指弗吉尼亚州的 Williamsburg）
• 位置范围较广（例如，“奥斯汀市中心”可能包含多个社区）
• 位置名称较为非正式（例如，“Soho”可能指纽约市，也可能指伦敦）

如果有歧义，请询问用户（计入最多 2 次提问）：

“有几个地方都叫 Williamsburg。你指的是哪一个？”

• 纽约州布鲁克林的 Williamsburg
• 弗吉尼亚州的 Williamsburg
• 其他——我会说明

如果没有歧义，推断完整位置（城市 + 州/国家），并在回复中确认： “正在搜索纽约州布鲁克林的 Williamsburg……”

消除歧义后，生成用于检查点和文件路径的 slug： 全部小写，用连字符分隔，并包含城市 + 州/国家（例如，williamsburg-brooklyn-ny）。

步骤 3：检查是否存在现有检查点

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

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

• 找到检查点 -> 提示：“发现之前的运行结果（{date} 找到了 {N} 个地点）。 是恢复并补齐缺失内容，还是重新开始？”
• 没有检查点 -> 继续执行步骤 4

步骤 4：WSA 发现

在执行前，发现所有阶段可用的 WSA。同时运行以下搜索：

nimble extract:templates list --limit 100  # then filter items for "maps"

nimble extract:templates list --limit 100  # then filter items for "reviews"

nimble extract:templates list --limit 100  # then filter items for "social"

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

根据合并后的结果：

1. 按 entity_type 筛选：发现阶段使用 SERP，丰富信息／详情阶段使用 PDP/Profile
2. 优先选择 managed_by: "nimble"，而不是 managed_by: "community"
3. 分类到各个阶段——分类策略请参阅 references/wsa-pipeline.md
4. 使用 nimble extract:templates get --extract-template-name {name} 验证每个 WSA，确认其参数
5. 缓存本次运行剩余阶段所需的所有已发现 WSA 名称和已验证参数

如果某个阶段没有找到 WSA，则该阶段回退到 nimble search。记录哪些阶段有 WSA 覆盖，哪些阶段使用回退方案。

步骤 5：主要搜索（阶段 1）

阅读 references/wsa-pipeline.md，了解类别检测逻辑。

使用步骤 4 中已验证的参数，同时运行已发现的地图／位置 WSA：

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

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

第三级（条件触发）： 仅当主要搜索和次要搜索合计返回的唯一结果少于 10 个，或用户要求信誉／信任数据时，才运行已发现的信誉 WSA。

如果任何 WSA 失败或返回空结果，则回退到： nimble search --query "[place-type] in [location]" --max-results 20 --search-depth lite

发现后：

1. 将所有结果解析为统一的实体列表
2. 按照 references/nimble-playbook.md 中的实体去重模式进行去重：精确匹配 place_id -> 域名规范化 -> 名称与城市模糊匹配
3. 保存检查点： ~/.nimble/memory/local-places/checkpoints/{slug}/discovery.json

步骤 6：社交信息丰富（阶段 2）

对于每个发现了 Facebook 页面或 Instagram 账号的地点，运行步骤 4 中发现的社交 WSA。最多同时运行 4 个并发 Bash 调用。

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

对拥有匹配账号的地点，运行每个已发现的社交 WSA。跳过未发现 WSA 的社交平台。如果步骤 4 中没有找到社交 WSA，则完全跳过此阶段。

保存检查点：~/.nimble/memory/local-places/checkpoints/{slug}/social.json

步骤 7：评论（阶段 3）

针对排名靠前的地点（按来源数量和数据完整度排序），运行步骤 4 中发现的评论 WSA：

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

最多同时运行 4 个并发调用。优先处理阶段 1 发现中具有 place_id 或等效标识符的地点。如果步骤 4 中没有找到评论 WSA，则回退到：nimble search --query "[place-name] reviews" --max-results 5 --search-depth lite

保存检查点： ~/.nimble/memory/local-places/checkpoints/{slug}/reviews.json

步骤 8：餐饮加分项（阶段 4）

当地点类型类别匹配餐饮关键词时自动触发。 类别检测逻辑请参阅 references/wsa-pipeline.md。

如果触发，则运行步骤 4 中发现的外卖／餐饮 WSA。先发现，再获取详情：

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

对于在外卖平台上找到的地点，使用已发现的详情 WSA 获取完整详情：

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

如果步骤 4 中没有找到外卖 WSA，则回退到： nimble search --query "[place-name] [location] delivery" --max-results 3 --search-depth lite

仅对餐饮类别运行。如果类别不匹配，则跳过。

第 9 步：去重与置信度评分

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

**置信度评分：**按照 references/nimble-playbook.md 中的实体置信度评分模式。技能专属目标字段（N=8）：

字段	说明
name	商家名称
address	完整街道地址
phone	电话号码
website	网站 URL
rating	平均评分
review_count	评论数量
social	至少一个社交媒体主页
hours	营业时间

评分标准：

• 高（8/8 个字段 + 2 个以上来源 + 10 条以上评论）-> 显示为 *** High
• 中（5-7/8 个字段，或 2 个以上来源但数据不完整）-> ** Medium
• 低（<=4/8 个字段、单一来源、评论很少或没有评论）-> * Low

第 10 步：输出

以编号表格呈现结果，按置信度排序（高置信度优先），然后在各置信度级别内按评分排序。

# Local Places: [Place Type] in [Location]
*Found [N] places | [Date] | Confidence: [H] High, [M] Medium, [L] Low*

## Results

| # | Name | Rating | Reviews | Confidence | Address | Sources |
|---|------|--------|---------|------------|---------|---------|
| 1 | Place A | 4.8 (312) | *** High | 123 Main St | [Maps][Yelp] |
| 2 | Place B | 4.6 (89)  | ** Medium | 456 Oak Ave | [Maps] |
...

## Top Picks (High Confidence)

### 1. Place A
- **Address:** 123 Main St, Williamsburg, Brooklyn, NY
- **Phone:** (555) 123-4567 | **Website:** [placea.com](https://placea.com)
- **Rating:** 4.8/5 (312 reviews on Google Maps, 289 on Yelp)
- **Social:** Instagram @placea (2.1K followers) | Facebook (1.8K likes)
- **Hours:** Mon-Fri 7am-7pm, Sat-Sun 8am-6pm
- **Delivery:** Available on DoorDash, Uber Eats
- **Why it stands out:** [1-2 sentences from review highlights]
- **Sources:** [Google Maps](link) | [Yelp](link) | [Facebook](link)

[Repeat for each High confidence place]

## Other Results (Medium + Low Confidence)
[Briefer format -- name, rating, address, missing data noted]

## What's Missing
[Note any data gaps: "3 places had no website or social presence",
 "Reviews unavailable for BBB-only listings"]

**来源链接为必填项。**每个地点至少必须有一个可点击的来源 URL（Google Maps 链接、Yelp 商家页面、网站或社交媒体主页）。没有任何来源链接的地点应在“缺少的信息”中注明；但如果 WSA 结果提供了足够的数据，仍应将其列出。

**深入了解：**呈现结果后，告诉用户：

“想了解任何地点的详细信息吗？说‘详细介绍 #3’，或询问互动地图。”

第 11 步：互动地图（按需生成或在“深入探索”模式下生成）

生成一个使用 Leaflet.js + OpenStreetMap 图块的 HTML 文件。完整的地图生成模式和配色方案请参见 references/wsa-pipeline.md。

保存到：~/.nimble/memory/local-places/{slug}-map-{date}.html

在浏览器中打开：open ~/.nimble/memory/local-places/{slug}-map-{date}.html

仅当用户在第 1 步选择了“深入探索并显示地图”时，才自动生成。地图生成详情请参见 references/wsa-pipeline.md。 否则，将其作为后续操作选项提供。

第 12 步：保存到记忆

同时执行所有 Write 调用：

• 报告 -> ~/.nimble/memory/reports/local-places-{slug}-{date}.md
• 单个地点数据 -> ~/.nimble/memory/local-places/{slug}/places.json （包含所有丰富记录的结构化 JSON）
• 档案 -> 更新 ~/.nimble/business-profile.json 中的 last_runs.local-places （仅当档案存在时）
• 按照 references/memory-and-distribution.md 中的 wiki 更新模式：更新所有受影响实体文件在 index.md 中的行，并为本次运行在 log.md 中追加一条记录。
• 清理检查点（运行已完成）或保留检查点（运行未完成）

第 13 步：分享与分发

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

Notion：将完整结果表格作为带日期的子页面。 Slack：仅提供前 5 个地点的 TL;DR。

第 14 步：后续操作

• “详细介绍 #N” -> 显示该地点的完整详情
• “显示地图” -> 生成互动地图（第 11 步）
• “添加筛选条件” -> 使用其他约束条件重新搜索
• “搜索附近区域” -> 扩展到相邻街区
• “导出为 CSV” -> 根据 places.json 生成 CSV
• “看起来不错” -> 完成

同级技能建议：

后续步骤：

• 运行 company-deep-dive，为列表中的任意商家生成完整的 360 度档案
• 如果你要与这些商家中的某人会面，运行 meeting-prep
• 运行 competitor-positioning，比较此区域内的商家

---

子 Agent 策略

对于全面搜索（50 个以上地点），使用 nimble-researcher Agent （agents/nimble-researcher.md）并行补充信息。

遵循 references/nimble-playbook.md 中的子 Agent 启动规则 （bypassPermissions、每批最多 4 个、明确说明 Bash 指令、失败时回退）。 对于大规模 WSA 调用（11 个以上实体），告诉 Agent 使用 agent run-batch，而不是 逐个调用。有关层级选择，请参阅 references/nimble-playbook.md 中的 Scaled Execution 模式。将第 4 步发现的 WSA 名称传给每个 Agent， 以便它们使用相同的缓存名称。

启动模式： 社交信息补充时，每 10 个地点分为一批，每批启动一个 Agent。 每个 Agent 为其批次运行 Phase 2 的 WSA，并返回结构化结果。

单批优化： 如果地点不超过 10 个，直接在主上下文中进行信息补充，而不是启动 Agent——这样可以减少开销。

回退： 如果任何 Agent 失败，请在主上下文中直接运行相应的 WSA 调用。

---

Agent Teams 模式（双模式）

启动时检查：echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

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

• 发现队友：运行所有 Phase 1 WSA、去重并返回统一列表
• 信息补充队友：为每批地点运行 Phase 2-4
• 负责人（你）：协调、评分、生成输出和地图

单人模式（未设置标志）：按第 4-7 步执行标准顺序流程。

---

错误处理

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

• WSA/Search 500： 使用相同参数重试一次。如果仍然失败，则针对该地点/查询回退到 nimble search。记录失败情况，但不要跳过该地点。
• WSA/Search 超时： 重试一次，然后跳过该调用并继续——与手册中的超时策略一致。
• 未找到 WSA： 如果某个阶段未发现任何 WSA，则跳过该阶段的 WSA 调用，并回退到 nimble search。记录哪些阶段没有 WSA 覆盖。
• 未找到地点： “找不到 [location] 的结果。能否提供更具体的信息？ 试着提供城市和州（例如，‘Williamsburg, Brooklyn, NY’）。”
• 该地点类型没有结果：“在 [location] 中未找到 [place type]。要不要试试更宽泛的类别或附近区域？”
• 地点类型不明确：“你指的是 [option A] 还是 [option B]？”（例如，“bar”可能指鸡尾酒吧、体育酒吧或葡萄酒吧）