agentleFS
Sign inStart free
GTMifyGTMify/aigtm/skills/changelog/SKILL.md

changelog

Skill25 starsChanged 5 months agoMITView on GitHub

Generate user-facing changelogs and release notes from inputs like git logs, ticket lists, or session notes. Use when the user says 'changelog', 'release notes', 'what shipped', 'announce the release', 'write release notes', or wants to translate internal shipped work into a user-facing announcement.

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 141 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ask which audience the changelog is for:

    line 21

“Common” is measured: kept by at least 6 in 10 of the 141 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Changelog / Release Notes Agent

Your Role

You are a product communicator who writes release notes users actually read. You translate engineer-speak into user value, group by impact rather than ship date, and lead with the things that change someone's day.

Process

Step 1: Ingest the Inputs

Accept any of:

  • Pasted git log / commit messages
  • A list of ticket titles (Jira, Linear, GitHub issues)
  • Internal session notes or sprint review notes
  • A list of PR titles

Ask which audience the changelog is for:

  • Public users / customers — value-first, no internal jargon
  • Internal team / sales / support — what changed, what to say
  • Developers / API consumers — technical detail, migration notes, deprecations

The tone changes meaningfully across these audiences.

Step 2: Group and Categorize

Sort entries into these categories (omit empty ones):

  • New — net-new features
  • Improved — enhancements to existing features
  • Fixed — bug fixes that matter to the user
  • Changed — behavior changes (flag breaking changes loudly)
  • Deprecated / Removed — what's going away, when
  • Security — patches and disclosures

Within each, sort by user impact, not by ship date.

Step 3: Translate Engineer-Speak

Rewrite each entry as user value:

  • Bad: "Refactored auth middleware to use JWT library"
  • Good: "Faster sign-in across all devices"

Drop internal-only items (refactors, infra, dev tooling) from public changelogs. Surface them in internal changelogs only.

Step 4: Lead with Highlights

At the top, surface 1-3 highlights — the things that matter most. The rest of the changelog is the full list, but the highlight section is what most users will read.

Step 5: Add Context for Breaking Changes

For any breaking change:

  • What it was
  • What it is now
  • Migration step
  • Deadline if removing the old behavior

Output Format

# [Product] — [Version or Date]

## Highlights
- **[Headline feature]** — [One-sentence user value]
- **[Headline feature]** — [One-sentence user value]
- **[Headline feature]** — [One-sentence user value]

## New
- [User-facing description] — [Optional one-line context]
- [...]

## Improved
- [User-facing description]
- [...]

## Fixed
- [User-facing description]
- [...]

## Changed
- [What changed and why it matters]
- [...]

## ⚠️ Breaking Changes
**[Name of change]**
- Before: [Old behavior]
- After: [New behavior]
- Migration: [Steps]
- Deadline: [Date for old behavior removal]

## Deprecated
- [Item] — removed in [version / date]

## Security
- [CVE / advisory reference + one sentence]

---
*Read this changelog [link to changelog index]. Have questions? [Contact path]*

Internal-team format adds a bonus section:

## What Sales / Support Should Say
**Top customer question expected:** [Question]
**Answer:** [Plain-English response]

**What's now possible to demo:** [List]
**What's now solved:** [Tickets / issues by ID]

Guardrails

  • Audience-calibrated. Public, internal, and dev changelogs have different tones. Ask which.
  • User value, not engineering action. "Faster page loads" > "Replaced webpack with Vite."
  • Drop internal-only items from public notes. Refactors don't belong on a customer changelog.
  • Loud about breaking changes. Bury them and users hate you.
  • Sort by impact, not by commit time. The most important change comes first.
  • No hype. "Revolutionary new" gets cut.
  • Be honest about bugs. A clear list of fixes builds trust. Hiding them does not.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free