Turn a product release, offer, or changelog into an owned-list launch while the rest of the product ships.
Your owned list sells while you ship when email is part of the release process, not a separate marketing project. The repeatable loop is simple: turn the change into a campaign, choose the people it helps, review the rendered email, deliver it with explicit approval, and feed the results into the next release.
Lumail is one line in that stack. Your product, checkout, source material, audience, and offer remain the system around it.
The result is not “a newsletter was sent.” The result is that the right people understood what shipped and had one obvious next step.
Write these five facts before opening an editor:
| Decision | Example for a product launch |
|---|---|
| Commercial event | A paid feature is available today |
| Audience | Trial users who reached the relevant limit |
| Promise | Finish the task without the old workaround |
| Evidence | Release notes, screenshots, pricing, and the live page |
| One action | Upgrade or try the feature |
If the offer, proof, or audience is unclear, an agent only produces a faster vague campaign. Fix the launch brief first.
These pages share one operating model but answer different questions. Use one canonical guide for each job instead of copying the same setup across several pages.
Use this when the release work already lives in Claude Code. The guide covers what “best email MCP” should mean, how Lumail and Kit differ, and how to turn repository evidence into a reviewable campaign draft.
Use this when the brief, changelog, screenshots, and product code are already open in Cursor. The guide keeps drafting, rendering, audience review, confirmation, and reporting in one observable sequence.
Use this when subscriber-tier pricing no longer matches how often you contact the list. The guide moves one representative launch first, preserves suppression state, and compares a normal month with a peak month before a full migration.
Give the agent primary material: the actual release notes, current pricing, screenshots, product page, and any claims already approved. A repository is useful evidence, but code alone does not prove that production works. Mark anything that still needs live verification.
“People likely to buy” is not a segment. “Active subscribers tagged course-creator who clicked a launch email in the last 90 days and have not purchased” is reviewable.
Ask for both the saved filter and the estimated recipient count. If either is surprising, stop before drafting.
The agent should return a campaign ID, subject, preview text, body, audience rule, and the facts it could not verify. Draft state is the right default because it is inspectable and reversible.
The product appears only where it explains the mechanism. A useful launch story is about what changed for the reader, how the release was promoted, and what happened next—not a feature inventory disguised as a tutorial.
Review what a recipient will receive, not only markdown in a chat. Check:
The campaign rendering workflow explains why draft creation and final delivery should stay separate.
Read back the campaign ID, sender, audience, recipient count, date, time, and time zone. A request to draft is never permission to send. A successful tool call is not proof of inbox delivery.
Compare the launch with similar sends. Opens can expose subject-line or deliverability problems, but clicks and attributed purchases are closer to the commercial result. Record what changed, what remained constant, and what the next campaign will test.
To launch with email, define one audience and one action, build the campaign from verified release evidence, render and review the saved draft, approve the exact recipient set and schedule, then compare clicks and purchases with previous launches. Keep the email platform as one component in the shipping stack, not the story itself.
Do not rebuild the operating system from scratch for every release. The existing prompt pack covers drafting, subject lines, click-based segments, re-engagement, changelog conversion, performance review, and a welcome sequence.
Get the seven prompts that run a newsletter. It is the only prompt pack used throughout these playbooks.