agentleFS
Sign inStart free
afaraha8403afaraha8403/balakit/.agents/skills/release-deploy/SKILL.md

release-deploy

Skill1 starsChanged 9 days agoMITView on GitHub

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/.

  • Commits and pushes

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Commits ≠ deploys: Only a git tag + GitHub Release triggers deployment (via GitHub Actions or project-specific release jobs).

    line 35
  2. Very specific:

    Look for projects/<repo-slug>.md next to this SKILL.md (slug = GitHub owner/repo with / → -, e.g.

    line 47
  3. Distinctive:

    If missing → run the first-time interview in references/interview.md, write the file from references/project.template.md, then continue.

    line 48
  4. Distinctive:

    Follow references/gh-release.md.

    line 60
  5. Distinctive:

    Ensure on the correct branch at the intended commit.

    line 62
  6. Very specific:

    Create annotated tag locally (optional if gh release create will create it).

    line 63
  7. Very specific:

    Never tag production from staging, or beta from main, unless the project config explicitly documents a different branch map and the user …

    line 70
  8. Distinctive:

    Never force-push tags or delete remote tags without explicit user request.

    line 71
  9. Distinctive:

    Never skip the interview on a first release in a repo.

    line 72
  10. Very specific:

    Never fabricate changelog entries.

    line 73
  11. Very specific:

    Prefer gh over raw API calls.

    line 74
  12. Distinctive:

    After the interview, project config names the stack.

    line 78

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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
    • Look for projects/<repo-slug>.md next to this SKILL.md (slug = GitHub owner/repo with / → -, e.g. acme-web-app).
    • If missing → run the first-time interview in references/interview.md, write the file from references/project.template.md, then continue.
  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:

  • Cloudflare Workers/Pages → references/platforms/cloudflare.md
  • Desktop apps (installers, auto-update, signed builds) → references/platforms/desktop.md
  • Generic / other → rely on projects/<slug>.md workflow names and URLs

Additional resources

  • references/interview.md — first-time setup questions
  • references/project.template.md — config file shape
  • references/versioning.md — semver + changelog rules
  • references/gh-release.md — GitHub CLI commands

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free