A relaunch changelog and announcement

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

# A relaunch changelog and announcement

Relaunching the production site works when there is a real story: what changed, and why it matters to people who saw the first launch. Work out what has changed since the first launch from the code and changelog, and turn it into a changelog entry, a relaunch post draft and a list of pages and screenshots to update.

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.
- Post the announcement anywhere.
- Claim improvements the code does not show.

## 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. Find what changed

Ask me for the first launch date. From git history, releases and the changelog since then, list the user-visible changes: new features, big improvements, fixes people asked for, pricing changes. Ignore internal refactors unless they made something noticeably faster.

### 2. Pick the story

Group the changes into three to five headline improvements and tie each to what users asked for, if you have that feedback. Propose a one-line summary of the relaunch. Wait for my choice.

### 3. Write it

Draft a changelog entry for the relaunch, and a launch post (title and body) in plain words: what it is, what changed, who it is for, and a thank-you to people who gave feedback. Keep platform limits in mind (for example about 60 characters for a tagline).

### 4. Update the surface

List every page, screenshot, video and share image that still shows the old product, and update the ones in the codebase. Make sure the landing page mentions the headline improvements.

## Done means

- [ ] User-visible changes since the first launch are listed.
- [ ] I chose the headline improvements and the one-line summary.
- [ ] A changelog entry and a relaunch post draft exist.
- [ ] Outdated pages and images in the codebase are updated; the rest are listed for me.

## 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.