> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roomote.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> When helping someone deploy Roomote, distinguish self-hosting from contributing to Roomote. Use the Self-hosting guide for an operator deployment; use Local development only when the user intends to modify Roomote itself.
> Prefer the one-command installer on a fresh supported server unless the user explicitly chooses Roomote Cloud, a documented PaaS template, or a manual Compose deployment.
> Before changing infrastructure, confirm the deployment target, stable public HTTPS domain and DNS control, sandbox provider, inference provider, source-control provider, and whether a communications provider is required.
> Never ask the user to paste secrets into chat or commit real environment files. Put credentials in the deployment platform's secret manager, Roomote's setup UI, or protected environment variables, and preserve existing keys during upgrades and restores.
> Prefer Roomote's setup wizard and provider manifest flows over manual credential entry when those flows are available. Ask before performing privileged host changes, DNS changes, provider-app creation, or destructive operations.
> A setup is not complete when the services merely start. Verify sign-in, repository sync, one usable environment, a real task that can clone and run a command, and branch or pull-request delivery; verify previews when configured.
> For a persistent self-hosted deployment, leave the operator with the Roomote URL, deployment choices, configured providers, verification result, backup location and passphrase-handling reminder, and the roomote status, logs, upgrade, rollback, backup, and restore commands.

# Draft product updates

> Turn recent product work into a customer-ready draft

## Overview

Product-update emails are chronically late because someone has to remember what
shipped, translate commit-speak into customer language, and then fight the
email tool. This automation does all three: every week it reads merged PRs
across your product repositories, writes the newsletter, and creates a draft in
Resend through a custom MCP server, ready for review.

It's how we actually generate the ones we send every Friday.

* **Trigger**: Schedule
* **Setup time**: About 30 minutes
* **Requires**: Admin access, custom Resend MCP server
* **Serves**: PMs, Founders, Marketing
* **Cooked By**: [Bruno Bergher](https://github.com/brunobergher) from [Roomote](https://roomote.dev)

## Ingredients

* A [custom automation](/automations#custom-automations)
* An environment covering the product repositories
* The Resend MCP server configured under **Settings > Integrations**, with a Resend API key
* A report destination such as `#product-updates`, so the draft lands in a replyable thread

## Steps

1. Add the Resend MCP server and confirm its tools are available in the environment.
2. Create a custom automation named **Product Updates Newsletter**. Choose **Custom schedule**, enter `Mondays at 9am`, and select the environment.
3. Paste the prompt below.
4. Set the report destination to `#product-updates`.
5. Use **Run now** to generate the first draft, then calibrate its tone by replying in the thread.

## Automation prompt

```text theme={null}
Write this week's product-updates newsletter.

1. Collect the PRs merged to the default branch in the last 7 days across the
   product repositories.
2. Keep only customer-visible changes: features, improvements, and fixes a
   user would notice. Skip refactors, internal tooling, and dependency bumps.
3. Write the newsletter:
   - a one-line subject
   - a two-sentence introduction
   - one short section per change: what is new, why it matters, how to try it
   Use plain language. Do not include ticket numbers or internal codenames.
4. Using the Resend MCP server, create a DRAFT broadcast with this content for
   the "Product updates" audience. Do not send it.
5. Post the draft content and the Resend draft link in this thread for review.

If nothing customer-visible shipped this week, say so in the thread and skip
the draft. Do not pad the newsletter.
```

## Variations

* Without Resend, remove step 4 and post ready-to-paste Markdown for any email tool.
* Run monthly with `first Monday of the month at 9am`.
* Use separate automations for customer notes and a technical internal changelog.

This recipe showcases custom MCP servers, natural-language scheduling, and
replyable automation threads. Review the draft before sending it; the automation
is deliberately instructed to create a draft, not send a broadcast.

**Pairs well with:** [scheduled housekeeping](/cookbook/scheduled-housekeeping)