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 adamayoung in adamayoung/TMDb

Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub…

Apache-2.0Auto-check passedDevelopment

Install Cut Release

skills CLI
$ npx skills add adamayoung/TMDb --skill cut-release -a claude-code

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

GitHub CLI
$ gh skill install adamayoung/TMDb 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/adamayoung/TMDb.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
178
Token cost
~3k tokens
SKILL.md length
1,751 words
Files
1
Skills in repo
18
Repo updated
First seen
Licence
Apache-2.0

At a glance

Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub…

  • Works in 9 steps: Preflight → Work out the version → Pre-tag housekeeping → …
  • Tasks that involve Changelog and release notes
  • SKILL.md covers Phase 1 — Preflight, Phase 2 — Work out the version, Phase 3 — Pre-tag housekeeping and Phase 4 — Draft the release…, plus 7 more sections
  • Calls git, gh and make

What it does

Cut Release is an agent skill from adamayoung/TMDb. Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub release. Presents the version (with its reasoning) and the full notes for approval and STOPS; nothing is tagged or published until you say go.

Its SKILL.md is about 3k 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 Git. The repository describes itself as: The Movie Database Swift Package. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Changelog and release notes

Example prompts

  • “/cut-release”

Workflow steps

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

  1. Preflight
  2. Work out the version
  3. Pre-tag housekeeping
  4. Draft the release notes
  5. Assemble the summary
  6. STOP
  7. Land the housekeeping
  8. Tag
  9. Publish

What it can do on your machine

Read from SKILL.md and the folder at commit a3f1311. 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
    • make

    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 3k tokens when it runs. Until then it costs about 88 tokens; SKILL.md has 1,751 words of instructions outside code blocks.

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

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 adamayoung/TMDb at commit a3f1311, republished under its Apache-2.0 licence (© adamayoung). 1,751 words, ~3,014 tokens.

Download SKILL.mdSave it as .claude/skills/cut-release/SKILL.md (or your agent's skills folder).
name
cut-release
description
Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub release. Presents the version (with its reasoning) and the full notes for approval and STOPS; nothing is tagged or published until you say go.

Cut Release

Takes main from "a pile of merged PRs" to "a tagged, published release".

This skill is never headless. Every other skill in this repo may decide for itself; this one may not. A tag is the one artifact consumers resolve against, and publishing one is effectively irreversible: SwiftPM hands a new minor or patch to everyone inside the current from: range the moment it exists, a new major reaches everyone who has since bumped, and deleting a tag does not un-fetch it from anyone who already resolved. Phases 1–5 are read-only and local. Phase 6 is a hard stop. Phases 7–9 run only on an explicit go-ahead.

If invoked with no human able to answer, run to the hard stop, print the summary, and exit. Do not tag.

Phase 1 — Preflight

Stop on any failure; report which one and what to do.

  • On main, clean tree, in sync with origin/main (git status --porcelain, git rev-list --count main..origin/main).
  • git fetch --tags; establish the last release: git tag --sort=-v:refname | head -1.
  • CI is green on the current main tip: gh api repos/adamayoung/TMDb/commits/<sha>/check-runs. This is the entry check — the commit that actually gets tagged does not exist yet (Phase 7 creates it), and Phase 7 re-checks that one. Starting from a red main just means finding out later.
  • There is something to release — at least one commit since the last tag that is not purely a tag-housekeeping commit.

Phase 2 — Work out the version

Two independent signals. They must agree, or you stop.

Signal A — the CHANGELOG (authoritative). The open ## [X.Y.Z] section at the top (no date = unreleased) is the proposal. Count **Breaking:** markers inside it, and read the section headings:

  • any **Breaking:** → major
  • otherwise any ### Added content → minor
  • otherwise (### Fixed / ### Changed only) → patch

Signal B — the commits (cross-check). git log <lasttag>..HEAD, bucketed by gitmoji. Consumer-visible: ✨ feature, 🐛 fix, ♻️ refactor, 🔒 security, ⚡️ perf. Not consumer-visible: 🔧 chore, 📝 docs, 👷 CI, ✅ tests, 📦 build. Count multibyte-safely — sort | uniq -c over emoji collapses distinct ones in a non-UTF-8 locale and will hand you a confidently wrong tally.

Gitmoji alone is not enough to pick a version in this repo, and you must not try. A 🐛 here is routinely source-breaking: "🐛 Surface task cancellation as TMDbError.cancelled" (PR #433) was filed as a fix and added an enum case, which breaks every exhaustive switch downstream. Signal B exists to catch omissions from the CHANGELOG, not to compute the bump.

Then reconcile:

  • The proposed section heading must match what Signal A computes from its own content. A section headed [20.0.0] containing no **Breaking:** is a mis-labelled release — stop and report, do not silently downgrade it.
  • knowledge/next-major.md's status line names the open window. If it disagrees with the CHANGELOG heading, stop.
  • The computed tag must not already exist.

Coverage check. Every commit since the last tag that touches Sources/ and carries a consumer-visible gitmoji should be represented somewhere in the open CHANGELOG section. List any that are not. This is the check that catches a real change shipping invisibly; the not-consumer-visible buckets legitimately have no CHANGELOG entry and are not flagged.

Phase 3 — Pre-tag housekeeping

Branch first. git checkout -b chore/prepare-<version>-release. Phase 1 put you on a clean main, and CLAUDE.md forbids editing there — but the practical reason is re-entrancy: if the run is abandoned at the Phase 6 stop, edits made on main leave a dirty tree that fails this skill's own Phase 1 preflight on the next attempt. Branching now costs nothing and makes an abort free.

A tag snapshots the tree, so anything that says "unreleased" is frozen saying it, forever, inside the very release it describes. These four are not optional, and all of them were needed for 19.0.0 (PR #406):

  1. README.md install snippet. from: "<previous major>" resolves to >=prev, <prev+1 — on a major, readers following the README would never resolve to the new version at all. Bump it. (This is the one with real user impact; the other three are hygiene.)

    Scripts/check-readme-version.py enforces this from make lint and CI: the snippet must match either the newest dated CHANGELOG section (the last release) or the newest undated one (the release being prepared). That second arm exists so this housekeeping PR is not blocked by the tag it is preparing — bump the snippet and date the section in the same commit and both arms stay satisfied. Forget the bump entirely and the check goes red on the next PR after the release.

  2. CHANGELOG.md. Date the section — ## [X.Y.Z] - YYYY-MM-DD — and add the link definition at the foot: [X.Y.Z]: https://github.com/adamayoung/TMDb/releases/tag/X.Y.Z. Check the previous version's definition is there too; they have been missed before.

  3. knowledge/next-major.md. Rewrite the status line: this version has shipped, and the next major's window is now open. Remove every backlog entry that shipped in this release (the file's own rule). An entry left behind claiming to await a window that just closed is invisible exactly when it should fire.

  4. ADR statuses. Every knowledge/decisions/*.md reading Accepted (in X.Y.Z, unreleased) becomes Accepted (shipped in X.Y.Z) — in the file and in the decisions/README.md index. Leave unreleased — tooling only ADRs alone; they describe .claude/ machinery with no library impact and no version to ship in.

Make these edits on the branch but do not commit yet — they are shown at the hard stop, and they go up as a PR, never straight to main.

Phase 4 — Draft the release notes

Structure, in this order:

  1. The opener. Two or three sentences, warm and a little funny. Write a new one every time — see Voice below.
  2. Upgrade impact, if this is a major or has any **Breaking:** entry. What breaks, and the one-line fix for each. This sits above the feature list.
  3. What's new / What's fixed / What changed — consumer-facing prose, drawn from the CHANGELOG (which is already written for humans), not from commit subjects.
  4. Commits, inside a <details> block: every commit since the last tag, one line each — <sha> <subject>. Collapsed, because it is a reference, not a read.
  5. Full Changelog compare link: https://github.com/adamayoung/TMDb/compare/<lasttag>...<newtag>.
Show full SKILL.md (753 more words)Show less
Voice

Slack's iOS notes are the reference: they open with something human, and they never pretend a bugfix release is a moon landing. Aim for a colleague writing to other developers — dry, specific, occasionally silly, never markety.

  • Good: naming the actual absurdity. "This release is mostly about a movie database telling us, with total confidence, that Bryan Cranston has never been in a TV series."
  • Good: cheerful understatement. "Eighteen of twenty tagged images were quietly going in the bin. They are no longer going in the bin."
  • Avoid: "We're excited to announce", "packed with", "🚀", exclamation marks in rows, and any claim the diff does not support.
  • Avoid: whimsy about the breaking part. Joke about the bug you fixed, not about the work you have just made someone do. If this release breaks builds, the opener stays light but stays short — then get straight to the impact.

Length: the opener is 2–3 sentences. If it needs a fourth, it is a paragraph, and paragraphs are what section 3 is for.

Phase 5 — Assemble the summary

Put together, for one message:

  • Version and the reasoning — the deciding evidence, not a recitation. "Major: 14 **Breaking:** entries, including four public enums gaining cases" beats "there were breaking changes".
  • Anything Signal B flagged as missing from the CHANGELOG.
  • The four housekeeping edits, as a diff summary.
  • The complete release notes, verbatim as they will be published.

Phase 6 — STOP

Present the summary and wait. Do not tag, push, or publish anything.

Ask plainly whether to go ahead. Treat anything short of a clear yes as a no — "looks good" about the notes is not approval to publish. If the answer is a change request, apply it and return to this phase; the gate re-arms every time.

Phase 7 — Land the housekeeping

Only after approval. The branch already exists from Phase 3.

Commit the Phase 3 edits as 🔧 Prepare the <version> release, open the PR via /pr, and let its CI run. The narrowed docs/config gate usually applies here — the diff is Markdown only — but /pr owns that call; do not pre-empt it.

Merge once green.

Then wait for main's own run. ci.yml triggers on push to main with **/*.md among its paths, so the squashed merge commit gets a CI run of its own — a different commit from the PR head, and the one the tag will point at. Phase 1's "green on the exact commit being tagged" means this run, not the PR's. Poll it:

bash
gh api repos/adamayoung/TMDb/commits/$(git rev-parse HEAD)/check-runs \
  --jq '[.check_runs[] | {name, status, conclusion}]'

Red or still running → do not tag. This is the cheapest place in the whole skill to be patient.

Phase 8 — Tag

On the merged main, at the housekeeping commit:

bash
git checkout main && git pull
git tag -a <version> -m "<version>"
git push origin <version>

Annotated, not lightweight — a release tag should carry an author and a date.

Regenerate the commit list before publishing. The notes were drafted in Phase 4, before the housekeeping merge existed — so their <details> list is short by exactly the commit being tagged, while the compare link below it includes it. Re-run the log against the new tag and refresh that block.

Phase 9 — Publish

bash
gh release create <version> --repo adamayoung/TMDb \
  --title "<version>" --notes-file <path> --verify-tag --latest

--verify-tag refuses to invent a tag that does not exist, which is what turns a typo into a failed command instead of a phantom release.

Then confirm: print the release URL, and re-read the published notes once to check nothing was mangled in transit.

After

Report the tag, the release URL, and what the next window is now open for. If any knowledge/next-major.md entries were deliberately carried forward rather than shipped, name them — that is the moment someone can still object.

Failure modes worth knowing

  • A red tag. Tagging a commit whose CI never passed. Phase 1 exists for this; do not skip it because "the PR was green" — the merge commit is a different commit, and it gets its own run.
  • Assuming a bad tag is cheap to undo. Two active tag rulesets cover ~ALL tags with creation, update and deletion rules. The repository-role bypass means the owner can force it, but nothing here is a casual git push --delete — and SwiftPM consumers who already resolved the version are unaffected by any of it. Get it right going in.
  • A frozen "unreleased". Skipping Phase 3 ships ADRs and a next-major.md that insist, inside the release, that the release has not happened.
  • A README nobody can follow. The from: bump is invisible in testing and breaks discovery for every new consumer on a major.
  • Version invented from commits. Deriving the bump from gitmoji rather than the CHANGELOG will under-call a major in this repo, roughly every time.

© adamayoung, 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

Just SKILL.md in .claude/skills/cut-release of adamayoung/TMDb.

Open the folder on GitHubat commit a3f1311

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 skilladamayoung/TMDb178—~3kAutomated safety check: PassApache-2.0
Draft Release Notesjamiepine/voicebox57k—~941Automated safety check: PassMIT
Mole Release Notes Publishertw93/Mole70k—~1.9kAutomated safety check: PassGPL-3.0
Release Bumpjamiepine/voicebox57k—~1.1kAutomated safety check: PassMIT
Verdaccio Pull Request Workflowverdaccio/verdaccio18k—~1.9kAutomated safety check: PassMIT
Go-Redis Release Preparationredis/go-redis22k—~1.1kAutomated safety check: PassBSD-2-Clause

Similar skills

  • 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 3 days ago
    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.

    70k 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 3 days ago
    DevelopmentAuto-check passed

  • Verdaccio Pull Request Workflow

    verdaccio/verdaccio

    Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

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

  • Go-Redis Release Preparation

    redis/go-redis

    Official

    Prepares a go-redis release locally: picks the next semver, gathers merged PRs, writes the RELEASE-NOTES entry and bumps versions, without publishing.

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

  • Hunk Release Workflow

    modem-dev/hunk

    Maintainer workflow for preparing, publishing, verifying and curating Hunk releases, with confirmation gates before tags, publishes and public edits.

    9.6k GitHub stars~3.8k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

More from adamayoung/TMDb

All 18 skills in this repo

  • Swift DocC Documentation

    adamayoung/TMDb

    Writes and maintains DocC /// comments for the public API of the TMDb Swift package, following the project's summary patterns and comment structure.

    178 GitHub stars~2.6k tokensUpdated 6 days ago
    Auto-check passed

  • TMDb Integration Failure Fixer

    adamayoung/TMDb

    Diagnoses a failing scheduled TMDb Integration run, re-runs transient failures, and fixes real API drift on its own branch with a PR, merging it only when told to.

    178 GitHub stars~2.7k tokensUpdated 6 days ago
    Auto-check passed

  • Implement Plan (Canon TDD)

    adamayoung/TMDb

    Drives an approved plan to completion test-first, deriving a Canon TDD test list, showing it before any code and stopping only when every item is written, passing and green.

    178 GitHub stars~4.5k tokensUpdated 6 days ago
    Auto-check passed

  • TMDb Backlog Triager

    adamayoung/TMDb

    Grooms the Backlog column of a GitHub project board by re-verifying each issue against current main, closing dead ones, promoting actionable ones to Ready and naming the decision the rest need.

    178 GitHub stars~5k tokensUpdated 6 days ago
    Auto-check passed

  • Canon TDD Workflow

    adamayoung/TMDb

    Has your agent build features and fix bugs in Canon TDD order: write a test list, then one failing test, make it pass, refactor, and repeat until the list is empty.

    178 GitHub stars~1.3k tokensUpdated 6 days ago
    Auto-check passed

  • Capture Knowledge

    adamayoung/TMDb

    Records non-obvious lessons from a finished task, such as gotchas, API quirks and design decisions, into a project's knowledge folder before a pull request opens.

    178 GitHub stars~2.3k tokensUpdated 6 days ago
    Auto-check passed

Works with

Categories

Questions about Cut Release

What does Cut Release do?

Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub…. Cut Release is an agent skill from adamayoung/TMDb. Cut a new TMDb release — work out the next SemVer version from the evidence, do the pre-tag housekeeping a tag would otherwise freeze in place, draft release notes, then tag and publish the GitHub release.

When should I use Cut Release?

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

How do I install Cut Release in Claude Code?

Run `npx skills add adamayoung/TMDb --skill cut-release -a claude-code`. Or copy the skill folder (.claude/skills/cut-release in adamayoung/TMDb) 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 adamayoung/TMDb --skill cut-release -a codex`. Or copy the skill folder (.claude/skills/cut-release in adamayoung/TMDb) 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 adamayoung/TMDb --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 the command-line tools its instructions call (git, gh and make).

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. Review the folder before installing.

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 3k 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 Cut Release?

Skills that share tags, products or a category with Cut Release: Draft Release Notes (jamiepine/voicebox, 57k stars), Mole Release Notes Publisher (tw93/Mole, 70k stars), Release Bump (jamiepine/voicebox, 57k stars) and Verdaccio Pull Request Workflow (verdaccio/verdaccio, 18k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Cut Release?

adamayoung (a GitHub user) maintains it in adamayoung/TMDb, which has 178 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on October 3, 2026.

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