--- name: email description: >- Build on-brand AssemblyAI emails for Iterable from the seven templates in this folder (launch, newsletter, notice, virtual event invite, in-person event invite, event follow-up, event follow-up for no-shows), apply the content length and style rules for each type, and stamp every link with the team's UTM conventions. Use whenever someone asks for an email, an Iterable campaign or template, a newsletter issue, a launch or announcement email, a deprecation or policy notice, an event invite or reminder, a post-event follow-up, asks to add or fix UTMs on email links, or asks who an email should go to, how big the list should be, or how to build the audience or segment for it. Also use to review an existing email HTML against the rules. Do NOT use for blog posts, landing pages, ads, or social; use /assemblyai-content, /ad-copywriting, or /copywriting for those. --- # Email This skill turns a request like "newsletter for September" or "invite for the Oct 7 SF workshop" into a finished HTML email that matches the brand design system and the emails AssemblyAI has actually sent, with every link tracked the same way. It exists so that anyone on the team, not only the person who built the last one, can produce an email that looks and reads like the rest. Everything here derives from the emails sent March–September 2026 and from `../assemblyai-brand-design-system.md`. The detailed rules live in two reference files; read the one for the email type before writing: - `references/GUIDELINES.md`: shared layout, type, color, copy rules, then a spec table per email type (subject and preheader length, word budgets, section counts, button limits, tone, what to avoid), a pre-send checklist, and the open design decisions. - `references/UTM.md`: how every link gets its parameters, the slug patterns per email type, and what never gets a UTM. - `references/PROCESS.md`: the five-step process for the person sending the email, and a troubleshooting section written for you to answer their questions from. Read Part 2 whenever the person reports a problem. - `references/AUDIENCE.md`: the coaching flow for building the list. A starter prompt, the conservative defaults, the 150,000-per-day ceiling on the promotional domain, the wave plan for audiences above 200,000, and the recipe format. Run it whenever the person asks who should get the email. Product facts (prices, language counts, latency figures, model names) come from `/product-claims`. Healthcare-adjacent copy runs through `/hipaa-language-check`. Links are verified with `/link-verification`. This skill does not restate those rules. ## Pick the template | Request sounds like | Template | Worked example inside | |---|---|---| | New model, API, or feature with a blog post | `templates/launch.html` | Universal-3.5 Pro Async | | The monthly digest | `templates/newsletter.html` | August 2026 issue | | Deprecation, retention or policy change, account or billing change | `templates/notice.html` | Summarization and Auto Chapters deprecation | | Workshop, webinar, or office hours on Zoom | `templates/event-virtual.html` | Sept 9 dictation workshop | | Event with a venue and a seat limit | `templates/event-inperson.html` | Sept 24 SF dictation workshop | | Materials and recap after an event, to attendees | `templates/event-followup.html` | Sept 24 follow-up | | Same, to registrants who did not attend | `templates/event-followup-noshow.html` | Sept 24 no-show follow-up | Every template carries a header comment listing its blocks (required and optional) and `SLOT:` comments on each block with the word budget for that slot. The example content is real, so the file renders as a complete email before a single edit. ## Rules that never bend 1. **One chrome for all seven.** 600px card on the warm ground, header with the logo and a category eyebrow chip, dark footer with the address and `{{unsubscribeUrl}}`. The footer is identical across templates and is not edited per campaign. That tag is the only correct unsubscribe tag. 2. **Cobolt `#3923c7` is the only accent.** Buttons, eyebrows, text links, step numerals, the highlighted row in a benchmark table. Nothing else gets color. Radius is 4px everywhere. Headings are Oceanic Text in sentence case; body is UN-11 ST falling back to the system sans; eyebrows, labels, and buttons are Modern Gothic Mono, uppercase. 3. **Notices are letters.** No hero, no buttons, no banners. Text links only. 4. **Event emails never state how many people attended or registered.** Describe what happened in the room, not the size of it. 5. **Every link is written by `utm.py`, never by hand.** One campaign slug per email, `utm_source=email`, `utm_medium=owned`, `utm_term` blank. Credit-grant links, `mailto:`, and the unsubscribe tag are left alone. 6. **Iterable treats `{{` as Handlebars.** A literal double brace in a code sample is written `\{{`. 7. **Copy rules from the brand:** the product is Speech-to-Text, never "transcription" as a category. "Production-ready" is banned. State what the API does and put every parameter and model name in a `.param` chip. Prices carry units. No em dashes in body copy. Soften absolutes. One clever line per email at most, and only in a headline. ## Workflow 1. **Read the spec** for the type in `references/GUIDELINES.md` and state the subject line, preheader, and campaign slug (pattern in `references/UTM.md` section 3) before writing. 2. **Copy the template** to a working file named `-.html`. 3. **Fill the slots.** Work through every `SLOT:` comment. Stay inside the word budgets; they are calibrated to what was sent. Delete optional blocks that are not needed rather than leaving them half-filled. 4. **Fill placeholders.** `REGISTRATION_URL`, `SLIDES_URL`, `RECORDING_URL`, `NEXT_EVENT_URL` become real URLs. New art is uploaded to the Iterable asset library first and referenced by its `library.iterable.com` URL; reusable assets are listed in `README.md`. 5. **Apply UTMs:** `python3 utm.py apply --campaign `. If the email has a credit-grant link, ask for that campaign value and pass it with `--credit-campaign`; never invent one. 6. **Render** at 640px and 375px (`render-templates.mjs`, or the equivalent for the working file) and look at both. Two-column blocks must stack on mobile; nothing may clip. 7. **Run the sibling checks:** `/product-claims` on every number and name, `/hipaa-language-check` if healthcare appears, `/link-verification` on every destination. 8. **Verify UTMs:** `python3 utm.py check ` must pass. Include the `python3 utm.py table ` output in the reply so every link can be reviewed before push. 9. **Walk the pre-send checklist** in `references/GUIDELINES.md` section 8. 10. **Push** per the section below. 11. **End every build reply with the handoff**, whether or not the push ran: the campaign name, then the three steps left in Iterable: send a test to themselves and one reviewer, attach the audience and check suppression lists, schedule. The full human process is `references/PROCESS.md`. When reviewing an existing email instead of building one, run steps 6 to 9 against it and report deviations from the spec table for its type. ## What the person gives you The person either pastes final copy (and often a screenshot of the design they want) or gives you source material: a blog post, a workshop brief, an event description, a Luma page, a deprecation ticket. Either way you pick the template and say why. For images unique to the email, they upload to Iterable's creative library and paste the `library.iterable.com` URL; you never accept images hosted anywhere else. For links, they paste plain destination URLs; you tag them. Do not ask them to build UTMs, name lists, or find message type IDs unless the project defaults are missing. ## Pushing to Iterable Push only when the Iterable MCP tools are available in the session. If they are not, deliver the HTML file and the link table, say so plainly, and give the manual path from `references/PROCESS.md` step 4. Never describe a push as done when it did not run. - Create or update the template with the email template upsert tool, using the working file name as the client template ID so re-pushes update in place. Subject and preheader come from the email. Sender and message type come from the project defaults below; only ask when the person behind a person-sent email is unknown. - Create the campaign as an unscheduled blast from that template. Never schedule, send, or trigger from this skill. Proofs, list selection, and scheduling happen in the Iterable UI. - `notice.html` defaults to the transactional message type and every other template is marketing. A transactional push always goes through the gate in the project defaults below. The rule and the grey areas are in `references/GUIDELINES.md`, "Sender, reply-to, and message type". ### Project defaults | Setting | Value | |---|---| | Reply-to, every email | `support@assemblyai.com` | | From, person-sent (launch, newsletter, all event emails) | `Name @ AssemblyAI` <`firstname@comms.assemblyai.com`>. The host for events, the launch owner for launches, the editor for the newsletter. Must match the signature block. | | From, notices (transactional) | `AssemblyAI Alerts` <`team@info.assemblyai.com`> | | From, marketing email with no natural person (rare) | `AssemblyAI Team` <`team@comms.assemblyai.com`> | | Campaign type, every email | Blast. Never triggered. | | Message type, `notice.html` | Transactional by default. Confirm with the person before every transactional push (see below). Look the type up with the message-types tool on connection; do not hardcode an ID. | | Message type, every other template | Marketing, always. | Prefer a person over `AssemblyAI Team` whenever one makes sense. If the request names no person for a launch or newsletter, ask who owns it rather than defaulting to the team sender. Notices always use the Alerts sender. Message types are project settings, separate from the blast/triggered campaign type. Before the first upsert in a session, list the project's message types and pick the marketing one for every template except `notice.html`. **Transactional gate.** Before any push on the transactional message type, stop and confirm with the person, in one message, that the email meets the definition: the recipient needs it to keep using the service regardless of marketing consent (a deprecation or its reminder, a retention or policy change, a billing or account change), it goes to a usage-defined list, and it contains nothing promotional beyond one sentence about the replacement. Quote the subject line back and ask for a yes. If the answer is no, or the email is mostly a pitch for a replacement feature, push it as marketing and drop "Action required" from the subject. Never push transactional on an assumption. If the project has only one email message type, use it and say so in the reply: a notice on a marketing type will not reach unsubscribed accounts, and a transactional type should be created before the next deprecation send. - Images cannot be uploaded through the MCP. Anything not already in the asset library is uploaded by hand first. ## Building the audience When the person asks who should receive the email, how big the list should be, or how to build it, run the coaching flow in `references/AUDIENCE.md`. Start with its starter prompt (what are you trying to accomplish, who must receive it, who must not, how fresh, what else is going out this week, when must it land), fill in what the email already answers, then return the recipe block: filters with exact field names, the always-on exclusions, the conservative defaults applied, and the send plan. Three rules from that file carry into every send plan you write: - **150,000 recipients per calendar day** across all marketing sends on the promotional domain, counted after the day's other campaigns. Never per campaign. - **No more than two marketing emails to a contact in seven days**, and never two on one day. Notices sit outside the cap but avoid the same day. - **Above 200,000 recipients, stage in waves**: Tier 1 and top-customer accounts first, then paying corporate accounts, then active corporate, then the rest. One wave per day, each under the ceiling, the next only after the previous delivered cleanly. Default to the moderately conservative audience (active in 90 days, engaged in 180, not emailed in 3 days, corporate domain, sales-managed excluded) and say which defaults you applied so the person can loosen one deliberately. You produce a specification; the person runs the count and builds the list. ## What is deliberately not here - Pulling email addresses or building the list itself. This skill specifies the audience; the person builds it in the audience tool, and the analytics skill confirms any field that is in doubt. - Iterable snippets for the shared header and footer. Planned once the MCP connection is live, so a footer change propagates without re-pushing every template. - A lifecycle or nurture sequence template. Not yet built.