create-changelog
The create-changelog skill generates a CHANGELOG.md file formatted according to keepachangelog.com standards by extracting version history from GitHub releases or git tags. Use this skill when a project needs an initial changelog or when backfilling version history from existing release data to establish a structured change log.
git clone --depth 1 https://github.com/tobihagemann/turbo /tmp/create-changelog && cp -r /tmp/create-changelog/claude/skills/create-changelog ~/.claude/skills/create-changelogSKILL.md
# Create Changelog Create a changelog backfilled with version history. ## Step 1: Run `/changelog-rules` Skill Run `/changelog-rules` to load shared changelog conventions. ## Step 2: Backfill Version History Collect release history from the most authoritative source available: 1. **GitHub releases** (preferred): Run `gh release list --limit 100 --json tagName,name,publishedAt,body` to get release notes. For each release, parse the body into changelog entries. 2. **Git tags** (fallback): If no GitHub releases exist, run `git tag --sort=-v:refname` to list tags. For each consecutive tag pair, run `git log <older-tag>..<newer-tag> --oneline` to collect commit summaries. For each version, classify entries into the standard change types and apply the changelog-worthiness criteria per `/changelog-rules`. ## Step 3: Check for Existing Changelog If the changelog file already exists, warn the user and confirm before overwriting. ## Step 4: Write Changelog Write the changelog following the `/changelog-rules` file structure and conventions. ## Step 5: Present the Result Briefly summarize how many versions were backfilled and which source was used (GitHub releases or git tags).
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.