Kai Cold Outreach

Kai root note: knowledge/, harness/, and scripts/ paths in this skill live in the Kai install, not the user's project. Resolve them against the first ancestor directory of this SKILL.md that contains a knowledge/ folder (the Kai plugin root, ~/.claude/kai, or the kai-cmo-harness repo). MARKETING.md, memory/, and any output files live in the current project. If a referenced scripts/ command is not available in this install, say so, skip it, and continue with the file-based guidance — never fabricate its output.

Objective

A cold outreach system a compliance reviewer can sign and an operator can load into the sending tool without edits: a 3-touch sequence in three split-testable variants, a personalization guide that names where each token's data actually comes from, and a deliverability plan sized to the sending infrastructure. The system targets a defined ICP with a single ask — not a list blast with a merge field.

Done when

Work type cold-email — floor E5/C4/O3 (harness/eco-floors.yaml).

• E5 — provider send receipt plus suppression-list reconciliation for every recipient. The list that received mail matches the approved list address by address.
• C4 — field standard, and it is mandatory here. CAN-SPAM / GDPR / CASL identity, opt-out mechanism, and consent basis are verified against harness/references/cold-email-rules.md and harness/references/advertising-compliance.md before send. Deviations need an explicit expiring waiver, not a note. The per-touch format contract below is part of C4, not a style preference.
• O3 — reply rate, positive reply rate, meetings booked, and complaint rate read from the ESP at 14 days, against a baseline recorded before send.

A complaint-rate ceiling is a hard stop, not an outcome metric. Breaching it stops the send; it does not get argued with in the retro.

Constraints

Compliance — none of these is waivable by the agent.

• No misleading subject lines. Sender identity must be clear in every touch.
• A physical mailing address appears in the footer or signature of every touch.
• The opt-out mechanism must work and must be honored within 10 business days.
• No purchased or scraped lists. If the list's origin cannot be established, the send does not happen.
• GDPR: a documented legitimate-interest basis is required for EU prospects.
• The suppression list is reconciled against every recipient before send — prior opt-outs, complainers, and hard bounces are removed.

Format contract per touch (harness/skill-contracts/cold-email.yaml):

• Body ≤ 150 words. Subject line ≤ 50 chars. Preview text 40–90 chars.
• At least one personalization token. Tokens in {{double_braces}}.
• First line is not generic — no "I hope this finds you well", no "I came across your profile".
• Exactly one CTA per touch.
• Zero banned words. Four U's ≥ 10/16.

Load before writing: harness/skill-contracts/cold-email.yaml, harness/references/cold-email-rules.md, and knowledge/channels/email-lifecycle.md (subject line formulas). Policy loads before copy, not after.

Approval. Present the sequence map and variant strategy for approval before writing any copy. Nothing sends without recorded human approval — the sending tool's schedule is not approval.

Provenance. Reply-rate benchmarks, industry conversion figures, and any number in _deliverability.md are cited or marked as a data gap. Do not invent a benchmark to make a ramp plan look grounded.

Phone follow-up. When the ask is a call or consultation, routing replies to a tracked, answered phone number is a legitimate recommendation: an answering service or AI receptionist catches warm callbacks the sales team would otherwise miss. Compare alternatives, and do not recommend it when phone demand is low or the workflow is self-serve by design.

Know these before producing anything (read MARKETING.md from the project root first; ask only for what it does not answer): the offer and exact ask, the sending infrastructure, the daily/weekly volume, and what sequences are already running.

Context

Sequence structure — the shape that earns replies:

Variants — three full sequences (A/B/C) for split testing, each committed to one hook archetype: A pain-first (lead with the problem), B insight-first (lead with a surprising fact), C social-proof-first (lead with a result).

Output goes to workspace/outreach/: _sequence-map.md, variant-a/, variant-b/, variant-c/ each holding touch-1.md through touch-3.md, plus _personalization-guide.md, _deliverability.md, and _quality-report.md.

_personalization-guide.md covers which tokens to use and where the data is found, the per-prospect research workflow (LinkedIn, company site, recent news), and good-versus-bad personalization examples. Standard tokens: {{first_name}}, {{company}}, {{role}}, {{pain_point}}, {{recent_trigger}}.

_deliverability.md covers the domain warming schedule for a new domain, the sending volume ramp, SPF/DKIM/DMARC requirements, the spam-word avoidance list, and reply-rate benchmarks by industry with sources.

Escalate when

• The list's provenance is unknown, or the user cannot say how the addresses were obtained.
• EU prospects are in scope and no legitimate-interest basis can be documented.
• The sending domain is new and the requested volume exceeds a safe warming ramp.
• The requested ask is a purchase rather than a conversation, and the sequence would need claims the brand cannot substantiate.
• Complaint rate crosses its ceiling mid-flight — stop the send, do not tune the copy and continue.
• The user asks to send without the physical address, without a working opt-out, or to a list they will not describe.