Skill-Details
changelog-generator
Release management supports EM work, but this is a narrow changelog utility.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- name: "changelog-generator" description: "Produce consistent, auditable release notes from Conventional Commits. Separates commit parsing, semantic-bump logic, and changelog rendering for automated releases with editorial control. Use when cutting a release, generating CHANGELOG.md from git history, computing the next semantic version from commits, automating release notes in CI, or planning a hotfix/rollback. Examples: 'generate the changelog for v1.4.0', 'what version bump do these commits require', 'we need an emergency hotfix process'." --- # Changelog Generator **Tier:** POWERFUL **Category:** Engineering **Domain:** Release Management / Documentation ## Overview Use this skill to produce consistent, auditable release notes from Conventional Commits. It separates commit parsing, semantic bump logic, and changelog rendering so teams can automate releases without losing editorial control. ## Core Capabilities - Parse commit messages using Conventional Commit rules - Detect semantic bump (`major`, `minor`, `patch`) from commit stream - Render Keep a Changelog sections (`Added`, `Changed`, `Fixed`, etc.) - Generate release entries from git ranges or provided commit input - Enforce commit format with a dedicated linter script - Support CI integration via machine-readable JSON output ## When to Use - Before publishing a release tag - During CI to generate release notes automatically - During PR checks to block invalid commit message formats - In monorepos where package changelogs require scoped filtering - When converting raw git history into user-facing notes ## Key Workflows ### 1. Generate Changelog Entry From Git ```bash python3 scripts/generate_changelog.py \ --from-tag v1.3.0 \ --to-tag v1.4.0 \ --next-version v1.4.0 \ --format markdown ``` ### 2. Generate Entry From stdin/File Input ```bash git log v1.3.0..v1.4.0 --pretty=format:'%s' | \ python3 scripts/generate_changelog.py --next-version v1.4.0 --format markdown python3 scripts/generate_changelog.py --input commits.txt --next-version v1.4.0 --format json ``` ### 3. Update `CHANGELOG.md` ```bash python3 scripts/generate_changelog.py \ --from-tag v1.3.0 \ --to-tag HEAD \ --next-version v1.4.0 \ --write CHANGELOG.md ``` ### 4. Compute the Next Version From Commits When the user has not decided the next version, derive it instead of guessing: ```bash git log v1.3.0..HEAD --oneline | \ python3 scripts/version_bumper.py --current-version 1.3.0 --output-format json ``` Output JSON contains `recommended_version`, `bump_type` (`major`/`minor`/`patch`/`none`), and with `--include-commands` the exact `git tag` commands. Feed `recommended_version` into `generate_changelog.py --next-version`. Pre-releases: add `--prerelease alpha|beta|rc`. Input must be real `git log --oneline` output (hex hashes); a sample lives at `assets/sample_git_log.txt`. ### 5. Lint Commits Before Merge ```bash python3 scripts/commit_linter.py --from-ref origin/main --to-ref HEAD --strict --format text ``` Or file/stdin: ```bash python3 scripts/commit_linter.py --input commits.txt --strict cat commits.txt | python3 scripts/commit_linter.py --format json ``` ## Conventional Commit Rules Supported types: - `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore` - `security`, `deprecated`, `remove` Breaking changes: - `type(scope)!: summary` - Footer/body includes `BREAKING CHANGE:` SemVer mapping: - breaking -> `major` - non-breaking `feat` -> `minor` - all others -> `patch` ## Script Interfaces - `python3 scripts/generate_changelog.py --help` - Reads commits from git or stdin/`--input` - Renders markdown or JSON - Optional in-place changelog prepend - `python3 scripts/commit_linter.py --help` - Validates commit format - Returns non-zero in `--strict` mode on violations ## Common Pitfalls 1. Mixing merge commit messages with release commit parsing 2. Using vague commit summaries that cannot become release notes 3. FailinVollständige Quelle auf GitHub lesen (öffnet externe Seite)