executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
inbox-unsubscribe-purgeCut 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 …
Independent GitHub snapshot · Automated classification · Original documentation governs
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.
Ask for these if not provided:
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.@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.| Sender | Volume /90d | Actually read? | Verdict |
|---|
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 actual rules, platform syntax, paste-ready]