Skill

release

Maak een nieuwe release van ZAD Actions. Gebruik bij vragen over 'release', 'versie', 'tag', 'version', 'publiceren', 'uitbrengen'.

npx claudepluginhub djimit/overheid-claude-plugins --plugin zad-actions

Configuration

Model: sonnet

Tool Access

This skill is limited to using the following tools:

Bash(git tag *)Bash(git push *)Bash(git fetch *)Read(*)

Preview

Create a validated release with annotated tag.

SKILL.md

Similar Skills

Create GitHub Release

Creates tagged GitHub releases with semantic versioning, categorized changelog notes, and optional build artifacts. Use for publishing stable software versions or distributing binaries.

agent-almanac

release

Creates GitHub releases with semantic versioning: analyzes commits for version bumps, generates changelogs, updates version files like package.json or pyproject.toml, creates git tags, publishes notes, and attaches artifacts.

alfred-dev

releasing

Automates semantic versioning releases via CHANGELOG validation, comparison links, GitHub Actions triggering/monitoring, and scaffolds release pipelines for projects.

8 files

git

Stats

Stars1

Forks2

Last CommitMar 18, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Release ZAD Actions

Create a validated release with annotated tag.

Usage

/release <version>

Example: /release 3.0.0

If no version is provided, ask the user for one.

Steps

Validate semver format: The version argument must match X.Y.Z (e.g., 2.1.0). Reject anything else.

Check for duplicate tags:

git fetch --tags
git tag -l "v<version>"

If the tag already exists, abort and inform the user.

Validate CHANGELOG.md: Read CHANGELOG.md and verify:

A ## [<version>] section exists with content
The ## [Unreleased] section is empty (all changes moved to the version section)
A comparison link exists at the bottom: [<version>]: https://github.com/RijksICTGilde/zad-actions/releases/tag/v<version>
The comparison links are in correct order (newest first)

If any of these fail, fix them or tell the user what needs to change.

Major version warning: If the major version changes (e.g., 1.x.x to 2.0.0), warn the user:

Breaking changes require updating the ## Migration from vX section
Users referencing the previous major version will NOT get this update automatically

Extract release notes: Extract the content between ## [<version>] and the next ## [ heading from CHANGELOG.md.

Create and push annotated tag:

git tag -a "v<version>" -m "<release notes>"
git push origin "v<version>"

The release workflow (.github/workflows/release.yml) handles:

Creating the GitHub Release
Updating the major version tag (e.g., v2)
Rolling back the tag on failure

Semver rules

Major (X.0.0): Breaking changes (removed/renamed inputs, changed behavior)

Minor (x.Y.0): New features (new inputs, new actions)

Patch (x.y.Z): Bug fixes, documentation changes

Release ZAD Actions

Create a validated release with annotated tag.

Usage

/release <version>

Example: /release 3.0.0

If no version is provided, ask the user for one.

Steps

Validate semver format: The version argument must match X.Y.Z (e.g., 2.1.0). Reject anything else.
Check for duplicate tags:
```
git fetch --tags
git tag -l "v<version>"
```
If the tag already exists, abort and inform the user.
Validate CHANGELOG.md: Read CHANGELOG.md and verify:
- A ## [<version>] section exists with content
- The ## [Unreleased] section is empty (all changes moved to the version section)
- A comparison link exists at the bottom: [<version>]: https://github.com/RijksICTGilde/zad-actions/releases/tag/v<version>
- The comparison links are in correct order (newest first)
If any of these fail, fix them or tell the user what needs to change.
Major version warning: If the major version changes (e.g., 1.x.x to 2.0.0), warn the user:
- Breaking changes require updating the ## Migration from vX section
- Users referencing the previous major version will NOT get this update automatically
Extract release notes: Extract the content between ## [<version>] and the next ## [ heading from CHANGELOG.md.
Create and push annotated tag:
```
git tag -a "v<version>" -m "<release notes>"
git push origin "v<version>"
```
The release workflow (.github/workflows/release.yml) handles:
- Creating the GitHub Release
- Updating the major version tag (e.g., v2)
- Rolling back the tag on failure

Semver rules

We follow Semantic Versioning:

Major (X.0.0): Breaking changes (removed/renamed inputs, changed behavior)
Minor (x.Y.0): New features (new inputs, new actions)
Patch (x.y.Z): Bug fixes, documentation changes