Dotcom release marketing summary

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