contact-sourcing

--- name: contact-sourcing description: 'Build a reusable on-demand tool that sources stakeholders at supplied accounts, qualifies their responsibilities, and returns all or up to N ranked by contact fit, with optional verified work email and phone enrichment. Triggers: "build a contact sourcing tool", "set up stakeholder sourcing", "rank stakeholders by relevance", "install contact sourcing", "return an enriched shortlist per account". LinkedIn, Sales Navigator, OpenAI, Cargo project. Skip when: the user wants people at named accounts once today; use find-stakeholders. Existing profiles needing data use enrich-linkedin-profile; CRM field maintenance uses crm-enrichment.' version: "0.1.0" compatibility: "Requires the cargo-project skill and a Cargo project. Checked with @cargo-ai/cdk 1.0.139 and zod 4.4.3 from the repository lockfile. No CRM, storage model, or play is required. Adapt in the consumer project before deployment." homepage: https://github.com/getcargohq/gtm-skills/tree/main/contact-sourcing metadata: author: getcargo source: cookbook personas: - gtm-engineering - revops - sales-development openclaw: requires: bins: - cargo-ai install: - kind: node package: "@cargo-ai/cli@latest" bins: - cargo-ai homepage: https://github.com/getcargohq/gtm-skills --- # Contact sourcing **State: to-be-approved.** Offline contracts are checked; a fresh demo workspace and two customer or partner implementations are still required for approval. ## The outcome For each supplied account, an on-demand Cargo tool returns the most relevant stakeholders found within an approved search limit, ranked by their fit for the seller's product or use case. It returns all qualified people or up to N per company, independently of optional verified work email and phone enrichment. Three is a starting suggestion, never a fixed ceiling. Ask for top 3, top 5, top 10, any other positive N, or all; enterprise accounts may need more. Relevance comes from responsibilities and current profile evidence. Buying role informs that assessment; seniority alone does not move someone above a relevant practitioner. Ranking never means outreach order, triangulation, or an allocation of seats on a buying committee. ```mermaid flowchart TD input["Supplied account"] --> identity{"Company ID available?"} identity -->|Yes| search["Search current employees · approved titles · cap"] identity -->|No| resolve["Resolve URL or domain · validate company"] resolve -->|Unresolved or conflicting| stop["Return company_not_resolved"] resolve -->|Resolved| search search --> dedup["Deduplicate stable person identities"] dedup --> evidence["Retrieve profile · structured AI qualification"] evidence --> rank["Qualified only · numeric sort · stable ties"] evidence --> uncertain["Keep insufficient evidence identifiable"] rank --> select["Select all or slice top N · maximum only"] select --> requested{"Enrichment requested?"} requested -->|No| full["Return selected ranked people"] requested -->|Yes| enrich["Reuse suitable data · requested email/phone only"] enrich --> result["Return selected people · preserve profile and rank · show failures"] ``` The installer builds only the chosen input and output paths. Seller research happens during setup. Each run uses the saved, approved criteria; the tool is a predictable workflow containing one structured qualification call per usable profile, with no autonomous research agent. ## Example > Build a tool that finds up to three people responsible for capital-project schedules at each account, starting with bridgeworks.example. I only need their profiles and fit scores. Illustrative output, fictional records: | Rank | Person | Current title | Fit / 10 | Supporting evidence | | ---- | ----------- | ------------------------ | -------- | --------------------------------------------------------- | | 1 | Morgan Vale | Project Controls Manager | 9 | Owns schedule-risk reviews across capital projects | | 2 | Alex Rowan | Senior Planner | 8 | Maintains construction schedules and evaluates delay risk | Two qualified people returned from 12 candidates; the maximum is three. Profile evidence accompanies each result. No email or phone lookup was requested. ## Put it in your project The procedure lands in `.agents/skills/contact-sourcing/`, with `.claude/skills/contact-sourcing` symlinked to it. If you found this file at either path in the project, the copy happened: start at step 2. Read the `cargo-project` skill before adapting resources. If absent, install it with `npx skills add getcargohq/cargo-skills --skill cargo-project`, then read its `SKILL.md` directly. 1. **Copy with the CLI.** In an existing project run `cargo-ai project add cookbook/contact-sourcing`. Without a project, `cargo-ai project init <dir> --cookbook contact-sourcing`, enter that directory, and install its dependencies. Never use `init --force` in a non-empty project. 2. **Inspect and derive.** Follow [audit.md](references/audit.md). Inspect the seller context, existing personas, authenticated connectors and reusable email/phone tools. Rewire the example's adopted connectors to compatible existing handles; remove duplicate declarations. No CRM is a valid setup. 3. **Confirm the title Boolean and people.** Derive personas and titles from the existing context graph, or crawl the seller's website, product pages and customer stories to fill missing knowledge of decision makers and relevant responsibilities. Offer optional closed-won intelligence after checking connectivity. Show the exact title Boolean, inclusions/exclusions, persona table and qualification prompt together and ask the operator to confirm them. Recommend slightly broader title coverage because retrieved candidates will be scored before selection; explain the additional profile/LLM cost. Apply corrections and save approved criteria in the consumer's context conventions. 4. **Configure and show.** Follow [configure.md](references/configure.md). Ask whether to use an OpenAI or Anthropic (Claude) API key or Cargo credits; reuse the selected connector, never ask for the secret in chat. For the chosen own-key provider use a bounded qualification agent with the same JSON schema; Claude runs through Anthropic, OpenAI through OpenAI. Confirm the model and billing choice. Ask how many qualified people to return per company: offer top 3, top 5, top 10, any positive N or all. Three is only a starting suggestion; recommend more for enterprise buying committees when the known context supports it. Choose the count independently of enrichment. If the optional CRM analysis already provides useful won-deal evidence, recommend N with a brief reason; otherwise ask directly. Do not add a separate audit. Recommend the input, requested fields, search limit and any relevance threshold from what was inspected. Explain each choice's effect and tradeoff next to that decision, ask only what remains unanswered, then build the chosen graph. Record choices under `## Decisions` in the consumer copy. A configuration approval already given in this session remains valid. 5. **Review before deployment.** Run the adapted contract, `cargo-ai project types`, `cargo-ai project check` and `cargo-ai project plan`. Show the actual graph and resource diff. Obtain criteria/configuration approval and explicit authorization for deployment in this consumer workspace before creating resources. Deploy within that authorization. Tools have no disabled-play switch: this tool has no trigger, schedule or implicit run. Provide its direct Cargo link. 6. **Calibrate on an approved sample.** Follow [run.md](references/run.md). Propose representative accounts, disclose cost by stage and ask approval of the sample and maximum cost. Run only that sample, show ranked people with evidence, collect corrections, update reusable criteria, and retest affected cases with additional cost approved where needed. Report actual cost, coverage and unresolved issues. 7. **Choose composition.** Only after calibration, ask whether to keep the on-demand tool or connect it to a play. A play needs an approved population, trigger, selection/enrichment owner and destination. Installation authorizes no CRM write, campaign, message, recurring schedule or full batch. At every meaningful decision: explain the change, recommend from the inspected situation, give the reason and alternative's tradeoff, ask for the operator's choice, then build it and show what happened. Keep this short and local to the choice. Derive available facts first; never ask twice for an answered decision. ## What you will be asked Derive before asking. The staged approval checkpoints are separate from missing configuration facts; bundle related choices without turning setup into a survey. | Input | Kind | How it is answered | Why it matters | | ---------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | `existing_context_and_connections` | derived | Read seller context, personas, connectors and tool releases; inspect CRM connectivity without reading private deal contacts yet | Prevents repeated research and duplicate resources; a CRM is optional | | `provider_contract_and_costs` | derived | Read current action schemas, output paths, autocomplete values and cost metadata | Prevents guessed filters and hidden page or verification charges | | `seller_and_personas` | asked if missing, then confirmed | Establish product/use case; offer optional customer intelligence; approve persona table, Boolean and prompt together | The tool ranks fit for this seller rather than generic seniority | | `company_input` | asked if missing | Choose ID, URL, domain, or necessary multiple-input support | An upstream ID skips paid resolution; extra identifiers must agree | | `output_and_scope` | asked if missing | Choose top 3, top 5, top 10, another N or all; use useful existing won-deal evidence to refine N; choose enrichment, LLM provider/key-or-credits, search limit and restrictions | Count and enrichment are separate; provider choice preserves the schema | | `sample_and_calibration` | asked | Approve exact sample/max cost; assess relevance and missing people | Static checks cannot prove provider coverage or qualification quality | ## What you can change Offer these when relevant, with the recommendation at the actual decision point. | Variation | When it is right | How | What it costs | | ----------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | `input` | Upstream already supplies ID, or the operator has URL/domain | Set `inputMode`; keep only necessary routes | URL/domain adds resolution; ID bypasses it | | `output` | The operator wants all relevant people or a bounded list | `topN: null` returns all qualified; a positive N slices after sorting, with or without enrichment | N caps output and any selected lookup spend; profile/AI spend still follows the search limit | | `enrichment` | The operator needs contact details with the ranked result | Set `email`/`phone` independently of the all-or-N choice | Adds only requested lookup/verification for selected people; a play can own this instead | | `search_and_criteria` | Title ambiguity, geography or business-unit differences affect fit | Update approved personas, title filters, optional threshold and restrictions together | Wider search raises profile/AI spend; narrower search can miss people | | `model` | The operator has an OpenAI/Anthropic key or wants another supported model | Choose `qualificationBackend`, `qualificationProvider` and `qualificationModel`; keep the shared schema and score anchors | Changes per-profile cost and judgment; agent mode adds only a bounded qualifier and its folder | | `customer_intelligence` | Deal evidence can refine website positioning | Read CRM/export contacts only after the operator chooses it | Extra analysis and private-data handling; website-only setup is faster | | `reachable_N` | Operator explicitly needs N reachable contacts | Add a separate maximum attempt/cost budget and report original ranks | May enrich lower-ranked people and cost more; never the default | | `play` | Calibrated results should feed an existing process | Confirm population, trigger, ownership and destination before wiring | Repeated executions rebill each eligible account; destination actions need their own authorization | ## What should not change - **Resolve before sourcing.** `infra/index.ts` gates every search on a valid, verified company ID. Missing or conflicting identity returns `company_not_resolved`; losing the gate permits an unscoped people search. - **Titles find; evidence qualifies.** Wrong employers and responsibility mismatches are excluded; insufficient evidence stays identifiable outside the shortlist. An advisory seat does not prove primary employment. - **One identity before repeated spend.** Deduplicate stable LinkedIn IDs and canonical URLs before profiles and qualification. Do not equate opaque Sales Navigator IDs with numeric LinkedIn IDs or deduplicate people by name. - **Qualification precedes selection.** Profile retrieval supplies evidence; email/phone lookup supplies contact details later. Ranking by title alone or applying N before qualification changes which people can be returned. - **Count is independent of enrichment.** Return all qualified or slice up to N after sorting, even without contact lookup. N is a maximum; fewer qualifying people means fewer results. Optional enrichment only touches selected people. - **Sort numerically with stable ties.** The 0–10 scale has anchors. Selection uses an ordinary slice. An LLM does not order the array or assign outreach priority; enrichment completion order cannot change the saved ranks. - **Preserve selected people.** Lookup failures retain profile, qualification and rank with explicit statuses. Do not backfill lower-ranked contacts or retrieve LinkedIn profiles again after selection. - **Found is not verified.** Reuse only contact data meeting the approved requirements. A returned address without explicit verification stays unknown. - **Keep installation bounded.** No CRM, model, play, agent or unused enrichment branch is required for the default OpenAI-action path. Agent mode adds only a one-step qualifier with the same schema, without tools, memory, browsing or triggers. Reuse audited resources and the chosen provider connection. - **Approval has separate scopes.** Criteria/deployment approval precedes resource creation; sample and maximum-cost approval precedes paid execution; a full batch, destination write or schedule requires its own scope. ## Done when - Approved seller criteria retain source URLs, observed evidence, inferences, exclusions, persona IDs, provider filters and prompt version in consumer context. - The operator's closed-won research choice is recorded; website-only setup works. - The operator confirmed the exact title Boolean derived from context or seller research, the slightly broader search and its cost, and the provider/billing choice. - The compiled graph contains only selected input/output paths and no implicit play. - Live provider schemas and existing tool output mappings have been checked. - Unresolved companies cannot source; stable identity deduplication precedes spend. - Qualifications preserve profile evidence, current employment, uncertainty and a numeric fit score; the returned contacts have deterministic ranks. - The operator chose all or up to N independently of enrichment; the sorted qualified ranking is sliced before any requested lookups, returning fewer when needed. Three is only a starting suggestion; the chosen N has no fixed ceiling. - Only selected people receive requested email/phone enrichment; verified data can be reused; failures remain visible without backfill or a repeated profile lookup. - The adapted executable contracts, project type generation, check and plan pass. - The operator approved deployment, then the exact paid sample and maximum cost. - The sample shows coverage, ranked evidence and actual stage costs; corrections update reusable criteria and affected examples are retested as authorized. - The final handoff identifies unperformed live checks and any pending approval evidence, including this build's requested fresh demo and two implementations. ## What it costs Read current `salesNavigator`, `linkedin`, the chosen LLM provider/agent and selected enrichment tool and verification metadata immediately before a preview. Record lookup time, CLI version, action slugs, units, cache assumptions and model settings. Separate company resolution, people sourcing, profile retrieval, AI qualification, email lookup/verification and phone lookup. Sales Navigator pages contain 25 records: the compiled provider limit is `ceil(searchLimit / 25) * 25`, while profile/qualification work is capped at `searchLimit`. Recommend a page multiple when it suits the account and explain any paid excess. Reaching the cap means limited coverage, even if every retrieved person is qualified. Use the formula and approval procedure in [run.md](references/run.md). Do not invent fixed prices, free-cache guarantees or a universal relevance threshold. ## Composes into - `tam-building` supplies accounts and can pass already-resolved company IDs. - `crm-enrichment` supplies reusable company identity/profile components when present. - A play can slice `contacts` and own enrichment itself, or consume an enriched shortlist directly; it owns any approved destination write. - `find-stakeholders` remains the one-off choice for people at named accounts today.

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本