Release Notes (Section)
End-user release notes. next.md accumulates approved entries as work lands (the commit flow offers a line per user-facing commit); /release folds them into a versioned v*.md (YAML front matter + What's New / Improvements / Bug Fixes); generate-index.ps1 builds releases.json, which the in-app "What's New" window renders.
Writing guide
The canonical voice guide is shared across products at ~/.claude/hooks/RELEASE_NOTES_STYLE.md (audience, length, verbs, translation table, categories, Group catch-alls, good vs bad). Read it before writing or editing any entry.
Shipping demand-backed work
When a release includes work a customer asked for, its DEM-NNNN ids go in the versioned note's YAML front matter (Demand: [DEM-0022]), never in a bullet: bullets are read by engineers in the What's New window, front matter is not. /release writes that key itself, from the roadmap lines ticked since the last release tag - so write one by hand only for an id that shipped without ever reaching its ticked line, and fix the line while you are there. Why that closes a customer's loop, and what else does: docs/agents/demand-link.md.
Section carve-out
- Never write migration or carry-over guidance. Section has no users yet, so nothing an entry could say about opening an older project reaches anybody: no "opening a project made before this change...", no list of what does not carry over, no advice to redo or re-check anything on first open. State what the product does now. This is Section-only - Beam EC2 is released and its notes do owe migration guidance. (Samir, 2026-08-06.) A corollary for design decisions: an in-app disclosure must not be traded away on the grounds that "the release note covers it" - here, that channel reaches no one.
- No em dashes or en dashes in any entry (root
CLAUDE.mdrule: release notes render in a user-facing window). Use a regular hyphen-, colons for label:description, or restructure. - Use Section vocabulary: cross-section, biaxial moment, prestress, N-M diagram, exposure class, neutral axis, utilisation.
- Entries are for structural engineers, not developers: skip refactors, CI, tests, and version bumps; an entry earns its place only if a user would notice.