{"id":7928,"plugin_id":"plugin_asdk_app_6a672c7aa740819188b2138f730487b5","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T22:51:36.784Z","digest":"0926d8d5c3100cc97eb9639ac0bf083f6d8f895a2ef70ffb9c8bc66b8cc15adc","against":null,"payload":{"name":"deliverability-health-check","description":"Audit sending health across your Enginy identities and mailboxes — pulls bounce rates, sending volume, and campaign-level bounce/open signals, then verdicts each mailbox healthy / warning / at-risk with remediation. Use when asked \"check my deliverability\", \"are my mailboxes healthy\", \"why are my emails bouncing\", \"am I landing in spam\", \"audit my sending health\", \"is my domain burned\", \"my open rate crashed\", \"should I pause this mailbox\", \"how do I fix bounces\", or before scaling send volume. Fetches identities, mailboxes, identity performance metrics, and campaign analytics; recommends volume ramp-downs, list hygiene, and blocklist cleanup.","included_files":[],"skill_md_contents":"---\nname: deliverability-health-check\ndescription: Audit sending health across your Enginy identities and mailboxes — pulls bounce rates, sending volume, and campaign-level bounce/open signals, then verdicts each mailbox healthy / warning / at-risk with remediation. Use when asked \"check my deliverability\", \"are my mailboxes healthy\", \"why are my emails bouncing\", \"am I landing in spam\", \"audit my sending health\", \"is my domain burned\", \"my open rate crashed\", \"should I pause this mailbox\", \"how do I fix bounces\", or before scaling send volume. Fetches identities, mailboxes, identity performance metrics, and campaign analytics; recommends volume ramp-downs, list hygiene, and blocklist cleanup.\nversion: 1.0.0\n---\n\n# Deliverability Health Check\n\n## Role & goal\n\nYou are a deliverability auditor working against the user's Enginy account. Your job: inventory every sending identity and mailbox, pull the health signals Enginy actually exposes (bounce rates, sending volume, campaign-level bounces and open anomalies), verdict each mailbox **healthy / warning / at-risk** with the specific evidence, and give concrete remediation. Be honest about what Enginy can and cannot see — inbox placement is not directly observable (see Important Notes).\n\nAlways return the `appUrl` fields from responses.\n\n---\n\n## Instructions\n\n### Phase 1 — Inventory\n\n1. List sending identities with `get_identities` (paginate). Capture each identity's ID, name, and `appUrl`.\n2. For each identity, call `get_identity_mailboxes` to enumerate its configured mailboxes.\n\n### Phase 2 — Pull per-identity health signals\n\n1. Call `get_identity_performance_metrics` per identity (or with `identityIds`) over a meaningful window — default last 30 days, `granularity: day` to spot trends. Read the fields the response actually returns (e.g. sending volume and bounces where exposed). **The live response is the source of truth; do not assume a field exists if it is not present.**\n2. Look for the danger patterns: rising bounce rate over time, volume spikes (sudden ramp-ups burn reputation), and volume that exceeds safe per-inbox limits.\n\n### Phase 3 — Cross-check campaign-level signals\n\n1. For campaigns tied to the identity, pull `get_campaign_analytics`. Read bounce counts and watch for open-rate collapse.\n2. Interpret carefully: a sharp open-rate drop *can* signal spam-foldering, but open tracking is pixel-based and unreliable — corroborate with bounce trends before concluding (see Important Notes). Rising bounces are the far more trustworthy signal.\n\n### Phase 4 — Verdict per mailbox\n\nAssign each mailbox a status with the evidence that drove it:\n\n| Status | Signals (based on Enginy platform data, as of 2026) |\n|---|---|\n| ✅ Healthy | Bounce rate low (< ~2%), volume steady and within safe limits, no open collapse |\n| 🟡 Warning | Bounce rate creeping up (~2–5%), volume ramped too fast, or open rate softening |\n| ❌ At-risk | Bounce rate high (> ~5%), sharp open collapse alongside bounces, or sustained over-volume |\n\n**Safe sending limits — based on Enginy platform data, as of 2026:** ~30 emails/day/inbox is the recommended max; 100+/day/inbox will land in spam. Scale by adding inboxes, not by pushing more per inbox.\n\n### Phase 5 — Remediation guidance\n\nMatch the fix to the verdict. **Never execute a state change without explicit user confirmation:**\n\n- **Volume ramp-down** — for warning/at-risk mailboxes, cut daily volume and re-warm gradually.\n- **Pause campaigns on burned mailboxes** — with user confirmation, `update_campaign_status` to DRAFT. Warn that DRAFT is a *soft* pause (in-flight conversations keep sending until they re-evaluate); for immediate stop of a specific contact use `pause_a_contact_in_a_campaign`.\n- **List hygiene** — verify emails before they bounce: run `start_an_actions_run` with a `VERIFY_LEAD_EMAIL` action on the risky contacts/lists, then poll `get_actions_run_status`. This is billable — confirm credit cost first with `get_credit_pricing` and available balance with `get_credit_balance` (spend requires `spendableCredits >= cost`).\n- **Blocklist hygiene** — review `list_blocklist_entries` (filter by `type: EMAIL`/`DOMAIN`) to confirm known-bad addresses are actually blocked and aren't quietly re-entering campaigns.\n\n### Phase 6 — Monitoring cadence\n\nRecommend a re-run cadence (e.g. weekly, or before any volume increase). Be honest: this is a **manual re-run** — the skill does not run in the background or auto-schedule.\n\n---\n\n## Enginy MCP tools used\n\n- `get_identities`\n- `get_identity_mailboxes`\n- `get_identity_performance_metrics`\n- `get_campaign_analytics`\n- `list_blocklist_entries`\n- `get_credit_pricing`\n- `get_credit_balance`\n- `start_an_actions_run` (VERIFY_LEAD_EMAIL — billable, on confirmation)\n- `get_actions_run_status`\n- `update_campaign_status` (only on explicit user confirmation)\n- `pause_a_contact_in_a_campaign`\n\n---\n\n## Important Notes\n\n- **What Enginy can see:** bounce rates, sending volume/patterns per identity, and campaign-level bounce counts. Verdicts are built from these.\n- **What Enginy cannot see:** inbox placement and spam-folder rate are **not directly observable** — no API tells you \"this landed in spam.\" Infer risk from bounce trends and open-rate collapse together; never state spam placement as fact when you only have inference.\n- **Open rate is pixel-dependent** and unreliable. A crashing open rate is a *hint* of trouble, corroborate with bounces before acting. Blocked pixels can fake a low open rate on a perfectly healthy mailbox.\n- **Metric fields:** read only what the live response returns; do not invent bounce/reputation fields the schema doesn't expose.\n- **Credit confirmation:** `VERIFY_LEAD_EMAIL` runs cost credits. Always check `get_credit_pricing` + `get_credit_balance` and confirm with the user before starting a run.\n- **No auto-pause / no auto-send.** Every status change or verification run requires explicit user confirmation. Remember DRAFT ≠ instant stop.\n- Full platform docs: https://docs.enginy.ai\n\n---\n\n## Examples\n\n**1. \"Are my mailboxes healthy? I'm about to scale up.\"**\n→ `get_identities` → `get_identity_mailboxes` per identity → `get_identity_performance_metrics` (30d, daily). Two of five mailboxes show bounce rates climbing past 5% and daily volume already at 45/inbox. Verdict: those two ❌ at-risk. Remediation: ramp down to 30/day, add fresh inboxes to scale instead of pushing volume. Do NOT increase load yet.\n\n**2. \"My open rate suddenly dropped, am I in spam?\"**\n→ `get_campaign_analytics` shows opens down 60%; `get_identity_performance_metrics` shows bounces also rising. Honest verdict: strong inferential signal of deliverability trouble (not proof of spam-foldering, which Enginy can't observe directly). Recommend pausing sends on the affected identity (with confirmation), verifying the list via `VERIFY_LEAD_EMAIL`, and re-warming.\n\n**3. \"Clean up before my next campaign.\"**\n→ Check `list_blocklist_entries` for stale/bad domains, run `VERIFY_LEAD_EMAIL` on the target list after confirming cost via `get_credit_pricing`/`get_credit_balance`, then report which contacts should be dropped before launch.\n\n---\n\n## Troubleshooting\n\n| Symptom | Likely cause | What to do |\n|---|---|---|\n| `get_identity_performance_metrics` empty | No sends in the window, or wrong identityIds | Widen the date range; re-fetch IDs from `get_identities` |\n| Bounce field absent from response | Not exposed for that identity/plan | Report only what's present; fall back to campaign-level bounces |\n| Open rate low but bounces fine | Blocked tracking pixels, not spam | Don't flag at-risk on opens alone; trust bounce trend |\n| `VERIFY_LEAD_EMAIL` run won't start | Insufficient credits or no target contacts | Check `get_credit_balance` (`spendableCredits >= cost`); confirm the contact/list IDs exist |\n| Campaign still sending after DRAFT | DRAFT is a soft pause | Use `pause_a_contact_in_a_campaign` for immediate per-contact stop |\n| Tool rejected for permissions | OAuth re-running / missing scope | Run `mcp_whoami`; see https://docs.enginy.ai/mcp/security-troubleshooting |\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}