Menu
Maintain CHANGELOG.md in Keep a Changelog format by updating Unreleased and version sections with user-relevant changes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Uses Forze queue, pub/sub, and stream contracts with QueueSpec, PubSubSpec, StreamSpec, SQSDepsModule, RabbitMQDepsModule, Redis adapters, and Mock adapters. Use when producing, consuming, or testing async messages/events.
Implements Forze document and search access the kit-first way: DocumentFacade and SearchFacade over build_document_registry / build_search_registry, kit DTOs (DocumentIdDTO, ListRequestDTO, DocumentUpdateDTO), the query DSL, pagination, cache-aware DocumentSpec / SearchSpec, and the Postgres / Mongo / Firestore / Meilisearch backends behind them. Use when building data access features.
Optimize code only after a real, measured performance problem - distinguish macro (design-level) from micro (fine-tuned) performance, reach for data-structure and algorithm wins before micro-tweaks, profile to find real hotspots, and don't trade readability or adaptability for unmeasured speed. Use when optimizing code, reviewing performance suggestions, choosing "faster" constructs, or when the user mentions performance, optimization, speed, or efficiency.
Name variables, functions, classes, and modules well by avoiding known anti-patterns - single letters, abbreviations, types baked into names, missing units, "Base"/"Abstract" class names, and "Utils"/"Helper" grab-bags. Use when naming or renaming code, reviewing names in a diff, or when the user mentions naming, identifiers, variable names, readability, or that a name feels off.
Keep code flat and readable by limiting indentation depth, using guard clauses with early returns, and extracting nested blocks into well-named functions. Use when writing or refactoring code with deep nesting, pyramid-shaped if/else, arrow code, or when the user mentions nesting, indentation, guard clauses, early returns, extracting functions, cyclomatic complexity, or making code more readable.
Make code explain itself instead of relying on comments - name sub-expressions, extract complex conditions into well-named functions, lean on the type system, and reserve comments for the "why" the code cannot express. Use when writing or reviewing comments, refactoring hard-to-read logic, deciding whether a comment is needed, or when the user mentions comments, self-documenting code, or code readability.
| name | keep-a-changelog |
| description | Maintain CHANGELOG.md in Keep a Changelog format by updating Unreleased and version sections with user-relevant changes. |
This skill helps keep CHANGELOG.md accurate, current, and user-focused following Keep a Changelog format.
It is intended for maintaining changelog entries as the product evolves.
The agent helps update ## [Unreleased] and, when explicitly asked, prepare version sections in the changelog.
The human remains responsible for deciding when and how to cut a release.
CHANGELOG.md## [Unreleased]CHANGELOG.md should be updatedAdded, Changed, Deprecated, Removed, Fixed, SecurityUnreleased notes into a versioned changelog sectionCHANGELOG.mdCHANGELOG.md does not follow Keep a Changelog structureThe changelog must include only user-relevant product changes.
For this repository, that generally means:
src/The changelog must NOT include:
tests/)If a change does not affect how users import, use, or install the library, it should generally be excluded from the changelog.
Only include changes that are meaningful to library consumers.
Do not include:
CHANGELOG.md must remain in this structure:
## [Unreleased]
### Added### Changed### Deprecated### Removed### Fixed### Security## [X.Y.Z] - YYYY-MM-DD[unreleased]: ..., [0.1.1]: ...)The six categories above are the baseline. Additional semantic sections MAY be
introduced when a change does not fit the basics (for example a dedicated
### Security callout, or another clearly-named category). Add them only when
they improve clarity; do not invent categories for changes that already fit.
Important: Do not add or modify bottom reference links unless explicitly asked.
# wrong
- Something
- Something 2
# right
- Something
- Something 2
`like_this`) as sparingly as
possible — only for an essential identifier such as a symbol or flag. Prefer
plain prose.Use these types as defined by Keep a Changelog:
Additional rules:
UnreleasedWhen the user says "update changelog", "add to changelog", or provides a list of changes:
## [Unreleased].## [Unreleased] blockCHANGELOG.mdWhen the user explicitly asks to convert current changelog notes into a versioned section:
Use the target version X.Y.Z.
Use today's date in YYYY-MM-DD using the user's timezone.
Create a new section directly under Unreleased:
## [X.Y.Z] - YYYY-MM-DD
Move content from ## [Unreleased] into that new version section:
Reset ## [Unreleased] categories back to placeholder state (- ...)
Do not edit reference links at the bottom unless explicitly asked
Output the proposed changelog edits as a diff or updated blocks
When updating the changelog, always produce:
CHANGELOG.md changes (diff or updated sections)CHANGELOG.md current