| name | release-notes |
| description | 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 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.