Triage manages the flow; the purge shrinks it. Most inbox volume is recurring senders — newsletters, notifications, marketing — and each one is a decision made once that pays forever. The purge runs a census of who actually sends the volume, sorts senders into kill/digest/keep, and executes with the safety rules most people don't know: legitimate senders' unsubscribe links are safe and legally binding-ish; spam senders' unsubscribe links are confirmation beacons — those get reported, never clicked.
What This Skill Produces
- The sender census — the top recurring senders by volume, from the actual inbox
- The sort — kill (unsubscribe) / digest (batch to a daily-read label) / keep (whitelist to inbox)
- The safety rules — which unsubscribe links to click, which to never touch, what gets spam-reported
- The filter set — the rules that auto-route what survives, and the notification-settings homework that beats filtering
Required Inputs
Ask for these if not provided:
- The census data — search counts per suspected sender, or a description of the noise ("LinkedIn, three newsletters, shop marketing, GitHub notifications")
- Honest reading behavior — which newsletters actually get read (the calendar answer; "I mean to" is a kill vote)
- The platform — Gmail/Outlook/other; filter syntax differs, and the skill writes the real rules
Framework: The Purge Rules
- Census before action: search per sender (
from:newsletter@x.com), count the last 90 days — volume × read-rate sorts everything. The top ten senders are usually half the noise; purge by impact order, not inbox order. - The kill test: would you notice if it stopped? Not "is it good" — would you notice. Unread-for-a-month newsletters, notification emails duplicating app pings, and every marketing list fail the test. Kill without ceremony.
- The safety line: known-legitimate senders (real newsletters, real companies) → unsubscribe link is safe and usually works. Unknown/sketchy senders → the link confirms your address is live; report as spam instead, never click. The test: did you knowingly sign up? No → spam-report path.
- Digest beats trickle for the keepers: surviving newsletters get a filter to skip the inbox into a
@read-laterlabel, read in one weekly sitting. Notifications that must exist (CI, mentions) get their source settings tightened first — filtering email that shouldn't be sent is fixing the wrong end. - The maintenance rule: every new recurring sender gets the kill test on first arrival — one decision at first touch beats a re-purge every quarter. The purge is an event; the test is a habit.
Output Format
Unsubscribe Purge: [inbox]The Census
| Sender | Volume /90d | Actually read? | Verdict |
|---|
Execution
Kill (safe unsubscribe): [list] · Spam-report (never click): [list, with why] · Digest: [list → the filter rule, in platform syntax] · Source-settings homework: [the app notifications to turn off at origin]
The Filters
[The actual rules, platform syntax, paste-ready]
Quality Checks
- The census is by measured volume, not by annoyance salience
- Every kill passed the would-you-notice test
- The click/never-click line is applied per sender, with the sketchy ones named
- Digest filters skip the inbox, not just label it
- Notification volume is fixed at the source where a source setting exists
Anti-Patterns
- Do not click unsubscribe on spam — it's a liveness beacon; report instead
- Do not keep newsletters aspirationally — the read-rate is the vote, not the intention
- Do not build filters for email that shouldn't exist — source settings first
- Do not purge alphabetically — impact order; the top ten senders are half the volume
- Do not skip the first-touch habit — without it, the purge is an annual chore instead of a one-time fix