home / skills / chachamaru127 / claude-code-harness / release-har

release-har skill

/skills/release-har

This skill automates release workflows across projects, generating changelogs, bumping versions, tagging releases, and publishing GitHub releases.

npx playbooks add skill chachamaru127/claude-code-harness --skill release-har

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.4 KB
---
name: release-har
description: "Universal release automation. CHANGELOG, commit, tag, GitHub Release supported. Use when user mentions release, version bump, create tag, publish release. Do NOT load for: harness release (use x-release-harness instead)."
description-en: "Universal release automation. CHANGELOG, commit, tag, GitHub Release supported. Use when user mentions release, version bump, create tag, publish release. Do NOT load for: harness release (use x-release-harness instead)."
description-ja: "汎用リリース自動化。CHANGELOG、コミット、タグ、GitHub Release をサポート。Use when user mentions release, version bump, create tag, publish release. Do NOT load for: harness release (use x-release-harness instead)."
allowed-tools: ["Read", "Write", "Edit", "Bash"]
argument-hint: "[patch|minor|major]"
context: fork
---

# Release Har Skill

Universal release automation skill. Works with any project.

## Quick Reference

- "**release**" -> `/release-har`
- "**bump version**" -> `/release-har patch`
- "**minor release**" -> `/release-har minor`

---

## Execution Flow

### Step 1: Check Current State

Run in parallel:

```bash
# Uncommitted changes
git status

# Changed files
git diff --stat

# Recent commit history
git log --oneline -10

# Existing tags
git tag --sort=-v:refname | head -5
```

### Step 2: Determine Version

Based on [Semantic Versioning](https://semver.org/):

| Version | Change Type |
|---------|-------------|
| **patch** (x.y.Z) | Bug fixes, minor improvements |
| **minor** (x.Y.0) | New features (backward compatible) |
| **major** (X.0.0) | Breaking changes |

Ask user: "What should the next version be? (e.g., 1.2.3)"

### Step 3: Update CHANGELOG (if exists)

If project has CHANGELOG.md, update it:

```markdown
## [X.Y.Z] - YYYY-MM-DD

### Added
- New feature

### Changed
- Change description

### Fixed
- Bug fix
```

**Skip if CHANGELOG does not exist**

### Step 4: Update Version Files (project-dependent)

Update version files based on project configuration:

| File | Update Method |
|------|---------------|
| `package.json` | `"version": "X.Y.Z"` |
| `pyproject.toml` | `version = "X.Y.Z"` |
| `VERSION` | Direct content update |
| `Cargo.toml` | `version = "X.Y.Z"` |

**Skip if no applicable file exists**

### Step 5: Commit and Tag

```bash
# Stage
git add -A

# Commit (only if changes exist)
git commit -m "chore: release vX.Y.Z"

# Create tag
git tag -a vX.Y.Z -m "Release vX.Y.Z"
```

### Step 6: Push

```bash
# Push branch
git push origin $(git branch --show-current)

# Push tag
git push origin vX.Y.Z
```

### Step 7: GitHub Release (Optional)

After user confirmation, create GitHub Release:

```bash
gh release create vX.Y.Z \
  --title "vX.Y.Z - Title" \
  --notes "$(cat <<'EOF'
## What's Changed

- Change 1
- Change 2

**Full Changelog**: https://github.com/OWNER/REPO/compare/vPREV...vX.Y.Z
EOF
)"
```

---

## Options

| Option | Description |
|--------|-------------|
| `patch` | Auto-increment patch version |
| `minor` | Auto-increment minor version |
| `major` | Auto-increment major version |
| `--dry-run` | Preview only, no execution |

---

## Project-Specific Handling

### Node.js (package.json)

```bash
npm version patch --no-git-tag-version
```

### Python (pyproject.toml)

Manually update `version = "X.Y.Z"`

### Rust (Cargo.toml)

Manually update `version = "X.Y.Z"`

---

## Related Skills

- `x-release-harness` - Harness plugin specific release (local only)
- `verify` - Pre-release verification

Overview

This skill automates universal release tasks across projects: version determination, changelog updates, file version bumps, git commits, tags, pushes, and optional GitHub Releases. It supports semantic versioning and common file types (package.json, pyproject.toml, Cargo.toml, VERSION). Use it to reduce manual steps and ensure consistent, repeatable releases.

How this skill works

The skill inspects the repository state (uncommitted changes, diffs, recent commits, existing tags) and asks for the next version or takes a semantic increment (patch/minor/major). It updates changelogs if present, edits applicable version files, stages and commits changes, creates annotated git tags, pushes branch and tag, and can create a GitHub Release with assembled release notes. A --dry-run option previews actions without executing them.

When to use it

  • When you need to bump a project version (patch/minor/major) and create a git tag.
  • When preparing a release and you want changelog and version files updated consistently.
  • When you want to push a release tag and optionally create a GitHub Release.
  • When you want an automated, repeatable release flow across multiple language projects.
  • When you need a dry-run preview to validate release steps before execution.

Best practices

  • Ensure the working tree is clean before starting to avoid unintended changes.
  • Run the skill with --dry-run first to verify the computed version and file changes.
  • Update or maintain CHANGELOG.md entries before or during the release step for clear release notes.
  • Confirm the chosen version (prompted by the skill) to avoid accidental major bumps.
  • Use branch protection and CI checks before pushing release tags to main branches.

Example use cases

  • Bump a Node.js package patch version, update package.json, commit, tag vX.Y.Z, and push.
  • Perform a minor release for a Python project by editing pyproject.toml and creating a GitHub Release.
  • Create a release for a Rust crate by updating Cargo.toml, tagging, and pushing the release tag.
  • Preview a release with --dry-run to inspect changes before committing and tagging.
  • Generate release notes from recent commits and publish a GitHub Release with the assembled notes.

FAQ

What file types does the skill update?

Common files supported include package.json, pyproject.toml, Cargo.toml, and plain VERSION files; it skips files that don't exist.

Can I automate the version increment?

Yes — use options patch, minor, or major to auto-increment according to semantic versioning; you can also provide an explicit version.

Does it publish to registries (npm/PyPI/crates.io)?

No — the skill handles versioning, tagging, and GitHub Releases. Publishing to registries should be done with your existing publish workflows or CI.