hex-release
Automates the release workflow for Hex packages, including versioning and changelogs.
Install
mkdir -p .claude/skills/hex-release && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2778" && unzip -o skill.zip -d .claude/skills/hex-release && rm skill.zipInstalls to .claude/skills/hex-release
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guides interactive Hex package release for AgentJido repos. Supports automated (GitHub Actions workflow_dispatch) and manual release flows. Uses git_ops for version bumping and changelog generation. Triggers on: release, hex publish, bump version, new release, publish package.Key capabilities
- →Identify Hex package name and current version from mix.exs
- →Check for git dependencies that block Hex publishing
- →Verify git status for uncommitted changes
- →Confirm current git branch is 'main'
- →Check for releasable commits since the last tag
- →Run project tests and quality checks
How it works
The skill performs pre-flight checks on an Elixir project, then guides the user through either an automated GitHub Actions workflow or a manual local process to bump the version, update the CHANGELOG, create a git tag, and publish to Hex.
Inputs & outputs
When to use hex-release
- →Bump project version
- →Publish to Hex
- →Generate automated release changelog
- →Tag new release in git
About this skill
Hex Release (Human-in-the-Loop)
Interactive workflow for releasing a Hex package with manual verification at each step. Supports two release paths: automated (via GitHub Actions) and manual (local).
When to Use
Use this skill when asked to:
- Release a new version to Hex
- Bump the package version
- Prepare a release
- Create a release tag
- Trigger a release workflow
Pre-flight Checks
Before starting, run these checks automatically:
1. Identify the Package
Read mix.exs to determine:
- Package name (from
project()→:nameor:app) - Current version (from
@versionorproject()→:version) - Whether it has
git_opsas a dependency (required for automated release)
2. Check for Git Dependencies
grep -E 'github:|git:|path:' mix.exs
Categorize any git/path deps found:
- dev/test only (
only: [:dev, :test]): Will not block Hex publish — note but continue - runtime deps: STOP — these block
mix hex.publish. Tell the user which deps need to be published to Hex first or switched to Hex versions
3. Git Status
git status --porcelain
If dirty, STOP and ask user to commit or stash changes first.
4. Verify Branch
git branch --show-current
Confirm user is on main. Warn if on a different branch.
5. Check for Releasable Commits
git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || echo "")..HEAD
If no commits since last tag, STOP — nothing to release.
Review commits and confirm they follow conventional commit format (feat:, fix:, chore:, etc.).
Non-conventional commits won't be picked up by git_ops for the CHANGELOG.
6. Run Tests
mix test
If tests fail, STOP and show failures.
7. Run Quality Checks
mix quality
This typically runs: format check, compile with warnings-as-errors, credo, and dialyzer.
If the alias doesn't exist, run mix format --check-formatted && mix compile --warnings-as-errors as a minimum.
If any check fails, STOP and show the issues.
8. Hex Publish Dry Run
mix hex.publish --dry-run
Verify the package metadata and file list look correct. If this fails, STOP.
SHOW USER: Summary of all pre-flight results and current version.
ASK USER: "All checks passed. Which release path: automated (GitHub Actions) or manual (local)?"
Path A: Automated Release (GitHub Actions)
The AgentJido repos have a reusable release workflow triggered via workflow_dispatch.
Step 1: Confirm Workflow Exists
Check that .github/workflows/release.yml exists and calls:
uses: agentjido/github-actions/.github/workflows/elixir-release.yml@main
Step 2: Explain Dispatch Options
TELL USER:
The release workflow supports these options:
• dry_run: true — Full dry run (no git push, no tag, no Hex publish)
• hex_dry_run: true — Runs git_ops release + push, but skips actual Hex publish
• skip_tests: true — Skip test step (use if CI already passed)
Recommended first run: dry_run: true
Step 3: Trigger the Workflow
Option 1 — GitHub CLI (if gh is available):
# Dry run first
gh workflow run release.yml -f dry_run=true
# Watch the run
gh run list --workflow=release.yml --limit=1
gh run watch
Option 2 — GitHub UI:
1. Go to: https://github.com/agentjido/{REPO}/actions/workflows/release.yml
2. Click "Run workflow"
3. Set dry_run = true for first attempt
4. Click "Run workflow"
ASK USER: "Run a dry run first? (recommended)"
Step 4: Verify Dry Run Results
After the dry run completes:
gh run view --log-failed # Check for errors
Review the workflow summary for:
- Version that would be released
- Hex publish dry-run output
- Any skipped steps
ASK USER: "Dry run succeeded. Ready to run the real release?"
Step 5: Trigger Real Release
gh workflow run release.yml
# Or with skip_tests if CI already passed:
gh workflow run release.yml -f skip_tests=true
Step 6: Verify
gh run watch # Wait for completion
TELL USER:
✅ Release triggered!
The workflow will:
1. Run git_ops.release to bump version + update CHANGELOG
2. Push the release commit and tag
3. Publish to Hex.pm
4. Create a GitHub Release
Monitor at: https://github.com/agentjido/{REPO}/actions
After publish, verify at: https://hex.pm/packages/{PACKAGE}
Path B: Manual Release (Local)
Use when the automated workflow isn't available, or for repos that can't publish to Hex (e.g., git deps blocking publish).
Step 1: Determine Version Bump
git_ops handles this automatically from conventional commits, but ask the user for confirmation.
Run the release in dry-run mode to preview:
mix git_ops.release --dry-run
This shows what version would be bumped to based on commit types:
feat:commits → minor bumpfix:commits → patch bumpBREAKING CHANGE:→ major bump
SHOW USER: The proposed version bump and commits that will be included.
ASK USER: "git_ops wants to release vX.Y.Z. Proceed, or override with a specific version?"
Step 2: Run the Release
# Let git_ops decide the version:
mix git_ops.release --yes
# Or force a specific version:
mix git_ops.release --yes --new-version X.Y.Z
This will:
- Bump the version in
mix.exs - Update
CHANGELOG.mdfrom conventional commits - Create a release commit
- Create a git tag
SHOW USER: The release commit diff and tag.
Step 3: Review Before Pushing
git log --oneline -3
git diff HEAD~1
git tag -l | tail -5
ASK USER: "Release commit and tag created locally. Ready to push?"
Step 4: Push
git push origin main
git push origin --tags
Step 5: Publish to Hex
# Final dry-run check
mix hex.publish --dry-run
# Publish
mix hex.publish --yes
Step 6: Create GitHub Release
VERSION="v$(grep -m1 '@version "' mix.exs | sed 's/.*"\(.*\)".*/\1/')"
gh release create "$VERSION" \
--title "Release $VERSION" \
--notes "See [CHANGELOG.md](CHANGELOG.md) for details."
TELL USER:
✅ Release complete!
Published: https://hex.pm/packages/{PACKAGE}
GitHub: https://github.com/agentjido/{REPO}/releases/tag/{VERSION}
Rollback
Before pushing:
git reset --soft HEAD~1 # Undo release commit
git tag -d v{VERSION} # Delete local tag
git checkout mix.exs CHANGELOG.md # Restore files
After pushing but before Hex publish:
git push origin :refs/tags/v{VERSION} # Delete remote tag
git revert HEAD # Revert release commit
git push origin main
After Hex publish:
Hex packages cannot be unpublished after 1 hour. You can retire a version:
mix hex.retire {PACKAGE} {VERSION} invalid --message "Released in error"
Notes
- All AgentJido repos use conventional commits — non-conventional commits are ignored by
git_ops - The
qualitymix alias varies per repo — checkmix.exsaliases section git_opsis a dev-only dependency — release commands run inMIX_ENV=dev- The automated workflow uses
GITHUB_TOKENfor git push andHEX_API_KEY(org secret) for Hex publish - Repos with runtime git dependencies (e.g.,
jido_runic) cannot publish to Hex — use manual path for git tag/release only, skip Hex publish step
When not to use it
- →When runtime git dependencies are present and Hex publishing is desired
- →When no commits have been made since the last tag
- →When git status is dirty with uncommitted changes
Limitations
- →Requires `git_ops` as a dependency for automated release
- →Cannot publish to Hex if runtime git dependencies exist
- →Non-conventional commits are ignored by `git_ops` for CHANGELOG generation
How it compares
This skill automates and guides the Hex package release process with interactive verification steps, unlike a purely manual release that requires direct command execution and checks.
Compared to similar skills
hex-release side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| hex-release (this skill) | 2 | 5mo | Review | Intermediate |
| run-nx-generator | 5 | 3mo | Review | Intermediate |
| upgrading-expo | 3 | 4mo | Review | Intermediate |
| monorepo | 1 | 2mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
run-nx-generator
nrwl
Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
upgrading-expo
sickn33
Upgrade Expo SDK versions
monorepo
EpicenterHQ
Monorepo script commands and conventions for this codebase. Use when running builds, tests, formatting, linting, or type checking.
agent-release-manager
ruvnet
Agent skill for release-manager - invoke with $agent-release-manager
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
turborepo
vercel
Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.