git-workflow-manager_skill

This skill enforces conventional commits, semantic versioning, and changelog discipline to streamline releases and improve project clarity.
  • Shell

65

GitHub Stars

3

Bundled Files

3 weeks ago

Catalog Refreshed

2 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstart where the catalogue uses aiagentskills.

npx veilstart add skill serejaris/ris-claude-code --skill git-workflow-manager

  • README.md1.8 KB
  • README.ru.md2.4 KB
  • SKILL.md3.0 KB

Overview

This skill enforces a consistent git workflow for commits, versioning, changelogs, and release notes. It automates and validates conventional commit messages and maps them to semantic version bumps. It also standardizes changelog structure and a release notes template to keep releases predictable and traceable.

How this skill works

It inspects commit messages since the last tag to determine the required semantic version bump (major, minor, patch) based on conventional commit types and breaking-change markers. It guides updating CHANGELOG.md by moving Unreleased entries into a dated release section and commits those changes, creates an annotated tag, and helps publish a GitHub release with a formatted release notes file. It provides quick commands and templates to avoid common mistakes and maintain a uniform release process.

When to use it

  • Before committing code to enforce conventional commit messages
  • When preparing a release to compute the next semantic version
  • When updating or generating CHANGELOG.md entries
  • When creating a GitHub release to ensure release notes follow a template
  • During CI checks to validate commit and changelog consistency

Best practices

  • Always prefix commit messages with conventional types (feat:, fix:, docs:, refactor:, chore:)
  • Use feat!: or fix!: to indicate breaking changes and trigger a major bump
  • Update CHANGELOG.md from the Unreleased section before tagging
  • Commit the changelog change separately using docs: update changelog for vX.Y.Z
  • Use annotated tags (git tag -a) and create a matching GitHub release with gh release create

Example use cases

  • Compute next version from commits since last tag and choose correct bump (patch/minor/major)
  • Move Unreleased changelog items into a new dated section and commit the update
  • Create an annotated tag and push tags, then publish a GitHub release with a prepared release-notes file
  • Run a pre-release script in CI to fail the pipeline on malformed conventional commits
  • Generate release notes from structured sections (What’s New, Key points, Installation) for consistent user-facing releases

FAQ

A major bump occurs when a commit includes a breaking-change marker like feat!: or fix!: or when commit body indicates BREAKING CHANGE. The tool scans commit headers and bodies since the last tag.

What sections should CHANGELOG.md include?

Keep these sections: Added, Changed, Deprecated, Removed, Fixed, Security, plus an Unreleased section and per-version dated sections for released versions.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
git-workflow-manager skill by serejaris/ris-claude-code | VeilStrat