Work & projects · v0.1.0
Changelog
Public 'what's new' page for a product: releases in reverse-chronological order, each with a version, date, colour-coded type label and a short list of changes. Use for release notes, product updates and version histories.
Paste the prompt into Claude (or any agent that can fetch URLs) with your content — you get back a finished, self-contained HTML file. Manifest ↗
Live preview — the example content ships with the template and is replaced by your content.
What an agent may change — and what content you should have ready. Everything outside these slots is fixed by design.
Slots
| Slot | Type | Req. | Example |
|---|---|---|---|
doc-title |
text | yes | Changelog — Sluis |
product-name |
text | yes | Sluis |
page-title |
text | yes | Changelog |
intro-line |
text | yes | Every change we ship to the Sluis API gateway, newest first — usually one release every two to three weeks, published the day it goes out. |
subscribe-line |
text | no | Machine-readable feed at sluis.dev/changelog.xml · or get every release by mail from Account → Notifications. |
upcoming-content |
html | no | <p>Being built now. Nothing here has a date until it ships.</p><ul><li>Policy versioning, with a diff view and one-click rollback.</li></ul> |
footer-line |
text | no | Sluis B.V. · Rotterdam · sluis.dev/docs |
Repeat: release (1–30×)
One block per shipped release, newest first (reverse chronological, top to bottom).
| Slot | Type | Req. | Example |
|---|---|---|---|
release-version |
text | yes | 3.2.0 |
release-date |
date | yes | 12 Aug 2026 |
release-tag |
text | yes | Feature release |
release-tag-class |
text | yes | tag tag-feature |
release-title |
text | yes | Regional failover and rule previews |
release-body |
html | yes | <ul><li><strong>Added</strong> Regional failover. A standby gateway takes over within 30 seconds.</li><li><strong>Fixed</strong> Keys created through the API lost their <span class="code">environment</span> label.</li></ul> |
Optional blocks
subscribe— Header line pointing at an RSS/JSON feed, release e-mails or a Slack app.upcoming— Panel above the release list saying what is being built next.legend— Three-column key explaining what the feature / patch / breaking labels mean.
The authoritative fill instructions from manifest.json — the only place a template may instruct an agent (why).
NEWEST RELEASE FIRST — reverse chronological, top to bottom. This is the mistake to check for before you finish. Delete the data-example releases; they are preview content only. Keep semver honest: breaking change = major (3.0.0), new functionality = minor (3.2.0), fixes only = patch (3.1.2). release-tag-class must match the release type and be exactly one of 'tag tag-feature', 'tag tag-fix', 'tag tag-breaking', with release-tag text to match ('Feature release' / 'Patch' / 'Breaking change'). release-title is a one-line human summary of what the release does — never a restatement of the version number. Keep each release-body to 3–6 bullets, each opening with a bold Added / Fixed / Changed / Removed and then one plain past-tense sentence: what changed, and for a breaking change what the reader must do about it. No marketing copy, no exclamation marks, no 'we're excited'. Inline code goes in <span class="code">. Dates exactly like the placeholder: '12 Aug 2026'. Drop the upcoming, legend or subscribe blocks when there is nothing real to put in them. If a version or date is unknown, write [VERSION] or [DATE] and tell the user to fill it in with the built-in Edit button.
Published versions are immutable: /t/changelog@{version}/ never changes once live. /t/changelog/ always points at the latest.