Update Changelog

update_changelog

Create or update a CHANGELOG.md in the repository root: a human-readable, day-grouped, add-only history derived from git commits, newest day first. Record later committed changes as new entries or day sections while preserving existing entries as immutable historical facts. build CHANGELOG.md, refresh changelog from git history, add the missing days to the changelog

Run scripts/prepare_changelog_day.sh YYYY-MM-DD from this skill when it is available. The script writes one structured context blob for a single calendar day to a file under the system tmp dir, with the day's commit subjects and bodies, the deduplicated repo-relative file list, per-file net diffs for the day, and generic placeholders for binary files. Its stdout prints exactly two lines: the context file's absolute path, then a one-line consumption directive. Exits 1 with no commits on when the date has no commits — skip silently.

Use the Read tool on the path printed by scripts/prepare_changelog_day.sh and read the entire file. This is the default path and works for normal-sized days. If the file overflows Read's default window, call Read again with offset/limit and continue in sequence until every byte is covered. Consume each page in order. Only when the file is so large that paginated Read is impractical, use grep/awk/sed via Bash to split the file into ordered slices. Read those slices sequentially from the top of the file through the end, preserving the original order of ` and sections. Use the script's context file as the sole per-day source. Never re-derive the day with git log, git diff, or git status; never truncate the blob with head; never sample by filename. Iterate every and ` section in order before composing the day section.

The file always begins with the H1 # CHANGELOG — {Project Name}, then a blank line, then the line stating that entries are grouped strictly by day, kept on their original implementation dates, and immutable once written. Substitute {Project Name} from the repo directory name, package.json, Cargo.toml, or the README's H1. One ## YYYY-MM-DD — {Day theme} heading per calendar day that has commits, ordered newest-first. {Day theme} is a 2-5 word editorial summary of that day's dominant focus. End every day section with a horizontal rule (---). One bullet per logical change inside the day section in the format - **Category:** Plain-English summary of the change.. added for new features or capabilities. changed for behavior that differs from before. deprecated for retired or removed behavior, or behavior kept only for legacy use. refactored for the same output from the same input with faster, more robust, or less buggy internals. docs for documentation- or specification-only changes. Express replacement or removal as a deprecated or changed entry on the date that later work happened. End every day section with a files-changed bullet listing every path the day touched, repo-relative, backtick-wrapped, comma-separated, deduplicated. Shape: a - **Files changed:** prefix followed by each path wrapped in single backticks and separated by a comma plus a space.

Build each run from committed git history only; ignore uncommitted and untracked working-tree state. On incremental runs, treat the most recent recorded day as provisionally complete because commits can share that calendar day after its section was first written. Reopen that day and every later committed date; days older than the most recent recorded day are settled for that run. Process one day at a time and flush each completed day section to CHANGELOG.md before moving to the next. Treat already-written days as committed output and let them fall out of working context. Repository histories can exceed any context window when read at once. Maintain strict newest-first day ordering. When updating an existing changelog, insert new day sections directly after the header and update the reopened most recent recorded day in place. Squash related commits into a single bullet. Write one entry per logical change, not per commit. Keep entries on their original implementation date forever. Treat each existing entry's date, text, and category as frozen once written. Record later committed changes only as new entries on the dates those changes happened. Write summaries in plain English, past tense, describing what was done. Leave why and how out of the summary. Stay concise but specific enough that a reader unfamiliar with the codebase understands the scope. Preserve existing day sections and entries in place. Add new day sections or entries for later committed changes while keeping existing entry dates, text, and categories unchanged. For the reopened most recent recorded day, follow ` instead of regenerating the section. When an incremental run reprocesses the most recent recorded day, compare that day's committed history with the existing section. Keep every existing entry's date, category, and text unchanged; add entries for newly found logical changes, extend the - Files changed: line with missing paths, and revise the day theme only when the added commits change the day's dominant focus. The model owns summarization, day-theme composition, and category assignment. Use script output as evidence and execution support. Treat this skill as the source of truth for /update_changelog` workflow, output format, and entry style.

Resolve {Project Name} from the repository directory name, an existing project title in the README's H1, the name field of package.json or Cargo.toml, or another canonical project metadata file. Build the date list from committed history. When CHANGELOG.md does not exist, run git log --reverse --format='%ad' --date=short --no-merges | sort -u to list every distinct commit date in the repository, oldest-first. When updating an existing changelog, read from the top only until the first ## YYYY-MM-DD heading; because the changelog is newest-first, that heading is the most recent recorded day D. Then run git log --reverse --format='%ad' --date=short --no-merges --since={D}T00:00:00 | sort -u (or an equivalent committed-history query) to list D and every later distinct commit date. Keep D in the list because same-day commits can land after its section was written. If CHANGELOG.md does not exist, create it with the header block. If it exists, leave the header in place.

For each selected date, oldest-first:

Run scripts/prepare_changelog_day.sh YYYY-MM-DD to produce that day's context file path. If the script exits 1, skip the date silently. Read the returned context file according to `, covering the full file before composing the day section. Read every and block from the consumed context. Aggregate related changes into logical entries, choose categories, and compose a 2-5 word day theme. Build the day section from the day theme, the entry bullets, and the - Files changed: ... bullet using the paths from . End the section with ---. For a new day, insert the completed day section directly after the header block in CHANGELOG.md. For the reopened most recent recorded day, reconcile the existing section in place per `. Flush to disk before composing the next day so prior detail can fall out of working context.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: theafh
• Source: theafh/ai-modules
• License: MIT

Install and usage instructions live in the source repository linked above.