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

Cut Release

by jfernandez in 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.

Apache-2.0Auto-check passedDevelopment

Install Cut Release

skills CLI
$ npx skills add jfernandez/bpftop --skill cut-release -a claude-code

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

GitHub CLI
$ gh skill install jfernandez/bpftop cut-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/jfernandez/bpftop.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/cut-release .claude/skills/cut-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
cut-release
GitHub stars
2.7k
Token cost
~2k tokens
SKILL.md length
882 words
Files
4 (incl. scripts, assets)
Skills in repo
1
Repo updated
First seen
Licence
Apache-2.0

At a glance

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.

  • Works in 5 steps: Pick the version → Open the bump PR → Wait for merge and green CI → …
  • The user says cut a release
  • SKILL.md covers Step 1: Pick the version, Step 2: Open the bump PR, Step 3: Wait for merge and… and Step 4: Cut the signed…, plus 4 more sections
  • Runs Shell scripts from its folder; calls git, gh and cargo

What it does

Cut Release is an agent skill from 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. Use whenever the user says "cut a release", "release X.Y.Z", "ship X.Y.Z", "time to release", "tag a new version", "bump to X.Y.Z", "let's do a release", or otherwise initiates a release. Trigger even when the user only asks for one step ("what version should we bump to?", "make the release PR", "tag it") — load this skill so the…

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including scripts and assets (for example `assets/release-notes-example-v0.9.0.md`, `assets/release-notes-template.md` and `scripts/contributors.sh`).

It sits in Development, covering Changelog and release notes. It works with GitHub and Linux. The repository describes itself as: bpftop provides a dynamic real-time view of running eBPF programs. It displays the average runtime, events per second, and estimated total CPU % for each program. The licence is Apache-2.0.

When your agent uses it

  • The user says cut a release
  • Time to release
  • Tag a new version
  • Lets do a release

Example prompts

  • “s established format. Use whenever the user says”
  • “release X.Y.Z”
  • “ship X.Y.Z”
  • “/cut-release”

Requirements

  • A Bash shell

Workflow steps

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

  1. Pick the version
  2. Open the bump PR
  3. Wait for merge and green CI
  4. Cut the signed annotated tag
  5. Draft the release notes

What it can do on your machine

Read from SKILL.md and the folder at commit 5a67ec0. 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

    Ships 1 file in scripts/ (Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • git
    • gh
    • cargo

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

  • Network

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

Cut Release loads about 2k tokens when it runs. Until then it costs about 152 tokens; SKILL.md has 882 words of instructions outside code blocks.

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

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); the scripts in this folder are not scanned.

SKILL.md

The full file from jfernandez/bpftop at commit 5a67ec0, republished under its Apache-2.0 licence (© jfernandez). 882 words, ~1,993 tokens.

Download SKILL.mdSave it as .claude/skills/cut-release/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
cut-release
description
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. Use whenever the user says "cut a release", "release X.Y.Z", "ship X.Y.Z", "time to release", "tag a new version", "bump to X.Y.Z", "let's do a release", or otherwise initiates a release. Trigger even when the user only asks for one step ("what version should we bump to?", "make the release PR", "tag it") — load this skill so the broader workflow context is available, and only do the step the user asked for.

Cut a release

This is the bpftop release runbook. Five steps: pick the version, open the bump PR, wait for merge, push a signed tag, fill in the release notes.

Tags and releases are user-visible and permanent. Confirm the version, the tag SHA, and the release notes content with the user before pushing the tag and before publishing the draft.

Step 1: Pick the version

bash
git log $(git describe --tags --abbrev=0)..HEAD --oneline

bpftop is pre-1.0. Apply semver:

  • Patch (0.x.y → 0.x.(y+1)) — only fixes, refactors, dep bumps
  • Minor (0.x → 0.(x+1)) — any new user-facing feature, or any breaking change to CLI flags / TUI keybindings / output format

CI churn, AI-assistant config tweaks, and dependabot bumps that don't change runtime behavior are not on their own a reason to cut a release.

Tell the user which commits drove the decision and let them confirm or override.

When the user asks about going to 1.0

The signal is UX/API stability, not feature completeness. Recommend 1.0 once the user is willing to commit that the next release won't break CLI flags or TUI keybindings without a deprecation cycle, the feature surface is additive (no "initial X" support, no churning subsystems), and they'd be comfortable with a distro packaging it. When something just landed in the prior release labeled "initial", recommend one more minor first.

Step 2: Open the bump PR

bash
git checkout -b release/X.Y.Z

Edit Cargo.toml:

toml
[package]
name = "bpftop"
version = "X.Y.Z"

Refresh the lockfile:

bash
cargo update -p bpftop --precise X.Y.Z

The diff should be exactly two lines: one in Cargo.toml, one in Cargo.lock. Verify before committing.

Commit format is strict and minimal — subject only, no body, with a Signed-off-by trailer:

bash
git commit -s -m "chore: bump version to X.Y.Z"

No commit body. Release notes live on the GitHub release page, not in the bump commit. This is a project convention — past releases (e.g. v0.8.0 commit aab2d53) follow this minimal pattern, and duplicating context here is noise.

Push and open the PR with an empty body:

bash
git push -u origin release/X.Y.Z
gh pr create --title "chore: bump version to X.Y.Z" --body ""

Do not merge the PR. Wait for the user to merge it.

Step 3: Wait for merge and green CI

bash
gh pr view <N> --json state,mergeCommit,statusCheckRollup

Look for state: MERGED and all checks SUCCESS (build_and_test on x86_64 and aarch64). Capture mergeCommit.oid — that's what gets tagged.

Step 4: Cut the signed annotated tag

bash
git checkout main && git pull --ff-only origin main
git tag -s vX.Y.Z -m "vX.Y.Z" <merge-commit-sha>
git tag -v vX.Y.Z
git push origin vX.Y.Z

The tag message body is the bare string vX.Y.Z — no "Release ..." prefix, no prose. Matches the v0.8.0 style.

After pushing, CI's create_release job auto-creates a draft release with the cross-compiled binaries (bpftop-aarch64-unknown-linux-gnu, bpftop-x86_64-unknown-linux-gnu) attached. Wait a few seconds, then verify:

bash
gh release list --limit 3
gh release view vX.Y.Z

You'll edit this draft in step 5. Don't gh release create a second one.

Step 5: Draft the release notes

The template lives at assets/release-notes-template.md and a worked example for v0.9.0 is at assets/release-notes-example-v0.9.0.md. Read both before drafting — the example is the single best reference for tone, grouping, and formatting.

The structure, in order:

  1. ## What's New — one short prose paragraph (2-3 sentences) summarizing the headline changes
  2. ### Features — feat: commits, new user-facing functionality
  3. ### Fixes — fix: commits
  4. ### Maintenance — chore:, refactor:, ci:, dep bumps. Drop internal AI-assistant / Claude-workflow churn — invisible to users, clutters the changelog.
  5. ## New Contributors — first-timers, one line each
  6. ## Contributors — alphabetical Display Name @login, one per line
  7. Full Changelog link — https://github.com/jfernandez/bpftop/compare/vPREV...vX.Y.Z

Each Features/Fixes/Maintenance bullet ends with (#N) referencing its PR. No by @author inline — attribution lives in the dedicated Contributors section. Direct-to-main commits with no PR don't get a number.

Show full SKILL.md (353 more words)Show less
Resolving the Contributors and New Contributors sections

Run the bundled script. It encodes the project's exclusion and sort rules, and resolves first-timer status correctly via PR history:

bash
.claude/skills/cut-release/scripts/contributors.sh vPREV

Output is two ready-to-paste markdown sections.

The script enforces:

  • First-timer detection via PR history per GitHub login. Comparing commit author names (git log --pretty=%an) misses people whose local git config user.name has changed since their first contribution — the same person can appear under different names across years. The login is stable.
  • Bots excluded. GitHub reports bots as either dependabot[bot] or app/dependabot; the script filters both forms.
  • Maintainer (jfernandez) included. This is a deliberate choice — the user wants their own name in the Contributors list. The convention in some projects is to omit the publisher; bpftop chooses to include them.
  • Alphabetical by display name, case-insensitive.
bash
gh release edit vX.Y.Z --notes "$(cat <<'EOF'
...notes...
EOF
)"

Tell the user the URL of the draft and wait for review. Publish only after they confirm:

bash
gh release edit vX.Y.Z --draft=false

Things that bit us before

  • GitHub shows the GPG key as expired but it isn't locally. Extending a GPG key's expiration locally doesn't propagate to GitHub, and same-fingerprint re-uploads are silently no-op'd. Fix: delete the existing GPG key on GitHub Settings → SSH and GPG keys, then re-upload gpg --armor --export <keyid>. Past commits stay verified once re-uploaded.
  • Mistakenly flagged a returning contributor as a first-timer. Always use the bundled contributors.sh script — don't eyeball it from git log.
  • Slipped a body into the release commit. If a body sneaks in, git commit --amend and force-push the branch before merging. Subject only + sign-off, empty PR body.
  • Tagged the local feature-branch tip instead of the merge commit. Always git checkout main && git pull --ff-only before tagging, then tag the merge commit by SHA captured from gh pr view.
  • Created a second draft when CI already auto-created one. CI creates the draft on tag push. Always gh release edit vX.Y.Z to populate it; never gh release create.

Doing only one step

If the user says "just tag it" or "just draft the notes", do only that step. Still confirm version / tag SHA / notes content before any irreversible action (push, publish).

File layout

.claude/skills/cut-release/
├── SKILL.md                                    (this file — workflow)
├── assets/
│   ├── release-notes-template.md               (literal template with placeholders)
│   └── release-notes-example-v0.9.0.md         (worked example — best reference)
└── scripts/
    └── contributors.sh                         (resolves Contributors + New Contributors)

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

Files

SKILL.md and 3 other files (scripts, assets) in .claude/skills/cut-release of jfernandez/bpftop.

  • SKILL.md
  • assets/release-notes-example-v0.9.0.md
  • assets/release-notes-template.md
  • scripts/contributors.sh

Open the folder on GitHubat commit 5a67ec0

Compare with similar skills

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

Cut Release compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Cut Release this skilljfernandez/bpftop2.7k—~2kAutomated safety check: PassApache-2.0
Prepare Releaseneetly/figma-agent-linux395—~833Automated safety check: PassMIT
Release NotesMikalaiBarysevich/CleverSwitch116—~975Automated safety check: PassGPL-3.0
Releasemqtt-viewer/mqtt-viewer133—~1.8kAutomated safety check: PassGPL-3.0
Kernel Watch Triageantoinecellerier/speaker-tuning-to-easyeffects142—~2.6kAutomated safety check: PassMIT
Releasing MarchatCod-e-Codes/marchat137—~801Automated safety check: PassMIT

Similar skills

  • Prepare Release

    neetly/figma-agent-linux

    Prepare a new figma-agent-linux release by updating the package version, changelog, and release links, then validating the changes.

    395 GitHub stars~833 tokensUpdated today
    DevelopmentAuto-check passed

  • Release Notes

    MikalaiBarysevich/CleverSwitch

    Generate GitHub release notes for unreleased CleverSwitch tags in the established repo format.

    116 GitHub stars~975 tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • Release

    mqtt-viewer/mqtt-viewer

    Publish a MQTT Viewer release end to end. An agent skill from mqtt-viewer/mqtt-viewer.

    133 GitHub stars~1.8k tokensUpdated today
    DevelopmentAuto-check passed

  • Kernel Watch Triage

    antoinecellerier/speaker-tuning-to-easyeffects

    Guides triaging a kernel-sound-watch hit comment on the "Kernel sound-tree watch" issue (40) — the weekly workflow's per-tag report of .github/kernel-watchlist.txt grep hits against a new…

    142 GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed

  • Releasing Marchat

    Cod-e-Codes/marchat

    Prepares marchat releases: version bumps, CHANGELOG, packaging checksums, GitHub Actions release workflow, and Docker tags.

    137 GitHub stars~801 tokensUpdated 5 days ago
    DevOps & CloudAuto-check passed

  • 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

Works with

Categories

Questions about Cut Release

What does Cut Release do?

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. Cut Release is an agent skill from 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.

When should I use Cut Release?

Cut Release fits situations like: the user says cut a release; time to release; tag a new version; lets do a release.

How do I install Cut Release in Claude Code?

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

How do I install Cut Release in Codex?

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

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

What does Cut Release need to run?

Going by SKILL.md and its folder, Cut Release needs a shell for the scripts in its folder and the command-line tools its instructions call (git, gh and cargo). Our summary lists: A Bash shell.

Does Cut Release access the network?

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

Is Cut 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. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Cut Release use?

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

How many tokens does Cut Release use?

About 2k tokens (SKILL.md is roughly 8k 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 Cut Release?

Skills that share tags, products or a category with Cut Release: Prepare Release (neetly/figma-agent-linux, 395 stars), Release Notes (MikalaiBarysevich/CleverSwitch, 116 stars), Release (mqtt-viewer/mqtt-viewer, 133 stars) and Kernel Watch Triage (antoinecellerier/speaker-tuning-to-easyeffects, 142 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cut Release?

jfernandez (a GitHub user) maintains it in jfernandez/bpftop, which has 2,706 GitHub stars. The repository was last updated on September 1, 2026.

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