agentleFS
Sign inStart free
ejwhite7ejwhite7/product-release-checklist/skills/changelog-automation/SKILL.md

changelog-automation

Skill0 starsChanged 35 days agoMITView on GitHub

Set up an automated, user-facing changelog on the marketing site, fed by repo releases, with a curation layer so internal or unreleased changes don't leak. Use when someone asks to automate the changelog, connect GitHub releases to the website, or write release notes for users.

14 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use linkerd-patterns, gitops-workflow and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • xfstudioSkill

    linkerd-patterns

    Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.

    Also in 4 projects that use this

  • xfstudioSkill

    gitops-workflow

    Implement GitOps workflows with ArgoCD and Flux for automated, declarative Kubernetes deployments with continuous reconciliation. Use when implementing GitOps practices, automating Kubernetes deployments, or setting up declarative infrastructure management.

    Also in 4 projects that use this

  • +10 more from xfstudio

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 14 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Add the PR template field and labels (user-facing, changelog:new|improved|fixed, changelog:hold).

    line 35
  2. Distinctive:

    Test with the last 3 releases as a dry run before turning on auto-PR.

    line 39

“Common” is measured: kept by at least 6 in 10 of the 14 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 Automation

The pitfall to design around

Raw repo releases aren't a changelog. They contain internal refactors and they leak unreleased or flagged features. Engineers also describe what changed in the code, while users need to hear what they can now do. On top of that, a "release" (deploy) isn't the same as availability: a feature can deploy behind a flag weeks before customers get it. The pipeline needs three things: a filter, a rewrite, and a human gate.

Target pipeline

PR merged with label  user-facing  (+ type: new | improved | fixed)
        │   PR template has a "Customer-facing note" field
        ▼
Release published (GitHub Release / tag)
        │   GitHub Action collects labeled PRs since the previous release
        ▼
Draft entry generated (Claude API rewrites notes into benefit-led copy,
grouped New / Improved / Fixed, links KB articles)
        │
        ▼
PR opened against the marketing-site repo (or a CMS draft created)
        │   PMM reviews; anything still flagged gets held back
        ▼
Merged → changelog page + RSS feed + (optional) in-app "What's new" feed
        │
        ▼
Monthly: T3 entries rolled up into a "What's new this month" post / email

Steps

  1. Inspect the repo: release process (tags, Releases, release-please, changesets), PR labels, and feature-flag tooling. Inspect the marketing site: framework or CMS (Next.js MDX, Webflow, Framer, Sanity, and so on) and where a changelog would live.
  2. Add the PR template field and labels (user-facing, changelog:new|improved|fixed, changelog:hold).
  3. Generate .github/workflows/changelog-draft.yml from reference/changelog-workflow.yml (in this skill's directory), adapted to the site's content format. The rewrite step uses the Claude API with the system prompt in reference/rewrite-prompt.md. Load the claude-api skill for the current model ID and SDK usage.
  4. Exclude PRs labeled changelog:hold, and PRs whose flag isn't on for the general audience (for example, check for a flag key in the PR body).
  5. Changelog page: one entry per release date, filters by type, permalink anchors, an RSS feed, and (optionally) a JSON endpoint for an in-app "What's new" widget. Each entry gets its own indexable URL for SEO.
  6. Test with the last 3 releases as a dry run before turning on auto-PR.

Get the user's confirmation before creating workflows, labels, or secrets in their repos.

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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