30x Outreach
Operate outbound as a compounding learning system. Preserve the reasoning between signal, message, result, and next action instead of treating each campaign as disposable copy.
When invoked through agents/thirtyx-outreach.agent.md, first load the selected Agent Core playbook and its tenant overlay. This skill owns the atomic 30x work; Agent Core owns orchestration and semantic readback. Never copy recipient data or aggregate experiment records into agents/state/.
Dynamic context
Business profile
!cat ${CLAUDE_SKILL_DIR}/data/business/profile.json 2>/dev/null || echo '{"status":"NOT_CONFIGURED","action":"Run Step 1"}'
Active ICP
!cat ${CLAUDE_SKILL_DIR}/data/icps/$0/profile.json 2>/dev/null || echo '{"status":"NOT_FOUND","icp":"$0","action":"Run Step 2"}'
Latest competitive intelligence
!cat ${CLAUDE_SKILL_DIR}/data/intel/competitive/latest.json 2>/dev/null || echo '{"status":"NO_DATA","action":"Run Step 4"}'
Latest cross-signals
!cat ${CLAUDE_SKILL_DIR}/data/intel/signals/latest.json 2>/dev/null || echo '{"status":"NO_DATA","action":"Run Step 4"}'
Non-negotiable invariants
- Never invent familiarity, praise, customer intent, proof, metrics, clients, or URLs.
- A personalization claim requires an observation, source, and
verified: trueevidence object. - Keep deterministic checks separate from model-assisted qualitative review.
- Default to preview. External writes require explicit
--executeand prior human review. - Email execution additionally requires a manifest matching the exact payload hash.
- Never pass secrets through CLI flags, config files, generated copy, or reports.
- Never commit real PII or run artifacts.
- Freeze hypothesis and decision thresholds before execution.
Startup router
- No business profile: run Step 1.
- Business profile exists but
$0ICP does not: run Step 2. - ICP exists: identify whether the request concerns infrastructure, intelligence, sourcing, sequence design, approval, execution, or learning and enter the corresponding step.
- No ICP argument: list directories under
data/icps/and ask which ICP to use or create.
Step 1: Build the business profile
Collect two evidence streams in parallel.
From public sources:
- Homepage, product, pricing, about, case studies, documentation, and recent launches.
- Positioning, buyer, offer, price, proof, objections, and alternatives.
- Source URL and retrieval date for every claim used later.
From the operator:
- What do you sell in one sentence?
- Who buys it and who never should?
- What next action is appropriate for a cold prospect?
- Why do customers choose it over alternatives?
- What proof can be disclosed and attributed?
- What objection appears most often?
Flag contradictions instead of silently merging them. Save reviewed output to data/business/profile.json and a readable brief beside it.
Step 2: Define ICP and anti-ICP
Use references/icp-template.md. Record:
- Primary, secondary, and excluded titles.
- Company size, vertical, geography, stage, and technical context.
- Buying signals and the source able to verify each signal.
- Anti-ICP company and contact traits.
- Buyer problem, offer fit, objections, and acceptable proof.
- Apollo parameters as a separate execution mapping.
Save structured data to data/icps/{icp-name}/profile.json. Confirm the profile before sourcing.
Step 3: Audit infrastructure
Set INSTANTLY_API_KEY in the environment and run:
python3 scripts/instantly-audit.py
Report sending accounts, warmup state, campaign metrics, conservative capacity, and blockers. This step is read-only. If no account meets the configured readiness rules, stop before sourcing or execution.
Step 4: Collect and connect signals
Run competitive intelligence and cross-source detection as relevant:
python3 scripts/competitive-monitor.py
python3 scripts/cross-signal-detector.py
Normalize useful observations into evidence objects:
{
"id": "signal-001",
"observation": "A directly observable fact",
"source": "https://source.example/item",
"verified": true
}
Do not convert a weak keyword match into intent. Keep confidence and provenance visible.
Step 5: Source, verify, and stage leads
Run the lead pipeline without --execute first:
python3 scripts/lead-pipeline.py \
--icp {icp-name} \
--campaign-id YOUR_CAMPAIGN_UUID
The pipeline reads Apollo, verifies through LeadMagic, deduplicates against Instantly and exclusions, and stores raw/verified/ready data locally. It does not upload in the default mode.
Review targeting parameters, counts, verification loss, exclusions, and the staged lead file. Only then may the operator authorize the same command with --execute.
Apollo identity and title fields are not buying signals. Before any execution, convert the reviewed recipients into thirtyx/contracts/audience-batch.schema.json. Each recipient needs provider verification and at least one sourced, timestamped, verified observation.
Step 6: Preregister the campaign
Create a campaign spec matching thirtyx/contracts/campaign-spec.schema.json with:
- Audience and anti-ICP.
- Buyer problem and value proposition.
- Verified evidence objects.
- Hypothesis and the single variable under test.
- Primary metric and guardrails.
- Minimum sample size.
- SCALE, KILL, and LEARN thresholds.
- Ordered steps with subject, body, CTA, and evidence IDs.
Use references/measurement-framework.md and references/copy-rules.md. Never choose thresholds after results arrive.
Step 7: Run the quality gate
30x evaluate \
data/campaign-spec.json \
--output data/output/sequence-evaluation.json
The ten lenses are targeting context, subject line, opening, relevance/evidence, value proposition, proof integrity, CTA, sequence logic, deliverability/compliance, and measurement/learning.
READY_FOR_HUMAN_REVIEW requires at least 85/100 and zero hard blockers. It is not permission to execute. If model-assisted critique is used, label the model and prompt, preserve its output separately, and never present it as independent human expertise.
Step 8: Bind human approval to the exact payload
Bind the campaign to its execution audience first:
30x preflight \
data/campaign-spec.json \
data/audience-batch.json
First preview the exact payload:
python3 scripts/cold-outbound-sender.py \
--approved-file data/cold-outbound-approved.json
Present the campaign, audience, recipient count, every message, evidence, evaluation, hypothesis, thresholds, limits, and planned execution path. Wait for explicit human approval of that exact file.
After approval, create the manifest:
30x approve data/cold-outbound-approved.json \
--by REVIEWER_ID \
--campaign-id CAMPAIGN_ID \
--output data/campaign-approval.json
Do not modify the payload after this command. Any change must invalidate the approval and trigger a new review.
Step 9: Execute explicitly
python3 scripts/cold-outbound-sender.py \
--approved-file data/cold-outbound-approved.json \
--approval-manifest data/campaign-approval.json \
--audience-batch data/audience-batch.json \
--execute
The sender must fail closed on manifest mismatch, missing credentials, suspicious content, duplicate recipients, or daily-limit exhaustion. It must never remove records from the approved payload.
Step 10: Close the learning loop
Export Instantly aggregate analytics with the exact campaign ID, then convert it into the provider-neutral observation and optional ledger record:
30x observe-instantly \
data/campaign-spec.json \
data/instantly-analytics.json \
--output data/experiment-observation.json \
--ledger .30x/learning.jsonl
Safety guardrails such as bounce rate can KILL immediately; they do not wait for the minimum sample. Campaign rules may be stricter, but may never relax the system ceilings: bounce >= 5% is an absolute KILL, and bounce >= 10% requires an all-sending emergency pause plus verification audit. For other outcomes, compute or inspect the decision from the frozen campaign:
30x decide \
data/campaign-spec.json \
data/experiment-observation.json \
--output data/output/decision.json \
--html data/output/decision.html
30x record \
data/campaign-spec.json \
data/experiment-observation.json \
--ledger .30x/learning.jsonl
30x verify-ledger --ledger .30x/learning.jsonl
COLLECT, SCALE, KILL, and LEARN are computed, not narrated after the fact. Preserve the original campaign spec and aggregate observation. Feed the hash-chained record into the next brief as a versioned input, not retroactive justification. Keep recipient identity out of the ledger.
Reference map
| File | Purpose |
|---|---|
references/icp-template.md |
ICP and anti-ICP collection |
references/copy-rules.md |
Copy hard constraints |
references/evaluation-rubric.md |
Ten transparent evaluation lenses |
references/measurement-framework.md |
Preregistration and decision semantics |
references/instantly-rules.md |
Platform variables and deliverability |
thirtyx/contracts/campaign-spec.schema.json |
Campaign contract |
thirtyx/contracts/audience-batch.schema.json |
Verified, signal-backed execution audience |
thirtyx/contracts/approval-manifest.schema.json |
Approval contract |
thirtyx/contracts/experiment-observation.schema.json |
Aggregate observation contract |
thirtyx/contracts/decision-record.schema.json |
Deterministic decision contract |
thirtyx/contracts/learning-record.schema.json |
Hash-chain memory contract |
Configuration
Use config.json only for non-secret settings. All credentials must come from environment variables named in .env.example.
[PROTOCOL]: 变更时更新此头部,然后检查 AGENTS.md