Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add swan-gtm/gtm-skills --skill email-deliverabilitygit clone --depth 1 https://github.com/swan-gtm/gtm-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/swan-gtm/gtm-skills/email-deliverability)<a href="https://agentmods.dev/skills/swan-gtm/gtm-skills/email-deliverability"><img src="https://agentmods.dev/badge/skills/swan-gtm/gtm-skills/email-deliverability/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/swan-gtm/gtm-skills/email-deliverability"><img src="https://agentmods.dev/badge/skills/swan-gtm/gtm-skills/email-deliverability.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00103 | $0.01018 |
| Opus 5 | $0.00051 | $0.00509 |
| Sonnet 5 | $0.00021 | $0.00204 |
| Haiku 4.5 | $0.00010 | $0.00102 |
Grade A, and why
email-deliverability scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- email-deliverability — 94% identical, 18 lines differ
How it starts
The opening of the file, as written. The whole thing — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Run this when email performance breaks, or before it gets the chance to. It produces either a severity-ranked audit of the sending setup or a root-cause diagnosis with a dated recovery plan.
The play
- Pick the mode. Proactive review → audit the setup top to bottom. Active fire ("we're in spam") → diagnose.
- Scope first. Pull send volume, open rates by mailbox provider, shared vs dedicated IPs, and what changed right before the drop. An open rate below 10% at any provider confirms a deliverability problem, whatever anyone thinks of open tracking accuracy.
- Walk the four pillars, in order:
- Infrastructure. SPF, DKIM, DMARC present and verified recently — whole zone files disappear during migrations. The server's HELO announcement must match the IP's reverse DNS; a mismatch is an automatic blocklisting.
- Data. Hard bounces above 0.5% mean stop and clean. Soft bounces above 2% mean investigate before removing anything: Microsoft graylists legitimate senders heavily and ProofPoint soft-bounces on send rate, so both inflate the number with no list-quality problem behind it. Retry soft bounces three times across 72 hours, then treat what still fails as hard. After an ESP migration, check whether old bounces were accidentally re-imported.
- Content. Ask: how is this email distinguishable from a scam? Missing branding, HTML-only sends, bloated code, and mismatched sender identity all read as scam patterns to filters.
- Traffic shape. The big one — solving it at the pipe solves most of the problem. Throttle per provider, never raise volume more than 50% week over week, and spread large sends across 3-4 days.
- Classify and prescribe. Blocklisted → delist, but fix the root cause first or the listing comes back. Content filtered → pause that provider for 24-48 hours, fix, retest on an engaged segment. Broken authentication → fix DNS, wait for propagation before resuming. New or damaged sender → run the ramp in references/warmup-playbook.md.
- Define monitoring. Set thresholds that trigger a pause, not a postmortem: bounce spikes, complaint rate above 0.3%, one provider dropping while the others hold.
When the work goes deep, read references/warmup-playbook.md (week-by-week recovery ramp with per-provider volumes), references/shared-pool-management.md (pool contamination, compliance rails, high-risk verticals), and references/provider-specific-tactics.md (Gmail, Microsoft, Yahoo, iCloud, ProofPoint).
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 47 lines · 103 tokens per session scan A 81c70970d4e3
email-deliverability is a skill published in the GitHub repository swan-gtm/gtm-skills (153 stars, last pushed 2d ago), licensed MIT. It adds 103 tokens to every session and 1,018 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
crash-analytics
When the user wants to monitor, triage, or reduce their app's crash rate — including setting up Crashlytics, prioritizing which crashes to fix first, interpreting crash data, and understanding how crashes affect App Store ranking. Use when the user mentions "crash", "crashlytics", "crash rate", "ANR", "app not…
de-vibe
Audit and fix the tells that software was vibe-coded / AI-generated, then give it a small distinctive identity, so it ships looking handcrafted and professional. Use whenever the user says "de-vibe", "does this look AI-generated / vibe coded?", "make this look shippable / handcrafted / professional", "remove the AI…
incident-postmortem
Close the learning loop after a rescue or incident — reconstruct the timeline from actionlog, run root-cause analysis (platform / site / measurement / external), produce a structured postmortem document, distill reusable insights via /learn, and propose preventive guardrails. Use after a /rescue, a CPA spike, a…
absolute-debt
Lint and typecheck debt paydown: clear pre-existing repo-wide lint/type violations and suppressions (@ts-ignore, # type: ignore) one rule per wave, fixing causes not symptoms. Runs on green main. For diff-scoped quality use absolute-simplify. Triggers on "absolute debt", "fix our lint warnings", "clear the type…
absolute-deflake
Flaky test fixes: detect nondeterministic tests empirically (repeat/shuffle/parallel runs), diagnose the root cause, fix it — never retry/skip/sleep — and verify across many randomized runs. Triggers on "absolute deflake", "fix flaky tests", "CI is flaky", "this test fails randomly/intermittently".
absolute-prune
Dead code and dependency cleanup, repo-wide: unused deps, unreferenced exports, unreachable code, orphaned files — removed only with tool evidence, in reversible waves. Runs on green main. For diff-scoped cleanup use absolute-simplify. Triggers on "absolute prune", "remove dead code", "find unused deps/exports", "what…