Prepare Release Agent Skill

Use when preparing a go-redis release — cutting a new version, bumping version.go, updating the go-redis dependency version in submodule go.mod files, or writing the RELEASE-NOTES.md entry for a new vX.Y.Z. Covers choosing the next semver, finding the last release and gathering merged PRs since then, the release-notes format and what to exclude, running scripts/release.sh to bump versions, and verifying with the scripts/tag.sh dry-run. Does NOT create tags, push, or commit — publishing stays a manual maintainer step.

1k tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

22209

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/redis/go-redis --skill prepare-release

What it tells the agent to use

found in the instruction text

Bash runs shell commands — read the instruction before connecting

The instruction itself

8 sections, as written by the author

Preparing a go-redis release

Stage everything for a release locally, then stop before anything is published.

This skill never publishes

Never run scripts/tag.sh ... -t — the -t flag creates and pushes git tags.
Never git push anything (no commits, no tags).
Never commit on the maintainer's behalf unless they explicitly ask.

The deliverable is a reviewable diff: bumped versions plus a new RELEASE-NOTES.md

entry. A human reviews it and runs the publish step.

1. Pick the next version

The current version is the source of truth in version.go:

grep 'return' version.go        # e.g. return "9.21.0"

Choose the next vX.Y.Z by semver, based on what shipped since the last release:

patch (Z) — bug fixes only; drop-in upgrade.
minor (Y) — new features, no breaking changes; drop-in upgrade.
major (X) — breaking changes.

Confirm the level with the user if the changeset is ambiguous.

2. Find the last release and gather changes

scripts/tag.sh also tags every public submodule (extra/redisotel/vX.Y.Z, …),

so a naive git describe returns a submodule tag. Match the root tag only:

LAST=$(git describe --tags --abbrev=0 --match 'v[0-9]*')   # e.g. v9.21.0
git log "$LAST"..HEAD --oneline
gh pr list --state merged --limit 100 \
  --json number,title,author,mergedAt,url --search "merged:>=<last-release-date>"

Categorize the PRs: highlights, new features, bug fixes, performance,

testing/infrastructure. Exclude dependabot bumps, typo-only doc fixes, internal

refactors with no user-facing effect, and dependabot[bot] from the contributor

list.

3. Write the release notes

Prepend a new # X.Y.Z (YYYY-MM-DD) section to the top of RELEASE-NOTES.md

(newest first; leave older entries untouched). Follow

.github/RELEASE_NOTES_TEMPLATE.md

exactly — section order, emoji headers, the (#PR) by @user link

format, and the Full Changelog compare link ${LAST}...vX.Y.Z. Open the

lead line with the release type and whether it is a drop-in upgrade, matching the

existing entries.

That template carries the full "what to exclude" and formatting rules — read it,

don't reinvent them. release-drafter separately auto-drafts a GitHub release

from PR labels (.github/release-drafter-config.yml); RELEASE-NOTES.md is the

curated, hand-written record and is the file you edit.

4. Bump versions

Run the repo's bump script. It rewrites the go-redis dependency version in every

submodule go.mod, runs go mod tidy, and bumps version.go. It does not

commit, push, or switch branches:

TAG=vX.Y.Z ./scripts/release.sh

5. Verify (dry run only)

Run the tag script's dry run — it checks that version.go and every go.mod

already match the tag, and prints the tags it *would* push. No -t:

./scripts/tag.sh vX.Y.Z         # DRY RUN — must pass cleanly; never add -t here
make build
git diff --stat                 # review version.go, submodule go.mod, RELEASE-NOTES.md

Fix anything the dry run flags before handing off.

6. Hand off

Report that the release is staged and list the publish steps for the maintainer

to run themselves (this skill does not do them):

Review git diff, then commit (chore(release): vX.Y.Z — see the

commit-style skill; no AI-attribution trailer).

Open and merge the release PR.
After merge, tag and push: ./scripts/tag.sh vX.Y.Z -t.
release-drafter publishes the GitHub release; reconcile it with the

RELEASE-NOTES.md entry if needed.

Stop after step 5. Do not commit, tag, or push.

Other skills for the same job

different authors, same section of the catalogue

Bioservices

by christophacham

×3

Unified Python interface to 40+ bioinformatics services. Use when querying multiple databases (UniProt, KEGG, ChEMBL, Reactome) in a single workflow with consistent API. Best for cross-database analysis, ID mapping across services. For quick single-database lookups use gget; for sequence/file manipulation use biopython.

Python library for working with geospatial vector data including shapefiles, GeoJSON, and GeoPackage files. Use when working with geographic data for spatial analysis, geometric operations, coordinate transformations, spatial joins, overlay operations, choropleth mapping, or any task involving reading/writing/analyzing vector geographic data. Supports PostGIS databases, interactive maps, and integration with matplotlib/folium/cartopy. Use for tasks like buffer analysis, spatial joins between datasets, dissolving boundaries, clipping data, calculating areas/distances, reprojecting coordinate systems, creating maps, or converting between spatial file formats.

Fast CLI/Python queries to 20+ bioinformatics databases. Use for quick lookups: gene info, BLAST searches, AlphaFold structures, enrichment analysis. Best for interactive exploration, simple queries. For batch processing or advanced BLAST use biopython; for multi-database Python workflows use bioservices.

Direct REST API access to UniProt. Protein searches, FASTA retrieval, ID mapping, Swiss-Prot/TrEMBL. For Python workflows with multiple databases, prefer bioservices (unified interface to 40+ services). Use this for direct HTTP/REST work or UniProt-specific control.

BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.

2k tokens

Moodle External API Development

by ComeOnOliver

×2

Create custom external web service APIs for Moodle LMS. Use when implementing web services for course management, user tracking, quiz operations, or custom plugin functionality. Covers parameter validation, database operations, error handling, service registration, and Moodle coding standards.

How to use it

Copy the folder

Take redis/prepare-release from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.