Release Process
SkillDev toolsRelease process for mdvs. Use when the user asks to make a release (patch, minor, major, or release candidate).
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Release Process skill
What this skill tells your AI
The instructions your AI receives, as published by edochi/mdvs in .claude/skills/release/SKILL.md and read by ahel’s review.
Releases go through a branch + PR (because main is protected), then a tag push
triggers the GitHub Actions release workflow (cargo-dist) that builds
cross-platform binaries and creates a GitHub Release.
Prerequisites
Before releasing, verify:
- All tests pass:
cargo test
cargo clippy -- -D warnings
cargo fmt --check
- Main branch is clean and up to date:
git checkout main && git pull
git status # must be clean
git log --oneline -5 # review recent commits
- CI is green on the latest commit:
gh run list --limit 1
Making a release
Step 1: Create release branch
git checkout -b release/v<version> main
Step 2: Bump version and changelog
Use cog bump with --skip-push (since we can't push directly to main):
cog bump --<level> --skip-push # or --auto --skip-push
This will:
- Bump the version in
Cargo.toml - Generate/update
CHANGELOG.mdfrom conventional commits - Create a bump commit
- Create a git tag
v<new_version>
If cog bump doesn't support --skip-push, do it manually:
- Edit
Cargo.tomlversion field - Run
cog changelog > CHANGELOG.md(or update manually) - Commit:
git commit -am "chore(release): v<version>"
Step 3: Push branch and create PR
git push -u origin release/v<version>
gh pr create --title "chore(release): v<version>" --body "Version bump and changelog for v<version>"
Wait for CI to pass, then merge the PR.
Step 4: Tag and push
After the PR is merged, tag main and push the tag:
git checkout main && git pull
git tag v<version>
git push origin v<version>
The tag push triggers .github/workflows/release.yml, which builds binaries for
macOS, Linux, and Windows, and creates a GitHub Release.
Release levels
| Level | Example | Use case |
|---|---|---|
--patch | 0.1.0 → 0.1.1 | Bug fixes |
--minor | 0.1.0 → 0.2.0 | New features |
--major | 0.1.0 → 1.0.0 | Breaking changes |
--minor --pre rc | 0.1.0 → 0.2.0-rc.1 | Release candidate |
--auto | (auto-detected) | Let commits decide |
Step 5: Monitor the release build
gh run list --limit 1 # find the run ID
gh run watch <run-id> --exit-status # live follow
If a build fails:
gh run view --job=<job-id> --log-failed
After success, verify the GitHub Release:
gh release view v<version>
Configuration
cog.toml— cocogitto config (tag prefix, bump hooks, changelog, commit validation)Cargo.toml— version field,[package.metadata.dist].github/workflows/release.yml— auto-generated bydist generate, do not hand-edit
Important notes
publish = false— no crates.io publishing. Releases are GitHub-only for now.- Tag format is
v{version}(e.g.,v0.1.0), configured bytag_prefix = "v"incog.toml. - Prerelease tags (e.g.,
v0.1.0-rc.1) create a GitHub Release marked as prerelease. --autoreads commits since last tag:feat:→ minor,fix:→ patch,BREAKING CHANGE→ major.- If cargo-dist config changes, regenerate the workflow:
dist generate - Branch protection blocks direct pushes to main — releases always go through a PR. Tags are not blocked.
Signals
- GitHub stars
- 27
- Forks
- 2
- Last commit
- Aug 2026
- Hacker News mentions
- 20
Advanced
- Catalog kind
- skill
- Gateway key
release-edochi- Source
- github.com/edochi/mdvs