New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Changelog Review

by areed1192 in areed1192/interactive-brokers-api

Audit, enforce, and maintain changelogs in Python projects. An agent skill from areed1192/interactive-brokers-api.

MITAuto-check passedDevelopment

Install Changelog Review

skills CLI
$ npx skills add areed1192/interactive-brokers-api --skill changelog-review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install areed1192/interactive-brokers-api changelog-review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/areed1192/interactive-brokers-api.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/changelog-review .claude/skills/changelog-review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
changelog-review
GitHub stars
103
Token cost
~2.3k tokens
SKILL.md length
1,098 words
Files
2 (incl. references)
Skills in repo
3
Repo updated
First seen
Licence
MIT

At a glance

Audit, enforce, and maintain changelogs in Python projects. An agent skill from areed1192/interactive-brokers-api.

  • Works in 9 steps: Header — File starts with # Changelog… → Unreleased section — An ## [Unreleased]… → Change type headings — Entries use only… → …
  • Someone asks to review a changelog
  • SKILL.md covers Before you start, Modes of operation, What does NOT need a changelog… and Constraints
  • Reaches keepachangelog.com and semver.org

What it does

Changelog Review is an agent skill from areed1192/interactive-brokers-api. Audit, enforce, and maintain changelogs in Python projects. Use this skill whenever someone asks to review a changelog, add a changelog entry, check if a changelog is up to date, fix changelog formatting, create a CHANGELOG.md from scratch, prepare a release, or ensure changelog compliance with Keep a Changelog. Trigger on phrases like "update the changelog", "add a changelog entry", "review my changelog", "is my changelog correct", "prepare for release", "bump the version", "what changed since last release", or…

Its SKILL.md is about 2.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/best-practices.md`).

It sits in Development, covering Changelog and release notes. It works with Python. The repository describes itself as: A python application used to interact with the Interactive Brokers REST API. The licence is MIT.

When your agent uses it

  • Someone asks to review a changelog
  • Add a changelog entry
  • Check if a changelog is up to date
  • Fix changelog formatting

Example prompts

  • “update the changelog”
  • “add a changelog entry”
  • “review my changelog”
  • “/changelog-review”

Requirements

  • Python 3

Workflow steps

9 steps, taken from the first numbered list in SKILL.md.

  1. Header — File starts with # Changelog and optionally a description
  2. Unreleased section — An ## [Unreleased] section exists at the top.
  3. Change type headings — Entries use only the six allowed types
  4. Version format — Released sections use ## [x.y.z] - YYYY-MM-DD
  5. Reverse chronological order — Newest version appears first.
  6. Comparison links — Bottom of file has [unreleased] and version
  7. No empty sections — Flag ### Added headings with no entries beneath them.
  8. Entry quality — Each entry should describe a user-visible change,
  9. Yanked releases — If any release was yanked, it should be marked

What it can do on your machine

Read from SKILL.md and the folder at commit 6d19ac2. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • keepachangelog.com
    • semver.org

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Changelog Review loads about 2.3k tokens when it runs, and up to ~6.4k if it reads all its reference files. Until then it costs about 187 tokens; SKILL.md has 1,098 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~187
When it runs · the whole SKILL.md, loaded when a task matches
~2.3k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~6.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from areed1192/interactive-brokers-api at commit 6d19ac2, republished under its MIT licence (© areed1192). 1,098 words, ~2,281 tokens.

Download SKILL.mdSave it as .claude/skills/changelog-review/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
changelog-review
description
Audit, enforce, and maintain changelogs in Python projects. Use this skill whenever someone asks to review a changelog, add a changelog entry, check if a changelog is up to date, fix changelog formatting, create a CHANGELOG.md from scratch, prepare a release, or ensure changelog compliance with Keep a Changelog. Trigger on phrases like "update the changelog", "add a changelog entry", "review my changelog", "is my changelog correct", "prepare for release", "bump the version", "what changed since last release", or any request involving CHANGELOG.md, release notes, or version management in a Python project. Also trigger when someone finishes a code change and needs to document it, or when they ask about semantic versioning.

Changelog Review

This skill audits, creates, and maintains changelogs in Python projects following the Keep a Changelog 1.1.0 format and Semantic Versioning 2.0.0.

Before you start

Read the best-practices reference file to ground your review:

cat references/best-practices.md

Use the rules and source citations in that file as your authoritative checklist.

Modes of operation

This skill operates in one of four modes depending on what the user needs. Determine the mode from their request, then follow the corresponding workflow.

Mode 1 — Audit an existing changelog

Use when the user says things like "review my changelog", "is my changelog correct", or "check my CHANGELOG.md".

Step 1: Read the changelog

Open CHANGELOG.md (or HISTORY.md, NEWS.md — check all common names). If no changelog exists, switch to Mode 3 (Create from scratch).

Step 2: Check structure against Keep a Changelog 1.1.0

Verify each of the following. For every violation, note the line number, what's wrong, and cite the source from references/best-practices.md:

  1. Header — File starts with # Changelog and optionally a description mentioning Keep a Changelog and Semantic Versioning.
  2. Unreleased section — An ## [Unreleased] section exists at the top.
  3. Change type headings — Entries use only the six allowed types: Added, Changed, Deprecated, Removed, Fixed, Security. Flag any non-standard headings (e.g., ### Improvements, ### Misc).
  4. Version format — Released sections use ## [x.y.z] - YYYY-MM-DD with ISO 8601 dates. Flag ambiguous date formats like 04/19/2026.
  5. Reverse chronological order — Newest version appears first.
  6. Comparison links — Bottom of file has [unreleased] and version comparison links pointing to the repository's diff URLs.
  7. No empty sections — Flag ### Added headings with no entries beneath them.
  8. Entry quality — Each entry should describe a user-visible change, not a commit message. Flag entries like "fixed bug" (no context) or entries that are clearly copy-pasted commit messages.
  9. Yanked releases — If any release was yanked, it should be marked with [YANKED] after the date.

Step 3: Cross-check with project metadata

  • Compare the latest released version in the changelog against version in pyproject.toml (or setup.py, setup.cfg). Flag mismatches.
  • If there are commits or code changes since the last release tag that are not reflected in ## [Unreleased], note them.

Step 4: Produce the audit report

Output a markdown table:

LineIssueSeveritySource
12Non-standard heading ### Improvementserror[KACL] §Types
45Date format 04/19/2026 should be 2026-04-19warning[KACL] §Dates

Severity levels:

  • error — Violates Keep a Changelog spec or Semantic Versioning.
  • warning — Deviates from best practice but not spec-breaking.
  • info — Suggestion for improvement.
Mode 2 — Add a changelog entry

Use when the user says things like "update the changelog", "add this to the changelog", or has just finished a code change.

Step 1: Identify what changed

Ask or infer from context:

  • Which files were added, changed, or fixed?
  • Is this a new feature (Added), a behavior change (Changed), a bug fix (Fixed), a removal (Removed), a deprecation (Deprecated), or a security fix (Security)?
  • Are there new test files? New sample/fixture files?

Step 2: Write the entries

Follow this format for each entry:

markdown
- **<file or module>**: Brief description of the user-visible change.
  - Sub-bullet for important details (methods, properties, behavior).
  - Another sub-bullet if needed.

Rules for writing entries:

  • Bold the file path — **path/to/file.py**: prefix identifies where the change lives.
  • One entry per logical change — do not combine unrelated changes.
  • Include test files — new test files get their own Added entry with the test count (e.g., "12 unit tests for…").
  • Include sample/fixture files — new or updated data files get their own entry.
  • Use the right section — new features → Added, behavior changes → Changed, bug fixes → Fixed, removals → Removed, deprecations → Deprecated, vulnerability fixes → Security.

Step 3: Insert into the changelog

Add the entries under the appropriate ### <Type> heading within ## [Unreleased]. If the heading doesn't exist yet, create it in the canonical order: Added, Changed, Deprecated, Removed, Fixed, Security.

Never modify entries under a released version section.

Show full SKILL.md (486 more words)Show less
Mode 3 — Create a changelog from scratch

Use when no CHANGELOG.md exists, or when the user asks to "create a changelog" or "initialize a changelog".

Step 1: Determine project state

  • Check pyproject.toml (or setup.py) for the current version.
  • Check git tags for previous releases.
  • Check git log for notable changes.

Step 2: Generate the file

Start with this template:

markdown
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

If the project already has released versions (from git tags), add sections for those versions with entries derived from commit messages between tags. Clean up commit messages into proper changelog entries — do not dump raw commit logs.

Add comparison links at the bottom of the file.

Step 3: Present and confirm

Show the generated changelog to the user for review before writing it to disk.

Mode 4 — Prepare a release

Use when the user says "prepare a release", "bump the version", "release v1.2.0", or "cut a release".

Step 1: Determine the version bump

Review the entries in ## [Unreleased] and recommend a version bump based on Semantic Versioning:

  • MAJOR — if any entry describes a breaking API change, backward-incompatible change, or removal of public functionality.
  • MINOR — if entries describe new features, additions, or non-breaking changes to existing functionality.
  • PATCH — if entries describe only bug fixes, security patches, or documentation corrections with no API impact.

Present the recommendation and let the user confirm or override.

Step 2: Update the changelog

  1. Replace ## [Unreleased] with ## [x.y.z] - YYYY-MM-DD using today's date in ISO 8601 format.
  2. Add a new empty ## [Unreleased] section above the new release.
  3. Add/update the comparison link at the bottom of the file.

Step 3: Update project metadata

Update the version field in pyproject.toml (or setup.py, setup.cfg) to match the new version. If the project uses a __version__ variable in __init__.py, update that too.

Step 4: Present changes

Show before/after diffs for:

  • CHANGELOG.md
  • pyproject.toml (or equivalent)
  • Any __version__ file

Wait for user approval before writing.

What does NOT need a changelog entry

Not every change is user-visible. Skip changelog entries for:

  • Internal refactors with no API or behavior change
  • Comment-only or docstring-only changes
  • CI/CD configuration changes (unless they affect users)
  • Developer tooling changes (linter config, pre-commit hooks)
  • Dependency version pin updates (unless they fix a user-facing bug)

If unsure, ask the user.

Constraints

  • Never edit released sections. Once a version is published, its changelog entries are immutable. If a correction is needed, add a note in the next release.
  • Always use ISO 8601 dates — YYYY-MM-DD, never regional formats.
  • Changelogs are for humans, not machines. Write clear, concise descriptions of what changed and why it matters. Do not paste commit hashes, PR numbers without context, or raw diff output.
  • One logical change per entry. Do not combine "added feature X and fixed bug Y" in a single bullet.
  • Follow the project's existing conventions. If the project already uses a specific entry format (e.g., bold file paths, module prefixes), match it. Only suggest format changes during an audit (Mode 1).

© areed1192, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in .github/skills/changelog-review of areed1192/interactive-brokers-api.

  • SKILL.md
  • references/best-practices.md

Open the folder on GitHubat commit 6d19ac2

Compare with similar skills

Changelog Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Changelog Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Changelog Review this skillareed1192/interactive-brokers-api103—~2.3kAutomated safety check: PassMIT
Release Skillsnexmoe/eve4213 repos~3.3kAutomated safety check: PassNone
Commitizencommitizen-tools/commitizen3.5k—~839Automated safety check: PassMIT
pybind11 Release Preparationpybind/pybind1118k—~1.7kAutomated safety check: PassCustom licence
pybind11 Release Publicationpybind/pybind1118k—~2.5kAutomated safety check: PassCustom licence
EverOS Release WorkflowEverMind-AI/EverOS13k—~1.3kAutomated safety check: PassApache-2.0

Similar skills

  • Release Skills

    nexmoe/eve

    Universal release workflow. An agent skill from nexmoe/eve.

    421 GitHub starsUsed in 3 repos~3.3k tokens
    DevelopmentAuto-check passed

  • Commitizen

    commitizen-tools/commitizen

    A skill your agent uses for tasks involving Conventional Commits, commit message validation, Commitizen configuration, semantic version bumps, changelog generation, or CI/release automation with the…

    3.5k GitHub stars~839 tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • pybind11 Release Preparation

    pybind/pybind11

    Opens the pybind11 release-preparation pull request: picking the release base, bumping the version in common.h and integrating the changelog, following docs/release.rst.

    18k GitHub stars~1.7k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • pybind11 Release Publication

    pybind/pybind11

    Walks a maintainer through publishing a pybind11 release after the preparation PR merges, with preflight checks, confirmations before each push and a GitHub release.

    18k GitHub stars~2.5k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • EverOS Release Workflow

    EverMind-AI/EverOS

    Walks through cutting a versioned everos release: bump the version, update the changelog, tag it, and review the drafted GitHub Release page before publishing.

    13k GitHub stars~1.3k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Pre Release

    ZhuoZhuoCrayon/throttled-py

    Automates release preparation for throttled-py. An agent skill from ZhuoZhuoCrayon/throttled-py.

    651 GitHub stars~1.1k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from areed1192/interactive-brokers-api

  • Package Audit

    areed1192/interactive-brokers-api

    Perform a comprehensive audit of a Python package and produce a phased improvement plan saved to IMPROVEMENT.md.

    103 GitHub stars~2.9k tokensUpdated 2 mo ago
    Auto-check passed

  • Python Logging Reviewer

    areed1192/interactive-brokers-api

    Audit, plan, and fix logging in any Python project. An agent skill from areed1192/interactive-brokers-api.

    103 GitHub stars~1.9k tokensUpdated 2 mo ago
    Auto-check passed

Works with

Categories

Questions about Changelog Review

What does Changelog Review do?

Audit, enforce, and maintain changelogs in Python projects. An agent skill from areed1192/interactive-brokers-api. Changelog Review is an agent skill from areed1192/interactive-brokers-api. Audit, enforce, and maintain changelogs in Python projects.

When should I use Changelog Review?

Changelog Review fits situations like: someone asks to review a changelog; add a changelog entry; check if a changelog is up to date; fix changelog formatting.

How do I install Changelog Review in Claude Code?

Run `npx skills add areed1192/interactive-brokers-api --skill changelog-review -a claude-code`. Or copy the skill folder (.github/skills/changelog-review in areed1192/interactive-brokers-api) into .claude/skills/changelog-review in your project. Claude Code loads it when a task matches its description.

How do I install Changelog Review in Codex?

Run `npx skills add areed1192/interactive-brokers-api --skill changelog-review -a codex`. Or copy the skill folder (.github/skills/changelog-review in areed1192/interactive-brokers-api) into .agents/skills/changelog-review in your project. Codex loads it when a task matches its description.

Can I use Changelog Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add areed1192/interactive-brokers-api --skill changelog-review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/changelog-review, .gemini/skills/changelog-review, .github/skills/changelog-review and .opencode/skills/changelog-review in your project.

What does Changelog Review need to run?

SKILL.md names no scripts, command-line tools or credentials: Changelog Review is instructions for the agent only. Our summary lists: Python 3.

Does Changelog Review access the network?

SKILL.md names 2 domains. In commands or code: keepachangelog.com and semver.org; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.

Is Changelog Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Changelog Review use?

Changelog Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Changelog Review use?

About 2.3k tokens (SKILL.md is roughly 9.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 4.1k tokens, read only when the agent opens those files.

What are the alternatives to Changelog Review?

Skills that share tags, products or a category with Changelog Review: Release Skills (nexmoe/eve, 421 stars), Commitizen (commitizen-tools/commitizen, 3.5k stars), pybind11 Release Preparation (pybind/pybind11, 18k stars) and pybind11 Release Publication (pybind/pybind11, 18k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Changelog Review?

areed1192 (a GitHub user) maintains it in areed1192/interactive-brokers-api, which has 103 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on July 24, 2026.

Source: areed1192/interactive-brokers-api on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.