GitHub Release Automation — Version Bump to Published Release in One Command

The Problem

Releases are tedious. Not hard — tedious. And tedious is where mistakes live.

Here's what a release used to look like at PyratzLabs: open the repo, scan merged PRs since last tag, write a changelog by hand, decide if it's a patch or minor bump, tag the commit, draft the GitHub release, paste in the notes, hit publish. Then copy the announcement to Discord. Then Telegram. Miss a PR? Wrong version number? Forgot the migration note for that breaking change? Start over.

For Mr.Chief — a project with 31 agents pushing code — we were releasing weekly. That's 52 chances per year to mess up a changelog. I got tired of it after release three.

The Solution

A single natural language command to our DevOps agent: release mrchief v2026.3.8. The agent handles everything — version bump, release note generation, categorization, migration guide detection, contributor credits, GitHub publication, and cross-platform announcements.

Built on the gh CLI, GitLab API, and Mr.Chief's agent orchestration layer.

The Process

The command kicks off a pipeline. Here's what the agent actually does:

Step 1: Version Bump

# Agent updates version across all relevant files
sed -i 's/"version": ".*"/"version": "2026.3.8"/' package.json
sed -i "s/__version__ = '.*'/__version__ = '2026.3.8'/" mrchief/__init__.py

# Commit the bump
git add -A
git commit -m "chore: bump version to v2026.3.8"
git tag -a v2026.3.8 -m "Release v2026.3.8"
git push origin main --tags

Step 2: Generate Release Notes

The agent pulls all merged PRs since the last tag and categorizes them:

# Fetch PRs merged since last release
gh pr list --state merged --search "merged:>2026-03-01" \
  --json number,title,labels,author --limit 100

It parses labels to categorize:

## 🚀 Features
- Agent-to-agent message routing (#412) @thom-agent
- Webhook retry with exponential backoff (#408) @backend-sub

## 🐛 Bug Fixes
- Fix race condition in sandbox cleanup (#415) @devops-sub
- Correct timezone handling in cron scheduler (#411) @thom-agent

## 📚 Documentation
- Update SKILL.md template with new fields (#409) @alfrawd

Step 3: Breaking Change Detection

The agent scans PR descriptions and commit messages for breaking change indicators:

BREAKING_PATTERNS = [
    r'BREAKING CHANGE:', r'⚠️', r'migration required',
    r'removed.*endpoint', r'changed.*schema', r'renamed.*field'
]

If detected, it auto-generates a migration guide section:

## ⚠️ Breaking Changes & Migration Guide
### Webhook payload schema changed (#413)
- `event_type` field renamed to `event`
- Migration: update all webhook handlers to use `payload.event`

Step 4: Publish and Announce

# Create GitHub release with generated notes
gh release create v2026.3.8 \
  --title "Mr.Chief v2026.3.8" \
  --notes-file /tmp/release-notes.md \
  --latest

# Cross-post to Discord and Telegram
curl -X POST "$DISCORD_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{"content": "🚀 **Mr.Chief v2026.3.8** released!\n\n3 features, 2 fixes\n\nhttps://github.com/pyratzlabs/mrchief/releases/tag/v2026.3.8"}'

The Results

Try It Yourself

You need: gh CLI authenticated, a tagging convention, and PR labels. The agent logic is straightforward — the value isn't in complexity, it's in never forgetting a step. Set up your release template, define your label-to-category mapping, and let the agent run the checklist you'd otherwise skip at 6pm on a Friday.

Releases should be boring. That's the point.