update-changelog
This skill updates the Unreleased section of CHANGELOG.md by analyzing staged or unstaged git changes and adding appropriate entries based on shared changelog conventions. Use it when a user requests changelog updates, such as "update changelog," "add changelog entry," or "log this change," provided the changelog file exists and the changes meet worthiness criteria.
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/update-changelog && cp -r /tmp/update-changelog/claude/skills/update-changelog ~/.claude/skills/update-changelogSKILL.md
# Update Changelog Update the Unreleased section of the changelog based on the current changes. ## Step 1: Run `/changelog-rules` Skill Run `/changelog-rules` to load shared changelog conventions. ## Step 2: Check for Changelog Use `git rev-parse --show-toplevel` to find the repository root. Look for the changelog file per `/changelog-rules`. If it does not exist, skip this skill. Do not create it. ## Step 3: Analyze the Changes Determine what changed: - Read `git diff --cached` for staged changes - If nothing is staged, read `git diff` for unstaged changes - Use the conversation context for the intent behind the changes ## Step 4: Assess Changelog-Worthiness Apply the `/changelog-rules` changelog-worthiness criteria. Also skip fixes to code introduced by the same branch/PR, as these are refinements of the in-progress feature, not separate changelog events. If no changes are changelog-worthy, skip this skill. ## Step 5: Check Existing Unreleased Entries Read the current Unreleased section of the changelog. Look for entries that relate to the same feature or fix. This prevents duplicates across multiple commits for the same body of work. - If an existing entry covers the same change, update its wording only if the current commit meaningfully extends or refines the feature. Do not add a duplicate entry. ## Step 6: Update the Unreleased Section Add or update entries in the Unreleased section following `/changelog-rules` conventions. Create subsection headers as needed (e.g., `### Added`). Then use the TaskList tool and proceed to any remaining task. ## Rules - Never modify released version sections. Only the Unreleased section is in scope. - Do not stage the modified file. Staging is handled separately.
For each reviewer question on a PR, recall implementation reasoning and compose a raw answer. Use when the user asks to \"answer reviewer questions\", \"draft answers to PR questions\", or \"explain reviewer questions\".
Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and offers to note genuine improvements for later. Use when the user asks to \"apply findings\", \"apply fixes\", \"apply suggestions\", \"apply accepted findings\", \"fix the findings\", or \"apply the review results\".
Project-wide health audit pipeline that fans out to all analysis skills in parallel, evaluates findings, and produces a unified report at .turbo/audit.md. Use when the user asks to \"audit the project\", \"run a full audit\", \"project health check\", \"audit my code\", \"codebase audit\", or \"comprehensive review\".
Shared changelog conventions and formatting rules referenced by $create-changelog and $update-changelog. Not typically invoked directly.
Enforce mirror, reuse, and symmetry principles to keep new code consistent with surrounding code. Use when writing new code in an existing codebase, adding new features, refactoring, or making any code changes.
Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".
Run AI-powered code review using the codex CLI. Use when the user asks to \"codex review\", \"run codex review\", or \"review a commit with codex\".
Shared commit message rules and technical constraints referenced by $stage-commit and $commit-staged. Not typically invoked directly.