/deepline-gtm

name: deepline-gtm
description: "GTM prospecting, enrichment, outreach, and Deepline Play work/audits. Providers: adyntel,affinity,ai_ark,akta,allegrow,amplemarket,apify,attention,attio,aviato,bettercontact,bigquery,bluesky,bounceban,browserbase,builtwith,clay,clickhouse,cloudflare,contactout,contextdev,crustdata-v3,customer_db,databricks,dataforseo,datagma,deepline_ip_to_company,deepline_native,deeplineagent,discolike,dropleads,emailbison,emailguard,enformion,enigma,exa,findymail,firecrawl,fireflies,firmable,forager,fullenrich,generic_http,gong,google_ads_audiences,google_workspace,govfiles,grain,hackernews,harvestapi,heyreach,hubspot,hunter,icypeas,instantly,intercom,ipqs,kaspr,kernel,leadmagic,lemlist,limadata,linkedin_ads_audiences,linkedin_scraper,luma,lusha,meta_audiences,nooks,openmart,opensosdata,openwebninja,outreach,parallel,peopledatalabs,podscan,postgres,predictleads,prospeo,quickenrich,redshift,rocketreach,salesforce,salesforge,salesloft,scrapecreators,searchbug,sec_edgar,sentrion,serper,slack,smartlead,snowflake,socrata,…."

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 ea