New: 98,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

Release

by Zeecka in Zeecka/AperiSolve

Cut a new AperiSolve release — bump the version, commit "chore(release): X.Y.Z", tag it, push, and publish a GitHub Release whose notes are computed from the commits since the last tag.

MITAuto-check passedSecurity

Install Release

skills CLI
$ npx skills add Zeecka/AperiSolve --skill release -a claude-code

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

GitHub CLI
$ gh skill install Zeecka/AperiSolve 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/Zeecka/AperiSolve.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release .claude/skills/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
release
GitHub stars
850
Token cost
~1.9k tokens
SKILL.md length
938 words
Files
1
Skills in repo
1
Repo updated
First seen
Licence
MIT

At a glance

Cut a new AperiSolve release — bump the version, commit "chore(release): X.Y.Z", tag it, push, and publish a GitHub Release whose notes are computed from the commits since the last tag.

  • Works in 9 steps: Preflight → Compute the version and the release text → Bump the version → …
  • The user says release
  • SKILL.md covers How this repo versions (facts,…, Workflow, Safety rules (non-negotiable) and Example usage
  • Calls git, gh and uv

What it does

Release is an agent skill from Zeecka/AperiSolve. Cut a new AperiSolve release — bump the version, commit "chore(release): X.Y.Z", tag it, push, and publish a GitHub Release whose notes are computed from the commits since the last tag. Use when the user says "release", "cut a release", "ship a release", "publish X.Y.Z", or "/release". Pushing the tag triggers the production deploy workflow, so this always confirms first.

Its SKILL.md is about 1.9k 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 Security. It works with GitHub. The repository describes itself as: Steganalysis web platform. The licence is MIT.

When your agent uses it

  • The user says release
  • The production deploy workflow
  • So this always confirms first

Example prompts

  • “chore(release): X.Y.Z”
  • “release”
  • “cut a release”
  • “/release”

Requirements

  • Docker
  • Pre-approved tools (allowed-tools): [Bash, Read, Edit, Write]

Workflow steps

9 steps, taken from the step headings in SKILL.md.

  1. Preflight
  2. Compute the version and the release text
  3. Bump the version
  4. Confirm (mandatory gate — this deploys to prod)
  5. Commit the bump
  6. Push main
  7. Tag and push the tag (⇒ triggers build + deploy)
  8. Publish the GitHub Release
  9. Report

What it can do on your machine

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

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • [Bash
    • Read
    • Edit
    • Write]

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • gh
    • uv

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

  • Network

    No URLs in SKILL.md. Its commands use git, gh 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

Release loads about 1.9k tokens when it runs. Until then it costs about 96 tokens; SKILL.md has 938 words of instructions outside code blocks.

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

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 Zeecka/AperiSolve at commit 2a675c2, republished under its MIT licence (© Zeecka). 938 words, ~1,920 tokens.

Download SKILL.mdSave it as .claude/skills/release/SKILL.md (or your agent's skills folder).
name
release
description
Cut a new AperiSolve release — bump the version, commit "chore(release): X.Y.Z", tag it, push, and publish a GitHub Release whose notes are computed from the commits since the last tag. Use when the user says "release", "cut a release", "ship a release", "publish X.Y.Z", or "/release". Pushing the tag triggers the production deploy workflow, so this always confirms first.
allowed-tools
[Bash, Read, Edit, Write]
argument-hint
[version | patch | minor | major]

release — bump, commit, tag, push, publish GitHub Release

Cut a release of AperiSolve. The steps are: bump the version, commit the bump as chore(release): X.Y.Z, push main, create and push an annotated tag X.Y.Z, then publish a GitHub Release whose body is computed from the commits since the last tag.

The user's version request (if any) is: $ARGUMENTS — an explicit version (3.3.3), a bump level (patch / minor / major), or empty (infer + confirm).

⚠️ Pushing the X.Y.Z tag triggers .github/workflows/release.yml, which builds the Docker image AND deploys to production. Treat this as a hard-to-reverse, outward-facing action: you MUST show the computed plan and get an explicit go-ahead (step 4) before executing step 5 onward.

How this repo versions (facts, don't re-derive)

  • Version lives in pyproject.toml ([project] version = "X.Y.Z") and in uv.lock (under [[package]] name = "aperisolve").
  • ⚠️ Never blind-sed uv.lock. Unrelated packages can share the version string (e.g. greenlet has sat at the same 3.3.x), so a global replace corrupts them. Bump the lockfile with uv lock, or, if offline, edit only the version = "…" line that sits directly under name = "aperisolve".
  • Tags are bare X.Y.Z (no v prefix), annotated, message Release X.Y.Z — <one-line summary>.
  • The release commit contains only the version bump (2 files). Feature code is expected to already be merged to main (via /commit).
  • Repo slug for compare/release URLs: Zeecka/AperiSolve.

Workflow

Run in order. Stop and report on any problem instead of forcing anything. Combine independent Bash calls where you can.

1. Preflight
  • git rev-parse --is-inside-work-tree; confirm origin exists (git remote).
  • gh auth status — must be logged in (needed for the GitHub Release).
  • Branch: git branch --show-current. Releases deploy from main, so require main. If you're not on main, stop and tell the user to land the code on main first (e.g. /commit) then re-run — do not tag a feature branch.
  • Sync: git fetch --tags origin, then ensure local main matches origin/main (git pull --ff-only origin main). If it can't fast-forward, stop and report.
  • Clean tree: git status --porcelain must be empty (the only diff will be the bump this skill creates). If dirty, stop — tell the user to commit/stash first.
2. Compute the version and the release text
  • Previous version = pyproject.toml [project] version (call it $PREV). Sanity-check a tag $PREV exists: git rev-parse -q --verify "refs/tags/$PREV".
  • Commits to release = git log "$PREV"..HEAD --no-merges --format='%h %s' (also skim bodies for BREAKING CHANGE). If empty, stop: "nothing to release since $PREV".
  • Next version $NEXT:
    • If $ARGUMENTS is an explicit X.Y.Z, use it.
    • If it's patch/minor/major, apply that bump to $PREV.
    • If empty, infer and propose (confirm in step 4): any feat → minor; only fix/perf/refactor/chore/docs/test → patch; any ! or BREAKING CHANGE → major. This is a suggestion, not a rule — the maintainer decides (past feat releases have shipped as patches).
    • $NEXT must be strictly greater than $PREV and not already a tag.
  • Compose two texts from the commits (this is the "computed content"):
    1. $SUMMARY — one line (≤ ~120 chars), plain, what changed. Used in the tag message and as the commit-body lead.
    2. $NOTES — the GitHub Release body, markdown, in this repo's house style: a themed ##/### heading, grouped bullets that describe user-visible changes (not raw commit subjects), and end with the compare link:
      **Full changelog:** https://github.com/Zeecka/AperiSolve/compare/$PREV...$NEXT
      Keep it faithful to the actual commits — summarize, don't invent.
Show full SKILL.md (408 more words)Show less
3. Bump the version
  • Edit pyproject.toml: [project] version = "$PREV" → "$NEXT" (the version line under [project], not target-version).
  • Update the lockfile: run uv lock (regenerates uv.lock, touching only the aperisolve version). If uv is unavailable/offline, edit only the version line directly beneath name = "aperisolve" in uv.lock.
  • Verify the diff is exactly those two files and just the version: git diff --stat (expect pyproject.toml, uv.lock) and eyeball git diff -- pyproject.toml uv.lock. If anything else changed, stop and report.
4. Confirm (mandatory gate — this deploys to prod)

Show the user, and get an explicit go-ahead before proceeding:

  • $PREV → $NEXT and how it was chosen,
  • the commit subject chore(release): $NEXT + $SUMMARY body,
  • the tag message Release $NEXT — $SUMMARY,
  • the full $NOTES release body,
  • a reminder that pushing the tag builds the image and deploys production.

If the user asked to proceed non-interactively in this turn, that go-ahead counts.

5. Commit the bump

Use a heredoc so the body + trailer stay intact:

sh
git commit -aF - <<'EOF'
chore(release): $NEXT

$SUMMARY

<session-required trailer lines>
EOF
  • Append the trailer this harness session requires — the Co-Authored-By: and Claude-Session: lines from your current environment's git/commit instructions. Read them from the live session; never hardcode them (the session URL changes each session). If the session specifies none, omit them.
6. Push main
  • git push origin main.
  • If rejected (non-fast-forward): stop, suggest git pull --rebase origin main and re-run. Never force-push.
7. Tag and push the tag (⇒ triggers build + deploy)
  • git tag -a "$NEXT" -m "Release $NEXT — $SUMMARY".
  • git push origin "$NEXT".
8. Publish the GitHub Release
  • Write $NOTES to a temp file (use the session scratchpad dir) and run:
    sh
    gh release create "$NEXT" --title "$NEXT" --notes-file <notes-file> --latest
  • The tag already exists on the remote, so gh attaches the release to it (it won't move or overwrite your annotated tag).
9. Report
  • New commit sha + subject, the pushed tag, and the release URL (gh release view "$NEXT" --json url -q .url).
  • Note that the tag push kicked off the Docker build + production deploy, and point at Actions to watch it: gh run list --workflow release.yml --limit 3.

Safety rules (non-negotiable)

  • Confirm before step 5 — the tag push deploys production. No silent releases.
  • Never blind-replace in uv.lock — uv lock or the anchored aperisolve line only.
  • Release only from main, with a clean, up-to-date tree.
  • $NEXT must be > $PREV and not an existing tag; tags are bare X.Y.Z.
  • Never force-push; never delete or move an existing tag/branch/release.
  • If any step fails, stop and report — don't improvise around a failure.

Example usage

/release            # infer the bump from commits since the last tag, then confirm
/release patch      # 3.3.2 -> 3.3.3
/release minor      # 3.3.2 -> 3.4.0
/release 3.4.0      # explicit version

© Zeecka, MIT. 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 .claude/skills/release of Zeecka/AperiSolve.

Open the folder on GitHubat commit 2a675c2

Compare with similar skills

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.

Release compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Release this skillZeecka/AperiSolve850—~1.9kAutomated safety check: PassMIT
Triage Codeqlnetdata/netdata81k—~1.8kAutomated safety check: NotesGPL-3.0
Security AdvisoryMidnightBSD/src114—~2.2kAutomated safety check: PassCustom licence
Security Vulnerability Analysiseclipse-ankaios/ankaios125—~1.5kAutomated safety check: PassApache-2.0
Agentic GitHub Actions Auditortrailofbits/skills7.4k6 repos~5.4kAutomated safety check: NotesCC-BY-SA-4.0
Report Clawhub Malicious Skillopenclaw/clawscan142—~1.1kAutomated safety check: PassMIT

Similar skills

  • Triage Codeql

    netdata/netdata

    Inspect, review or triage GitHub Code Scanning alerts, including CodeQL findings; apply verified dismissals when authorized.

    81k GitHub stars~1.8k tokensUpdated today
    SecurityAuto-check: notes

  • Security Advisory

    MidnightBSD/src

    Handle a security fix end to end for MidnightBSD src - triage a FreeBSD security advisory (FreeBSD-SA-) or CVE against this tree, port the fix to master and both stable branches, add the UPDATING…

    114 GitHub stars~2.2k tokensUpdated 4 days ago
    SecurityAuto-check passed

  • Security Vulnerability Analysis

    eclipse-ankaios/ankaios

    Analyze potential Ankaios security vulnerabilities from pasted reports, local evidence, or advisory URLs.

    125 GitHub stars~1.5k tokensUpdated today
    SecurityAuto-check passed

  • Agentic GitHub Actions Auditor

    trailofbits/skills

    Official

    Statically audits GitHub Actions workflows that run AI coding agents, tracing attacker-controlled input to agent prompts and flagging unsafe sandbox, trigger and allowlist settings.

    7.4k GitHub starsUsed in 6 repos~5.4k tokens
    SecurityAuto-check: notes

  • Report Clawhub Malicious Skill

    openclaw/clawscan

    A skill your agent uses when a researcher, maintainer, or contributor found or suspects a malicious skill on ClawHub and needs a private reporting workflow: opening a GitHub private vulnerability…

    142 GitHub stars~1.1k tokensUpdated today
    SecurityAuto-check passed

  • Warp Vulnerability Triage

    warpdotdev/warp

    Gathers security findings from Dependabot, GCP container scanning, Docker Scout and Linear security issues, then triages and remediates them across Warp's repos and images.

    65k GitHub starsUsed in 1 repo~2.1k tokens
    SecurityAuto-check passed

Works with

Categories

Questions about Release

What does Release do?

Cut a new AperiSolve release — bump the version, commit "chore(release): X.Y.Z", tag it, push, and publish a GitHub Release whose notes are computed from the commits since the last tag. Release is an agent skill from Zeecka/AperiSolve.Z", tag it, push, and publish a GitHub Release whose notes are computed from the commits since the last tag.

When should I use Release?

Release fits situations like: the user says release; the production deploy workflow; so this always confirms first.

How do I install Release in Claude Code?

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

How do I install Release in Codex?

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

Can I use 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 Zeecka/AperiSolve --skill 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/release, .gemini/skills/release, .github/skills/release and .opencode/skills/release in your project.

What does Release need to run?

Going by SKILL.md and its folder, Release needs the command-line tools its instructions call (git, gh and uv). Our summary lists: Docker. Its frontmatter pre-approves these tools: [Bash, Read, Edit, Write].

Does Release access the network?

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

Is 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 Release use?

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

How many tokens does Release use?

About 1.9k tokens (SKILL.md is roughly 7.7k 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 Release?

Skills that share tags, products or a category with Release: Triage Codeql (netdata/netdata, 81k stars), Security Advisory (MidnightBSD/src, 114 stars), Security Vulnerability Analysis (eclipse-ankaios/ankaios, 125 stars) and Agentic GitHub Actions Auditor (trailofbits/skills, 7.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release?

Zeecka (a GitHub user) maintains it in Zeecka/AperiSolve, which has 850 GitHub stars. The repository was last updated on October 7, 2026.

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