Every message the product sends out of the app — transactional email, push, in-app — for whether it is timely, wanted, clear, and controllable.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: inventory everything the product sends a user outside the app — email, push, in-app notifications — and judge whether each is timely, wanted, clear, and under the user's control, or noise that trains people to ignore you.
Read-only pass. Read the sending code, templates, and triggers; change nothing but the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
the moments that should trigger a message, and the noisy ones that should not
receipts, resets, confirmations: clear, branded, and actually useful
SPF/DKIM/DMARC, sending reputation, links and content that dodge spam filters
granular opt-outs, one-click unsubscribe, and honoring them
batching, digests, and caps versus a stream users learn to ignore
the right channel per message, not everything pushed everywhere
each message has a clear purpose and next step; no dead-end pings
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
List every message the product can send, its trigger, and its channel.
Coverage & timing — the moments that should trigger a message, and the noisy ones that should not.
Rank by reach × harm or value.
Create NOTIFICATIONS.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:notification-email.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-notification-email:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=106 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/106.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Notification & Email Audit You are working inside this repo. Mission: inventory everything the product sends a user outside the app — email, push, in-app notifications — and judge whether each is timely, wanted, clear, and under the user's control, or noise that trains people to ignore you. Read-only pass. Read the sending code, templates, and triggers; change nothing but the report file. ## Phase 1 — Inventory what gets sent - List every message the product can send, its trigger, and its channel. - Note which are transactional (receipts, resets) and which are lifecycle or marketing. - Find where preferences and unsubscribe are handled, if at all. ## Phase 2 — Audit through 7 lenses 1. **Coverage & timing** — the moments that should trigger a message, and the noisy ones that should not 2. **Transactional clarity** — receipts, resets, confirmations: clear, branded, and actually useful 3. **Deliverability** — SPF/DKIM/DMARC, sending reputation, links and content that dodge spam filters 4. **Preference & control** — granular opt-outs, one-click unsubscribe, and honoring them 5. **Frequency & fatigue** — batching, digests, and caps versus a stream users learn to ignore 6. **Channel fit** — the right channel per message, not everything pushed everywhere 7. **Content & action** — each message has a clear purpose and next step; no dead-end pings ## Phase 3 — Curate - Rank by reach × harm or value: a broken password-reset email outranks a rare digest tweak. - For each, decide keep, cut, re-time, or move channel. - Flag anything that risks deliverability for the whole domain. ## Phase 4 — Report Create `NOTIFICATIONS.md` at repo root: 1. **Send inventory** — message · trigger · channel · transactional or lifecycle 2. **Findings** — each: lens · message · the problem · the fix 3. **Deliverability** — the domain-level risks and the setup to fix them 4. **Control & cadence** — the preference and frequency changes that cut fatigue Start the report with today's date. If `NOTIFICATIONS.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Every send earns its place; the unsubscribe is a feature, not a loophole - A domain-level deliverability problem outranks any single template - No notifications or email in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which notifications to fix first
reports/ directory exists at the repo root, write the report there instead of the root.The flagship. Understand the whole product, then surface prioritized opportunities across UI, UX, retention, engagement, community, and beauty.
How user signal re-enters the product — corrections captured or evaporating, thumbs nobody reads, and the complaint-to-fix path.
The product's own search — whether users can find what they are looking for: relevance, recall, forgiveness, and what happens on zero results.
The whole arc of an account beyond signup — settings, export, plan changes, and deletion — and whether the product treats users with dignity, even leaving.