agentsclimarketplace
Sign in

Release deploy

Skill balacodeio/balakit/skills/release-deploy

Release and deploy via GitHub tags and GitHub Actions (not every commit). Creates production releases from main and beta releases from staging using the GitHub CLI. Use when the user asks to release, ship, deploy, cut a version, tag a release, publish beta/production, create a GitHub Release, or bump a semver tag. On first use in a project, run the setup interview and write a project-specific config under projects/.From its SKILL.md

Install
npx -y skills add balacodeio/balakit --skill release-deploy

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.6 KB, 855 tokens by cl100k_base, as published. Nobody here has run it

Release & Deploy (GitHub Tags)

Leading words: commits ≠ deploys; branch → channel; tag triggers ship; changelog is truth; interview once; never guess channel.

Core model

  • Commits ≠ deploys. Only a git tag + GitHub Release triggers deployment (via GitHub Actions or project-specific release jobs).
  • Branch → channel
    • main → production release
    • staging → beta release
  • Tags
    • Production: vMAJOR.MINOR.PATCH (e.g. v1.4.0)
    • Beta: vMAJOR.MINOR.PATCH-beta.N (e.g. v1.4.0-beta.1)
  • Release notes come from the project's maintained CHANGELOG.md (do not invent a changelog). See references/versioning.md.

Before every release

  1. Load project config
  2. Confirm channel with the user: beta (staging) or production (main). Never guess.
  3. Verify git state (PowerShell-safe; run as separate commands):
    • Correct branch checked out (staging or main)
    • Working tree clean (or user explicitly accepts dirty)
    • Branch is up to date with its remote
    • HEAD is the commit they intend to ship
  4. Determine next version from existing tags + user intent. Follow references/versioning.md.
  5. Extract notes from CHANGELOG.md for that version (or [Unreleased] if they are cutting that section into a version). If changelog is missing/ambiguous → stop and ask.

Release workflow

Follow references/gh-release.md. Summary:

  1. Ensure on the correct branch at the intended commit.
  2. Create annotated tag locally (optional if gh release create will create it).
  3. gh release create with tag, title, notes from changelog, and --target set to the branch (or SHA).
  4. Watch the project's release/deploy workflow (from project config) until green or report failure.
  5. Summarize: tag, release URL, channel, deploy target/URL from project config.

Hard rules

  • Never tag production from staging, or beta from main, unless the project config explicitly documents a different branch map and the user confirms.
  • Never force-push tags or delete remote tags without explicit user request.
  • Never skip the interview on a first release in a repo.
  • Never fabricate changelog entries; only use CHANGELOG.md (or ask the user to update it first).
  • Prefer gh over raw API calls. Prefer project config over inventing deploy steps.

Platform-specific behavior

After the interview, project config names the stack. Read the matching reference only when needed:

Additional resources

What ships with it: 8 files

16.4 KB alongside SKILL.md

projects/

references/

Keep looking

Skills are one crate of 326,861. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.