From connect-tech
Generates Markdown release notes for the most recent release of a GitHub repository. Given a GitHub repo URL (or owner/repo), this skill finds the latest two releases, collects all PRs merged between them, categorizes each change as New / Improvement / Fix / Infra / Docs, and produces a clean, grouped Markdown file saved to the outputs folder. Use this skill whenever the user asks to "generate release notes", "write a changelog", "summarize what changed in the last release", "what was in the last release", or similar. Also trigger when the user provides a GitHub repo URL or owner/repo string alongside any mention of releases, PRs, or changelogs. The skill works for any public or private GitHub repo accessible via the user's `gh` CLI session.
npx claudepluginhub dimagi/dimagi-claude-workflows --plugin connect-techThis skill uses the workspace's default tool permissions.
You are generating release notes for the most recent release of a GitHub repository. The goal is a clean, human-readable Markdown summary of what changed — the kind of thing you'd send to stakeholders or post in a changelog.
Generates formatted changelogs from git history since last release tag, categorizing commits into breaking changes, features, fixes, and notes for GitHub releases. Use when preparing release notes.
Generates structured changelogs and release notes from git history and PRs, classifying breaking changes, features, fixes, performance, docs using conventional commits.
Generates human-friendly changelogs from git history between ref ranges, tags, or PRs. Follows Keep a Changelog format, polishes commit messages, and optionally creates GitHub Releases.
Share bugs, ideas, or general feedback.
You are generating release notes for the most recent release of a GitHub repository. The goal is a clean, human-readable Markdown summary of what changed — the kind of thing you'd send to stakeholders or post in a changelog.
The user will provide a GitHub repo — either as a full URL (https://github.com/owner/repo) or an owner/repo string. Extract the owner/repo identifier from whatever they provide.
If the user specifies a product name to use in the title, use that. For the dimagi/commcare-connect repo, the product name is "Connect" (not "CommCare Connect").
When writing user-facing release notes, use the correct user-facing terms — not internal code names:
| Use this | Not this |
|---|---|
| PersonalID | ConnectID |
If you encounter other code-level identifiers in PR titles or bodies, use your judgment: if it reads like an internal variable name or database field rather than a product concept, rephrase it into plain language.
gh release list --repo <owner/repo> --limit 5
Identify the latest release (most recent) and the previous release (the one before it). Note the tag names and published dates of both.
Use the published dates of the two releases to filter merged PRs:
gh pr list \
--repo <owner/repo> \
--state merged \
--search "merged:YYYY-MM-DD..YYYY-MM-DD" \
--json number,title,author,mergedAt,labels \
--limit 100
Use the previous release date as the start and the latest release date as the end.
For each PR, fetch the title and body to understand what it does:
gh pr view <number> --repo <owner/repo> --json title,body,labels
Read the body — not just the title — to get the actual description of what changed. The first few sentences of the body (often under a "Product Description" or similar heading) are usually the most useful.
Batch these requests efficiently — there's no need to fetch one at a time if you can parallelize.
Assign each PR one of these categories based on what it does:
New — A brand-new feature or capability that didn't exist beforeImprovement — An enhancement, refinement, or extension of something existingFix — A bug fix or correctionInfra — Infrastructure, performance, configuration, or DevOps changesDocs — Documentation-only changesThen group related PRs into logical sections by feature area (e.g., "Work Areas", "Notifications & Email", "Reporting"). If several PRs all touch the same feature, they belong in the same section. A section with only one item is fine. Don't force unrelated things together.
Skip PRs that are purely internal (e.g., dependency bumps, version bumps, CI config) unless they're meaningful to users.
Use this format:
# Release Notes — {Product Name} v{version}
*Released {date}*
---
## {Section Name}
**`New`** **Feature Title** — One or two sentence description of what changed and why it matters. [Screenshots](PR_URL)
**`Improvement`** **Feature Title** — Description.
---
## {Section Name}
**`Fix`** **Feature Title** — Description.
Guidelines:
[Screenshots](PR_URL). If there are relevant Confluence/docs links you know about, add them too. Don't make up links.Save the file to ./outputs/release_notes_{version}.md, creating the outputs/ directory if it doesn't exist.
Then tell the user the file path where the notes were saved.