Inbox Unsubscribe Purge Skill
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-later label, 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
Anti-Patterns
1---2name: inbox-unsubscribe-purge3description: Cut inbox volume at the source — the unsubscribe purge that classifies recurring senders into kill/digest/keep, executes safely (real unsubscribes vs. spam-report vs. never-click), and installs the filters that catch the rest. Use when asked my inbox is all newsletters, mass unsubscribe safely, cut my email volume, or set up filters for the noise. Produces the sender census, the kill/digest/keep sort, the safe-unsubscribe rules, and the filter set.4---5
6# Inbox Unsubscribe Purge Skill
7
8Triage 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.
9
10## What This Skill Produces
11
12- **The sender census** — the top recurring senders by volume, from the actual inbox
13- **The sort** — kill (unsubscribe) / digest (batch to a daily-read label) / keep (whitelist to inbox)
14- **The safety rules** — which unsubscribe links to click, which to never touch, what gets spam-reported
15- **The filter set** — the rules that auto-route what survives, and the notification-settings homework that beats filtering
16
17## Required Inputs
18
19Ask for these if not provided:
20- **The census data** — search counts per suspected sender, or a description of the noise ("LinkedIn, three newsletters, shop marketing, GitHub notifications")
21- **Honest reading behavior** — which newsletters actually get read (the calendar answer; "I mean to" is a kill vote)
22- **The platform** — Gmail/Outlook/other; filter syntax differs, and the skill writes the real rules
23
24## Framework: The Purge Rules
25
261. **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.
272. **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.
283. **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.
294. **Digest beats trickle for the keepers:** surviving newsletters get a filter to skip the inbox into a `@read-later` label, 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.
305. **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.
31
32## Output Format
33
34# Unsubscribe Purge: [inbox]
35
36## The Census
37| Sender | Volume /90d | Actually read? | Verdict |
38|---|---|---|---|
39
40## Execution
41**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]
42
43## The Filters
44[The actual rules, platform syntax, paste-ready]
45
46## Quality Checks
47
48- [ ] The census is by measured volume, not by annoyance salience
49- [ ] Every kill passed the would-you-notice test
50- [ ] The click/never-click line is applied per sender, with the sketchy ones named
51- [ ] Digest filters skip the inbox, not just label it
52- [ ] Notification volume is fixed at the source where a source setting exists
53
54## Anti-Patterns
55
56- [ ] Do not click unsubscribe on spam — it's a liveness beacon; report instead
57- [ ] Do not keep newsletters aspirationally — the read-rate is the vote, not the intention
58- [ ] Do not build filters for email that shouldn't exist — source settings first
59- [ ] Do not purge alphabetically — impact order; the top ten senders are half the volume
60- [ ] Do not skip the first-touch habit — without it, the purge is an annual chore instead of a one-time fix
Mohit Aggarwal