How do I install the Release Notes skill?

Run npx skillmds@latest add zrozoom/release-notes in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release Notes safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release Notes?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release Notes free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release Notes?

ZroZoom (@zrozoom) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release Notes by zrozoom — Agent Skill

Name: Release Notes
Author: ZroZoom

File contents

Release Notes Skill

Generate a bilingual changelog from merged PRs.

Contract

Inputs: optional --since <tag|date>, --until <date>, --target team|investors|both.
Output: markdown release notes in PL and EN.
Side effects: none unless the user asks to create a GitHub Release or commit a changelog.

Workflow

1. Resolve range

Prefer an explicit --since. Otherwise use the newest tag:

git fetch --tags origin
git tag --sort=-creatordate | head -5
git describe --tags --abbrev=0

If there are no tags, use the last merged release PR or a date confirmed by the user.

2. Collect merged PRs

For a tag range:

BASE_TAG=vX.Y.Z
BASE_DATE=$(git log -1 --format=%cI "$BASE_TAG")

gh pr list \
  --repo <OWNER>/<REPO> \
  --state merged \
  --search "merged:>=$BASE_DATE base:main" \
  --limit 500 \
  --json number,title,mergedAt,author,labels,url

Use --limit 500 for any range longer than a few days. Repos with merge queues, dependency groups, or automatic version bumps can exceed 200 merged PRs in a month. Confirm the count before writing notes:

gh pr list \
  --repo <OWNER>/<REPO> \
  --state merged \
  --search "merged:>=$BASE_DATE base:main" \
  --limit 500 \
  --json number \
  --jq 'length'

Also inspect commits if PR data is incomplete:

git log --oneline "$BASE_TAG"..HEAD

3. Group changes

Use title prefixes first, then labels:

Group	Signals
Features	`feat`, `enhancement`, user-visible additions
Fixes	`fix`, `bug`, regressions, production issues
Content	`content`, copy / docs changes
Tests and QA	`test`, `area: tests`, Playwright/Vitest/manual QA
Tooling	`chore`, `ci`, `tooling`, scripts, agent skills
Docs	`docs`, documentation-only changes

Exclude noise:

version bump PRs unless they are the release itself; collapse automatic bumps into a short Not included note and keep at most one bullet for the highest version reached
reverted PRs when the revert also merged in range
duplicate squash commits
grouped dependency bumps; list the count and impact once instead of enumerating every package bump

4. Write PL and EN outputs

Team format:

## Release notes PL

### Najważniejsze zmiany
- ...

### Funkcje
- ...

### Poprawki
- ...

### Testy i tooling
- ...

### Ryzyka i follow-up
- ...

Investor format:

## Release notes EN

### Highlights
- ...

### Product progress
- ...

### Quality and reliability
- ...

### Next risks
- ...

Rules

Keep every bullet traceable to a PR number.
Do not invent impact metrics.
Translate meaning, not commit prefixes.
Mention incomplete CI or unmerged PRs only in a separate Not included section.
If the range is ambiguous, ask for the range before generating final notes.

---name: release-notesdescription: Release notes generator. Collects merged PRs since the latest tag, groups by type, and emits Polish and English changelog markdown. Trigger when: /release-notes, changelog, release notes, notatki wydania.---# Release Notes SkillGenerate a bilingual changelog from merged PRs.## Contract- Inputs: optional `--since <tag|date>`, `--until <date>`, `--target team|investors|both`.- Output: markdown release notes in PL and EN.- Side effects: none unless the user asks to create a GitHub Release or commit a changelog.## Workflow### 1. Resolve rangePrefer an explicit `--since`. Otherwise use the newest tag:```bashgit fetch --tags origingit tag --sort=-creatordate | head -5git describe --tags --abbrev=0```If there are no tags, use the last merged release PR or a date confirmed by the user.### 2. Collect merged PRsFor a tag range:```bashBASE_TAG=vX.Y.ZBASE_DATE=$(git log -1 --format=%cI "$BASE_TAG")gh pr list \ --repo <OWNER>/<REPO> \ --state merged \ --search "merged:>=$BASE_DATE base:main" \ --limit 500 \ --json number,title,mergedAt,author,labels,url```Use `--limit 500` for any range longer than a few days. Repos with merge queues, dependency groups, or automatic version bumps can exceed 200 merged PRs in a month. Confirm the count before writing notes:```bashgh pr list \ --repo <OWNER>/<REPO> \ --state merged \ --search "merged:>=$BASE_DATE base:main" \ --limit 500 \ --json number \ --jq 'length'```Also inspect commits if PR data is incomplete:```bashgit log --oneline "$BASE_TAG"..HEAD```### 3. Group changesUse title prefixes first, then labels:| Group | Signals ||---|---|| Features | `feat`, `enhancement`, user-visible additions || Fixes | `fix`, `bug`, regressions, production issues || Content | `content`, copy / docs changes || Tests and QA | `test`, `area: tests`, Playwright/Vitest/manual QA || Tooling | `chore`, `ci`, `tooling`, scripts, agent skills || Docs | `docs`, documentation-only changes |Exclude noise:- version bump PRs unless they are the release itself; collapse automatic bumps into a short `Not included` note and keep at most one bullet for the highest version reached- reverted PRs when the revert also merged in range- duplicate squash commits- grouped dependency bumps; list the count and impact once instead of enumerating every package bump### 4. Write PL and EN outputsTeam format:```markdown## Release notes PL### Najważniejsze zmiany- ...### Funkcje- ...### Poprawki- ...### Testy i tooling- ...### Ryzyka i follow-up- ...```Investor format:```markdown## Release notes EN### Highlights- ...### Product progress- ...### Quality and reliability- ...### Next risks- ...```## Rules- Keep every bullet traceable to a PR number.- Do not invent impact metrics.- Translate meaning, not commit prefixes.- Mention incomplete CI or unmerged PRs only in a separate `Not included` section.- If the range is ambiguous, ask for the range before generating final notes.

Frequently asked questions

Release Notes