Open-sourcing release-kit: Claude Code Skills for Shipping

Open-sourcing release-kit: Claude Code Skills for Shipping

Every time you ship some code, there's a stretch of work that has nothing to do with writing code. Update the changelog. Write release notes that make sense to users. Draft a tweet and LinkedIn post. It's not hard, but it's tedious, and I've watched it quietly eat up time across my personal projects, as well as at work.

So I built release-kit, a set of Claude Code skills that automate the whole process. You tell Claude to update your changelog, write release notes, or draft an announcement, and it figures out what actually changed by analyzing your diffs, PRs, issues, and test descriptions, not just your commit messages.

Let me walk through what it does and why I built it the way I did.

The Problem with Commit Messages

Here's a real scenario. You've been heads-down for a week, and your commit history looks like this:

fix stuff
wip
update deps
john's changes
PR #89

Now try writing a coherent changelog from that. You can't. And yet, most changelog generators just scrape commit messages and call it a day. The result is either useless or requires you to go back and rewrite everything anyway.

The actual information about what changed lives in other places: PR titles and descriptions, closed issues, test names that describe behavior, file paths that reveal which features were touched, and the diff itself. Commit messages are the least useful signal.

What Are Claude Code Skills?

Before diving into release-kit, a quick primer. Skills are markdown files that give Claude Code specialized knowledge for specific tasks. You drop them into your project's .claude/skills/ directory, and Claude Code automatically applies the right skill when it recognizes a matching task.

Think of them as reusable prompts with domain expertise baked in. Instead of writing a long, detailed prompt every time you want a changelog, you install the skill once, and from then on you just say "update the changelog" naturally.

The Three Skills

release-kit ships three skills that cover the full release communication pipeline:

1. Changelog

Generates CHANGELOG.md entries in Keep a Changelog format. It categorizes changes into Added, Changed, Deprecated, Removed, Fixed, and Security sections.

"Update the changelog for v2.4.0"

Produces:

## [2.4.0] - 2025-01-15

### Added
- Add bulk CSV export for all report types
- Add keyboard shortcuts for common actions

### Fixed
- Fix crash when opening files larger than 2GB
- Fix incorrect totals on the billing summary page

2. Release Notes

Generates user-friendly release notes suitable for GitHub Releases, app stores, or internal distribution. The output is structured with a headline, features, improvements, and bug fixes. Written for users, not developers.

"Write release notes for everything since the last tag"

3. Announce

Drafts social media posts for Twitter/X and LinkedIn. It picks the most compelling change to lead with and formats each post for its platform: under 280 characters for Twitter, 3-5 paragraphs for LinkedIn.

"Draft a tweet and LinkedIn post announcing v3.0"

You can also invoke any of these directly with slash commands: /changelog, /release-notes, /announce.

How Context Gathering Works

The core design decision behind release-kit is how it gathers context. Each skill follows the same signal hierarchy, ordered by usefulness:

  1. PR titles and descriptions - Usually the best summary of what a change does and why
  2. Closed issues - Reveal user-reported problems that were fixed
  3. Test descriptions - Names like it('should allow bulk export') directly describe behavior
  4. File and folder paths - Reveal which features or modules were affected
  5. The diff itself - The ground truth of what changed
  6. Config and dependency changes - Surface new integrations or breaking updates
  7. Commit messages - Checked last, often the least useful signal

This ordering matters. When a PR title says "Add real-time collaboration" but the commits say "wip" and "fix stuff," the skill knows to trust the PR.

Each skill determines the version range automatically using git tags, then queries GitHub's API for PRs and issues merged or closed since the last release. It reads the actual diff for source files, ignoring lockfiles and minified assets. It even checks test files for new describe and it blocks that hint at what was added.

Writing for Humans

One thing I spent time on was the writing rules embedded in each skill. The instructions push Claude away from developer-speak and toward user benefit:

  • "Add bulk CSV export for reports" instead of "Implement exportToCsv utility function"
  • "Search results now load 3x faster" instead of "Improve performance"
  • "Fix crash when opening files larger than 2GB" instead of "Fix file handling bug"

The skills also filter aggressively. Internal refactors, CI config changes, test improvements, and dependency bumps all get skipped unless they have user-facing impact. The goal is a changelog that someone actually wants to read.

Installation

The simplest way to install is through the Claude Code CLI:

claude install-skill tilomitra/release-kit/changelog
claude install-skill tilomitra/release-kit/release-notes
claude install-skill tilomitra/release-kit/announce

Or install all skills at once via skills.sh:

$ npx skills add tilomitra/release-kit

You can also clone the repo and copy the skill directories into .claude/skills/, or add it as a git submodule for easy updates.

Why I Built This

I've been using Claude Code daily for development, and skills felt like the right abstraction for this problem. Release communication is repetitive, follows clear patterns, and benefits from deep context about the codebase. Those are exactly the conditions where a well-crafted skill shines.

The alternative is either doing it manually every release (tedious), using a conventional-commit-based tool that only reads commit messages (insufficient), or writing a long prompt from scratch every time (repetitive). Skills let you encode the expertise once and reuse it forever.

I've been running these skills on my own projects for a while now, and they consistently produce release notes that I'd ship with minimal edits.

Contributing

If you have ideas for new skills or improvements to existing ones, PRs are welcome. Each skill is just a markdown file in its own directory, so contributing is straightforward: no build step, no dependencies, just edit the SKILL.md and submit.

Check out the repo on GitHub and give it a try next time you ship a release. ✌️