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.
来源信息
- 仓库
- gavin844/claude-code-skills
- 最近来源活动
- 2026年10月5日 19:27
- 检测到的 SKILL.md 语言
- 英语
- 星标
- 0
- 分支
- 0
安装方式
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
检查来源文件
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
文件资源管理器
2 个文件正在显示 SKILL.md
SKILL.md
来源说明 · 只读预览- 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.
在 GitHub 查看