Changelog entries

/changelog on the landing site is written by hand on purpose. It is not a list of PR titles. Each minor version line (2.3, 2.2, …) is one entry with a human title and summary, and patch releases fold into it. The raw line items live in packages/core/CHANGELOG.md, written by Changesets. This skill turns those into page copy.

• Data: apps/web/lib/changelog.ts (types Era, Release, Patch, Shot).
• Rendering: apps/web/components/changelog/timeline.tsx. You shouldn't need to touch it.
• Guard: apps/web/lib/changelog.test.ts (runs in pnpm test:changelog, its own CI job). It fails when a stable core version in CHANGELOG.md is missing from the page, when the page lists a version that was never published, or when the latest page version doesn't match packages/core/package.json.
• The release count and latest version on the page are computed. Don't hard-code numbers.

When to run it

Changesets opens chore: release packages (branch changeset-release/main), which bumps packages/core/package.json and prepends to CHANGELOG.md. GitHub Actions does not run on that bot PR, so nothing fails there. If it merges without a page entry, the test fails on main and on every PR after it, until the entry lands.

Preferred: add the entry as the last commit on the release PR, right before merging it. The Changesets action force-pushes that branch whenever another PR merges to main, which would drop an earlier commit. If the release has already merged, open a follow-up PR to main instead. Before merging, check the release PR's CHANGELOG.md diff: it is the source of truth for what shipped.

Steps

1. Find what's missing. Run pnpm test:changelog. The failure lists the versions. Read their sections in packages/core/CHANGELOG.md, and the same-date sections of packages/cli/CHANGELOG.md: CLI changes fold into the core entry they shipped with.