Use emails for contacts who already have a relationship with your product: new signups, resource subscribers, or inactive customers. It connects each message to a purpose, a delay, and a next action. The useful first output is a reviewable lifecycle flow that you can later configure in your email platform.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill emails -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use emails and supply your material. The installation command belongs in the terminal, not in your content brief.
Start with the user event
Do not begin by requesting an arbitrary number of messages. Explain why recipients enter the sequence. Someone who registered, downloaded a guide, or purchased a subscription has different knowledge and needs. Provide .agents/product-marketing.md, the current onboarding flow, and other emails already being sent.
Example brief:
Use emails to design a five-message activation flow.
Entry is completed signup. Success means creating a project and inviting a colleague; see onboarding.md.
Users who already invited someone must exit invitation reminders. Security and billing emails also run separately.
First show the flow, then write subjects, previews, bodies, CTAs, delays, and exit conditions.
Review the sequence before polishing individual messages. Deliver the promised value first. Give later messages distinct jobs, such as one setup step, a useful capability, or a relevant objection. Do not combine payment, a survey, and a team invitation into one primary request. Suggested day intervals in the skill are starting points to adapt to product complexity and behavior.
Check who continues receiving messages
Every email needs a sending condition, a destination, and a reason to stop. Walk through the flow as a user who never started, one who completed the first step, and one who already paid. Look for reminders that no longer apply. Preview text should extend the subject, and mobile readers should be able to identify the main action quickly.
Then map the design to your actual provider. Mailchimp describes flows in terms of triggers, rules, actions, and exits. Its triggers normally respond to events occurring after activation; writing the sequence does not automatically enroll historical contacts. Available branching and data connections also depend on the platform configuration.
If the product does not track an event, do not build a precise branch around an invented label. Start with states you can reliably detect. Before enabling the flow, use test contacts to check destination links, exits, and overlapping sequences. Judge the program against the intended behavior, replies, and unsubscribes, rather than treating an open as successful activation.
Draw the state transitions before writing messages
Pick one kind of sequence—welcome, activation, nurture, or re-engagement—and define entry, start time, and exit events. An activation sequence should stop saying “you have not started” once a user completes the key action. A customer who upgrades should not keep receiving a trial countdown. Ask the skill for triggers, delays, exits, suppression rules, and the single job of each message before drafting any email copy.
An example brief: “Design three activation emails for people who registered but have not created a first project. Use our help documentation and known user questions. First show entry and exit logic; then write a subject, preview text, body, and one CTA per message. Stop this sequence when a project is created or the person unsubscribes.” This is a planning example; the skill does not silently configure your email platform. Someone still needs to implement the logic in the actual service.
Walk through recipient paths before launch: completed action, no action, repeated entry, and overlap with another sequence. Check that each email brings new information rather than repeating one request seven times. Verify links, personalization variables, and unsubscribe behavior. After launch, examine the target action alongside complaints, unsubscribes, and replies; an open rate alone cannot tell you whether the sequence helped.
Example: create a win-back flow that does not mislabel active users
Suppose a collaboration product sends win-back messages after thirty days without login, but some people continue working through links shared by teammates. Give the skill the login and project-activity event definitions, existing unsubscribe behavior, and release notes. Ask: “Use emails for at most three win-back messages. Define genuine inactivity first, then entry, exit, and exclusions. Make each message useful in a different way. Do not describe someone working in an active project as churned.”
Test three accounts on paper: entirely inactive, no login but ongoing project activity, and unsubscribed. The second should not receive an inaccurate “we miss you”; the third should not enter a marketing series. If the agent only gives polished prose without events, return to the flow diagram. If it suggests a misleading “urgent notice” subject to boost opens, replace it with an accurate one. Confirm triggers and exits in the email platform’s test environment before sending to real users.
A public sequence and one installation caveat
Phoebe Fu published an inspectable five-email learning sequence for her Skill evaluation checklist: immediate delivery, a day-two source check, a lesson on why installation is not proof, a day-seven evidence framework, and a day-ten field-test invitation. Each message has a subject, preview and one main action; entry is an optional request, with unsubscribe, bounce and completion as exits. These are drafts and automation specifications, not sent-email or deliverability results.
If the linked Customer.io or Mailchimp notes under ../../tools/ are missing after installation, the issue may be package scope. A community user reproduced that installing emails alone copies the Skill folder but not the repository-level integration notes. Read the relevant original files under tools/integrations/ in the upstream repository, then configure your actual sending platform. You can still draft the sequence first; sending and automation rules need separate verification.