This Claude skill automates the end-to-end software release lifecycle, specifically designed for Windows applications. It streamlines DevOps workflows by analyzing commit history for semantic versioning, executing build scripts, and generating distributable packages, ensuring a consistent and error-free deployment process.

When should I use release?

release is useful in the following scenarios: • Automated Semantic Versioning: Analyzing git logs to determine if a release should be a Major, Minor, or Patch update based on change scope. • Build and Distribution Packaging: Compiling .NET applications into self-contained executables and automatically creating ZIP archives for end-user distribution. • Version Synchronization: Updating project metadata (e.g., .csproj files) and creating corresponding Git tags to maintain a clean and traceable version history. • Release Readiness Auditing: Using automated checklists to verify that all changes are committed and the application builds successfully before publishing.

name	Release
description	This skill should be used when the user asks to "create a release", "make a release", "publish a new version", "bump version", "prepare release", "build release zip", or mentions releasing, versioning, or packaging the application.
version	1.0.0

Release Skill for ProxyStat Windows

Create releases for the ProxyStat Windows application by analyzing changes, bumping the semantic version, building the application, and packaging it into a distributable zip file.

When to Use

Creating a new release
Bumping the version number
Packaging the application for distribution
Checking what changed since the last release

Release Process

Step 1: Check for Changes

Identify the last release tag and analyze commits since then:

# Get the latest release tag
git describe --tags --abbrev=0

# List commits since last tag
git log "$(git describe --tags --abbrev=0)..HEAD" --oneline

Or run the helper script:

./scripts/Analyze-Changes.ps1

If no tags exist, this is the initial release (1.0.0).

Step 2: Analyze Change Scope

Review the commits to determine the version bump type:

Change Type	Version Bump	Examples
Major	X.0.0	Breaking changes, major rewrites, incompatible API changes
Minor	x.Y.0	New features, significant enhancements, new capabilities
Patch	x.y.Z	Bug fixes, small improvements, documentation updates

If uncertain about the scope, ask the user before proceeding.

Common indicators:

Major: "breaking", "rewrite", "redesign", "incompatible"
Minor: "add", "feature", "new", "enhance", "support"
Patch: "fix", "update", "correct", "typo", "docs"

Step 3: Update Version

Update the version in ProxyStat/ProxyStat.csproj:

<Version>X.Y.Z</Version>

Step 4: Build the Application

Build and publish a self-contained release:

cd ProxyStat
dotnet publish -c Release -r win-x64 --self-contained true -o ../publish

Or run the helper script:

./scripts/Build-Release.ps1 -Version X.Y.Z

This creates a self-contained executable that runs without .NET installed.

Step 5: Create Release Package

The build script automatically creates the zip. If done manually:

New-Item -ItemType Directory -Path releases -Force
Compress-Archive -Path publish/* -DestinationPath "releases/ProxyStat-vX.Y.Z-win-x64.zip"

The zip should contain:

ProxyStat.exe - Main executable
All required DLLs and runtime files

Step 6: Create Git Tag

Tag the release and push:

git add ProxyStat/ProxyStat.csproj
git commit -m "Bump version to X.Y.Z"
git tag vX.Y.Z
git push origin main --tags

Output

The release process produces:

Updated version in ProxyStat.csproj
Git tag vX.Y.Z
Release zip: releases/ProxyStat-vX.Y.Z-win-x64.zip

Version History Convention

Tags follow the format vX.Y.Z (e.g., v1.0.0, v1.1.0, v2.0.0).

Checklist

Before creating a release:

All changes committed
Changes analyzed for version bump type
Version updated in .csproj
Application builds successfully
Zip package created
Git tag created and pushed

release

When & Why to Use This Skill

Use Cases