메뉴
Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | changelog |
| description | Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…". |
| version | 1.0.0 |
| license | MIT |
| keywords | ["changelog","release","git","keep-a-changelog","semver"] |
A changelog is for users deciding whether to upgrade, not a commit dump. Format: Keep a Changelog + semver sections.
Find the range. Last release tag: git describe --tags --abbrev=0.
Collect commits since: git log <tag>..HEAD --oneline --no-merges.
Bucket each commit:
Added (feat) · Fixed (fix) · Changed (behavior changes, perf)Deprecated · Removed · Securitychore/ci/test/docs noise unless user-visible.Rewrite each line user-first. Translate implementation into impact:
fix(ingest): treat mtime regressions as editsFixed duplicate chunks after restoring files from backup.
One line each; link the PR/issue number when the repo uses them.Squash threads. Five commits iterating on one feature = one entry.
Pick the version bump from the buckets: breaking → major, Added → minor, only Fixed → patch (pre-1.0: breaking → minor).
Write the section at the top of CHANGELOG.md:
## [0.2.0] - 2026-06-10
### Added
- Live re-indexing: `engram watch` picks up edits automatically.
### Fixed
- Duplicate chunks after restoring files from backup.
Keep an ## [Unreleased] section at the very top for changes landing between
releases; releasing = renaming it and starting a fresh one.
Every entry answers: what can I do now / what stopped being broken? If an entry needs the source code to make sense, rewrite it.
Make the agent improve with every task — review the run, distill lessons into durable memory, and reinforce what worked. Use at the end of any non-trivial task, or when the user asks the agent to "learn from this".
Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.
Write a reviewer-first pull-request description from the actual branch diff. Use when opening a PR or asked to write/improve a PR description.
Root-cause a bug with a hypothesis-driven loop instead of shotgun edits. Use when a bug isn't obvious after the first look, or when asked to "find out why" something fails.
Write tests that catch real regressions — behavior-focused, minimal mocking, edge cases chosen from the code's actual branches. Use when adding tests for new code or backfilling tests for a fix.
Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.