/dotcom-release-marketing

name: dotcom-release-marketing
description: Post a plain-language summary of what's shipping in this week's tldraw.com (dotcom) release to the marketing team's Discord channel. Use when preparing the weekly dotcom release, when asked what's going out this week for a non-engineering audience, or when the scheduled release-marketing automation runs. Examines the production...main commit range, writes the user-facing changes in the house release-notes style, and posts a concise summary via a Discord webhook.

Dotcom release marketing summary

Summarize what's shipping in this week's dotcom release (the commits on `main` that are not yet on `production`) for the **marketing team**, and post it to their Discord channel.

This is the marketing counterpart to [[dotcom-release-crew]]. Same commit range, different audience: the release-crew message names engineers to have on hand; this one tells non-technical folks **what users will notice** so they can plan announcements, social posts, and changelog copy. No engineer pings, no release-risk framing.

The output is a **draft for a human to edit**, not finished copy. It should read like a streamlined version of the SDK release notes: the same voice, the same discipline about describing bugs precisely, but only the highlights and with every developer-facing detail removed.

**Arguments**: $ARGUMENTS

• `--dry-run` — print the finished message to stdout instead of posting it. Use this for testing and for reviewing a draft locally.
• `--range <base>...<head>` — compare this range instead of `production...main`. Use it to regenerate a past week's summary (for example, the previous deploy's source commit against `main` as it was at the time).

Inputs

• `DISCORD_MARKETING_WEBHOOK_URL` — environment variable holding the Discord webhook that posts to the marketing channel. Required unless `--dry-run` is given. If it is unset and this is not a dry run, stop and tell the user to set it (do not hardcode a webhook URL — this repo is public).
• `GH_TOKEN` — used by `gh`. Present automatically in CI; locally, ensure `gh auth status` works.

Style source

Before writing anything, read the house style. Do not invent a tone.

1. `skills/shared/release-notes-guide.md` — the SDK release-notes style guide. Its rules for entry format, what to include, and what to omit apply here too. 2. The two most recent published release notes in `apps/docs/content/releases/` (the highest `vX.Y.0.mdx` files, not `next.mdx`). Read their introduction paragraph, `## Improvements`, and `## Bug fixes` sections. These are the examples to match.

Take their **discipline**, not their register. The SDK notes are written for developers; this summary is written for someone who uses tldraw.com and has never read a commit.

What to take from them:

• The **introduction paragraph** pattern: one or two sentences that lead with concrete features, not adjectives.
• The way **bugs are described as observed**, with the situation that triggered them. "Fix undo after a cut also reverting the change made before it." "Fix Escape being ignored while pressing on the canvas with the select tool." The condition is always there. Keep that; rephrase it for a user.
• Their restraint: short entries, no fluff, nothing that can't be verified.
• **No decorative emoji.** The SDK notes use none apart from 💥 and 🔜 as markers, and this summary uses none at all.

What to leave behind: anything under `## API changes`, PR links and numbers, anything in backticks, package names, the `Add`/`Fix` verb-first form, and explanations of *how* something was fixed.

Workflow

1. Fetch the commit range

Set the range. Default is `production...main`; `--range` overrides it.

Get every commit in the range with its **full message**, not just the subject line. tldraw squash-merges PRs, so the subject is the PR title and the body is the PR description, which usually includes `### Before`, `### After`, or `### Release notes` sections. Those sections are where the precise description of a bug lives. `--paginate` handles ranges larger than 250 commits.

gh api "repos/tldraw/tldraw/compare/${RANGE}" --paginate \
  --jq '.commits[] | {sha: .sha[0:10], message: .commit.message}'

Also capture the human-readable diff URL: `https://github.com/tldraw/tldraw/compare/${RANGE}`.

If there are **zero** commits, post a brief note that there's nothing new shipping this week and stop.

2. Select what's worth telling marketing about

Keep only changes a **user of tldraw.com could notice**. Apply the SDK guide's include/omit rules, then tighten them for this audience.

**Include:**

• New features and capabilities users can see or use, in `dotcom`, `tldraw`, `editor`, or collaboration and sync.
• Improvements users will feel: visible polish, and performance only when the difference is noticeable in normal use.
• Fixes for bugs users would have hit: broken interactions, rendering, export, embeds, sync, sharing, sign-in.

**Exclude:**

• Anything that would sit under `## API changes` in the SDK notes.
• `docs`, `test`, `chore`, `ci`, `build`, dependency bumps, refactors, tooling, and anything only observable in code.
• Fixes for bugs introduced in the same range (the bug never reached users).
• Anything whose only honest description needs a code identifier.

For every candidate, answer one question: **what would a user have to do to notice this?** If there is no answer, drop it. If the answer is the condition of a bug, that condition goes in the bullet.

Aim for **three to six bullets**. Fewer is fine. It is normal for most commits not to make the cut.

3. Write the entries

Write each kept change as one or two short sentences to a person who uses tldraw.com. Under about 30 words per bullet, even for a feature made of several PRs: name the two or three things they'll notice and stop.

**Every bullet contains the situation**: what the reader does, or sees, that the change affects. Take it from the PR body's befor