GTM Meta Skill

Quick Start

npm install -g deepline
# Fallback for secure sandboxes: mkdir -p "$HOME/.local" && npm config set prefix "$HOME/.local" && export PATH="$HOME/.local/bin:$PATH" && npm install -g deepline --registry https://code.deepline.com/api/v2/npm/
deepline auth register --wait auto
deepline auth wait --timeout 120 # completes Cowork/browser approval; no-op if already connected
deepline auth status
deepline -h

CLI resolution

Run deepline commands bare — no pipes, redirection, 2>&1, command chaining, or backgrounding around them. The CLI already formats, truncates, and prints what you need; deepline billing usage | head reads as parsing and loses output.

Run deepline when it is available. If the shell reports that command is missing, use <workspace-root>/.deepline/runtime/bin/deepline (or the npm-created .cmd shim on Windows). If neither exists, follow https://code.deepline.com/INSTALL.md to set up Deepline.

Before the first Deepline fanout in a task, run deepline preflight --json as one standalone command and wait for it to finish. Never submit preflight beside another Deepline command. It combines health, authentication, and balance in one process and gives any automatic CLI update a serial boundary.

After preflight succeeds, prefix every Deepline command that may run concurrently with DEEPLINE_SKIP_SELF_UPDATE=1. This environment prefix is the only exception to the bare-command rule above. Serial commands may stay bare; the opt-out is required for every member of a parallel batch.

Debug every Play run first. Start a new run with deepline plays run <play> --input '<json>' --debug; for an existing run save the complete retained stream with deepline runs logs <run-id> --out run.log --json, then use deepline runs get <run-id> --full --json. This preserves the durable trail instead of spending on a duplicate run. A caught non-2xx ctx.fetch records a customer-safe diagnostic with its call key, method, destination origin, and HTTP status. Generic HTTP is a separate provider surface: inspect the full run package before treating its provider-level error status as the upstream HTTP status or its error body as a safe customer-facing explanation.

Ask for requirements, not implementation instructions. Requirements are the business outcome, target population, constraints, time horizon, requested destination, and any stated spend or authority boundary. The provider, tool, query shape, identifier recovery, filter expression, fallback order, and workflow structure are implementation decisions. Infer and execute the latter; do not turn them into a questionnaire. When a requirement is genuinely absent and materially changes the result or external action, ask one concise question with a recommendation. Otherwise state a reasonable assumption in the result and keep moving.

Decision-ready communication. The user should never have to infer the answer from a status update. When work produces people, companies, events, or rows that determine the next move, show those real records in a readable Markdown table first. Link a person's name to their verified LinkedIn profile when one was returned; do not hide the decision behind counts, summaries, or a generic Profile column. For choices, show the comparison; for copy, show the draft; for research, show the evidence that supports the conclusion.

Then make one plain-language recommendation based on what is visible. State the concrete boundary—who is in, out, or what changes—not a label such as “keep” or “refine.” Do not ask the user to design routine filters or choose plumbing. Keep validation, raw ids, feeds, and tool mechanics internal unless they change scope, cost, risk, confidence, or action.

When the user is calibrating, choosing a scope, prioritizing a list, or authorizing a change, use this complete envelope:

<the table, comparison, draft, or evidence>

Recommendation: <one concrete next state and why>.
Want me to use that, or adjust it?

End with Want me to use that, or adjust it? exactly. The user can say “yes” or name the adjustment. A calibration, scope, or prioritization response is incomplete without that final line, even when it starts no external action. Do not add a second question, a menu, or an implementation checklist. If no user decision is needed, state the outcome and stop.

Paid monitors. Before deployment show the recommended scope, live Deepline price, and delivery in the smallest useful shape. Check Slack first; recommend a real connected channel when one is available, otherwise offer Slack or the configured CRM. The monitor recipe covers consent, history, and similar-company scope.

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. Do not start with broad people-search queries.

Named companies are enough to start. When the user gives company names but not domains, resolve each canonical company domain before asking them for anything. A domain is a recoverable identifier, not clarification debt. Carry the resolved domain and its official-page evidence into the downstream lookup; do not ask the user to paste a domain list merely because a later tool needs one. Read finding-companies-and-contacts.md for the identity gate and ambiguity handling.

Known companies + nuanced roles: qualify the real title roster first. For requests such as "AI leadership at Mount Sinai," "job titles at these companies," or "find the RevOps buyers at these accounts," read and follow recipes/find-qualified-titles.md: company_titles -> qualify exact roster titles -> deepline_native_search_contact with title_lists. Use Exa afterward for public-profile gaps and DropLeads last for supplemental database rows. Broad audience sizing remains a valid DropLeads use case.

CLI recovery

The SDK CLI is the supported CLI. If it is unavailable, run deepline update or reinstall it with npm install -g deepline@latest; do not switch CLI families.

2) Read the matching workflow before execution

SKILL.md routes; the matching doc supplies the execution contract. Read it before using a provider so its schema, sequencing, and known failure modes govern the run.

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 (that SKILL.md doesn't)
Finding companies, finding people, building lead lists, prospecting, portfolio/VC sourcing, contact finding at known companies, coverage completion at scale	finding-companies-and-contacts.md	Provider filter schemas, parallel execution patterns, provider mix tables, role-based search rules, subagent orchestration, at-scale coverage completion, portfolio/VC shortcuts, contact finding patterns.
Researching companies or people, understanding what they build, figuring out use cases, personalizing based on mission/product/industry, enriching a CSV, adding data columns, waterfall enrichment, finding emails/phones/LinkedIn, coalescing data, custom signals, run_javascript / deeplineagent columns, Apify actors — any task that adds or transforms row-level data	enriching-and-researching.md	Play routing per scenario (deepline plays run + batch prebuilts + fork/wrap), waterfall orders for email/phone/LinkedIn, run_javascript / deeplineagent routing inside custom plays, multi-pass pipeline patterns, coalescing, custom signal buckets, Apify actor selection, GTM definitions and defaults.
Writing, running, auditing, or modernizing Deepline plays — composing tools/plays, mapping CSV rows, reviewing an existing .play.ts or saved Play for deprecated APIs/tool IDs, fallback logic, joins/projections, durable datasets, custom run/export behavior, or webhook/cron-style orchestration.	recipes/deepline-plays.md	Direct vs compose decisions, plays check-driven audits and remediation order, bootstrap/wrap/fork rules, durable authoring basics, run/export/repair routing, and exact SDK/API reference pointers.
Writing cold emails, personalizing outreach, lead scoring, qualification, sequence design, campaign copy, inspecting CSVs in Playground. If the task also requires researching companies/people to inform the writing, read enriching-and-researching.md too — it has the multi-pass pipeline pattern.	writing-outreach.md	Prompt templates from prompts.json. Scoring rubrics. Email length/tone/structure rules. Personalization patterns. Qualification frameworks. Playground inspection commands.
Deepline Monitors — continuously capturing a provider's webhook events (email replies, new job postings, intent signals) into a Customer DB table, or deploying/listing/managing those upstream provider pipes. Event-driven streaming, NOT an on-demand enrich/sourcing run. Conditional gate: run deepline monitors status --json first. Read the recipe only when the command exits 0 with has_access: true. Exit 1 with has_access: false means rollout access is absent. For exit 3, fix auth/permission; for exit 5, diagnose configuration/server reachability. Do not reinterpret other failures as rollout denial.	recipes/deepline-monitors.md	What Monitors are, when to use them vs plays, the full deepline monitors command set (status, available, check, deploy, list, get, update, delete, reactivate), monitor definition shape, the provider-webhook → Customer DB → triggered-play data flow, and the access gating.

If you are hand-authoring enrich columns instead of using a native play, jump straight to the "Handmade step shape quick reference" section in enriching-and-researching.md. That section spells out the exact runtime contract for run_javascript, extract_js, result, and persisted matched_result.

Recipes: step-by-step playbooks for specific tasks (check before executing)

Read the matching recipe before executing. Follow its sequence; adapt it only when the request requires it.

Recipe	Use when...
account-orgchart.md	Building an org chart, account map, buying committee, stakeholder map, or multi-threading plan around a target person or company
build-tam.md	Building a total addressable market list or large company list from ICP criteria
clay-to-deepline.md	Converting a Clay table to Deepline (deprecated enrich-era recipe — use its action mappings, author the result as a custom play)
deepline-monitors.md	ACCESS-GATED. Deepline Monitors continuously capture a provider's webhook events into a Customer DB table and trigger plays. Run deepline monitors status --json first; only exit 1 with has_access: false is a clean rollout denial. Diagnose auth, configuration, and server failures by their actual exit code.
deepline-plays.md	Creating or auditing .play.ts and saved Plays, including deprecated APIs/tool IDs, durable datasets, fallback logic, joins/projections, webhook/cron-style orchestration, and custom run/export behavior
find-qualified-titles.md	Primary path for nuanced roles at known companies: "AI leadership at Mount Sinai", "find all job titles at these companies", or "find the marketing-ops/RevOps/Salesforce buyers". Pull each company's real title roster (free company_titles), qualify exact titles, then find contacts with tiered (LinkedIn, email, phone) reveal.
linkedin-url-lookup.md	Resolving a person's LinkedIn profile URL from their name and company with strict identity validation
portfolio-prospecting.md	Finding companies backed by a specific investor or accelerator, then finding contacts and building personalized outbound
small-business-prospecting.md	Finding local small businesses or storefront/service-area companies using Maps-style search. Doctors, services business, restaurants, etc.

Public/social source discovery, community-language pulls, pre-research source planning, or provider-coverage/cost comparison → use the standalone deepline-pre-research skill, not a recipe here. It owns X/Twitter, Reddit, Hacker News, Bluesky, and public-registry fanout plus the source-plan + Deepline-cost synthesis.

If none match, grep for more specific keywords: Grep pattern="<keyword>" path="<directory containing this SKILL.md>/recipes/" glob="*.md" output_mode="files_with_matches"

Data

• When the user hands you a CSV, run deepline csv show --csv <path> --summary first to understand its shape (row count, columns, sample values) before deciding how to process it.
• NEVER read a large CSV into context with the Read tool. Reading CSV rows into the conversation window exhausts context and produces zero output. This is the single most common failure mode.
• For row-by-row processing (enrichment, rewriting, research, scoring), use a Deepline play per §2.5: prebuilt if one fits, fork/wrap when close, author when not.
• To explore or understand CSV content without loading it, use deepline csv show --csv <path> --rows 0:2 for a two-row sample, or spawn an Explore subagent to answer questions about the data.
• Pilot before scale: slice the CSV (head -3 in.csv > pilot.csv), run the play on the slice, deepline runs export and inspect, then run the full file. Small-input exception: when an exact-fit prebuilt covers a small input (≤ ~25 rows) whose scope the user already stated, the full file IS the pilot — run it once.
• The pilot is never the deliverable. A task is not done until the FULL input has run and the result is exported to the exact requested output path: deepline runs export <run-id> --out "$FINAL_CSV". Finishing with only a pilot CSV, or an export under a play-derived name, is the single most common way to fail the task while feeling done.

Tools

For signal-driven discovery (investor, funding, hiring, headcount, industry, geo, tech stack, compliance), start with deepline tools search. Do not guess fields. Its syntax is deepline tools search [query] [--categories <categories>] [--search_terms <terms>] [--json]: provide a query, or at least one of --categories and --search_terms. The query is optional only for structured filtering. Use commas for multiple categories or search terms. There is no --prefix flag; include a provider name in the query when needed.

Search 2-4 synonyms, execute in parallel only after the standalone preflight:

DEEPLINE_SKIP_SELF_UPDATE=1 deepline tools search investor
DEEPLINE_SKIP_SELF_UPDATE=1 deepline tools search "crustdata investor"
DEEPLINE_SKIP_SELF_UPDATE=1 deepline tools search --categories company_search --search_terms "structured filters,icp"
DEEPLINE_SKIP_SELF_UPDATE=1 deepline tools search --categories people_search --search_terms "title filters,linkedin"

2.5) Plays are the surface

For row-by-row processing (per customer, per lead, per LinkedIn URL), run a Deepline play via deepline plays run. deepline enrich is deprecated — do not use or document it; when no play fits, author one.

1. Discover live, then run. deepline plays search <query> and deepline plays describe <name> — choose from the live catalog and its contract, never from memory. Search results include a runCommand and a cloneEditStarter for every prebuilt.

2. Prebuilt fits → run it. Batch prebuilts take a CSV directly: deepline plays run prebuilt/name-and-domain-to-email-waterfall-batch --input '{"csv":"leads.csv"}', then deepline runs export <run-id> --out "$FINAL_CSV".

3. Close but not exact → pull and edit it. Every prebuilt is forkable:

   deepline plays get prebuilt/<name> --source --out ./<name>.play.ts
   deepline plays check ./<name>.play.ts   # mandatory before running
   deepline plays run --file ./<name>.play.ts --input '{...}'
   

   If plays check fails on a missing local import, that prebuilt is multi-file — wrap it instead of forking: deepline plays bootstrap <family> --from <source> --using play:prebuilt/<name> --limit 5 --out workflow.play.ts.

4. No play fits → author one from scratch per recipes/deepline-plays.md: compose tools and other plays, map CSVs, add fallback logic and joins.

Results live in the Customer DB. Every batch play persists its dataset as a durable table: deepline db query --sql 'select * from "storage"."<table>" limit 20' --max-rows 20 --json (the run output names the table). Columns are the play's snake_case fields plus per-leg columns like email_result__hunter_email — the per-provider audit trail. Rerunning reuses filled cells instead of re-buying them; exports are projections of this table, so nothing is lost if a CSV goes missing.

The iterate loop — pilot, price, fix, then scale:

1. Run a few rows (slice the CSV or run 2-3 scalar inputs).
2. Read price and performance: deepline runs get <run-id> --full --json reports billing and per-step outcomes; the storage table's per-leg columns show which providers hit, missed, or erred.
3. Fix what the pilot exposed BEFORE scaling: a provider that misses or flakes on your segment gets dropped or reordered in a fork; wrong columns get a columns map; weak coverage gets a different route. Do not buy the same failure at full scale.
4. Run the full file, export to FINAL_CSV, and report to the user: rows delivered, coverage, observed credits, and what you changed after the pilot.

3) Core policy defaults

3.1 Definitions and defaults

GTM time windows, thresholds, and interpretation rules are defined in the Definitions section of enriching-and-researching.md.

Provider Playbooks

Provider-specific playbooks are bundled as separate reference files. Open the relevant playbook when provider-specific behavior, pricing, caveats, or payload conventions matter.