New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Gh Release

by TracecatHQ in TracecatHQ/tracecat

Cut a stable GitHub release or prerelease directly from a Tracecat release branch, including the version bump, tag, image verification, and categorized release notes.

AGPL-3.0Auto-check passedDevelopment

Install Gh Release

skills CLI
$ npx skills add TracecatHQ/tracecat --skill gh-release -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install TracecatHQ/tracecat gh-release --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/TracecatHQ/tracecat.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/gh-release .claude/skills/gh-release && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
gh-release
GitHub stars
3.8k
Token cost
~3.1k tokens
SKILL.md length
1,711 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Cut a stable GitHub release or prerelease directly from a Tracecat release branch, including the version bump, tag, image verification, and categorized release notes.

  • Tasks that involve Changelog and release notes
  • SKILL.md covers Choose the version and branch, Preflight and confirmation, Bump, commit, and tag and Verify the images before…, plus 2 more sections
  • Calls gh, git and uv

What it does

Gh Release is an agent skill from TracecatHQ/tracecat. Cut a stable GitHub release or prerelease directly from a Tracecat release branch, including the version bump, tag, image verification, and categorized release notes.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Changelog and release notes. It works with GitHub. The repository describes itself as: Open-source security automation platform for teams and AI agents. The licence is AGPL-3.0.

When your agent uses it

  • Tasks that involve Changelog and release notes

Example prompts

  • “/gh-release”

Requirements

  • Python 3

What it can do on your machine

Read from SKILL.md and the folder at commit a01d80b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git
    • uv
    • just

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, git and uv, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Gh Release loads about 3.1k tokens when it runs. Until then it costs about 44 tokens; SKILL.md has 1,711 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~44
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from TracecatHQ/tracecat at commit a01d80b, republished under its AGPL-3.0 licence (© TracecatHQ). 1,711 words, ~3,090 tokens.

Download SKILL.mdSave it as .claude/skills/gh-release/SKILL.md (or your agent's skills folder).
name
gh-release
description
Cut a stable GitHub release or prerelease directly from a Tracecat release branch, including the version bump, tag, image verification, and categorized release notes.
argument-hint
[<tag>] [<commit>]

gh-release

Cut a release directly from a release branch. Do not open a release PR, merge the release branch into main, or advance main to record a release. Follow the version policy in CONTRIBUTING.md.

Choose the version and branch

Parse $ARGUMENTS as <tag> [<commit>]. Tags are bare public versions without v: 1.2.0-alpha.1, 1.2.0-alpha.1.1, 1.2.0-rc.1, 1.2.0, or 1.2.1. Validate numeric components without leading zeros. Prereleases use alpha.N, alpha.N.M (a hotfix of alpha N), or rc.N and only attach to a .0. Stable patches increment the patch component. If no tag was given, inspect published releases and ask which version to cut. Do not infer permission to publish from a request to inspect or prepare a release.

  • Before freeze, a new alpha X.Y.0-alpha.N starts from the chosen merged main commit (default origin/main) on release/X.Y.0-alpha.N.
  • An alpha hotfix X.Y.0-alpha.N.M reuses release/X.Y.0-alpha.N. Require the existing branch and a published alpha on that line; no stable release is required. Cherry-pick fixes onto it and add successive immutable tags. Never create a branch per hotfix or start the hotfix from newer main code. For example, 1.1.0-alpha.1.1 and 1.1.0-alpha.1.2 both use release/1.1.0-alpha.1; 1.1.0-alpha.2 starts a new alpha line from main.
  • At freeze, create release/<major>.<minor> from the chosen merged main commit. RCs, stable minors, and subsequent patches use that train branch.
  • For an existing alpha line or frozen train, default to its current remote tip. An explicit commit must be that tip; prepare any required cherry-picks separately first. Never reset a release branch to main or create a patch branch from newer trunk code.
  • A stable patch requires an existing train branch and a published stable release on that train.
  • Both alpha hotfixes and stable patches contain fixes that landed on main first and were cherry-picked onto the release branch. Verify the full diff from the previous release: no migration changes, database-schema changes, backfills, or new registry actions. If a fix depends on those changes, exclude it rather than pulling its feature dependencies into the patch.

Resolve the selected commit to an immutable COMMIT_SHA and the branch to BRANCH. A new alpha line's base or a new train's base must be reachable from origin/main; hotfix commits instead descend from their release branch and retain the source commits' cherry-pick provenance. Do not release an unmerged PR. Check the selected commit's CI and stop on missing or failing evidence unless the user explicitly accepts it. Verify the selected branch contains the stable-only image guard and the current release workflow before cutting its tag; old train branches may need those changes cherry-picked first.

Preflight and confirmation

Fetch branches and tags, inspect the working tree, and verify the public tag is absent locally, remotely, and from GitHub releases. Distinguish a missing release from an API/authentication error. If the tag exists, stop; never move it.

A new alpha line's branch must be absent remotely and locally. For an alpha hotfix or an existing frozen train, reuse the existing release branch; create a train branch only at its initial freeze. Preserve any prepared local cherry-picks and verify they fast-forward the remote tip before pushing. Use an isolated worktree if the branch is checked out elsewhere. Do not stash, reset, or overwrite unrelated working changes.

Strict invariant: patches cannot contain database migrations

Every patch release, including alpha hotfixes (X.Y.0-alpha.N.M) and stable patches (X.Y.Z, where Z > 0), must pass this gate before any version bump, release commit, push, tag, image build/rebuild, or publication. Prerelease status does not exempt a patch. Never deploy a patch that violates this invariant; deployment remains outside this skill's scope.

Resolve and pin PREV_TAG using the published-release baseline rules in Release notes below, before mutation. Require it to be an ancestor of COMMIT_SHA. Compare the complete release trees, not just the latest commit or the cherry-picked fixes:

sh
git diff --name-status "$PREV_TAG" "$COMMIT_SHA" -- alembic/versions/
git diff "$PREV_TAG" "$COMMIT_SHA"

Any added, modified, deleted, or renamed migration is a hard blocker, including edits to an already-published migration. Inspect the full diff for migrations outside that directory, database-schema changes, and data backfills; those also block the patch. Existing migrations unchanged from the baseline are allowed. If the baseline or inspection cannot be verified, stop.

On a blocker, refuse the patch release and report the baseline, candidate SHA, and offending files. Release approval, urgency, successful CI, or claims that a migration is safe do not waive this invariant. Exclude the change and its dependencies from the patch, or propose a separately approved non-patch release. Never silently change the requested version to bypass the gate.

Before mutation, show:

  • Base commit and CI evidence; branch to create or reuse.
  • For a patch, the pinned baseline and evidence that the migration gate passed.
  • Public tag and whether the GitHub release is stable or a prerelease.
  • Version-bump, branch-push, tag-push, and release-publication commands.
  • Stable image tags update latest; prereleases leave latest unchanged. This policy permits an older train's stable hotfix to become latest.

Wait for explicit confirmation unless the user already approved this exact release plan. Approval to merge or fix a PR is not release authorization.

Bump, commit, and tag

Create or switch to BRANCH at the verified commit. Run just update-version <tag> and answer its overwrite prompt only for the approved release. It writes the public tag to __version__ and its PEP 440 value to __pep440_version__ (for example, 1.2.0-alpha.1 becomes 1.2.0a1, and 1.2.0-alpha.1.2 becomes 1.2.0a1.post2). Verify both application and registry versions agree, and validate the Python version with packaging.version.Version through uv run python.

Review the generated diff and, for a patch, repeat the migration gate against the final release tree (including all version-bump edits) before committing or pushing. Stage only the changed files individually, and create a signed release: <tag> commit. Never bypass hooks or signing. Push BRANCH. For a prerelease, record both current latest image digests before pushing the tag. Create an annotated <tag> on the version-bump commit and push it. No merge to main is involved. Leave the branch in place.

Show full SKILL.md (738 more words)Show less

Verify the images before publication

Tag push triggers .github/workflows/build-push-images.yml. Find the run whose tag and headSha match the new release commit, then watch it to successful completion. Inspect both multi-platform manifests and their version/revision labels. For a prerelease, compare both latest digests before and after the build; for a stable release, verify latest points to the new image manifests.

If image publication fails, stop before creating the GitHub release. Report the existing branch/tag and failed run; never move the tag or automatically cut a replacement. To rebuild, use a separate trusted, updated main checkout and run:

sh
uv run python scripts/rebuild_release_images.py '<tag>'

The helper requires the remote tag's workflow to exactly match the committed publisher in that checkout before dispatching with the tag as both ref and input. An older tag runs its own historical workflow, so guards on main cannot protect a direct dispatch or rerun. On a mismatch or lookup failure, stop; never bypass the helper or move the tag. A new release containing the current publisher requires a separately approved release plan. For a retry, verify the run ID, event, and release commit rather than accepting an older successful run.

Release notes

Resolve PREV_TAG from published releases, paginating the full list. For an alpha hotfix, use the previous published hotfix on the same alpha.N line, or its original alpha tag for the first hotfix. For 1.1.0-alpha.1.2, the baseline is 1.1.0-alpha.1.1, even if 1.1.0-alpha.2 has already shipped. Verify the baseline is an ancestor of the selected release commit. For other releases, use the previous version on the same major/minor train, ordered by semantic version (alpha before RC before stable, then patches). For the first alpha of a new train, use the preceding stable version. If a train skips alphas, its first release also uses the preceding stable version. Never pick an unrelated train merely because it was published most recently. If there is no unambiguous baseline, ask before publication.

Pin the range to PREV_TAG..<tag>. The draft maintained on main is not a release branch's changelog; do not publish or consume that draft.

Generate raw notes with explicit tag_name, previous_tag_name, and the version-bump commit as target_commitish:

sh
REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
RAW_NOTES=$(gh api "repos/$REPO/releases/generate-notes" \
  --method POST \
  -f tag_name='<tag>' \
  -f previous_tag_name="$PREV_TAG" \
  -f target_commitish='<release-commit>')

Extract PR numbers from the returned body and retrieve their titles and labels. For cherry-picked fixes, verify that the notes include the original merged PRs represented in the commit range, even if GitHub omits their associations.

Read .github/release-drafter.yml and derive the buckets from it. Do not copy the category list into this skill: the last copy drifted, and a stale copy silently files changes under headings the real release notes do not have.

From that file you need:

  • exclude-labels: drop any PR carrying one of these.
  • categories, in order: bucket each remaining PR into the first category whose labels intersect the PR's labels. Use the category's title verbatim.

Anything left with no matching label goes under a trailing Other section. Do not silently drop PRs.

Format each entry as - <title> (#<number>), matching the config's change-template, then apply every rule in the config's replacers: to the assembled body, in order. Read them from the file the way you read categories:; do not restate them here.

They are not cosmetic, and they are not only scope aliases. They rewrite the type prefix too -- chore(deps) and fix(deps) become build(deps), a scope that merely repeats its type is dropped, feat!(api) moves the bang to feat(api)! -- and they capitalize the first letter of most descriptions. Three shapes are spared, and the config lists them: a first word holding _ or ., a first word with a capital after its first letter, and an explicit list of lowercase names that must not be Title-cased. Read the guard from the file rather than reasoning about which of the three applies.

Skip the replacers and this skill's output disagrees with the stable release notes for the same commits.

Publish and report

Write the categorized Markdown and a PREV_TAG...<tag> comparison link to a temporary notes file. Publish the existing tag using --verify-tag, so a typo cannot create a tag on the default branch:

sh
# Stable release:
gh release create '<tag>' --verify-tag --latest \
  --title 'Tracecat <tag>' --notes-file "$BODY_FILE"

# Prerelease:
gh release create '<tag>' --verify-tag --prerelease --latest=false \
  --title 'Tracecat <tag>' --notes-file "$BODY_FILE"

Run only the command for the approved release type. If the range contains no changes, state No changes since <PREV_TAG>. rather than reusing older notes.

Report the branch, immutable tag/commit, GitHub release URL, image-build run, and manifest verification. Never delete the alpha-line or train branch, force-push, amend existing release commits, or deploy as part of this skill. If signing or a publication step fails, stop and report the concrete state before attempting further external mutations.

© TracecatHQ, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/gh-release of TracecatHQ/tracecat.

Open the folder on GitHubat commit a01d80b

Compare with similar skills

Gh Release next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Gh Release compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Gh Release this skillTracecatHQ/tracecat3.8k—~3.1kAutomated safety check: PassAGPL-3.0
Cutting A ReleaseTriliumNext/Trilium38k—~3.2kAutomated safety check: PassAGPL-3.0
Mole CLI Release Flowtw93/Mole69k—~2.5kAutomated safety check: PassGPL-3.0
Draft Release Notesjamiepine/voicebox57k—~941Automated safety check: PassMIT
Mole Release Notes Publishertw93/Mole69k—~1.9kAutomated safety check: PassGPL-3.0
Release Bumpjamiepine/voicebox57k—~1.1kAutomated safety check: PassMIT

Similar skills

  • Cutting A Release

    TriliumNext/Trilium

    A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.

    38k GitHub stars~3.2k tokensUpdated today
    DevelopmentAuto-check passed

  • Mole CLI Release Flow

    tw93/Mole

    Runbook for assessing and executing a Mole CLI release: distribution channels, pre-flight checks, capital-V tags, build artifacts and the handoff to curated release notes.

    69k GitHub stars~2.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Draft Release Notes

    jamiepine/voicebox

    Writes or refreshes the Unreleased section of CHANGELOG.md as a themed narrative built from the commits, PRs and diff since the last version tag.

    57k GitHub stars~941 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Mole Release Notes Publisher

    tw93/Mole

    Publishes curated, bilingual release notes for an existing Mole version tag with gh release edit, including contributor thanks and reactions, after the release workflow finishes.

    69k GitHub stars~1.9k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Release Bump

    jamiepine/voicebox

    Ends a release cycle by moving the Unreleased changelog notes under a dated version heading, bumping version files with bumpversion and tagging the commit.

    57k GitHub stars~1.1k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Cut Release

    jfernandez/bpftop

    Cut a new versioned release of bpftop — pick the version, open a version-bump PR, sign-tag the merge commit on main, and draft GitHub release notes in the project's established format.

    2.7k GitHub stars~2k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from TracecatHQ/tracecat

  • Docs Authoring

    TracecatHQ/tracecat

    A skill your agent uses when adding or updating documentation pages in an existing docs site.

    3.8k GitHub stars~3.1k tokensUpdated yesterday
    Auto-check: notes

  • Make PR

    TracecatHQ/tracecat

    Create, retitle, or label a pull request for the current branch.

    3.8k GitHub stars~2.7k tokensUpdated yesterday
    Auto-check passed

  • Tracecat QA

    TracecatHQ/tracecat

    QA Tracecat product features in a real local cluster. An agent skill from TracecatHQ/tracecat.

    3.8k GitHub stars~1.1k tokensUpdated yesterday
    Auto-check: warnings

Works with

Categories

Questions about Gh Release

What does Gh Release do?

Cut a stable GitHub release or prerelease directly from a Tracecat release branch, including the version bump, tag, image verification, and categorized release notes. Gh Release is an agent skill from TracecatHQ/tracecat. Cut a stable GitHub release or prerelease directly from a Tracecat release branch, including the version bump, tag, image verification, and categorized release notes.

When should I use Gh Release?

Gh Release fits situations like: tasks that involve Changelog and release notes.

How do I install Gh Release in Claude Code?

Run `npx skills add TracecatHQ/tracecat --skill gh-release -a claude-code`. Or copy the skill folder (.agents/skills/gh-release in TracecatHQ/tracecat) into .claude/skills/gh-release in your project. Claude Code loads it when a task matches its description.

How do I install Gh Release in Codex?

Run `npx skills add TracecatHQ/tracecat --skill gh-release -a codex`. Or copy the skill folder (.agents/skills/gh-release in TracecatHQ/tracecat) into .agents/skills/gh-release in your project. Codex loads it when a task matches its description.

Can I use Gh Release in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add TracecatHQ/tracecat --skill gh-release -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/gh-release, .gemini/skills/gh-release, .github/skills/gh-release and .opencode/skills/gh-release in your project.

What does Gh Release need to run?

Going by SKILL.md and its folder, Gh Release needs the command-line tools its instructions call (gh, git, uv and just). Our summary lists: Python 3.

Does Gh Release access the network?

SKILL.md contains no URLs. Its commands use gh, git and uv, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Gh Release safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Gh Release use?

Gh Release is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Gh Release use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Gh Release?

Skills that share tags, products or a category with Gh Release: Cutting A Release (TriliumNext/Trilium, 38k stars), Mole CLI Release Flow (tw93/Mole, 69k stars), Draft Release Notes (jamiepine/voicebox, 57k stars) and Mole Release Notes Publisher (tw93/Mole, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Gh Release?

TracecatHQ (a GitHub organization) maintains it in TracecatHQ/tracecat, which has 3,824 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on October 7, 2026.

Source: TracecatHQ/tracecat on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.