release-notes
Drafts clear, user-focused release notes by analyzing merged PR descriptions on GitHub.
Install
mkdir -p .claude/skills/release-notes-tariknz && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/11949" && unzip -o skill.zip -d .claude/skills/release-notes-tariknz && rm skill.zipInstalls to .claude/skills/release-notes-tariknz
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Generate user-facing release notes for a version by reading PR descriptions from GitHub. Use when the user asks to create or draft release notes.Key capabilities
- →Generate release notes for a given version tag or range
- →Fetch PR descriptions including title, body, and author from GitHub
- →Write release notes to a specified markdown file
- →Group related PRs under single headings in the Features section
- →Order changelog entries by commit type and PR number
- →Summarize the release content to the user
How it works
The skill uses 'gh' to retrieve merged PRs within a specified range, then reads their full descriptions to compile a human-readable changelog.
Inputs & outputs
When to use release-notes
- →Draft release notes for a version
- →Summarize recent project changes
- →Prepare documentation for end users
About this skill
Release Notes Generator
Generate release notes for the given version tag or range. The user will provide the version (e.g. v0.1.0) or a comparison range (e.g. v0.0.41...v0.1.0).
Arguments: $ARGUMENTS
Step 1: Get the PR list
Use gh to get all merged PRs in the release range. If the user provides a single version tag, find the previous tag to build the comparison range.
# Find the previous tag if needed
git tag --sort=-v:refname
# Get the commit range
git log <previous-tag>...<version-tag> --oneline
# Extract PR numbers from merge commits or commit messages
Step 2: Fetch every PR description
For each PR, fetch the title, body, and author using gh:
gh pr view <number> --json title,body,author
This is critical — do NOT write release notes from PR titles alone. You MUST read the full PR description body to understand what each change actually does.
Step 3: Write the release notes
Write the notes to /Users/tarik/Desktop/irdashies-demos/release-<version>.md.
Tone and audience
- User-facing — write for iRacing sim racers who use the app, not developers
- No technical jargon — no code references, function names, variable names, file paths, algorithm descriptions, hook names, or internal architecture details
- Describe what changed for the user — what they'll see, what they can now do, what's fixed from their perspective
- Keep it concise — one clear sentence per bullet point where possible
Document structure
## Features
### Feature Name (by @author)
Brief description of the feature.
- Bullet points describing what users can do
### ...more features...
### Performance Optimizations (by @author)
- Bullet points — describe the user-visible improvement (e.g. "smoother rendering"), not the implementation
### Bug Fixes
- **Short label** — one-line description of what was broken and what's fixed now (by @author)
### Changelog
- commit-prefix: title by @author in PR-URL
- ...
### New Contributors
- @user made their first contribution in PR-URL
**Full Changelog**: compare-URL
Grouping rules for the Features section
- Group related PRs together under a single heading (e.g. multiple standings fixes/features become "Standings Enhancements")
- Credit all contributing authors in the heading:
(by @author1 and @author2)or(by @author1, @author2, and @author3) - Use
**bold label**with em-dash for each bullet when a section has multiple items - Performance and bug fix sections are separate from features
Changelog ordering
Order the changelog entries by commit type, then by PR number within each group:
feat:— new featuresfix:— bug fixesperf:— performance improvementschore:— maintenance, deps, tests, refactors (mergerefactor:intochore:prefix)
What to include / exclude
- Include all PRs in the range
- For PRs with empty descriptions, use the title and your best judgement but keep it brief
- For dependabot PRs, just list them in the changelog — no feature/bugfix entry needed
- For documentation-only PRs (readme updates, storybook), just list in changelog
- Dev-only fixes (e.g. hot reload, dev refresh) go in Bug Fixes but note they're development-related
Step 4: Show the user
After writing the file, let the user know it's ready and give a brief summary of what's in the release.
When not to use it
- →When release notes need to be written from PR titles alone
- →When the output should include technical jargon like code references or internal architecture details
- →When the target audience is developers rather than end users
Limitations
- →It does not write release notes from PR titles alone; full PR description body is required.
- →It excludes technical jargon, code references, and internal architecture details from the output.
- →It is designed for iRacing sim racers, not developers.
How it compares
This skill automatically fetches PR details and structures release notes for end-users, unlike manually compiling changes from commit messages or PR titles.
Compared to similar skills
release-notes side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| release-notes (this skill) | 0 | 4mo | Review | Beginner |
| docs-write | 22 | 6mo | No flags | Beginner |
| content-research-writer | 15 | 10mo | No flags | Beginner |
| doc-coauthoring | 16 | 8mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
docs-write
metabase
Write documentation following Metabase's conversational, clear, and user-focused style. Use when creating or editing documentation files (markdown, MDX, etc.).
content-research-writer
ComposioHQ
Assists in writing high-quality content by conducting research, adding citations, improving hooks, iterating on outlines, and providing real-time feedback on each section. Transforms your writing process from solo effort to collaborative partnership.
doc-coauthoring
anthropics
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
research-grants
davila7
Write competitive research proposals for NSF, NIH, DOE, and DARPA. Agency-specific formatting, review criteria, budget preparation, broader impacts, significance statements, innovation narratives, and compliance with submission requirements.
teams-channel-post-writer
daymade
Creates educational Teams channel posts for internal knowledge sharing about Claude Code features, tools, and best practices. Applies when writing posts, announcements, or documentation to teach colleagues effective Claude Code usage, announce new features, share productivity tips, or document lessons learned. Provides templates, writing guidelines, and structured approaches emphasizing concrete examples, underlying principles, and connections to best practices like context engineering. Activates for content involving Teams posts, channel announcements, feature documentation, or tip sharing.
write-docs
tldraw
Writing SDK documentation for tldraw. Use when creating new documentation articles, updating existing docs, or when documentation writing guidance is needed. Applies to docs in apps/docs/content/.