release-notes
When the user wants a human-readable changelog or release notes from shipped work. Use when he says "write release notes," "changelog," "what shipped," "summarize this branch/PR for release," or wants a plain-language summary of what changed for a project. Turns git history, a branch, or a set of PRs into notes that read like a product update, not a commit log.
Informations de source
- Dépôt
- gavin844/claude-code-skills
- Dernière activité de la source
- 5 octobre 2026 à 19:27
- Langue détectée de SKILL.md
- anglais
- Étoiles
- 0
- Forks
- 0
Options d'installation
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Vérifiez les fichiers source
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Explorateur de fichiers
2 fichiersAffichage de SKILL.md
SKILL.md
Instructions source · Aperçu en lecture seule- name
- release-notes
- description
- When the user wants a human-readable changelog or release notes from shipped work. Use when he says "write release notes," "changelog," "what shipped," "summarize this branch/PR for release," or wants a plain-language summary of what changed for a project. Turns git history, a branch, or a set of PRs into notes that read like a product update, not a commit log.
- metadata
- {"version":"1.0.0"}
# Release Notes
Turn shipped work into notes a non-engineer can read: what changed, why it matters, what
to do about it. Works from a branch, a range of commits, or a set of merged PRs.
## When to use
The user wants to know or communicate what shipped: a project update for himself, a note
for a colleague or a client, or user-facing release notes.
## Inputs
- The repo and the range: a branch vs main, "since last release," or specific PRs.
- Read the diff and commit messages (git), and any linked Linear/Jira issues if connected,
to recover the WHY behind each change, not just the what.
## How to build them
1. Group changes by theme, not by commit. A reader cares about features and fixes, not
individual commits.
2. For each item, write one line in plain product language: the change and why it matters.
Translate file/function names into features (the standing rule: features, not
plumbing).
3. Separate into **New**, **Improved**, **Fixed**, and **Behind the scenes** (infra/refactor
that has no user-facing effect but is worth noting).
4. Lead with what a person would notice. Bury the plumbing at the bottom or drop it.
## Output
```
## <Project> - <date>
**New**
- <feature>: <what it does for the user>
**Improved**
- <change>: <the before/after in one line>
**Fixed**
- <bug>: <what was broken, now works>
**Behind the scenes**
- <infra/refactor>, if worth a mention
```
## Rules
- House writing rules: no em/en dashes, no AI-tell triads, no hedge words,
active voice, one idea per line.
- Claim only what actually shipped. If it's on a branch and not merged/deployed, say so.
- Never invent a change that isn't in the diff. If the WHY isn't recoverable, describe the
what plainly rather than guessing intent.
Voir sur GitHub