用途：把描述整个市场的 Sales Navigator 公司搜索构建成部署式管道的账户全库，即使该搜索返回数量远超提取器上限也能处理。流程在 deploy-cookbook 中，所有 cookbook 的脚手架、适配、部署、验证四步一致。
主要能力：先对市场搜索计数，再按面向拆分为每个都低于上限的子搜索，解析为真实域名，合并到共享 accounts 模型并去重。计数是设计时 CLI 调用而非部署资源，返回 total_results 且只花费少量额度。拆分顺序通常为：先行业（仅在细分仍超限时沿 LinkedIn 分类下探），再地域，再人数区间；每个子搜索都重新计数，仍超限则继续拆。
使用方式： npx skills add getcargohq/cargo-cookbooks/deploy-cookbook cargo-ai cdk init my-tam --from getcargohq/cargo-cookbooks/tam-building 计数命令： cargo-ai orchestration action execute --wait-until-finished --action '{"kind":"connector","integrationSlug":"salesNavigator","actionSlug":"searchCompanyMetrics","config":{}}' --data '{"url":"<your Sales Navigator company-search URL>"}' cookbook.json 有三个输入：marketSearch 是唯一需要询问的输入；searchUrls 由计数和拆分推导；limit 默认 1000。回答前请先读本目录 README.md。
验收标准（Done when）：各子搜索提取数之和大致等于原始全市场搜索的计数；没有子搜索恰好返回上限值（说明仍被截断）；提升后的账户出现在 accounts 中且带 website，并在重叠子搜索间去重。
成本与限制：计数仅花费少量额度；提升是昂贵步骤，每个提升公司需两次计费调用（matchBusiness 加 enrichBusinessFirmographics），因为 Sales Nav 不返回域名而两者都需用于解析。5000 家 TAM 约需 10000 次 enrichment 调用。控制在上游：config.limit 和添加的子搜索 URL 数量；要少花钱就少提取，建议先跑一个小型子搜索确认正确再扩大。此 cookbook 状态为 to-be-approved，尚未针对实时工作区做部署验证，部署前请审查 cargo-ai cdk plan，在 cookbook.json 标记 approved 前不要对该 cookbook 作任何结果承诺。可组合到 list-building、contact-sourcing、account-scoring、signal-based-tam。