Cargo Gtm

Cargo GTM — Meta Skill

Use this skill for prospecting, account research, contact enrichment, verification, lead scoring, personalization, signal monitoring, and campaign activation.

1) What this skill governs

• Route GTM decisions, safety gates, and provider/quality defaults before execution.
• Keep long command chains and tooling nuance in sub-docs; provider-specific implementation detail in provider-playbooks/*.md.
• Anchor recipes in credits-based actions (the high-value action calls). Free CRUD (createLead, getLead, deleteRecords) doesn't need this skill — agents can compose those ad hoc.

Process / goal

The user is generally trying to go from "I have an ICP" to "Here's a list of prospects with verified emails and personalized signals." They may be anywhere in this process — guide them along.

Discovery order: companies first, then people. When the task requires finding contacts at companies matching criteria (portfolio, ICP, hiring signal), discover the company set first, then find people at each company. Don't start with broad people-search queries.

Documentation hierarchy

• Level 1 — SKILL.md (this file): decision model, guardrails, routing table, links to sub-docs.
• Level 2 — Phase docs: [guides/finding-companies-and-contacts.md](guides/finding-companies-and-contacts.md), [guides/enriching-and-researching.md](guides/enriching-and-researching.md), [guides/writing-outreach.md](guides/writing-outreach.md).
• Level 2.5 — Recipes: [recipes/*.md](recipes/) — step-by-step playbooks for specific scenarios.
• Level 3 — Provider playbooks: [provider-playbooks/.md](provider-playbooks/) — provider-specific quirks, costs, and fallback behavior.

2) Read behavior — MANDATORY before any execution

STOP. Do not call any provider, run any cargo-ai orchestration action execute command, or write any search query until you have opened the correct sub-doc for your task.

These docs encode what works, what fails, and why. They contain validated parameter schemas, cheapest-provider mappings, parallel execution patterns, sample payloads, and known pitfalls. Reading the right doc for 10 seconds saves 10 failed action calls, wasted credits, and garbage output.

Routing rules — match your task to a doc and READ IT

| When the task involves… | You MUST read this doc first | What it gives you | |---|---|---| | Finding companies, finding people, building lead lists, prospecting, portfolio/VC sourcing, contact finding at known companies | [guides/finding-companies-and-contacts.md](guides/finding-companies-and-contacts.md) | Provider filter schemas, cheapest-source decision tree, parallel patterns, role-based search rules, portfolio/VC shortcuts, contact-finding patterns. | | Enriching companies or contacts, finding emails/phones/LinkedIn, waterfall enrichment, signal lookup (job change, funding, tech stack), coalescing data | [guides/enriching-and-researching.md](guides/enriching-and-researching.md) | Waterfall patterns with fallback chains, when to use cargo-native vs waterfall vs FullEnrich vs peopleDataLabs, email/phone/LinkedIn fallback orders, signal segments, output retrieval via run download-outputs. | | Writing cold emails, personalizing outreach, lead scoring, qualification, sequence design, campaign copy | [guides/writing-outreach.md](guides/writing-outreach.md) | LLM provider routing (openAi/anthropic/perplexity/gemini), prompt templates, scoring rubrics, email length/tone rules, personalization patterns. | | Building or modifying a recurring workflow (cron / webhook / scheduled tool / play), designing step sequences, triggers, deploy/verify cycles | [../cargo-orchestration/SKILL.md](../cargo-orchestration/SKILL.md) (capability) + apply-patterns from this skill's recipes + the [provider playbook](provider-playbooks/) of every paid node (§11, esp. its Recurring use section) | Schema for tool/play workflows, node graph syntax, polling strategies, output retrieval; per-provider cadence defaults and re-billing gates. |

Recipes: step-by-step playbooks (check before executing)

Scan this list and read the recipe matching your task. When a recipe matches: follow it step-by-step as your execution plan.

| Recipe | Use when… | |---|---| | [recipes/prospecting.md](recipes/prospecting.md) | End-to-end find → enrich → verify → sync (P1/P2/P3 variants) | | [recipes/build-tam.md](recipes/build-tam.md) | Building a Total Addressable Market list at scale (100–10,000 companies) | | [recipes/linkedin-url-lookup.md](recipes/linkedin-url-lookup.md) | Resolving a person's LinkedIn profile URL from name + company with strict identity validation | | [recipes/portfolio-prospecting.md](recipes/portfolio-prospecting.md) | Investor / accelerator → portfolio companies → contacts | | [recipes/job-change-monitoring.md](recipes/job-change-monitoring.md) | waterfall.detectJobChange (cargo-unique) on a contact segment | | [recipes/funding-watch.md](recipes/funding-watch.md) | Tracking companies that recently raised funding | | [recipes/tech-intent.md](recipes/tech-intent.md) | Finding companies by tech-stack or hiring-intent signals | | [recipes/icp-discovery.md](recipes/icp-discovery.md) | Diffing Closed-Won vs Closed-Lost segments to surface ICP signals | | [recipes/outreach-activation.md](recipes/outreach-activation.md) | Turning a signal segment into send-ready outreach (enrich → verify → personalize → sequencer handoff) | | [recipes/re-engagement.md](recipes/re-engagement.md) | Waking up stale contacts only when a fresh signal fires (job change, funding, tech intent) | | [recipes/lost-deal-revival.md](recipes/lost-deal-revival.md) | Reviving Closed-Lost CRM deals by branching on lost_reason (champion left, budget, timing) | | [recipes/account-expansion.md](recipes/account-expansion.md) | Multi-threading existing customer accounts — net-new buyers, deduped against the workspace's Contacts model | | [recipes/save-as-play.md](recipes/save-as-play.md) | Converting a successful ad-hoc run into a durable scheduled play or cron tool — offer after any repeatable pull | | [recipes/import-gtm-data.md](recipes/import-gtm-data.md) | Importing existing GTM data (CSV/CRM exports from any tool) into models, QA-auditing it, and selectively rebuilding recurring logic as plays with a parity check |

If none match, scan the phase docs above for the closest pattern and adapt — or invoke [agents/execution-plan-creator.md](agents/execution-plan-creator.md) to compose a custom chain with provider/action slugs and cost estimates. For wide sourcing sweeps that fan out (per-industry, per-geo), delegate approved slices to [agents/list-builder.md](agents/list-builder.md) — it executes exactly one pre-approved action per slice and returns rows to a file, keeping row data out of the main context. (On Claude Code with the plugin, both are installed as native subagents: cargo-execution-planner and cargo-list-builder.)

3) Cost discipline — MANDATORY gates

Full spec: [references/cost-discipline.md](references/cost-discipline.md). The short version every task must honor:

1. Sample → approval → full run, in that order. Run a slice of the exact input first — 1–3 rows to prove one action's config, 10–20 records before any batch (one row can't show a hit-rate). Then present the 4-section approval message (Assumptions · Sample result verbatim · Credits/Scope/Cap — always stating how many records the full run enrolls and what they cost, reconciled against the actual balance · 3 shaped choices); stay in AWAIT_APPROVAL until the user picks. Never fan out on an unapproved or cost-unknown action, and never read approval of the sample as approval of the full enrollment.
2. Receipt after every paid action: credits spent + balance remaining + hit-rate ("found 34 emails of 40") + estimate-vs-actual with the why when they diverge. Prefer billing usage get-metrics over your own arithmetic.
3. Over-provision 1.4×N, then filter — coverage is a property of the company; drop incomplete rows instead of chasing them with more providers.
4. Count first, pay second — search is billed on returned rows; keep limit strict and size the pool with a 1-row probe before any full pull.
5. Phone is the guarded lever (3–7 credits, ~10× email) — explicit user request only, qualified leads only.

4) After every run — receipt, then grounded next steps

End every completed run with the receipt (above), then propose 2–3 next steps maximum, computed from the data just produced — never a generic menu. Required shape:

1. Continuity — builds on this session's artifacts ("67 of these 70 companies have RevOps teams — find the leads?"), not a fresh generic idea.
2. Budget-aware — framed against the remaining balance ("with your ~9 credits left, ~5 verified emails fits").
3. Cost-per-unit stated — "email waterfalls run ~1.4 credits each."
4. A default picking heuristic so answering takes one word ("I'd default to: has funding data + RevOps ≥ 2 + posting is recent").
5. An escape hatch — always end with "or something else entirely."

When a run produced a durable, repeatable result, one of the suggestions should be making it systematic — see [recipes/save-as-play.md](recipes/save-as-play.md).

When a run or batch misbehaved — errors, missing downstream values, cost surprises — hand off to the cargo-diagnostics skill (../cargo-diagnostics/SKILL.md): sweep the batch for root causes before re-running anything paid. Interaction defaults for plan gates, shaped choices, and presenting results live in ../cargo/references/interaction.md.

5) Priority provider stack (recipes lead with these 6)

These six credits-based providers cover the full prospecting → enrichment → verification → signal pipeline at the lowest credit cost in the catalog. Every recipe in this skill's recipes/ leads with this stack:

| Provider | Role | Key actions (cost in credits) | |---|---|---| | salesNavigator | Sourcing | searchLeads (0.02), searchAccounts (0.05), findCompanyInsights/Metrics/EmployeesCount/Distribution (0.25 each) | | cargo (native) | Firmographic + signal intelligence | enrichBusinessFirmographics (0.5), …Technographics (1), …FundingAndAcquisitions (0.5), enrichProspectDetails/LinkedinProfile/LinkedinPosts (2), matchBusiness/matchProspect (0.5), 13 more | | waterfall | Multi-source enrichment + signal | enrichContact (2), enrichCompany (1), verifyEmail (0.1), detectJobChange (3), searchProspects (3), findPhone (7) | | FullEnrich | Premium contact lookup | findEmail (1), findPhone (6), findPhoneAndEmail (7), reverseEmailLookup (2) | | theirStack | Tech-stack + hiring intent | searchTechnologies (0.5), searchJobs (0.5), searchCompanies (0.5) | | peopleDataLabs | Heavyweight backfill | enrichPerson (3), enrichCompany (3), searchPeople (3), searchCompanies (3), queryPeople/Companies (3) |

See [provider-playbooks/](provider-playbooks/) for per-provider deep dives — including each provider's Recurring use section for when the task is a monitor, play, or scheduled pull rather than a one-off. See [references/stage-action-map.md](references/stage-action-map.md) for the complete cheapest-action-per-stage table across the full 120-integration catalog.

> Already holding identifiers (not sourcing)? The stack above leads the sourcing-first spine. When you already have LinkedIn URLs, the cheapest enrich is [linkedin](provider-playbooks/linkedin.md) — enrichProfile / enrichCompany (0.25, URL → person/company details incl. headcount, industry, funding), not waterfall.enrichContact (which keys on email or name+company). Have a LinkedIn event URL? linkedin.extractEventAttendees sources the attendee list directly. Have emails? leadMagic / contactOut. See references/stage-action-map.md for the full input-type → cheapest-action map.

6) Recipe spine (default chain)

1. SOURCE   → salesNavigator.searchLeads / searchAccounts            (0.02–0.05/record)
2. DEDUPE   → cargo.matchProspect / cargo.matchBusiness              (0.5/record)
3. ENRICH   → LinkedIn URL in hand? linkedin.enrichProfile/enrichCompany  (0.25) FIRST
              cargo.enrichBusinessFirmographics / Technographics
              + waterfall.enrichContact / enrichCompany              (0.5–2/record)
4. SIGNAL   → cargo.enrichBusinessFundingAndAcquisitions
              + theirStack.searchJobs
              + waterfall.detectJobChange                            (0.5–3/record)
5. CONTACT  → FullEnrich.findEmail (fallback peopleDataLabs)         (1–3/record)
6. VERIFY   → waterfall.verifyEmail                                  (0.1/record)
7. BACKFILL → peopleDataLabs.enrichPerson (only if step 5 missed)    (3/record)
8. QA       → scripts/contact-accuracy-audit.ts                      (free, local)

Adapt by phase: drop steps that aren't relevant to the user's goal. For pure sourcing, run step 1 only. For "enrich a list I already have," run steps 2–7.

7) Output retrieval — use run download-outputs, not run download

When the agent needs the actual data produced by an action (enriched fields, found emails, search results), use:

cargo-ai orchestration run download-outputs \
  --workflow-uuid  \
  --output-node-slug  \
  --format json

(Don't pass --is-finished — the CLI help still lists it but the API currently rejects it with unrecognized_keys; reported.)

Returns {"url": "..."} — a signed URL to a CSV/JSON containing only the output node's data. Faster and cheaper than run download (which pulls full run records). See [references/output-retrieval.md](references/output-retrieval.md) and [../cargo-analytics/SKILL.md](../cargo-analytics/SKILL.md).

8) Contact accuracy — run the QA scripts, don't eyeball

Four deterministic TypeScript scripts in [scripts/](scripts/) (Node ≥ 22.18, zero deps, fixture-tested in CI) replace in-context row checking. Run the script — never re-derive its logic by reasoning over rows. Full doctrine, pipeline order, and the SEND/VERIFY/REVIEW/REMOVE verdict semantics: [references/contact-accuracy.md](references/contact-accuracy.md).

• scripts/validate-emails.ts — free syntax/risk/duplicate cull before paid verifyEmail.
• scripts/select-current-role.ts — pick the real current role from an experiences array (catches job changers).
• scripts/validate-linkedin-names.ts — name↔profile match (catches same-name decoys); pairs with [recipes/linkedin-url-lookup.md](recipes/linkedin-url-lookup.md).
• scripts/contact-accuracy-audit.ts — final per-row audit_action stamp on the merged output; cite its summary counts in the receipt. Reads files or a finished run directly (--workflow-uuid, via @cargo-ai/api).

9) Action shape rules (every recipe)

Every action JSON in this skill follows the rules in [../cargo-orchestration/references/examples/actions.md](../cargo-orchestration/references/examples/actions.md):

• kind: "connector" action shape: {"kind":"connector","integrationSlug":"","actionSlug":"","config":{}}. connectorUuid is NOT in config — the platform resolves the workspace's authenticated connector from integrationSlug automatically.
• For multi-step node graphs: connectorUuid lives at the top level of the node, not in config. Cross-node interpolation uses {{nodes..}}. Agent node outputs wrap under .answer (read as {{nodes..answer.}}).

10) When stuck — file a workspace report

If a recipe fails repeatedly and the cause isn't obvious, escalate via cargo-ai workspaceManagement report create. See [../cargo-workspace-management/SKILL.md](../cargo-workspace-management/SKILL.md) (Reports section).

11) Provider playbooks — read before you call (one-off or recurring)

**STOP — do not execute any paid a

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: getcargohq
• Source: getcargohq/cargo-skills
• License: MIT
• Homepage: https://getcargo.ai

Install and usage instructions live in the source repository linked above.