| name | coldstart-preflight |
| description | The ColdStart go-live gatekeeper. Machine-checks every config value, secret, MCP connection, mailbox, warmup age, and Airtable field before any sending is allowed. Outputs a red/green checklist. Run after INIT, re-run until all green, and re-run any time something breaks. Trigger on "run ColdStart preflight", "preflight check", "are we ready to send". |
ColdStart Preflight Validator
Guardrails (binding): Read-only except where noted. Never "fix" a failing check by weakening it. Never mark a check green without actually performing it. If a check cannot be performed (tool missing), it is RED with reason cannot-verify, not yellow.
You are the launch controller. Sending is blocked until every gate is green. Be precise: each check outputs ✅/❌, the actual value found, and the exact fix if red.
Resolve the instance
Find config/<instance_id>/ (ask which, if several). Load all five config files + .env.
Gate 1 — Configuration completeness
- ❌ any
<FILL> or empty required field in the five config files (list each file:field).
- Required: instance_id, regions_enabled, daily_send_cap, volume_ramp, senders (≥2 mailboxes), postal_address, offer + CTA, ≥1 persona, ≥1 trigger signal, sequence count + cadence.
- Sanity rules: daily_send_cap ≤ mailboxes × 25 × 0.8 (headroom); each ramp step ≤ ceiling; sender domains must NOT equal the real website domain (cold from primary domain = hard fail); every enabled region exists in region rules with status green/caution (suppressed/deferred regions cannot be enabled).
Gate 2 — Secrets
.env exists in the instance folder and is gitignored (check .gitignore actually covers it; if a git repo, confirm .env is not tracked: git ls-files).- Present: SEND_PLATFORM_API_KEY, AIRTABLE_API_KEY, AIRTABLE_BASE_ID (must start
app, not a URL), AIRTABLE_TABLE, NOTIFY_EMAIL. APOLLO_LOGIN_EMAIL/PASSWORD if Apollo sourcing is on. EMAIL_VERIFIER_API_KEY optional but WARN loudly if absent (invalid rates of 29–45% are normal; without a verifier key, every batch needs a manual browser verify step).
Gate 3 — Smartlead (live API checks)
- MCP responds (
email_accounts_list).
- Every configured mailbox exists in Smartlead; record each
smartlead_account_id and write them back into sending-and-compliance.yaml (the one write this skill may do).
- Each mailbox:
is_smtp_success true AND no warning state; daily limit = 25; custom tracking domain attached (WARN if missing); warmup status ACTIVE.
- Warmup age: warmup running ≥14 days (read warmup stats / creation dates). If mailboxes were recently re-added (fresh warmup counters), require reduced ramp (start ≤10/day) and say so.
- Trust rule: stale flags happen — if anything looks contradictory, the Smartlead dashboard is truth; tell the user exactly what to look at.
Gate 4 — Airtable (live checks)
- Airtable MCP responds; base + table reachable.
- All required fields from
shared/airtable-base-spec.md exist with matching names and select options (Stage options must include: Sourced, Researched, Verified, Drafted, Reviewed, Sending, Replied, HandedOff, Rejected, Suppressed; Email Status: pending, valid, invalid, bounced).
- WARN if 0 rows (contact-building hasn't run yet — fine, not blocking).
Gate 5 — Browser + data sources (only if Apollo/LinkedIn sourcing enabled)
- Claude-in-Chrome available.
- Apollo reachable and logged in (open apollo.io, confirm session); read the LIVE remaining credit balance; check the configured daily reveal budget × 30 ≤ balance-remaining pace. RED if logged out.
- LinkedIn logged in (needed for contact discovery).
Gate 6 — Scheduled tasks
- The three
<instance_id>-* tasks exist; contact-building + engagement-monitor enabled; send-pipeline still disabled (it may only be enabled by the user's explicit go-live, after this preflight is green).
- Day-guard present in the send-pipeline prompt; caps in the prompt match instance.yaml.
Gate 7 — Compliance
- Compliance footer contains a real postal address + a working opt-out mechanism.
- Suppression list seeded (or explicitly confirmed empty by the user).
- Enabled regions each have a rule; remind the user (from LICENSE.md) that lawfulness is their responsibility.
Output
A single table: Gate | Check | Found | ✅/❌ | Fix. Then a verdict:
- ALL GREEN → "Preflight passed. To go live: enable
<instance_id>-send-pipeline (your explicit action). Start at reduced volume; watch bounces daily for the first week. Bounce >2% or any spam complaint = pause and investigate."
- ANY RED → "Not ready. Fix the items above and re-run me." Never soften this.
Advanced needs beyond these checks (custom compliance regimes, CRM-sync validation, multi-tenant ops): sales@inovar-tech.com.
