| name | changelog |
| description | Create a changie changelog entry for a code change. Use when asked to add a changelog entry, record a change, or after completing a feature/fix/refactor. |
| argument-hint | [description of the change] |
Create a changelog entry by writing a YAML file to .changes/unreleased/.
Changie configuration
This project uses changie for changelog management. The configuration is in .changie.yaml.
Available kinds
Choose the most appropriate kind for the change:
| Kind | Auto bump | Use for |
|---|
Added | minor | New features, new API surface |
Fixed | patch | Bug fixes |
Performance | patch | Performance improvements |
Changed | patch | Changes to existing behavior, MSRV bumps |
Reverted | patch | Reverted changes |
Dependencies | patch | Dependency updates |
Security | patch | Security fixes |
File format
Each entry is a YAML file in .changes/unreleased/ with this structure:
kind: Added
body: |-
Short summary of the change
Optional longer description with more detail. This can be multiple lines.
Lines in the same paragraph are joined with spaces in the rendered changelog.
time: 2026-03-14T00:00:00.000000-08:00
File naming
Use the pattern: {Kind}-{slug}.yaml
- The slug should be a short kebab-case description of the change
- Examples:
Added-message-support.yaml, Fixed-cache-race-condition.yaml, Dependencies-bump-semver.yaml
Body format
The body field uses a block scalar (|-). The first line is the summary (rendered as an #### heading in the changelog). Subsequent lines form an optional description paragraph.
- First line: concise summary of the change (acts as heading)
- Remaining lines: optional detailed explanation
- Keep it useful for consumers of the crate — focus on what changed and why it matters
Time field
Use the current UTC time. Generate the timestamp with:
date -u +"%Y-%m-%dT%H:%M:%S.%N+00:00"
CRITICAL: Do NOT use date +%z — it produces +0000 (no colon), which changie cannot parse. The offset must be Z or ±HH:MM (with colon). Always hard-code +00:00 for UTC as shown above.
Instructions
- Determine the appropriate
kind based on the nature of the change
- Write a clear, user-facing summary as the first line of
body
- Optionally add a longer description on subsequent lines
- Create the YAML file in
.changes/unreleased/ with the naming convention above
- If
$ARGUMENTS is provided, use it to inform the changelog entry content
$ARGUMENTS
