Menu
Use when deciding changelog entries, maintaining [Unreleased], removing reverted unreleased entries, or preparing release version and changelog sections.
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
| name | changelog |
| description | Use when deciding changelog entries, maintaining [Unreleased], removing reverted unreleased entries, or preparing release version and changelog sections. |
Use this skill when a project has a CHANGELOG.md or equivalent release history.
Use normal mode for implementation, documentation, packaging, test, workflow, and behavior changes before release.
[Unreleased], leave VERSION unchanged, and leave dated release sections for release mode.[Unreleased].VERSION.CHANGELOG.md as a human-readable standalone text file. Do not collapse release notes into version-control compare links, commit lists, issue lists, or diff summaries. Compare links may supplement the prose, but they must not replace meaningful entries.[Unreleased] entry in the same change.Use release mode only when preparing a release.
[Unreleased] and choose or confirm the SemVer version from the accumulated entries.[Unreleased] to [MAJOR.MINOR.PATCH] - YYYY-MM-DD.[Unreleased] section.VERSION, to the same version.Use SemVer: MAJOR.MINOR.PATCH.
PATCH: bug fixes, refactors, documentation, tests, packaging metadata, validation-policy changes, or internal changes with no new user-visible capability and no breaking change.MINOR: new backwards-compatible user-visible capability.MAJOR: breaking changes to behavior, API, data format, command contract, or other external interface.When in doubt, treat a change that adds no new user-visible capability as PATCH.
Reject ordinary implementation commits that:
VERSION;[Unreleased];[Unreleased] entry without rationale.Reject release preparation that:
[Unreleased] entries duplicated in the release section;[Unreleased];VERSION, changelog heading, release notes, or tag version inconsistent.Use when changing what a running devloop harness serves — pointing it at a different directory or worktree, or making the live harness serve newer or different code (a newer commit, another branch, or in-progress edits) without a wasteful restart.
Use when verifying that a UI change works end to end by driving the running app in a real browser — confirming a fix, reproducing a reported UI symptom, or proving a wizard/form/flow behaves — with Playwright against the exact code under review.
Enforce a Roborev plus Kata development workflow for code changes. Use when Codex is asked to implement, fix, refactor, or review work tracked by Kata and Roborev, especially when branch discipline, non-blocking review jobs, validation gates, SemVer, changelog checks, and final delivery reporting matter.
Use when working on GitHub pull requests that need PR-ready validation, review-thread replies, reviewer mentions, linked external references, or merge readiness checks.
Create or review a standalone repository that publishes a set of Codex or Claude skills with shared validation, linking, eval, and agent metadata conventions.
Prepare small, reviewable local commits with explicit rationale, SemVer impact, task hygiene, branch cleanup expectations, and clear commit commentary. Use when asked to commit work, prepare a PR-ready change, decide version impact, write commit messages, or clean up merged feature branches.