home / skills / microck / ordinary-claude-skills / prepare-changelog

prepare-changelog skill

/skills_all/prepare-changelog

This skill guides you in creating Keep a Changelog style release notes for nextest, with user-visible changes and clear formatting.

npx playbooks add skill microck/ordinary-claude-skills --skill prepare-changelog

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
8.0 KB
---
name: prepare-changelog
description: Guidelines for preparing changelog entries for nextest releases following Keep a Changelog format
---

# Changelog Format Guide

This document describes the format and conventions used in `site/src/changelog.md`.

## Overall Structure

The changelog follows the [Keep a Changelog](https://keepachangelog.com/) format with nextest-specific conventions.

### Version Header

```markdown
## [X.Y.Z] - YYYY-MM-DD
```

- Version numbers are in brackets
- Date is in ISO 8601 format (YYYY-MM-DD)
- Each version should have a corresponding link at the bottom of the file (though this is often omitted for newer entries)

## Section Organization

Sections should appear in this order (only include sections that are relevant):

1. **Added** - New features
2. **Changed** - Changes to existing functionality
3. **Fixed** - Bug fixes
4. **Deprecated** - Soon-to-be removed features
5. **Removed** - Removed features
6. **Security** - Security-related changes
7. **Known issues** - Known problems with this release
8. **Miscellaneous** - Other notable changes that don't fit elsewhere
9. **Internal improvements** - Internal changes that may interest contributors

### Section Style

- Use `###` for section headers (e.g., `### Added`)
- Each section contains bullet points starting with `-`
- Indent sub-bullets with two spaces

## Content Guidelines

### What to Include

- User-visible changes and new features
- Bug fixes that affect users
- Performance improvements
- Breaking changes (clearly marked)
- MSRV (Minimum Supported Rust Version) changes
- Security updates

### What to Exclude

- Internal dependency updates
- Internal refactoring (unless it has user-visible effects)
- Documentation-only changes to the site
- CI/CD workflow changes
- Dependency updates for minor versions (can be grouped)

### Writing Style

1. **Be concise but descriptive**: Each bullet should clearly explain what changed and why it matters
2. **Use present tense**: "Nextest now supports..." not "Nextest now supported..."
3. **Link to documentation**: When introducing features, link to relevant docs with the full URL path
4. **Include context**: Explain the motivation or benefit when it's not obvious

### Examples

Good:
```markdown
- Nextest can now update itself! Once this version is installed, simply run `cargo nextest self update` to update to the latest version.
```

Good (with note to distributors):
```markdown
- Nextest now sets `NEXTEST_LD_*` and `NEXTEST_DYLD_*` environment variables to work around macOS System Integrity Protection sanitization.
  > Note to distributors: ...
```

Good (with forward-looking context):
```markdown
- A new `threads-required` configuration that can be specified as a per-test override. This can be used to limit concurrency for heavier tests, to avoid overwhelming CPU or running out of memory.
```

## Links and References

### PR and Issue Links

- Use inline links: `([#2618])`
- Define the link at the end of the section or version: `[#2618]: https://github.com/nextest-rs/nextest/pull/2618`
- For pull requests, use the `/pull/` URL
- For issues, use the `/issues/` URL

### External Links

- Use inline markdown links: `[text](URL)`
- Examples: `[GHSA-xxxx](https://github.com/advisories/GHSA-xxxx)`, `[CVE-xxxx](https://nvd.nist.gov/vuln/detail/CVE-xxxx)`

## Contributor Attribution

### First-time Contributors

Always thank first-time contributors using this format (use GitHub username only, not full name):

```markdown
Thanks [username](https://github.com/username) for your first contribution!
```

Place the attribution:
- At the end of the bullet point if it's a single change
- At the end of the section if multiple related changes

Examples:
```markdown
- New feature that does something. Thanks [alice](https://github.com/alice) for your first contribution!
```

```markdown
### Added

- Feature A
- Feature B

Thanks [bob](https://github.com/bob) for your first contribution!
```

### Returning Contributors

For contributors who have contributed before, you can optionally thank them but don't say "first contribution":

```markdown
Thanks [charlie](https://github.com/charlie) for your contribution!
```

Or simply:
```markdown
Thanks [charlie](https://github.com/charlie)!
```

### Multiple Contributors

When multiple people contributed to a feature:
```markdown
Thanks [alice](https://github.com/alice) and [bob](https://github.com/bob) for your contributions!
```

## Special Notations

### Notes to Distributors

Use blockquotes for notes to distributors or package maintainers:

```markdown
> Note to distributors: you can disable self-update by building cargo-nextest with `--no-default-features`.
```

### Upcoming Changes

For warning about future behavior changes:

```markdown
### Upcoming behavior changes

If no tests are run, nextest will start exiting with the advisory code **4** in versions released after 2024-11-18. See [discussion #1646](https://github.com/nextest-rs/nextest/discussions/1646) for more.
```

### Experimental Features

Clearly mark experimental features:

```markdown
- Experimental support for [feature name](link). Please try them out, and provide feedback in the [tracking issue](link)!
```

### Breaking Changes

If a release contains breaking changes, consider adding a note at the top:

```markdown
This is a major release with several new features. It's gone through a period of beta testing, but if you run into issues please [file a bug]!
```

## Formatting Conventions

### Code and Commands

- Use backticks for inline code: `` `cargo nextest run` ``
- Use triple backticks for code blocks with language specification: ` ```toml `, ` ```bash `

### Configuration Examples

When showing configuration:

```markdown
For example, to time out after 120 seconds:

  ```toml
  slow-timeout = { period = "60s", terminate-after = 2 }
  ```
```

Note the indentation for the code block within a bullet point.

### Environment Variables

- Use all caps with backticks: `` `NEXTEST_RETRIES` ``
- Use the format `` `NAME=value` `` when showing how to set them

### Version References

- Cargo versions: "Cargo 1.87"
- Rust versions: "Rust 1.64"
- Nextest versions: "nextest 0.9.100" or "version 0.9.100"

## Dependency Updates

List major dependency updates or security updates separately:

```markdown
- Update rust-openssl for [CVE-2025-24898](https://nvd.nist.gov/vuln/detail/CVE-2025-24898).
```

## Examples of Well-Formed Entries

### Simple Feature Addition

```markdown
### Added

- A new `--hide-progress-bar` option (environment variable `NEXTEST_HIDE_PROGRESS_BAR`) forces the progress bar to be hidden. Thanks [Remo Senekowitsch](https://github.com/remlse) for your first contribution!
```

### Complex Feature with Documentation

```markdown
### Added

- Nextest now supports assigning [test priorities](https://nexte.st/docs/configuration/test-priorities) via configuration.
```

### Bug Fix with Issue Link

```markdown
### Fixed

- Fixed an occasional hang on Linux with [libtest JSON output](https://nexte.st/docs/machine-readable/libtest-json/). For more details, see [#2316].

[#2316]: https://github.com/nextest-rs/nextest/pull/2316
```

### Breaking Change

```markdown
### Changed

- If nextest is unable to parse `--target` (and in particular, a custom target), it now fails rather than printing a warning and assuming the host platform. This is being treated as a bugfix because the previous behavior was incorrect.
```

## Determining What Changed

To generate a changelog entry:

1. Get the commit list: `git log <previous-tag>..main --oneline`
2. Review each commit to determine if it's user-visible
3. Group related commits together (e.g., multiple USDT commits into one feature)
4. Check for first-time contributors: `git log --all --author="Name" --oneline | wc -l`
5. Get PR author GitHub username: `gh pr view <number> --json author --jq '.author.login'`
6. Examine key commits for context: `git show <commit> --stat`

Filter out:
- Documentation site updates (unless they document new features)
- CI configuration changes
- Internal refactoring without user impact
- Most dependency updates (group them together)

Overview

This skill provides concise guidelines for preparing changelog entries for nextest releases using the Keep a Changelog format. It codifies version header rules, section order, writing style, link conventions, contributor attribution, and examples so entries are consistent and useful. Use these rules to produce clear, user-focused release notes for nextest projects.

How this skill works

The guide inspects release content and tells you which items to include, how to organize them into standard sections (Added, Changed, Fixed, etc.), and how to format headers, dates, links, and contributor attributions. It also defines what to exclude (internal-only changes) and provides examples and special notations for distributors, upcoming changes, experimental features, and breaking changes.

When to use it

  • When drafting a new nextest release note or converting raw commit/PR information into a changelog entry
  • When reviewing or editing changelog drafts to ensure consistent format and clarity
  • When preparing release notes that must include PR/issue links and contributor acknowledgements
  • When classifying changes as user-visible versus internal and deciding what to omit
  • When adding security, MSRV, or breaking-change notices that require precise phrasing

Best practices

  • Start each version with '## [X.Y.Z] - YYYY-MM-DD' using ISO 8601 dates
  • Only include sections that are relevant and keep the section order consistent
  • Write concise, present-tense bullets that explain what changed and why it matters
  • Link PRs and issues inline and define link references at the end of the section or file
  • Thank first-time contributors by GitHub username and place attribution per guidelines
  • Exclude purely internal refactors, minor dependency bumps, and CI-only changes

Example use cases

  • Convert a set of merged PRs since the last tag into a clean 'Added' and 'Fixed' list
  • Document a breaking change up top and provide migration notes and links to issues
  • Add a security section with CVE or advisory links and affected versions
  • Prepare a release note that includes MSRV changes and environment-variable examples
  • Draft a distributor note using a blockquote to explain packaging nuances

FAQ

Should I include every merged PR in the changelog?

No. Include user-visible changes, bug fixes, performance or security updates; omit internal refactors, minor dependency bumps, and CI-only updates.

How do I credit first-time contributors?

Thank them using their GitHub username and link, e.g., 'Thanks [username](https://github.com/username) for your first contribution!' at the end of the bullet or section.