changelog-generator

---
name: changelog-generator
description: Draft Rove release notes as Changesets. Writes user-facing entries as `.changeset/*.md` files for `@sma1lboy/rove` (consumed into `packages/kobe/CHANGELOG.md` at release time). Use when the user asks for "changelog", "release notes", "what changed", "add a changeset", or before cutting a version. Enforces Rove's no-soft-wrap rule so GitHub release pages render flowing text.
metadata:
  internal: true
---

<!-- Adapted from https://github.com/ComposioHQ/awesome-claude-skills/blob/master/changelog-generator/SKILL.md -->

# Changelog Generator (Rove)

Drafts release notes as **Changesets** — one `.changeset/<name>.md` file per change — in Rove's house style. The release (via `changeset version`) later consumes them into [`packages/kobe/CHANGELOG.md`](../../../packages/kobe/CHANGELOG.md) and the GitHub release body. See [`docs/RELEASING.md`](../../../docs/RELEASING.md) for the full flow.

## When to use

- The user says "draft changelog", "write release notes", "add a changeset", "what changed since v0.X.Y", or similar.
- After landing a user-facing change that has no changeset yet (e.g. it was committed before this skill existed, or in a batch that skipped them).
- Before cutting a release tag — to backfill changesets for anything user-facing that slipped through, so the generated notes are complete.

## Rove project conventions (load-bearing)

### File format — a changeset, not a CHANGELOG edit

- Do **not** hand-edit `packages/kobe/CHANGELOG.md` or invent a `## [Unreleased]` section — that file is generated.
- Each change is a new file `.changeset/<two-words-random>.md` (the `changeset` CLI names it; if writing by hand, any unique kebab name works). Shape:

  ```markdown
  ---
  "@sma1lboy/rove": patch
  ---

  Single-line user-facing summary. This text lands verbatim under the next release and in the GitHub release body.
  ```

- The canonical frontmatter bump key is `@sma1lboy/rove`, with value `patch` | `minor` | `major`.
- Default to `patch` for every change, including features and pre-1.0 breaking changes. Use `minor` or `major` only when the user explicitly requests that bump in the current turn.
- The bump type *is* the category — Changesets groups output under `### Minor Changes` / `### Patch Changes` automatically. Don't write `### Added`/`### Fixed` headings yourself.
- One changeset per coherent change. A batch that did three user-visible things → three changesets (or one with three bullets if they're one feature). Prefer the `changeset` CLI: `bun run changeset` (interactive) writes the file for you.

### **HARD RULE — no soft wraps**

Every bullet, every paragraph in a changeset body must be on a **single line**. Do not wrap at column 70/80/whatever. The line can be 400 chars long; that's fine.

**Why:** GitHub renders release bodies with GFM's hard-break extension. Each newline inside a list item or paragraph becomes a `<br>` tag. Soft-wrapped text renders as a narrow column broken every ~70 chars on the live release page, which looks broken.

### Voice

- Present tense, user-perspective. "Add X", "Fix Y", "Move Z" — not "Added X", not "I added X".
- Lead with what changed, not why. The why goes in a follow-up clause if it's non-obvious.
- Short bold lead-in for headlines (`**The thing** — explanation...`) is the established pattern.
- Reference internal anchors with backticks (\`task.new\`, \`ctrl+,\`, \`packages/kobe/src/foo.ts\`) rather than prose.

### Filtering

Pull in: features, behaviour changes the user can see/feel, bug fixes affecting user-visible behaviour, distribution / packaging / install changes.

Skip: pure refactors, internal test additions (UNLESS a milestone), CLAUDE.md / docs / skills / memory / agent-config tweaks, dependency bumps with no behaviour delta, CI tweaks (unless a new gate the user cares about). A change that needs no release can still record that explicitly with `bun run changeset -- --empty`.

When in doubt, ask "would a Rove user reading this on github.com/Sma1lboy/rove/releases care?" If no → skip (or empty changeset).

## How to draft

1. Find the cut point: the latest `## [<version>]` heading in `packages/kobe/CHANGELOG.md`, or the last `v*` tag.
2. Run `git log --no-merges <last-tag>..HEAD --pretty=format:'%h %s%n%b%n---'` to get the commit set, and check `.changeset/*.md` for changes that already have one (don't duplicate).
3. Group the *un-covered* user-facing changes. Write one changeset file per coherent change, each with the right bump type and a single-line summary per the rules above.
4. Prefer `bun run changeset` so the CLI writes the file; only hand-author the `.changeset/<name>.md` if scripting a batch.
5. Commit each changeset with the change it describes, and list the files in your report.

## Example output (a changeset file)

`.changeset/swift-pandas-cheer.md`:

```markdown
---
"@sma1lboy/rove": patch
---

**The Tasks pane fills its tmux pane and adapts to its width** — the task list now stretches to 100% of the pane as you drag the tmux split. On a narrow pane the secondary columns step aside so the task name stays readable: the branch label drops first, then the changes chip, and the title ellipsises only when it must.
```

Note: the summary is one long line. No newlines inside it. That's the only reliable way to make the GitHub release page render flowing text.

## What to avoid

- ❌ Hand-editing `packages/kobe/CHANGELOG.md` or recreating a `## [Unreleased]` section — it's generated from changesets.
- ❌ Soft-wrapping a changeset summary at column 70 because "it looks nicer in the editor". Render-time soft-wrap exists for a reason.
- ❌ Changesets like "Refactor X to use Y pattern" — internal change, skip (or `--empty`).
- ❌ Auto-generating from `git log` without filtering. Most commits are noise.
- ❌ Touching the version number in `package.json` — `changeset version` (run at release time) owns that.

More agent context in Sma1lboy/rove

19 other files this repository gives its agents.