| name | whats-new |
| description | Build or refresh a "What's New" digest of recently merged pull requests across one or more GitHub repos. Use when asked to produce a changelog, release digest, or weekly "What's New" report from merged-PR history. |
What's New digest builder
Turns the merged pull requests of one or more GitHub repositories into a
human-readable "What's New" digest. You (the AI assistant) write the one-line
summaries; a person reviews and commits the result. Runs locally against the
GitHub API via gh. No server infrastructure.
This skill is repo-agnostic: point it at any repo(s) you can read with gh.
Prerequisites
gh installed and authenticated (gh auth status).jq for shaping JSON (optional but convenient).- Read access to the target repositories.
Inputs you need from the user
- repos — one or more
owner/name slugs (e.g. octocat/hello-world).
- cutoff — how far back to look. Default: 90 days. Or an explicit
ISO-8601 UTC start (e.g. a go-live date).
- output file — where the digest JSON should live (e.g.
whats-new.json,
or a site data file). Ask if not given.
Steps
-
Fetch merged PRs since the cutoff. For each repo, list PRs merged after
the cutoff. Example (adjust --search window and --limit as needed):
SINCE=$(date -u -d '90 days ago' +%Y-%m-%d 2>/dev/null || date -u -v-90d +%Y-%m-%d)
gh pr list --repo <owner/name> --state merged --limit 200 \
--search "merged:>=$SINCE" \
--json number,title,body,mergedAt,url,labels,author \
> /tmp/whats-new-<repo>.json
For an explicit cutoff, set SINCE to the ISO date directly. Repeat per
repo and concatenate. Note any repo that was empty or unreachable.
-
Deduplicate against any existing digest. If the output file already
exists, load it and skip PRs whose id (use repo#number or the PR URL) is
already present — never re-summarize an entry that's already written, so
reviewed wording stays put. Idempotency is the point.
-
Summarize each new PR. For every PR produce
{ "id", "repo", "category", "title", "summary", "mergedAt", "url" }:
category ∈ Feature | Fix | Performance | Docs | Maintenance. Use the
conventional-commit prefix in the title as a hint
(feat→Feature, fix→Fix, perf→Performance, docs→Docs;
chore/refactor/build/ci/test/style→Maintenance), but reclassify
from the actual PR body when that's clearer.summary: ONE plain-language sentence describing the change and, where
possible, its value to a user of the project. Strip issue numbers, internal
ticket refs, deploy/CI mechanics, and jargon. Write in an approachable,
community voice.title: keep the PR title, or supply a cleaner display title.
-
Write the digest. Merge the new entries into the output file (append to
the existing array, keep it sorted newest-first by mergedAt). Write valid
JSON; don't reorder or reword existing entries.
-
Report to the user: how many new entries were added, from which repos,
and covering which date range. Remind them to review the output file and
commit it. This skill does not deploy or publish — it only produces the data.
Notes
- Idempotent: PRs already in the file are never re-summarized.
- Windows: if
/tmp isn't writable, use a temp dir you can write to.
- Private/enterprise repos: work fine as long as
gh is authenticated for
them; the digest content is only as public as you choose to publish it.
- Adapt the schema to your target. If you're feeding a static-site data file
or a CHANGELOG, map the fields above onto that format in step 4.
