Agent skill

Release

by jjjkkkjjj in jjjkkkjjj/Matft

Procedure for releasing a new version of Matft (decide the version → check tests → write release notes → create and push an annotated tag → publish a GitHub Release).

BSD-3-ClauseAuto-check passedDevelopment

Install Release

skills CLI
$ npx skills add jjjkkkjjj/Matft --skill release -a claude-code

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

GitHub CLI
$ gh skill install jjjkkkjjj/Matft 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/jjjkkkjjj/Matft.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
147
Token cost
~1.8k tokens
SKILL.md length
802 words
Files
1
Skills in repo
5
Repo updated
First seen
Licence
BSD-3-Clause

At a glance

Procedure for releasing a new version of Matft (decide the version → check tests → write release notes → create and push an annotated tag → publish a GitHub Release).

  • Works in 9 steps: Pre-checks and choosing the commit to tag → Decide the version → Check tests and CI → …
  • The conversation is about bumping Matfts version
  • SKILL.md covers 1. Pre-checks and choosing the…, 2. Decide the version, 3. Check tests and CI and 4. Check for an existing draft…, plus 6 more sections
  • Calls git, gh and swift

What it does

Release is an agent skill from jjjkkkjjj/Matft. Procedure for releasing a new version of Matft (decide the version → check tests → write release notes → create and push an annotated tag → publish a GitHub Release). Use this skill whenever the conversation is about bumping Matft's version, tagging, or creating/updating a GitHub Release — e.g. "bump the version", "cut a release", "ship 0.3.4", "tag it", "create the Release", "publish a new version", or in Japanese「バージョンアップして」「リリースして」「0.3.4 を出して」「タグ打って」「Releases 作って」「新しいバージョン公開」— even if the word "skill" is never…

Its SKILL.md is about 1.8k 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 and NumPy. The repository describes itself as: Numpy-like library in swift. (Multi-dimensional Array, ndarray, matrix and vector library). The licence is BSD-3-Clause.

When your agent uses it

  • The conversation is about bumping Matfts version
  • Creating/updating a GitHub Release — e.g

Example prompts

  • “s version, tagging, or creating/updating a GitHub Release — e.g.”
  • “cut a release”
  • “ship 0.3.4”
  • “/release”

Workflow steps

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

  1. Pre-checks and choosing the commit to tag
  2. Decide the version
  3. Check tests and CI
  4. Check for an existing draft Release
  5. Write the release notes
  6. User confirmation
  7. Tag and push
  8. Publish the GitHub Release
  9. Verify and report

What it can do on your machine

Read from SKILL.md and the folder at commit 618dcfc. 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:

    • git
    • gh
    • swift

    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

Release loads about 1.8k tokens when it runs. Until then it costs about 134 tokens; SKILL.md has 802 words of instructions outside code blocks.

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

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 jjjkkkjjj/Matft at commit 618dcfc, republished under its BSD-3-Clause licence (© jjjkkkjjj). 802 words, ~1,771 tokens.

Download SKILL.mdSave it as .claude/skills/release/SKILL.md (or your agent's skills folder).
name
release
description
Procedure for releasing a new version of Matft (decide the version → check tests → write release notes → create and push an annotated tag → publish a GitHub Release). Use this skill whenever the conversation is about bumping Matft's version, tagging, or creating/updating a GitHub Release — e.g. "bump the version", "cut a release", "ship 0.3.4", "tag it", "create the Release", "publish a new version", or in Japanese「バージョンアップして」「リリースして」「0.3.4 を出して」「タグ打って」「Releases 作って」「新しいバージョン公開」— even if the word "skill" is never mentioned.

Matft release procedure

Matft is distributed via SwiftPM, and users resolve versions from git tags in x.x.x form (no v prefix — SwiftPM would no longer recognize it as a semantic version). So the core of a release is "put the tag on the right commit, push it, and publish the GitHub Release tied to it". CocoaPods (Matft.podspec) and Carthage are out of scope for this skill; do not touch them.

Pushing a tag and publishing a Release are public operations that immediately affect users' Package.resolved. They are hard to undo, so always get the user's confirmation before running any publishing command.

1. Pre-checks and choosing the commit to tag

A release is defined not by the working tree but by the single commit to be tagged (<commit> below). All subsequent log, test, and CI checks are done against this <commit>. That way the release can proceed even if there are unrelated work-in-progress changes or unpushed operations-only commits locally.

sh
git fetch origin --tags
git branch --show-current
git status --porcelain
git rev-list --left-right --count origin/main...HEAD   # "<only on origin> <only local>"
gh auth status
  • <commit> is usually the tip of origin/main (git rev-parse origin/main). Specify it by hash, not branch name, so it does not move if the branch moves later.
  • If there are unpushed local commits: check whether they contain code changes that should be in the release. If they are operations-only (e.g. adding CLAUDE.md), ignore them and target origin/main. If they are code changes, push them first (after user confirmation) or ask the user.
  • Uncommitted changes are not included in the release as long as you tag an explicit <commit>. Mention "working tree changes are not included" when confirming.
  • Stop only when the target cannot be determined, e.g. gh is not authenticated, or origin has commits you have not pulled and it is unclear which to ship.

2. Decide the version

sh
git tag --sort=-v:refname | head -5                   # recent tags
git log --oneline <latest tag>..<commit>              # changes since the last release
  • If the user specified a version, use it. Verify it is in x.x.x form, does not duplicate an existing tag, and is greater than the latest tag.
  • Otherwise propose one from the changes: breaking changes (e.g. spec changes to match Numpy behavior) or new features → minor; bug fixes only → patch. It is 0.x, so leave the final decision to the user.

3. Check tests and CI

As CLAUDE.md requires, never release anything whose tests do not all pass. Running swift test in the working tree can fail because of uncommitted TDD-in-progress changes (tests in the Red state, etc.), so check out <commit> cleanly and test that.

sh
git worktree add <scratchpad>/matft-release <commit>
(cd <scratchpad>/matft-release && swift test)
git worktree remove <scratchpad>/matft-release

gh run list --commit <commit>      # both the Swift and wasm workflows should be success

If the working tree is clean and HEAD equals <commit>, you may run swift test in place. If tests or CI fail, abort the release and report the cause.

4. Check for an existing draft Release

A draft Release with the same name (often without a tag) may already exist on GitHub with release notes written in advance. Reuse it rather than discarding it.

sh
gh api repos/jjjkkkjjj/Matft/releases \
  --jq '.[] | select(.draft and .name=="<version>") | {id, name, tag_name, body}'

If found, note its id and body.

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

5. Write the release notes

Base them on git log <latest tag>..<commit> --pretty='%h %s'. If there is a draft body, start from it and add missing changes (things merged after the draft was created are often missing).

Commit subjects often contain only a number, like fixed #47. In that case look up the title to understand the change:

sh
gh api repos/jjjkkkjjj/Matft/issues/<n> --jq '{title, pull_request: (.pull_request != null)}'

Follow the format of existing releases (N/A for empty sections):

markdown
- New Features
  - Add `Matft.foo` (#100)
- Improvement
  - N/A
- Bug fixed
  - `Matft.bar` returns wrong shape for negative axis (#101)
  • Write concisely in English. Wrap function names etc. in backquotes.
  • Include only changes that affect library users (features, behavior, public API, warnings, etc. in Sources/). Leave out CI/workflow changes, test-only changes, documentation or operations changes such as README and CLAUDE.md, and merge commits.
  • Append the related PR/issue numbers ((#57, #58) if several).

6. User confirmation

Present the results so far and get an explicit OK:

  • Version number
  • Commit to tag (hash and subject)
  • Test / CI results
  • Full release notes
  • Whether to reuse the draft or create a new Release

7. Tag and push

sh
git tag -a <version> -m "<version>" <commit>
git push origin <version>

Push the tag by name, not with git push --tags, so that stale or experimental tags left locally are not published along with it.

8. Publish the GitHub Release

Write the release notes to a temporary file (in the scratchpad) and pass that, to avoid escaping accidents with newlines and backquotes.

If there is a draft (a draft without a tag cannot be looked up by tag name with gh release edit, so update it through the API):

sh
gh api -X PATCH repos/jjjkkkjjj/Matft/releases/<draft-id> \
  -f tag_name=<version> -f name=<version> \
  -f body="$(cat <notes-file>)" \
  -F draft=false -f make_latest=true

If there is no draft:

sh
gh release create <version> --verify-tag --title <version> --notes-file <notes-file> --latest

--verify-tag makes it fail if the pushed tag does not exist, preventing gh from creating a tag on some other commit by itself.

9. Verify and report

sh
gh release view <version>
gh release list --limit 3        # the new version should be Latest
git ls-remote --tags origin <version>

Report the Release URL and that SwiftPM users can get it via File > Packages > Update to Latest Package Versions.

If you need to redo it

If a mistake is found after publishing, with the user's confirmation:

sh
gh release delete <version> --yes        # delete the Release (if needed)
git tag --delete <version>
git push origin :refs/tags/<version>

Also tell the user that a published tag may already be cached on the users' side, so re-releasing under the next patch number is often safer than re-tagging the same number.

© jjjkkkjjj, BSD-3-Clause. 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 jjjkkkjjj/Matft.

Open the folder on GitHubat commit 618dcfc

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 skilljjjkkkjjj/Matft147—~1.8kAutomated safety check: PassBSD-3-Clause
Cutting A ReleaseTriliumNext/Trilium38k—~3.2kAutomated safety check: PassAGPL-3.0
Rea Changelog Updatemorluto/rea80k—~1.9kAutomated safety check: PassMIT
Mole CLI Release Flowtw93/Mole70k—~2.6kAutomated safety check: PassGPL-3.0
Draft Release Notesjamiepine/voicebox57k—~941Automated safety check: PassMIT
Mole Release Notes Publishertw93/Mole70k—~1.9kAutomated safety check: PassGPL-3.0

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
  • Prepare or rewrite REA release changelogs and GitHub release notes from pinned Git history, with verified contributor thanks and Release Please synchronization.

    80k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed
  • 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.

    70k GitHub stars~2.6k tokensUpdated today
    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 4 days ago
    DevelopmentAuto-check passed
  • 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.

    70k GitHub stars~1.9k tokensUpdated today
    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 4 days ago
    DevelopmentAuto-check passed

More from jjjkkkjjj/Matft

  • Docs

    jjjkkkjjj/Matft

    Procedure for writing and updating Matft's documentation (the Docusaurus site in website/ and the doc comments on the public API that become the Swift-DocC API reference).

    147 GitHub stars~2.7k tokensUpdated 14 days ago
    Auto-check passed
  • Test Design

    jjjkkkjjj/Matft

    Procedure for designing and writing Matft's XCTest cases with high coverage — boundary values, dtypes, memory layouts, NaN/inf, empty arrays, broadcasting, platform differences, performance and…

    147 GitHub stars~2k tokensUpdated 14 days ago
    Auto-check passed
  • Benchmark

    jjjkkkjjj/Matft

    Procedure for benchmarking Matft's PerformanceTests against Numpy and reporting the results (and, when asked, updating the speed comparison table on the docs site, website/docs/performance.md).

    147 GitHub stars~1.7k tokensUpdated 14 days ago
    Auto-check passed
  • Image Visual Check

    jjjkkkjjj/Matft

    Procedure for adding tests for Matft's image processing (Matft.image., indexing or channel swapping on images, etc.), generating comparison images that put the result next to an OpenCV reference…

    147 GitHub stars~2.3k tokensUpdated 14 days ago
    Auto-check passed

Works with

Categories

Questions about Release

What does Release do?

Procedure for releasing a new version of Matft (decide the version → check tests → write release notes → create and push an annotated tag → publish a GitHub Release). Release is an agent skill from jjjkkkjjj/Matft. Procedure for releasing a new version of Matft (decide the version → check tests → write release notes → create and push an annotated tag → publish a GitHub Release).

When should I use Release?

Release fits situations like: the conversation is about bumping Matfts version; creating/updating a GitHub Release — e.g.

How do I install Release in Claude Code?

Run `npx skills add jjjkkkjjj/Matft --skill release -a claude-code`. Or copy the skill folder (.claude/skills/release in jjjkkkjjj/Matft) 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 jjjkkkjjj/Matft --skill release -a codex`. Or copy the skill folder (.claude/skills/release in jjjkkkjjj/Matft) 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 jjjkkkjjj/Matft --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 swift).

Does 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 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 BSD-3-Clause 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.8k tokens (SKILL.md is roughly 7.1k 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: Cutting A Release (TriliumNext/Trilium, 38k stars), Rea Changelog Update (morluto/rea, 80k stars), Mole CLI Release Flow (tw93/Mole, 70k stars) and Draft Release Notes (jamiepine/voicebox, 57k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release?

jjjkkkjjj (a GitHub user) maintains it in jjjkkkjjj/Matft, which has 147 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on September 27, 2026.

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