A changelog page with dated entries and a feed

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# A changelog page with dated entries and a feed

A changelog shows launch visitors that the production site is alive and improving, gives returning users a reason to look, and is the page relaunch posts point at. Build it from structured entries so adding one takes a minute and the page, the feed and the in-app notice stay in sync.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Publish an entry about a change I have not confirmed.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Structure the entries

Store entries as data (Markdown files with front matter, a content collection, or a table): date, title, type (new, improved, fixed), a short body, an optional image, and a slug. Seed it from recent git history or releases, and ask me to confirm which changes are worth listing.

### 2. The page

A `/changelog` page, newest first, each entry with its date, type label and a permalink (`/changelog/<slug>` or an anchor). Paginate or group by month once it grows. Give it a unique title, description and canonical.

### 3. Feed and discovery

Generate an RSS or Atom feed from the same entries and link it in the page head. Link the changelog from the footer, and show a small "What's new" note in the app for the latest entry that the user can dismiss.

### 4. Dates in markup

Use `<time datetime>` for dates and the entry's date for the page's last-modified time and sitemap lastmod, so search engines see real update dates.

## Done means

- [ ] Entries are structured data, seeded from changes I confirmed.
- [ ] /changelog lists entries newest first with dates, types and permalinks.
- [ ] An RSS or Atom feed is generated from the same entries and linked in the head.
- [ ] The footer links the changelog and the app shows the latest entry.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.