القائمة
Tame notification overload by reclassifying noisy senders, grouping repetitive notifications, and bulk-archiving cleared alerts.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use the Spark MCP extension to access and act on the user's Spark email data - list emails, search by topic, read threads, check calendar events, find availability, look up contacts, view team info, draft messages (from scratch or saved templates), send drafts, share drafts with teammates, post team comments, triage threads, create/update/delete calendar events and manage attendees, and manage contacts. Use when the user asks about their emails, calendar, contacts, meetings, scheduling, or wants to send, reply, archive, snooze, assign, comment, categorize, or schedule.
Executive assistant persona for Spark. Morning briefings, draft replies, schedule management, and contact lookup.
Founder / CEO persona for Spark. High-volume triage, aggressive delegation, cross-team oversight, and selective engagement.
Freelancer / solo operator persona for Spark. Multi-client management, invoice follow-ups, availability, and quick responses.
Meeting manager persona for Spark. Meeting preparation, transcript review, follow-up drafts, and scheduling.
Project manager persona for Spark. Project thread tracking, stakeholder updates, action item extraction, and cross-team coordination.
| name | spark-recipe-notification-hygiene |
| description | Tame notification overload by reclassifying noisy senders, grouping repetitive notifications, and bulk-archiving cleared alerts. |
| metadata | {"version":"1.0.0","requires":{"skills":["spark"],"accessLevel":"triage"}} |
Tame notification overload by identifying noisy senders, reclassifying misplaced mail, grouping repetitive notifications, and clearing out what's no longer relevant.
Prerequisite: Read the spark base skill for tool reference and filter syntax.
Access level required: triage.
emails { "folder": "Inbox", "filter": "category:notification is:unread" }
Count the unread notifications. If the number is high, scan the sender list for patterns - which senders dominate?
Look for senders that generate high-volume, low-value notifications (CI bots, social media alerts, shipping updates after delivery, etc.).
Read a few to confirm they're noise:
thread { "message_id": "<id>" }
Some "notifications" are really newsletters in disguise:
contact-action { "action_name": "changeCategoryNewsletters", "emails": ["noisy-digest@example.com"] }
Some are actually from real people and should be in People:
contact-action { "action_name": "changeCategoryPersonal", "emails": ["colleague@example.com"] }
These changes apply to all future mail from the sender.
For senders that are useful but send too often (CI systems, monitoring alerts):
contact-action { "action_name": "groupEmailsFromContact", "emails": ["ci-bot@company.com"] }
This collapses their messages into grouped entries, reducing inbox clutter while keeping them accessible.
For notifications that have been seen and are no longer relevant:
action { "action_name": "archive", "message_ids": ["<id1>", "<id2>", "<id3>"] }
Pass multiple IDs in a single call to archive in batch.
For senders whose emails you want to receive but not be alerted about:
contact-action { "action_name": "unmarkContactAsImportant", "emails": ["alerts@service.com"] }
contact-action) is more effective than per-message (action) because it fixes all future mail.recipe-newsletter-cleanup for a full inbox declutter session.