agentsclimarketplace
Sign in

Changeset writing

Skill segunadebayo/design-eng-skills/skills/changeset-writing

Use when writing a changeset for a change to a published package. Picking the semver bump, writing the summary, flagging breaking changes, and making sure the entry still reads well once aggregated into CHANGELOG.md.From its SKILL.md

Install
npx -y skills add segunadebayo/design-eng-skills --skill changeset-writing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, 676 tokens by cl100k_base, as published. Nobody here has run it

Changeset Writing

A changeset is a written intent to change, created while the change is fresh, versioned and merged into CHANGELOG.md later. Write it for the consumer reading the changelog after an upgrade, not for yourself reading the diff today.

0. Check what this repo already does

Look for an existing convention before applying this skill's defaults: a header in CHANGELOG.md declaring a format (Keep a Changelog, Common Changelog), an internal style guide, or just the shape of recent real entries. Match it. Only fall back to this skill's own defaults, described in references/CATEGORIZATION.md, if nothing exists yet.

1. Decide if this needs a changeset at all

Not every change does. Internal refactors, CI tweaks, dependency bumps with no observable effect, and doc-only changes don't need one. If a consumer would never notice or care, skip it. If you're unsure whether it's user-facing, that uncertainty is itself a sign to go check, not to default to writing one anyway.

2. Pick the semver bump

Patch, minor, or major, this is a judgment call with real edge cases: dependency-only bumps, experimental APIs, deprecations that don't remove anything yet, monorepo packages that only re-export another package's change. Full decision tree in references/BUMP-DECISIONS.md.

3. Write WHAT, WHY, and HOW

Three things, in order, every time: what changed, why a consumer should care, and (if it's not obvious) how they should react. Lead with a verb, imperative mood (Add, Fix, Remove, not Added, Fixed, Removed), name the exact API in backticks. Skip WHY and HOW when the WHAT is self-evident, don't pad a one-line fix into three sentences it doesn't need.

4. Flag breaking changes on purpose

A breaking change is not a bigger version of a normal entry, it's a different shape: what broke, why, and the exact migration step, not just a warning that something changed. Full template and real examples in references/BREAKING-CHANGES.md.

5. Check how it reads next to its neighbors

A changeset gets concatenated with every other changeset in the release. Read it once as if it's sitting between two other entries: does it repeat context they already established, does it use the same component/module name consistently, does it stay one line where the others are one line. Concrete before/after examples in references/EXAMPLES.md.

Sentence-level rules (no hype words, no em dashes, be specific, say what's rough) are the same ones engineering-writing uses. But there's no audience-diagnosis or narrative structure here, a changeset is a fact, stated precisely, not a story. The narrative writing, announcements, deep-dives, retrospectives, is engineering-writing's job, not this one.

What ships with it: 5 files

18.9 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most docs writing skills give in 676 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • Check existing changelog conventions first
  • Skip changesets for internal refactors
  • Determine semver bump type
  • Write what changed and why
  • Lead entries with imperative verbs
  • Name exact APIs in backticks

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.