Release Skill

Creates a release by comparing dev to main, generating changelog entries from commits, bumping the version, and creating a PR. After the tag is pushed and the release workflow finishes building binaries, updates the Homebrew formula with the real SHA256 values from the published checksums.txt, syncs the coleam00/homebrew-archon tap, and verifies the end-to-end install path via /test-release.

⚠️ CRITICAL, Homebrew formula SHAs cannot be known until after the release workflow builds binaries.

The version field in homebrew/archon.rb and the sha256 fields must be updated atomically. Never update one without the other.

The correct sequence is:

1. Tag is pushed → release workflow fires → binaries built → checksums.txt uploaded
2. Fetch checksums.txt from the published release
3. Parse the SHA256 per platform
4. Update homebrew/archon.rb with the new version AND the new SHAs in a single commit
5. Sync to the coleam00/homebrew-archon/Formula/archon.rb tap repo

Updating the formula's version field without also updating the sha256 values creates a stale, misleading formula that looks valid but produces checksum mismatches on install. This has happened before (v0.3.0: version updated to 0.3.0 but SHAs were still from v0.2.13). Always do both or neither.

Process

Step 1: Validate State

# Must be on dev branch with clean working tree
git checkout dev
git pull origin dev --no-rebase
git status --porcelain  # must be empty
git fetch origin main

If not on dev or working tree is dirty, abort with a clear message.

Then check that dev actually contains main. Anything committed directly to main, a docs typo fix, a hotfix, the previous release's formula commit, stays stranded there until someone merges it back. The release PR would then propose reverting it, and the next release inherits the drift.