chore: add /release skill for automated SemVer version bumps
Adds a Claude Code skill that automates the release workflow: parse bump type (major/minor/patch), update Cargo.toml + Cargo.lock, commit, and tag. Intentionally does not auto-push so the user retains control over when releases go to the remote. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
106
.claude/skills/release/SKILL.md
Normal file
106
.claude/skills/release/SKILL.md
Normal file
@@ -0,0 +1,106 @@
|
|||||||
|
---
|
||||||
|
name: release
|
||||||
|
description: Bump version, tag, and prepare for next development cycle
|
||||||
|
version: 1.0.0
|
||||||
|
author: Taylor Eernisse
|
||||||
|
category: automation
|
||||||
|
tags: ["release", "versioning", "semver", "git"]
|
||||||
|
---
|
||||||
|
# Release
|
||||||
|
|
||||||
|
Automate SemVer version bumps for the `lore` CLI.
|
||||||
|
|
||||||
|
## Invocation
|
||||||
|
|
||||||
|
```
|
||||||
|
/release <type>
|
||||||
|
```
|
||||||
|
|
||||||
|
Where `<type>` is one of:
|
||||||
|
- **major** — breaking changes (0.5.0 -> 1.0.0)
|
||||||
|
- **minor** — new features (0.5.0 -> 0.6.0)
|
||||||
|
- **patch** / **hotfix** — bug fixes (0.5.0 -> 0.5.1)
|
||||||
|
|
||||||
|
If no type is provided, ask the user.
|
||||||
|
|
||||||
|
## Procedure
|
||||||
|
|
||||||
|
Follow these steps exactly. Do NOT skip any step.
|
||||||
|
|
||||||
|
### 1. Determine bump type
|
||||||
|
|
||||||
|
Parse the argument. Accept these aliases:
|
||||||
|
- `major`, `breaking` -> MAJOR
|
||||||
|
- `minor`, `feature`, `feat` -> MINOR
|
||||||
|
- `patch`, `hotfix`, `fix` -> PATCH
|
||||||
|
|
||||||
|
If the argument doesn't match, ask the user to clarify.
|
||||||
|
|
||||||
|
### 2. Read current version
|
||||||
|
|
||||||
|
Read `Cargo.toml` and extract the `version = "X.Y.Z"` line. Parse into major, minor, patch integers.
|
||||||
|
|
||||||
|
### 3. Compute new version
|
||||||
|
|
||||||
|
- MAJOR: `(major+1).0.0`
|
||||||
|
- MINOR: `major.(minor+1).0`
|
||||||
|
- PATCH: `major.minor.(patch+1)`
|
||||||
|
|
||||||
|
### 4. Check preconditions
|
||||||
|
|
||||||
|
Run `git status` and `git log --oneline -5`. Show the user:
|
||||||
|
- Current version: X.Y.Z
|
||||||
|
- New version: A.B.C
|
||||||
|
- Bump type: major/minor/patch
|
||||||
|
- Working tree status (clean or dirty)
|
||||||
|
- Last 5 commits (so they can confirm scope)
|
||||||
|
|
||||||
|
If the working tree is dirty, warn: "You have uncommitted changes. They will NOT be included in the release tag. Continue?"
|
||||||
|
|
||||||
|
Ask the user to confirm before proceeding.
|
||||||
|
|
||||||
|
### 5. Update Cargo.toml
|
||||||
|
|
||||||
|
Edit the `version = "..."` line in Cargo.toml to the new version.
|
||||||
|
|
||||||
|
### 6. Update Cargo.lock
|
||||||
|
|
||||||
|
Run `cargo check` to update Cargo.lock with the new version. This also verifies the project compiles.
|
||||||
|
|
||||||
|
### 7. Commit the version bump
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git add Cargo.toml Cargo.lock
|
||||||
|
git commit -m "release: v{NEW_VERSION}"
|
||||||
|
```
|
||||||
|
|
||||||
|
### 8. Tag the release
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git tag v{NEW_VERSION}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 9. Report
|
||||||
|
|
||||||
|
Print a summary:
|
||||||
|
```
|
||||||
|
Release v{NEW_VERSION} created.
|
||||||
|
|
||||||
|
Previous: v{OLD_VERSION}
|
||||||
|
Bump: {type}
|
||||||
|
Tag: v{NEW_VERSION}
|
||||||
|
Commit: {short hash}
|
||||||
|
|
||||||
|
To push: git push && git push --tags
|
||||||
|
```
|
||||||
|
|
||||||
|
Do NOT push automatically. The user decides when to push.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
```
|
||||||
|
/release minor -> 0.5.0 -> 0.6.0
|
||||||
|
/release hotfix -> 0.5.0 -> 0.5.1
|
||||||
|
/release patch -> 0.5.0 -> 0.5.1
|
||||||
|
/release major -> 0.5.0 -> 1.0.0
|
||||||
|
```
|
||||||
Reference in New Issue
Block a user