本文へ移動
cccskills
無料GitHub で公開

changelog-generator

Generate changelogs from git commits. Use when user says "generate changelog", "update changelog", "what changed since last release", or before preparing a new release.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md8.4 KB
  • README.md1.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Changelog Generator Skill

Generate changelogs from conventional commits for Java projects.

When to Use

  • Before a release
  • User says "generate changelog" / "update changelog" / "what changed since last release"
  • After completing a milestone

Versioning Convention Detection

Detect versioning style using this priority order:

1. Check CLAUDE.md (if exists)

grep -A5 "## Versioning" CLAUDE.md 2>/dev/null

Look for explicit convention:

## Versioning
This project uses Semantic Versioning (x.y.z).
Tag format: `release-x.y.z`

2. Fallback: Detect from git tags

git tag --sort=-version:refname | head -10
Pattern detectedVersioning style
v3.15.0, 3.15.0SemVer (x.y.z)
release-3.15.0SemVer with prefix
v2.1, 2.1Two-component (x.y)
2026.01, 26.1CalVer
No patternAsk user

3. Fallback: Detect from CHANGELOG.md

grep -E "^\#+ \[.*\]" CHANGELOG.md | head -5

Extract version format from existing entries.

4. Last resort: Ask user

No versioning convention detected. Which format does this project use?
- Semantic Versioning (x.y.z) - e.g., 3.15.0
- Two-component (x.y) - e.g., 2.1
- Calendar Versioning - e.g., 2026.01

Supported Versioning Styles

StyleFormatTag examplesVersion bump
SemVerx.y.zv3.15.0, release-3.15.0major.minor.patch
Two-componentx.yv2.1, 2.1major.minor
CalVerYYYY.MM[.patch]2026.01, 2026.01.1year.month[.patch]

Legacy Projects (CLAUDE.md without versioning section)

If CLAUDE.md exists but has no versioning info:

  1. Don't assume - detect from tags/changelog
  2. If detected, optionally suggest adding to CLAUDE.md:
    Detected versioning: SemVer (x.y.z) with tag prefix 'release-'
    Want me to add this to CLAUDE.md for future reference?
    

Output Format

Supports two formats - detect from existing CHANGELOG.md or ask user preference.

Format A: Keep a Changelog (h2 versions)

# Changelog

## [Unreleased]

## [1.2.0] - 2026-01-29

### Added
- [#123]: New feature for plugin dependencies

### Changed
- [#456]: Improved performance of plugin loading

### Fixed
- [#234]: Resolved NPE when directory missing

Format B: pf4j style (h3 versions)

## Change Log

### [Unreleased][unreleased]

### [3.15.0] - 2026-01-29

#### Added
- [#123]: New feature for plugin dependencies

#### Changed
- [#456]: Improved performance of plugin loading

#### Fixed
- [#234]: Resolved NPE when directory missing

Reference-Style Links (Recommended)

Use reference-style links for cleaner, more readable entries:

#### Fixed
- [#648]: Restore missing `module-info.class` in multi-release JAR
- [#625]: Fix exception handling inconsistency in `startPlugin()`

#### Added
- [#629]: Validate dependency state on plugin start
- [#633]: Allow customization of `PluginClassLoader` parent delegation

<!-- At the bottom of the file -->
[#648]: https://github.com/user/repo/issues/648
[#633]: https://github.com/user/repo/pull/633
[#629]: https://github.com/user/repo/pull/629
[#625]: https://github.com/user/repo/pull/625

Benefits:

  • Cleaner to read (no long URLs inline)
  • Links defined once, reusable
  • Easier to write and maintain

Version Comparison Links

Add comparison links at the bottom for easy diff viewing:

[unreleased]: https://github.com/user/repo/compare/release-3.15.0...HEAD
[3.15.0]: https://github.com/user/repo/compare/release-3.14.1...release-3.15.0
[3.14.1]: https://github.com/user/repo/compare/release-3.14.0...release-3.14.1

Pattern: [version]: https://github.com/{owner}/{repo}/compare/{previous-tag}...{current-tag}

Section Order

Adapt to existing file, or use this default order:

SectionWhen to use
FixedBug fixes
ChangedChanges to existing functionality
AddedNew features
DeprecatedSoon-to-be removed features
RemovedRemoved features
SecurityVulnerability fixes (CVEs)

Note: pf4j uses Fixed → Changed → Added → Removed. Keep a Changelog uses Added → Changed → Deprecated → Removed → Fixed → Security.

Rule: Follow existing file's order if present.

Mapping Conventional Commits to Changelog

Commit TypeChangelog Section
featAdded
fixFixed
perfChanged
refactorChanged
build(deps)Changed or Security (if CVE)
BREAKING CHANGEChanged (with bold note)
deprecateDeprecated

Workflow

  1. Check for existing CHANGELOG.md

    cat CHANGELOG.md | head -20
    

    Detect format (h2 vs h3 versions, section order, link style).

  2. Determine version range

    # Find last tag
    git describe --tags --abbrev=0
    
    # List recent tags
    git tag --sort=-version:refname | head -5
    
  3. Get commits since last release

    git log v3.14.1..HEAD --oneline
    
  4. Extract issue/PR references Look for patterns: #123, fixes #123, closes #123, (#123)

  5. Generate changelog entry

    • Group by section
    • Use reference-style links
    • Add version comparison link
  6. Suggest version bump (based on detected versioning style)

    SemVer (x.y.z):

    • BREAKING CHANGE → Major (3.0.0 → 4.0.0)
    • feat → Minor (3.14.0 → 3.15.0)
    • fix only → Patch (3.14.0 → 3.14.1)

    Two-component (x.y):

    • BREAKING CHANGE → Major (2.0 → 3.0)
    • feat/fix → Minor (2.1 → 2.2)

    CalVer (YYYY.MM):

    • New month → 2026.01 → 2026.02
    • Same month, new release → 2026.01 → 2026.01.1

Token Optimization

  • Use git log --oneline for initial scan
  • Only fetch full body if BREAKING CHANGE suspected
  • Reuse existing link definitions from file
  • Don't re-read entire changelog - just prepend new section

Example: Full Workflow

Input: User says "generate changelog for next release"

Step 1: Check existing format

head -30 CHANGELOG.md

→ Detects pf4j style (h3 versions, Fixed first)

Step 2: Find version range

git describe --tags --abbrev=0

→ release-3.15.0

Step 3: Get commits

git log release-3.15.0..HEAD --oneline

→ 5 commits found

Step 4: Generate entry

### [Unreleased][unreleased]

#### Fixed
- [#650]: Fix memory leak in extension factory

#### Changed
- [#651]: Rename `LegacyExtension*` to `IndexedExtension*`

#### Added
- [#652]: Add support for plugin priority ordering

Step 5: Generate link definitions

[#652]: https://github.com/pf4j/pf4j/pull/652
[#651]: https://github.com/pf4j/pf4j/pull/651
[#650]: https://github.com/pf4j/pf4j/issues/650

Step 6: Update version comparison links

[unreleased]: https://github.com/pf4j/pf4j/compare/release-3.15.0...HEAD

Step 7: Suggest version

Suggested: 3.16.0 (minor - has new feature)

Handling Edge Cases

No conventional commits

List under "Changed" with original message:

#### Changed
- Updated plugin loading mechanism
- Refactored test utilities

Security fix

#### Security
- [#618], [#623]: Fix path traversal vulnerabilities in ZIP extraction

Breaking change

#### Changed
- **BREAKING**: [#645] Renamed `LegacyExtension*` classes to `IndexedExtension*`

Multiple issues for same fix

- [#630], [#631]: Set `failedException` when plugin validation fails

Integration with Existing CHANGELOG.md

  1. Read existing file to detect:

    • Heading level (## or ### for versions)
    • Section order
    • Link style (reference or inline)
    • Existing link definitions
  2. Insert new version after [Unreleased] section

  3. Merge link definitions - add new ones, keep existing

  4. Update [unreleased] comparison link to point to new version

Quick Reference

User saysAction
"generate changelog"Full changelog since last tag
"changelog since v3.14"From specific version
"what's unreleased"Preview unreleased changes
"update changelog for 3.16"Generate and insert for version
"add changelog entry for #123"Single issue entry

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Review REST API contracts for HTTP semantics, versioning, backward compatibility, and response consistency. Use when user asks "review API", "check endpoints", "REST review", or before releasing API changes.

日本語の概要は準備中です。原文の説明を表示しています。

decebals/claude-code-java7512026年9月7日 更新

Analyze Java project architecture at macro level - package structure, module boundaries, dependency direction, and layering. Use when user asks "review architecture", "check structure", "package organization", or when evaluating if a codebase follows clean architecture principles.

日本語の概要は準備中です。原文の説明を表示しています。

decebals/claude-code-java7512026年9月7日 更新

Clean Code principles (DRY, KISS, YAGNI), naming, function design and readability. Use when code is hard to read, with long methods, unclear names, duplication or deep nesting. For how responsibilities are split across classes and which way dependencies point, use solid-principles instead.

日本語の概要は準備中です。原文の説明を表示しています。

decebals/claude-code-java7512026年9月7日 更新

Review Java concurrency code for thread safety, race conditions, deadlocks, and modern patterns (Virtual Threads, CompletableFuture, @Async). Use when user asks "check thread safety", "concurrency review", "async code review", or when reviewing multi-threaded code.

日本語の概要は準備中です。原文の説明を表示しています。

decebals/claude-code-java7512026年9月7日 更新

Common design patterns with Java examples (Factory, Builder, Strategy, Observer, Decorator, etc.). Use when user asks "implement pattern", "use factory", "strategy pattern", or when designing extensible components.

日本語の概要は準備中です。原文の説明を表示しています。

decebals/claude-code-java7512026年9月7日 更新

Generate conventional commit messages for Java projects. Use when user says "commit", "create commit", "commit changes", or after completing code changes that need to be committed.

日本語の概要は準備中です。原文の説明を表示しています。

decebals/claude-code-java7512026年9月7日 更新

decebals のスキルをすべて見る

このスキルの問題を報告する