release-post

Produce the X announcement for a release: a bento release card as a paste-ready PNG, plus post copy.

When invoked

Use this skill when asked for a release announcement, a release image or card, or post copy for a version — phrases like "image for an X post about the release", "announce the release", "release card".

Two principles govern everything below: facts come from the repo, never from memory (the tag, the commits, the token CSS), and the card is drawn in the system's own visual language — it should look like a screen from the site, not a generic promo graphic.

Instructions

1. Gather the release facts

Work from the tag, not recollection:

git log --oneline $(git describe --tags --abbrev=0 v<version>^)..v<version>
git show v<version> --no-patch --format='%s%n%b'

(git describe on the version tag's parent resolves to the previous release's tag, so the range is exactly this release.) The repo's first tag (v1.0.0) has no earlier tag to anchor the range — take it from the full history instead (git log --oneline v1.0.0).

The tag message names the headline features; the commit list fills in the rest. The version's entry in the release log (website/src/data/release-log.json, written at publish time by the release skill) is the summary of record — the card and copy must agree with it. Pick the strongest feature as the hero and a handful of others as supporting tiles; a release with more features than tiles drops features rather than shrinking them.

2. Lift the real design values

Read the token files before drawing — never write a colour or type value from memory:

• src/tokens/tokens-primitives.css — the hex values behind the semantic roles
• src/tokens/tokens-dark.css — which primitive each dark-theme role resolves to (the card is dark-theme; it reads best in a feed)
• src/tokens/tokens-typography.css — the display sizes, weights and letter-spacing

This repo has no earlier cards to match, and the site does not serve the base theme. Resolve every role through the served theme: SERVED_THEME_ID in website/src/lib/theme/brand.ts names it, and the root layout renders it as data-brand on <html>. Its generated stylesheet in src/tokens/presets/ overrides the base theme's tokens (composed by presetOverrides in website/src/lib/theme/presets.ts), so read the base token files and then that sheet, never the base files alone. The sheet has a light block and a dark block, and a tinted preset's neutral primitives differ between them, so read the block for the theme the card is drawn in.

The values to resolve: the page and container greys, the container border, the text ramp, the dark-theme action colour and its ink as the served theme resolves them, and — if a tile shows status colours — the dark-theme status icon hues. Radii follow the system's rules: pill for buttons and chips, the card radius for tiles, the composer radius if a tile draws the composer. design.md owns those; check it when unsure rather than guessing.

3. Draw the card

Author a plain HTML file in the scratchpad (never in the repo tree) at 1200×675 — X's landscape card ratio. The established layout (this repo has no earlier cards of its own to match; the layout below is the record):

• Header row: the package name as an uppercase overline in the action colour; the version large in the light display weight with its tracking; the release date beside it; an npm i pill and the site's host (from SITE_URL in scripts/brand.mjs) on the right.
• Bento grid below: four columns by two rows. The hero feature takes a 2×2 tile with a title, one sentence, a few pill chips, and a small abstract drawing of the feature (panels, glyphs, a miniature control — drawn with divs and inline stroke SVG, never emoji or screenshots). Each remaining feature gets a 1×1 tile: bold title, a tiny visual or code chip, one caption sentence.
• A faint radial glow or two behind everything, in the ambient colours (--color-ambient-* as the served theme resolves them) — the site's ambient background in still form. Subtle; the ground stays near-black.

The faces the served theme declares load from Google Fonts via a <link> in the head. All copy on the card follows content-design.md: sentence case, neutral, no emoji, no em dashes, one idea per line. Tile captions are one short sentence each.

4. Render to PNG

Render headlessly with the Playwright already in the repo's dependencies — no browser pane, no manual export. ESM ignores NODE_PATH on every platform, so import Playwright by an absolute file:// URL into its package inside the repo's node_modules (derive the repo root with git rev-parse --show-toplevel). On a Windows checkout only, also strip the leading slash a file:// pathname puts before the drive letter; on macOS or Linux that slash is the path's root and must stay.

The render script: chromium headless, viewport 1200×675 with deviceScaleFactor: 2, goto the card file with waitUntil: 'networkidle', then await page.evaluate(() => document.fonts.ready) plus a short settle before screenshotting the card element — without the fonts wait, the PNG ships in the fallback face. The result is 2400×1350: crisp at twice the post size.

Look at the PNG before handing it over. Read the image and judge it like a design-QA pass: nothing clipped, the hero drawing balanced in its tile (the first render of the first card left it sunk in a corner), captions unwrapped where they should be, glyph colours right. Fix and re-render until it holds up.

5. Write the copy

Post copy is shipped prose in spirit — content-design.md governs it. Additionally:

• Fit the standard character limit (280). Count it. Offer one primary version that fits, and optionally a longer alternate.
• Lead with the package and version, or with the hero feature — either works; hype never does.
• Name real things: components, exports, subpaths. "FilterMenu joins the shared overlay behavior layer" beats "big improvements to overlays" (FilterMenu is fictional — pull the real names and counts from the release's own diff and registries, never from this file).
• No emoji, no exclamation marks, no hashtag stuffing.

The copy and the card must tell the same story: the hero feature on the card is the hero feature in the copy.

6. Deliver

Send the PNG with SendUserFile so it lands as a file the owner can copy straight into the post, and put the copy in the reply as a quoted block. If the owner wants to hand-tweak the card, the design canvas flow (publish the card as an editable artifact) is the follow-up to offer — not the default, since the ask is a paste-ready image.

Guardrails

• Never restate release facts from memory — the tag, the commits, and the version's release-log entry are the sources, and they must agree with what the card claims
• Never write a hex value or font size the token CSS didn't supply this session; the card is a picture of the system, so a drifted colour is a wrong picture
• Working files live in the scratchpad, never the repo tree; nothing this skill produces is committed
• The card carries no screenshots and no third-party marks — abstract drawings only
• Posting is the owner's move: this skill ends at a PNG and copy, never at anything published