GTM Meta Skill
Use this skill for prospecting, account research, contact enrichment, verification, lead scoring, personalization, 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. - Provide clear entry points for both paid and non-paid workflows, including
--rows 0:1one-row pilots.
Process/goal
Customer is generally trying to go from "I have an ICP" to "Here's a list of prospects with email/linkedin and very personalized content or signals". They may be anywhere in this process, but 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. Do not start with broad people-search queries.
Documentation hierarchy
- Level 1 (
SKILL.md): decision model, guardrails, approval gates, links to sub-docs. - Level 2 (phase docs): finding-companies-and-contacts.md, enriching-and-researching.md, writing-outreach.md,
prompts.json. - Level 2.5 (
recipes/*.md): step-by-step playbooks for specific tasks (email lookup, LinkedIn resolution, waterfall patterns, contact finding, actor contracts). Search like code with Grep. - Level 3 (
provider-playbooks/*.md): provider-specific quirks, cost/quality notes, and fallback behavior.
No-loss rule: moved guidance remains fully documented at its canonical level and is linked from here.
2) Read behavior — MANDATORY before any execution
STOP. Do not call any provider, run any deepline tools execute, or write any search command until you have opened the correct sub-doc for your task.
These skill docs and sub-docs are not generic documentation — they are distilled from hundreds of real runs and encode exactly what works, what fails, and why. They contain validated parameter schemas, correct filter syntax, parallel execution patterns, tested sample payloads, and known pitfalls that took many iterations to discover. Think of them as shortcuts: reading a doc for 5 seconds saves you from 10 failed tool calls, wasted credits, and garbage output. Every time an agent skips reading the docs and tries to "figure it out" from first principles, it re-discovers the same failure modes that are already documented and solved.
SKILL.md is the routing layer — it tells you WHERE to go, not HOW to execute. The sub-docs and task-specific skills contain the HOW. Without them you will guess parameters, pick wrong providers, run searches sequentially instead of in parallel, and produce garbage results. This has happened repeatedly.
Open the right doc BEFORE executing
This is not optional. Read the matching doc. Do not skip this step. Do not "just try Apollo real quick" or "just run one search to see." These docs exist because the correct approach was non-obvious and had to be learned through trial and error — they are shortcuts that let you skip straight to what works.
!important READING MULTIPLE DOCS IS A GREAT IDEA AND OFTEN SUPER ESSENTIAL. JUST READ MORE.
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 steps, Apify actors — any task that adds or transforms row-level data | enriching-and-researching.md | deepline enrich syntax and all flags. Waterfall patterns with fallback chains. run_javascript / deeplineagent routing. Multi-pass pipeline patterns (research pass → generation pass). Coalescing patterns. Email/phone/LinkedIn waterfall orders. Custom signal buckets. Apify actor selection. GTM definitions and defaults. |
| 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. |
Building or modifying a cloud workflow (deepline workflows apply), designing step sequences, data contracts, triggers (webhook/cron/API), waterfall blocks, expectations, deploy/verify cycles, or debugging a failing workflow run. This is NOT the same as a GTM enrichment workflow — cloud workflows are persisted automations with triggers. | references/cloud-workflow-builder.md | Schema for WorkflowApplyInput, Command, and Waterfall blocks. Placeholder resolution rules. run_javascript environment. Spec template. Deploy/verify/iterate loop. Execution modes (smoke_test, dry_run). Disabled steps. Poll+dispatch and fanout patterns. |
If you are hand-authoring enrich col