hermeticormus/plugins/release-notes/skills/release-note-formats
plugins/release-notes/skills/release-note-formats/SKILL.md
# Release Note Formats > Release note structures for different audiences, channels, and release types. ## Knowledge Base ### Release Note vs Changelog | Changelog | Release Notes | |-----------|--------------| | Technical record of changes | Communication to users | | Every version, every change | Curated highlights | | Developer audience | Multiple audiences | | Keep a Changelog format | Flexible format | | Lives in CHANGELOG.md | Lives in GitHub Releases, blog, email | A changelog is the
tools
Updated Apr 21, 2026
$ install --global
skillsauthnpx skillsauth add hermeticormus/librecopy-claude-code plugins/release-notes/skills/release-note-formatsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 21, 2026, 10:07 PM148.9s1 file scanned
SKILL.md
Release Note Formats
Release note structures for different audiences, channels, and release types.
Knowledge Base
Release Note vs Changelog
| Changelog | Release Notes | |-----------|--------------| | Technical record of changes | Communication to users | | Every version, every change | Curated highlights | | Developer audience | Multiple audiences | | Keep a Changelog format | Flexible format | | Lives in CHANGELOG.md | Lives in GitHub Releases, blog, email |
A changelog is the raw material. Release notes are the polished product.
Audience Needs
| Audience | Cares About | Does Not Care About | |----------|-------------|-------------------| | End Users | New features, UX changes, fixed annoyances | API changes, internal refactors | | Developers | API changes, SDK updates, breaking changes | Marketing copy, UI screenshots | | Admins | Infrastructure changes, security patches, config changes | New UI features | | Executives | Impact metrics, strategic features | Technical details |
Release Types
| Type | Tone | Content Focus | |------|------|--------------| | Major (X.0.0) | Exciting but careful | Highlights, breaking changes, migration | | Minor (0.X.0) | Positive | New features, improvements | | Patch (0.0.X) | Reassuring | Bug fixes, security patches | | Hotfix | Urgent, professional | Specific fix, impact scope | | Security | Serious, actionable | CVE details, patch instructions |
Format by Channel
GitHub Release:
- Full markdown with all details
- Code examples for API changes
- Links to migration guide
- Comparison link to previous version
Blog Post:
- Narrative introduction with context
- Feature highlights with screenshots
- Quotes from team or community
- Call to action (upgrade, try it)
Email Digest:
- 3-5 bullet points maximum
- Links to full release notes
- Clear upgrade call to action
- Unsubscribe option
In-App Notification:
- One sentence per feature (3-5 features)
- "New" badges on affected UI elements
- Link to "What's New" page
Breaking Change Documentation Standard
Every breaking change entry must include:
- What changed: One sentence describing the change
- Why it changed: Brief rationale
- Migration path: How to update (code diff preferred)
- Automated fix: Codemod command if available
- Timeline: When the old behavior will be fully removed (if deprecation)
Patterns
- Highlight Reel: Lead with the 2-3 most impactful changes. Bury the detailed list below.
- Progressive Detail: Title > One-liner > Paragraph > Code example. Each level adds detail for readers who want it.
- Version Badge: Clearly show the version number and release date at the top.
- Comparison Link: Always link to the full diff (e.g.,
v1.9.0...v2.0.0) for developers who want to see every commit. - Credit Contributors: Thank contributors by name. It costs nothing and builds community.
Anti-Patterns
- The Git Log Dump: Pasting raw commit messages as release notes. Commits are not user communication.
- "Various bug fixes": Tells users nothing. List the actual bugs that were fixed.
- Breaking Changes Buried: Hiding breaking changes in the middle of a feature list. They deserve their own prominent section.
- No Upgrade Path: Announcing breaking changes without explaining how to migrate. Users feel abandoned.
- Marketing-Only: Release notes that read like press releases with no technical substance.
- Stale Template: Using the same generic template for every release without adapting to the content.
References
- GitHub Releases Best Practices
- Keep a Changelog
- Semantic Versioning
- Release Please
Related Skills
hermeticormus/plugins/user-documentation/skills/user-doc-patterns
tools
VerifiedTrustedCommunity
# User Doc Patterns > Patterns for writing clear, accessible end-user documentation. ## Knowledge Base ### User Documentation vs Developer Documentation | User Docs | Developer Docs | |-----------|---------------| | Task-oriented ("How do I...") | Concept-oriented ("How does it work...") | | Plain language | Technical language | | Screenshots and visual aids | Code examples | | Step-by-step procedures | API references | | Feature names and UI labels | Function signatures and parameters | | A
SKILL.mdUpdated Apr 21, 2026
hermeticormus/plugins/tutorial-creation/skills/tutorial-structures
tools
VerifiedTrustedCommunity
# Tutorial Structures > Pedagogical patterns and frameworks for creating effective technical tutorials. ## Knowledge Base ### The Tutorial Spectrum Tutorials exist on a spectrum between two extremes: | Recipe | Concept Guide | |--------|--------------| | "Do exactly this" | "Understand this idea" | | Step-by-step | Explanation-heavy | | Fast to complete | Deep understanding | | Low retention | High retention | The best tutorials blend both: steps for doing, explanations for understanding.
SKILL.mdUpdated Apr 21, 2026
hermeticormus/plugins/tutorial-creation/skills/tutorial-patterns
tools
VerifiedTrustedCommunity
# Tutorial Patterns ## Tutorial vs. How-to Guide: The Critical Distinction Before writing, identify which document is actually needed: | Tutorial | How-to Guide | |----------|-------------| | "Build a REST API in Node.js" | "Add JWT authentication to your Express API" | | For someone new to this | For someone who knows the domain | | Explains why each step is done | Steps are efficient, minimal explanation | | Has checkpoints, explores | Numbered steps, no detours | | Learner reaches a comple
SKILL.mdUpdated Apr 21, 2026
hermeticormus/plugins/technical-blogging/skills/tech-blogging-patterns
tools
VerifiedTrustedCommunity
# Tech Blogging Patterns ## The Developer Reading Pattern Developers do not read technical posts linearly. They scan in this order: 1. Headline (is this relevant to me?) 2. Code blocks (is this real code I can use?) 3. Headers (what does this cover?) 4. First paragraph (what's the point?) 5. Key takeaways / conclusion (is it worth reading fully?) Design for scanning first, reading second. Put real code within the first 25% of the post. ## The Before/After Pattern The contrast between a pain
SKILL.mdUpdated Apr 21, 2026