Set Up the Outbound Email Skill

---
name: surface-campaign-pipeline
description: Set up, extend, resume, or monitor a Surface Vault campaign using Surface MCP. Use for focused campaign tasks, contact discovery, qualification, draft outreach, requested reply sync, recovery, and health checks.
---

# Surface campaign pipeline

Create a campaign operated through committed Vault records. **Prospect → Qualify → Draft Outreach is the default starting shape, not a fixed task count. Every task must have one clear job with an independently verifiable result.** Extend or split the pipeline when the campaign needs it. Use Surface MCP for all campaign, Vault, connection-catalog, and task operations. Public web research may inform seller/ICP facts when permitted. Do not fall back to SQL, app REST, browser automation, credential files, or direct provider tools to complete campaign operations.

Use the providers the user's Surface environment actually exposes. Clay, Apollo, MarqRadar, and Amplemarket are examples, not dependencies. Missing capabilities produce explicit blockers or Vault-only output, never invented tools or a false claim of a working pipeline.

## Scope and intake

1. Establish seller, target segment, intended team/environment, provider preferences, and whether the user wants setup, commissioning, recurring operation, repair, or a health check. Reuse supplied answers. When an app URL is supplied, anchor reads and changes to its environment/task IDs; otherwise resolve the intended environment through Surface MCP. Verify returned identifiers: a production hostname or matching campaign name does not distinguish production from test. Save the selected identifiers and ask only when scope is ambiguous.
2. List scheduled-task connections, browse campaign files, and list existing tasks. Follow pagination. Resume matching campaigns with saved IDs; a failed run does not justify another folder/task.
3. Check workspace Company files describe the actual seller before borrowing claims or exclusions. Otherwise keep sourced seller context inside this campaign. Record URLs and uncertainty. Never invent customers, proof, contacts, or evidence.
4. Present defaults briefly and proceed when sane defaults were authorized. Ask only for material missing facts, especially seller/segment, intended environment, or sender mailbox. Obtain sender first name from the user or a verified profile, not a guess from an address. Do not impose per-file approval checkpoints.

Suggested starting values; adapt to user intent, provider latency, and current tool limits:

| Setting | Starting value |
| --- | --- |
| Cadence | Hourly: Prospect :00, Qualify :20, Draft Outreach :40 |
| Timezone | User's stated timezone; otherwise environment timezone, explicitly disclosed |
| Prospect batch | One qualified existing account, up to two contacts, then at most one new account/run; omit contact work when separately owned |
| Qualify batch | One account/run, including resumed work |
| Outreach batch | Up to two contacts/run; fewer when needed to complete and save drafts |
| Commissioning ceiling | Suggest 30 new accounts; record whether a ceiling applies to recurring operation |
| Task budget | 15 minutes, 20 documents, 60,000 output tokens |
| Soft stop | Stop new work by 8 minutes, 12 provider calls, or about 35,000 output tokens |
| Provider call ceiling | 15 per run, including reads, writes, polls, and verification |
| Worker steps | Plan below the observed 24-step ceiling; inspect current limits and reserve steps for persistence and finalization |
| Outreach | Email only; four steps on business days 0, 3, 7, 11 |
| Publication | Inactive drafts only; no launch, resume, activation, or sending |
| Notifications | Vault summaries; Slack only when separately requested with a resolved destination |

These are ceilings, not quotas. Do not widen the ICP to fill them. The account ceiling limits **new accounts**, not bounded contact repair for existing accounts. Increase throughput only after consecutive measured runs consistently commit every expected record and verify provider outcomes within budget. More time or tokens cannot overcome a step ceiling.

Before recurring operation, disclose any remaining discovery pause or ceiling and its release condition. An instruction to unpause discovery or remove a ceiling must be reflected in both saved definitions and task instructions; do not leave an older gate silently stopping work. Removing a total ceiling preserves per-run budgets.

## Choose task boundaries

Define each task by its one job, committed inputs, eligibility gate, owned outputs, allowed operations, cadence, budget, and observable completion condition. Several tool calls can support one job. Split work when it has its own queue, retry policy, cadence, permissions, or failure mode that needs independent monitoring and adjustment.

For a simple campaign, the three defaults may suffice. When contact discovery follows qualification or needs repeated fallbacks, use **Prospect → Qualify → Find Contacts → Draft Outreach**. CRM account-fit checks may warrant their own task if they repeatedly block discovery. Reply Sync is a separate job when requested; do not fold inbox processing or CRM updates into outreach drafting. Add only jobs needed by this campaign.

When splitting an existing task, transfer its pending work and output ownership, remove that responsibility from the original task, and update downstream reads and gates together. Keep one writer per file. Commission the new handoff before enabling its recurrence; do not create two tasks that both keep repairing the same records.

## Build the campaign contract

Read [references/vault-contract.md](references/vault-contract.md) when creating/adapting files. Build seller context, ICP, exclusions, complete sequence copy, persistence templates, and initial checkpoints before task creation. Seed empty data tables, not fake prospects.

Choose an outreach representation before marking setup ready:

- Prefer reusable persona sequences with **documented per-contact fields** for every variable part of every email, and a way to verify each recipient's rendered content.
- If unsupported, use a dedicated draft per contact when the provider supports it and this fits the user's scope. Name it deterministically with campaign, copy version, persona, and stable contact ID. Build across bounded runs if needed.
- Otherwise choose `vault_only`: save personalized copy and disclose that automatic provider enrollment is unavailable. Do not call this a fully commissioned external-outreach pipeline.

Never put one recipient's literal company/evidence into a shared sequence and reuse it for other companies. Preserve existing occupied drafts, reconcile them, and choose a compatible strategy for future contacts.

Use `ready_for_draft_pipeline` only when the core contract is coherent. Track readiness by stage: a missing sender/outreach connector must not block account discovery or research. Missing qualification capability blocks Qualify and downstream eligibility, not setup files. Draft-copy approval is not live-send authorization.

## Create the required tasks

Read [references/task-instructions.md](references/task-instructions.md). Compile its short shared block plus the relevant job and only the optional rules that job owns. Resolve environment, paths, grants, and outcome; keep account names, exceptions, search/enrichment IDs, and recovery history in account records. Store campaign policy, schemas, and provider procedures in Vault definitions/templates. Runtime tasks cannot read this local skill, so populate those files before saving instructions and retain critical safety/finalization rules in the prompt.

Replace accumulated prompt patches rather than append another exception. Migrate their facts and unresolved work to the owning account records, read them back, and save a short generic task. Aim for roughly 4,000 characters for ordinary tasks, measuring the complete assembled prompt; this is a concision target, not a reason to drop essential rules. One observed Prospect cleanup reduced about 22,000 characters to 3,900.

Name tasks `{Short campaign name} · {Job}`, using Prospect, Qualify, and Draft Outreach for the defaults and equally specific names for extensions. Save every returned task ID/URL and its job in `setup-log.md`.

Grant only each stage's provider(s) and Vault reads/writes. POST-based research/enrichment may need a write grant; constrain permitted operations in instructions. A broad connector write grant does not authorize live outreach. Grant optional web reads only where needed; no Slack by default. Inspect current Surface schemas rather than assuming config fields or provider capabilities.

Create tasks paused and verify returned state. For existing tasks, use `get_scheduled_task` and current `updatedAt` for updates. Omitted fields preserve configuration; supplied permission arrays replace arrays. Re-read and merge after conflicts. Wait if an active run prevents editing. Preserve another actor's acceptance/scheduling choices unless changing them is requested.

Offsets are intended spacing, not dependencies or guaranteed execution times. Inspect actual next-run information and any scheduler execution window when exposed; report uncertainty when Surface only exposes nominal cron times. Consume committed eligible rows and own separate files; never assume the prior stage succeeded because its scheduled time passed.

## Verify and commission within authorized scope

Setup verification is read-only: read back files and all task configurations, grants, exact paths, stage gates, copy strategy, and timezone. Check all referenced fields exist, copy is complete, days increase, exclusions exist, and unresolved settings are explicitly blocked. Check that eligibility rules agree across the ICP, workflow, saved instructions, and existing holds; account qualification, evidence eligibility, contact readiness, and enrollment are separate facts. Resolve conflicts during setup before commissioning. Report setup separately from runtime verification.

`run_scheduled_task` performs real external actions and may spend credits. A request to create this skill or set up tasks alone is not authorization to run them. Continue without re-asking when commissioning/recurring operation was already authorized. Otherwise leave the concrete setup paused and ask only for the missing execution authorization.

For authorized commissioning, follow the workflow's dependency order:

1. Run Prospect once; inspect all activity/write pages and current saved records. Check write order: existing contact record first, new account then directory, checkpoint last. Proposals are not durable until finalization; a successful provider call is not persisted progress. Commission any separate CRM Fit gate before its dependent tasks.
2. Run Qualify against committed scan-ready accounts. Pending reports are normal: save exact IDs and resume with a fresh bounded polling allowance in a later authorized run. Never resubmit to make the first test look complete.
3. Commission any added jobs in dependency order against their committed inputs. For Find Contacts, inspect the actual search coverage and fallback checkpoint, including zero-result outcomes. For Reply Sync, verify message coverage and destination mapping in a dry run before authorized CRM writes.
4. Run Draft Outreach when a qualified account has an eligible contact. Verify personalized content, sender, provider draft lifecycle, membership, and contacted/sent state when available. Preserve explicit user sender confirmations and timing decisions with their exact scope; do not repeatedly reopen an unchanged confirmed gate. A lead status named `active` is not necessarily a live sequence; inspect sequence lifecycle and documented semantics.
5. Verify committed records, actual draft membership, recipient-rendered copy, and unsent state rather than trust a COMPLETED label; the observed 24-step ceiling can stop work before finalization. Accept a run using `accept_scheduled_task_run` only after outputs pass review. Use `activate_scheduled_task` only when recurring execution is authorized and that task passed commissioning. Surface schedule activation and provider campaign activation differ; only the former belongs here.

Read [references/recovery.md](references/recovery.md) on failures, uncertain writes, authentication, truncation, or count mismatches. Do not repeatedly run blocked tasks. If downstream has no eligible work, report the bottleneck rather than claiming full pipeline validation.

## Monitor progress

For health checks, read [references/recovery.md](references/recovery.md). Report committed movement over a stated interval, queue age, and blocker counts alongside execution/schedule health. A task can be running successfully while useful work remains parked. Separate what the next run can advance from what needs a rule, data, capability, or user decision. A health-check request alone does not authorize edits or runs; continued monitoring needs a cadence and end condition, reusing any already supplied.

## Finish

Return campaign/task links supplied by tools, schedules/timezone, paused/armed state, provider/copy strategy, verified counts by stage, and remaining blockers. Say whether anything ran and whether contacts entered inactive drafts. No live campaigns or prospect messages are part of this skill.

Keep choices, IDs, verification, and unresolved recovery work in `setup-log.md`. Record new provider techniques in one campaign `surface-mcp-notes.md`, separating observed behavior from assumptions. Avoid raw credentials, personal contact dumps, and full execution logs in that notes file.

Installing manually? Keep all 5 files together. SKILL.md uses the reference files.