Automated Git Releases (GitHub / GitLab)

Feature Overview

Automate GitHub/GitLab Release workflows, following Semantic Versioning specifications. Automatically analyze Git commit history and update CHANGELOG.md, then determine the appropriate version number and complete the release.

Release Workflow

Step 0: Verify Git Platform

Check the Git platform type of the current repository:

bash

git remote get-url origin

Parse and verify URL format:

GitHub:

HTTPS:
```
https://github.com/owner/repo.git
```
SSH:
```
git@github.com:owner/repo.git
```
Extract
```
owner/repo
```
for subsequent GitHub Release creation

GitLab:

HTTPS:

https://gitlab.com/owner/repo.git

or self-hosted

https://gitlab.example.com/owner/repo.git

SSH:

git@gitlab.com:owner/repo.git

git@gitlab.example.com:owner/repo.git

Extract
```
owner/repo
```
(or full path for self-hosted) for subsequent GitLab Release creation

Neither GitHub nor GitLab:

Notify users that this skill only supports GitHub and GitLab
Ask whether to only execute git tag/push (skip Release creation)

Proceed to Step 1 after platform detection

Step 1: Analyze Commits and Update CHANGELOG

Automatically analyze recent Git commits and update CHANGELOG.md:

Get commits since last release:

bash

# Get latest tag
LATEST_TAG=$(git describe --tags --abbrev=0 2>/dev/null || echo "")

# Get commits after the latest tag (all commits if no tag exists)
if [ -n "$LATEST_TAG" ]; then
  git log ${LATEST_TAG}..HEAD --pretty=format:"%h|%s|%an" --reverse
else
  git log --pretty=format:"%h|%s|%an" --reverse
fi

Parse and categorize commit messages:

Categorize using Conventional Commits format:

```
feat:
```
→ Added (new features)
```
fix:
```
→ Fixed (bug fixes)
```
break:
```
or
```
BREAKING CHANGE:
```
→ Changed (breaking changes)
```
refactor:
```
,
```
perf:
```
,
```
chore:
```
,
```
docs:
```
,
```
test:
```
,
```
style:
```
→ Changed (other changes)

For each commit message:

Extract category (type) prefix
Extract scope (if exists), display as
```
scope: xxx
```
in description
Clean message (remove conventional commit prefix)
Group by category

Update CHANGELOG.md:

Read existing CHANGELOG.md and update the

[Unreleased]

section:

markdown

## [Unreleased]

### Added

- scope: feature description 1
- feature description 2

### Changed

- scope: refactor/other change 3
- **Breaking**: breaking change 4

### Fixed

- scope: fix bug description

Update Rules:

If
```
[Unreleased]
```
section exists and has content, append new commits to corresponding categories
If
```
[Unreleased]
```
section exists but is empty, fill with categorized commits
If
```
[Unreleased]
```
section does not exist, create a new section at the top

Implementation Key Points:

Use Edit tool to modify CHANGELOG.md
Preserve existing unreleased content (if any)
Format: each bullet is concise, using commit message body
If commit includes scope, add
```
scope: xxx
```
before description
Add
```
**Breaking**:
```
prefix to breaking changes for emphasis

Show summary to user:

Display summary of content added to CHANGELOG:

Analyzed X commits (since v{version}):
- 3 Added (new features)
- 2 Changed (including 1 breaking change)
- 1 Fixed (bug fix)

Step 2: Analyze Unreleased Changes

Read updated CHANGELOG.md and check

[Unreleased]

section, categorize changes:

MAJOR (X.0.0): Contains breaking changes, requires major version upgrade
MINOR (x.Y.0): New features added
PATCH (x.y.Z): Only bug fixes

Version Decision Matrix:

Breaking changes exist → MAJOR
New features (no breaking changes) → MINOR
Only bug fixes → PATCH

Step 3: Determine New Version Number

Get current version from git tags:
```
git describe --tags --abbrev=0
```
Parse version number (MAJOR.MINOR.PATCH)
Apply version upgrade based on categorized changes
Show decision to user and request confirmation

Example Display:

Current version: 1.2.3
Unreleased changes:
- Breaking: breaking change description
- Added: new feature description
- Fixed: bug fix description

Recommended version: 2.0.0 (breaking changes detected)
Confirm? (yes/no)

Step 4: Update CHANGELOG.md

Replace
```
## [Unreleased]
```
with
```
## [X.Y.Z] - YYYY-MM-DD
```
Add version link at the bottom (based on platform):

GitHub:

markdown

[X.Y.Z]: https://github.com/owner/repo/compare/vA.B.C...vX.Y.Z

GitLab:

markdown

[X.Y.Z]: https://gitlab.com/owner/repo/-/compare/vA.B.C...vX.Y.Z

Self-hosted GitLab:

markdown

[X.Y.Z]: https://gitlab.example.com/owner/repo/-/compare/vA.B.C...vX.Y.Z

Commit:
```
git commit -m "chore: release vX.Y.Z"
```

Step 5: Create and Push Tag

bash

git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin main
git push origin vX.Y.Z

Step 6: Create Release

GitHub Release

Use

gh release create

to create formatted release notes:

bash

gh release create vX.Y.Z \
  --title "vX.Y.Z" \
  --notes "## What's Changed

### Added

- scope: feature description 1
- feature description 2

### Fixed

- scope: fix bug description

### Changed

- other change description

**Full Changelog**: https://github.com/owner/repo/compare/vA.B.C...vX.Y.Z"

Release Notes Format Specifications:

Use English title
```
## What's Changed
```
Use
```
### Added
```
,
```
### Fixed
```
,
```
### Changed
```
for categorization
Each entry starts with
```
-
```
, concise and clear
If commit includes scope, add
```
scope: xxx
```
before description
Add
```
**Breaking**:
```
prefix to breaking changes
Use
```
**Full Changelog**:
```
for link text
Omit empty categories
Extract corresponding version's
```
Added
```
,
```
Fixed
```
,
```
Changed
```
content from CHANGELOG.md

Important Notes: If gh command fails due to authentication issues, provide users with:

Link to manually create release in GitHub Web UI
Formatted release notes content for copy-paste

GitLab Release

Use

glab release create

to create formatted release notes:

bash

glab release create vX.Y.Z \
  --name "vX.Y.Z" \
  --notes "## What's Changed

### Added

- scope: feature description 1
- feature description 2

### Fixed

- scope: fix bug description

### Changed

- other change description

**Full Changelog**: https://gitlab.com/owner/repo/-/compare/vA.B.C...vX.Y.Z"

Release Notes Format Specifications: Same as GitHub Release, use unified

## What's Changed

format

Important Notes: If glab command fails due to authentication issues, provide users with:

Link to manually create release in GitLab Web UI
Formatted release notes content for copy-paste

Self-hosted GitLab: Need to configure CLI host address first:

bash

glab config set host gitlab.example.com

Error Handling

Unsupported Git Platform: Notify users that this skill only supports GitHub and GitLab, ask whether to only execute git tag/push
No Unreleased Changes: Notify users and ask whether to proceed
Dirty Git Workspace: Abort and require users to commit/stage changes first
Authentication Failure: Provide Web UI alternative
Push Conflict: Instruct users to pull/rebase first then retry
No Remote Repository Configured: Abort and require users to configure remote repository first

CHANGELOG Format

Expect to use Keep a Changelog format:

markdown

## [Unreleased]

### Added

- scope: feature description

### Changed

- **Breaking**: incompatible change

### Fixed

- scope: fix bug description

## [1.0.0] - YYYY-MM-DD
...

Release Notes Format Specifications

When creating Release, must use the following unified format template to ensure consistency across all versions:

markdown

## What's Changed

### Added

- scope: feature description 1
- feature description 2

### Fixed

- scope: fix bug description

### Changed

- other change descriptions (refactoring, performance optimization, etc.)
- **Breaking**: breaking change description (if any)

**Full Changelog**: https://github.com/owner/repo/compare/vA.B.C...vX.Y.Z

Format Requirements:

Fixed Title: Use
```
## What's Changed
```
(English, maintain consistency with historical versions)
Categorization Standards:
- ```
### Added
```
  : New features
- ```
### Fixed
```
  : Bug fixes
- ```
### Changed
```
  : Other changes (refactoring, performance optimization, documentation, etc.)
Scope Display: If commit includes scope, add
```
scope: xxx
```
before description
Breaking Changes: Use
```
**Breaking**:
```
prefix in Changed category for emphasis
Link Text: Use
```
**Full Changelog**:
```
(English)
Omit Empty Categories: If a category has no content, omit it
Content Source: Extract corresponding version's content from CHANGELOG.md

Example 1 - Only New Features:

markdown

## What's Changed

### Added

- scope: feature support new validation rules
- add configuration item for custom behavior

**Full Changelog**: https://github.com/owner/repo/compare/v1.0.14...v1.0.15

Example 2 - Mixed Categories:

markdown

## What's Changed

### Added

- scope: feature add trim configuration support
- add named parameter support

### Fixed

- fix null value issue during data processing

### Changed

- CI: optimize test execution strategy

**Full Changelog**: https://github.com/owner/repo/compare/v1.0.13...v1.0.14

Example 3 - Only Bug Fixes:

markdown

## What's Changed

### Fixed

- scope: fix nested object validation issue

**Full Changelog**: https://github.com/owner/repo/compare/v1.0.12...v1.0.13

When Extracting Content from CHANGELOG:

Preserve original descriptions in CHANGELOG
Maintain categorization structure (Added/Fixed/Changed)
Preserve scope prefix (if any)
Remove date and version number (already included in Release title)
Ensure Full Changelog link is correct

Platform CLI Tools

GitHub

Requires
```
gh
```
CLI tool installation
GitHub token needs
```
repo
```
and
```
workflow
```
permissions
Installation: https://cli.github.com/

GitLab

Requires
```
glab
```
CLI tool installation
GitLab token needs
```
api
```
and
```
write_repository
```
permissions
Installation: https://glab.readthedocs.io/

Conventional Commits Support

This skill parses commit messages based on Conventional Commits specification:

Type	Category	Description
`feat:`	Added	New feature
`fix:`	Fixed	Bug fix
`break:` / `BREAKING CHANGE:`	Changed	Breaking change
`refactor:`	Changed	Code refactoring
`perf:`	Changed	Performance optimization
`chore:`	Changed	Build/toolchain updates
`docs:`	Changed	Documentation updates
`test:`	Changed	Test-related changes
`style:`	Changed	Code style (no functional impact)

Scope Support:

If commit message includes scope (e.g.,
```
feat(api): add new interface
```
), it will be displayed as
```
scope: api add new interface
```
in description

Scope format:

type(scope): description

type!: description

(breaking change)

Usage Examples

Release New Version: User says "release new version" or "create release"
Version Upgrade: User mentions version number bump or tag creation
Complete Important Features: After user adds important features or fixes multiple bugs
Scheduled Releases: Release versions on a scheduled basis (e.g., weekly, monthly)

Notes

Ensure all changes to be released have been committed and pushed to remote
CHANGELOG.md should exist in repository root directory
GitHub: Requires
```
gh
```
CLI tool installation to create GitHub Release
GitLab: Requires
```
glab
```
CLI tool installation to create GitLab Release
Self-hosted GitLab instances require additional configuration of
```
glab
```
host parameter
It is recommended to use Conventional Commits format for commit messages for automatic categorization

git-release

NPX Install

Tags

SKILL.md Content (Chinese)

Automated Git Releases (GitHub / GitLab)

Feature Overview

Release Workflow

Step 0: Verify Git Platform

Step 1: Analyze Commits and Update CHANGELOG

Step 2: Analyze Unreleased Changes

Step 3: Determine New Version Number

Step 4: Update CHANGELOG.md

Step 5: Create and Push Tag

Step 6: Create Release

GitHub Release

GitLab Release

Error Handling

CHANGELOG Format

Release Notes Format Specifications

Platform CLI Tools

GitHub

GitLab

Conventional Commits Support

Usage Examples

Notes