# Release Notes

> 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.

- Skill: `zrozoom/release-notes` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zrozoom/release-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zrozoom/release-notes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ZroZoom (https://skillmd.com/u/zrozoom)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zrozoom/release-notes

---


# 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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```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.