Release Notes One Pager
Publish a single-page HTML release notes doc with Added, Fixed, Breaking, Known issues, and Upgrade sections tied to your design system.
Overview
release-notes-one-pager is an agent skill for the Ship phase that writes a design-system-aligned HTML release notes page with standard version sections and explicit empty-state wording.
Install
npx skills add https://github.com/nexu-io/open-design --skill release-notes-one-pagerWhat is this skill?
- HTML one-pager with Highlights, Added, Fixed, Breaking changes, Known issues, Upgrade note
- Explicit None-style sections when the user omits details
- Pre-flight: copy assets/template.html, layouts.md, and map DESIGN.md to six :root variables
- P0 / P1 / P2 gates in references/checklist.md
- Six :root variables mapped from DESIGN.md
- P0 / P1 / P2 quality gates in references/checklist.md
- Standard sections: Highlights, Added, Fixed, Breaking changes, Known issues, Upgrade note
Adoption & trust: 809 installs on skills.sh; 61.4k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are cutting a release but only have scattered PR titles and no consistent one-page changelog customers can trust.
Who is it for?
Indie developers shipping versioned SaaS, CLIs, or APIs who already maintain DESIGN.md and want repeatable HTML release comms.
Skip if: Multi-page marketing launch sites or teams that refuse a shared template and design-token map.
When should I use this skill?
User mentions release notes, changelog, what's new, version update, change log, or release summary.
What do I get? / Deliverables
You get index.html-style release notes from the shared template with gated sections and token-mapped styling ready to publish or attach to a release.
- Single-page index.html release notes from assets/template.html
- Section-complete changelog with Highlights through Upgrade note
Recommended Skills
Journey fit
How it compares
Template-driven release comms skill, not automated git changelog extraction or app-store ASO copy.
Common Questions / FAQ
Who is release-notes-one-pager for?
Solo builders and tiny eng teams publishing structured what's-new pages for desktop or web products with an existing design system doc.
When should I use release-notes-one-pager?
During Ship launch prep when you need release notes, changelog HTML, or a version summary with breaking-change and upgrade guidance.
Is release-notes-one-pager safe to install?
Review the Security Audits panel on this Prism page and inspect local template assets before copying HTML into customer-facing hosts.
SKILL.md
READMESKILL.md - Release Notes One Pager
# Release Notes One-Pager Skill Produce a single-page release notes document in HTML. ## Resource map ``` release-notes-one-pager/ ├── SKILL.md ← this file ├── example.html ← quality bar and style reference ├── assets/ │ └── template.html ← local seed file to copy to project index.html └── references/ ├── checklist.md ← P0 / P1 / P2 gates └── layouts.md ← local section skeletons ``` Do not write CSS from scratch unless the user explicitly asks for a bespoke structure. ## Workflow ### Step 0 — Pre-flight 1. Read `assets/template.html`. 2. Read `references/layouts.md`. 3. Read active `DESIGN.md` and map it to the six `:root` variables. ### Step 1 — Start from the shared seed Copy `assets/template.html` to project `index.html`. Update: - `<title>` - topnav logo text - topnav link labels (destinations are pre-wired to `#added`, `#fixed`, `#upgrade-note`) - topnav CTA label and `href` destination, or omit the topnav CTA entirely if no real destination exists - ensure the topnav link targets exist by adding matching section `id` attributes ### Step 2 — Build release-note structure Inside `<main id="content">`, compose this section order: 1. Hero (Layout 1 or 2): version, date, one-sentence summary. 2. Added (use Layout 7 log-list; section root must include `id="added"`). 3. Fixed (use Layout 7 log-list; section root must include `id="fixed"`). 4. Breaking changes (use Layout 7 log-list, or one row explicitly saying "None"; section root must include `id="breaking-changes"`). 5. Known issues (Layout 7 or card list; section root must include `id="known-issues"`). 6. Upgrade note (short steps list or explicit no-action statement; section root must include `id="upgrade-note"`). 7. Closing CTA strip (Layout 6). For every CTA in the emitted HTML (topnav, hero, closing strip), replace both the visible label and the `href` destination with real, safe values. If no real destination is available, omit the CTA entirely—do not use a placeholder such as `href="#"`, a misleading page-anchor, or `REPLACE_WITH_REAL_URL`. Hero CTAs are optional; only add them when real destinations exist. ### Step 3 — Honesty rules for missing details If the user does not provide details, do not invent them. Write explicit placeholders: - Summary: `No summary provided.` - Added: `No additions provided` - Fixed: `No fixes provided` - Breaking changes: `None` - Known issues: `None reported` - Upgrade note: `No upgrade actions required based on provided information` If release version or date is missing, use `—` and label the field rather than guessing. ### Step 4 — Self-check Run `references/checklist.md`. Every P0 must pass. ### Step 5 — Emit artifact Wrap output as: ``` <artifact identifier="release-notes-one-pager" type="text/html" title="Release Notes"> <!doctype html> <html>...</html> </artifact> ``` One sentence before the artifact. Nothing after `</artifact>`.