--- name: github-release-notes-draft description: "Every Thursday: PRs merged since the last release, grouped by label into breaking, new, fixed and internal, and rewritten so a customer can follow them. Use when the user asks for this, or when it runs on a schedule." --- # GitHub release notes draft Every Thursday: PRs merged since the last release, grouped by label into breaking, new, fixed and internal, and rewritten so a customer can follow them. Release notes tend to get written the morning of the release, by scrolling merged PRs and translating titles like "fix: nil check in useOrgPlan" into something a customer understands. GitHub can list the titles for you, but titles are written for reviewers. The agent finds the last release, collects every PR merged since, groups them by label and rewrites each one as a line a user would follow, reading the PR body when the title is vague. It suggests the next version number and leaves publishing to you. ## Two ways to get the data Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used. ## Route A: API or MCP server ### What you need - Read access to the repo, and write access only if the agent should save a draft release. - The `gh` CLI signed in, or a GitHub MCP server or connector that can read releases and pull requests. If something is missing, say what and stop; do not invent numbers. ### Steps 1. **Find the last release** (GitHub): `gh release view --repo acme/acme-web --json tagName,publishedAt` returns the latest published release. If the team tags without GitHub releases, use `git describe --tags --abbrev=0` on the default branch instead. 2. **Collect merged PRs** (GitHub): `gh pr list --repo acme/acme-web --state merged --base main --search "merged:>2026-10-02T15:04:00Z" --json number,title,body,labels,author --limit 200`, with the timestamp taken from `publishedAt`. 3. **Group by label**: Map `breaking-change` to Breaking, `feature` or `enhancement` to New, `bug` to Fixed, and `chore` or `dependencies` to Internal. If the repo has a `.github/release.yml`, use its categories instead. Unlabeled PRs go on a separate list rather than into a guessed section. 4. **Rewrite each line**: One sentence per user-facing PR, from the user's side, with the PR number at the end: "Invoice dates now show in your workspace time zone (#1284)". Internal changes keep their titles. 5. **Draft, never publish** (GitHub): Write Markdown with a suggested version: major if anything is breaking, minor for features, patch for fixes only. If you allow writes, save it with `gh release create v2.15.0 --draft --notes-file notes.md`; never publish the release. ## Route B: the browser ### What you need - Signed in to GitHub with read access to the repository, and write access only if the agent should save a draft release. If something is missing, say what and stop; do not invent numbers. ### Steps Start at https://github.com/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears. 1. **Find the last release**: Go to `github.com///releases`. The top entry is the latest published release; note its tag and hover the relative date for the exact publish time. If the team tags without releases, use the **Tags** tab instead. 2. **Collect merged PRs**: Open **Pull requests** and search `is:pr is:merged base:main merged:>2026-10-02T15:04:00Z` with the publish time from the previous step. Read every page, noting number, title, author and labels, and open PRs whose titles are vague to read the body. 3. **Get GitHub's own grouping as raw material**: On Releases click **Draft a new release**, type the next tag, and click **Generate release notes**: GitHub lists the PR titles under the categories of `.github/release.yml`, with new contributors at the end. Treat it as the input, not the output. 4. **Group and rewrite**: Map `breaking-change` to Breaking, `feature` or `enhancement` to New, `bug` to Fixed, `chore` or `dependencies` to Internal; unlabeled PRs go on their own list. One plain sentence per user-facing PR with its number at the end. 5. **Draft, never publish**: Suggest the version (major for breaking, minor for features, patch for fixes only). If you want the draft saved, paste the Markdown into the release form and click **Save draft**; never click **Publish release**. Note: The pull request list shows 25 per page. **Generate release notes** only groups by the categories in `.github/release.yml` and keeps the raw titles, which is why the rewrite step is still needed. ## The report - **Suggested version** and the reason (major, minor or patch). - **Breaking**, **New**, **Fixed** and **Internal** sections, one plain line per PR with its number. - **Needs a label**: PRs it could not place. - **Contributors**, by GitHub handle. ## Post it to Briefkin When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on. ```bash [ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \ -H "authorization: Bearer $BRIEFKIN_TOKEN" \ -H "content-type: application/json" \ -d @- <<'JSON' { "v": 1, "event_id": "github-release-notes-draft/", "item_key": "github-release-notes-draft", "project": "acme-web", "source": "GitHub release notes draft skill", "kind": "update", "title": "Release notes for v2.15.0 drafted from 14 PRs", "summary": "4 new features, 6 fixes and 3 internal changes since **v2.14.2**. One PR has no label yet.", "widget": [ { "type": "Badges", "props": { "items": [ { "label": "New 4", "tone": "accent" }, { "label": "Fixed 6", "tone": "ok" }, { "label": "Internal 3" }, { "label": "Unlabeled 1", "tone": "warn" } ] } }, { "type": "Table", "props": { "columns": [ "Section", "Line" ], "rows": [ [ "New", "Export the audit log as a CSV from Settings > Security (#1302)" ], [ "New", "Set a default currency for each workspace (#1276)" ], [ "New", "Settings pages open without a full page reload (#1297)" ], [ "Fixed", "Invoice dates show in your workspace time zone (#1284)" ], [ "Fixed", "CSV exports keep commas inside quoted fields (#1290)" ], [ "Fixed", "Saving a plan no longer fails when billing is busy (#1293)" ] ] } }, { "type": "Text", "props": { "text": "One more feature, 3 more fixes and the internal changes are in the full draft.", "variant": "muted" } }, { "type": "Callout", "props": { "text": "#1305 \"misc cleanup\" has no label: file it under Fixed or Internal before publishing.", "tone": "warn" } } ] } JSON ``` Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report. ## Run it on a schedule Suggested: Thursdays at 14:00 (`0 14 * * 4`). From cron, with the agent signed in on that machine: ```bash 0 14 * * 4 claude -p "Run the github-release-notes-draft skill" # Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run ``` Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/github-release-notes-draft#schedule Source: https://briefkin.dev/skills/github-release-notes-draft