Manages Python library releases including semantic versioning, changelog maintenance (Keep a Changelog format), release automation with GitHub Actions, and deprecation workflows. Use when planning releases, writing changelogs, automating release pipelines, or communicating breaking changes.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
MAJOR.MINOR.PATCH (e.g., 1.2.3)
PATCH: Bug fixes, no API changes
MINOR: New features, backward compatible
MAJOR: Breaking changes
# Changelog
## [Unreleased]
### Added
- New `batch_encode()` function
## [1.2.0] - 2024-03-15
### Added
- Support for custom formats (#123)
### Fixed
- Edge case at -180 longitude (#145)
### Deprecated
- `old_function()` - use `new_function()` instead
[Unreleased]: https://github.com/user/repo/compare/v1.2.0...HEAD
[1.2.0]: https://github.com/user/repo/releases/tag/v1.2.0
Categories: Added, Changed, Deprecated, Removed, Fixed, Security
# src/package/__init__.py
__version__ = "1.2.3"
# Or use importlib.metadata
from importlib.metadata import version
__version__ = version("my-package")
A tag-triggered workflow builds and publishes to a registry via trusted publishing (no stored token) is the general shape — swap the publish step for whatever registry the project actually uses (PyPI, npm, crates.io, ...):
# .github/workflows/release.yml
on:
push:
tags: ['v*']
jobs:
release:
runs-on: ubuntu-latest
permissions:
contents: write # create the GitHub release
id-token: write # trusted publishing (no token)
steps:
- uses: actions/checkout@v4
- uses: astral-sh/setup-uv@v5
- run: uv build
- uses: softprops/action-gh-release@v2
with:
files: dist/*
- uses: pypa/gh-action-pypi-publish@release/v1
Warn with stacklevel=2 so the message points at the caller.
import warnings
def old_function():
"""Deprecated: Use new_function() instead."""
warnings.warn(
"old_function() deprecated, will be removed in 2.0.0",
DeprecationWarning,
stacklevel=2,
)
return new_function()
# 1. Update CHANGELOG.md (move Unreleased to version)
# 2. Bump version in the project manifest
# 3. Commit and tag
git commit -am "Release v1.2.0"
git tag -a v1.2.0 -m "Release v1.2.0"
git push origin main --tags
# 4. CI publishes automatically (if automated) or publish manually
Before Release:
- [ ] All tests pass
- [ ] CHANGELOG updated
- [ ] Version bumped
- [ ] Documentation current
After Release:
- [ ] Registry shows new version
- [ ] A fresh install actually works (not just that the tag/publish succeeded)
- [ ] GitHub release created
- [ ] Docs updated
CHANGELOG.md here already follows Keep a Changelog's dated-section format
(## 0.10.0 — 2026-09-06 — ...), so the format guidance above matches this
repo exactly. Two real differences from the generic PyPI example:
.github/workflows/release.yml — the 0.10.0 release this session did every
step by hand: bump package.json's version, convert the CHANGELOG's
## Unreleased into a dated section, git tag, create the GitHub Release,
then npm publish separately. This is exactly the gap managing-python-releases
is meant to close with automation — worth considering if releases become
frequent enough that a manual miss (like 0.9.2 sitting un-published to npm
for a while, discovered this session) becomes a recurring problem.__version__ in code —
scripts/_contract.py's skill_version() and doctor's version field
both read package.json directly (see this repo's own concurrent-branches
and build-artifacts skill notes for the related merge-conflict and
publish-verification patterns this touches).Source: wdm0006/python-skills (MIT).
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Builds robust Python MCP (Model Context Protocol) servers with FastMCP — tool design, error contracts, event-loop-safe blocking work, subprocess/CLI wrapping, single-file vs packaged distribution, global-state-free testing, and prompt-injection awareness. Use when writing an MCP server, exposing a tool or CLI to an LLM client, debugging tool registration/packaging, or testing MCP tools.
日本語の概要は準備中です。原文の説明を表示しています。
Generate GitHub Actions CI/CD pipeline configurations for automated building and testing of library and package projects. Use when creating or updating CI workflows for npm packages, Python packages, Go modules, Rust crates, or other library projects that need automated build and test pipelines. Includes templates for common package ecosystems with best practices for dependency caching, matrix testing, and artifact publishing.
日本語の概要は準備中です。原文の説明を表示しています。
Resolve conflicts and merges when several branches are open against one repo at the same time — the hotspot files every change must touch (registry manifests, a single version field, shared tool config, one aggregated test module, tracked build output), union-vs-recompute-vs-rebuild as three different correct resolutions, generated artifacts that must never be merged, non-deterministic serialization that makes every branch conflict, renumbered identifiers that git cannot show you, and why a clean auto-merge is not a passing test. Use when rebasing or merging a long-lived branch, resolving conflict markers, reviewing a merge commit, deciding what a repo should commit vs generate, or setting up a repo that will take parallel contributions.
日本語の概要は準備中です。原文の説明を表示しています。
Edit video and audio with local FFmpeg from natural-language requests: cut, trim, join, resize/reframe (9:16, 1:1), speed change, captions and subtitles (SRT/ASS, animated, karaoke), logos and text overlays, lower-thirds and titles, silence removal, multicam and external-mic sync, loudness normalisation, HDR/Dolby Vision to SDR, LUTs, background music with ducking, platform exports (YouTube, Reels, TikTok, X), compliance checks, scene detection and highlight reels, contact sheets to inspect results, and whole-edit project files. Use this skill whenever the user mentions a video or audio file (mp4, mov, mkv, wav, m4a), footage, a clip, captions, subtitles, a reel or short, YouTube/Instagram/TikTok delivery, LUFS, sync, transcoding, ffmpeg, or asks to make something "60 seconds", "vertical", "louder", "captioned" — even when they do not say "edit". Python 3.9 standard library only, no cloud, no API keys.
日本語の概要は準備中です。原文の説明を表示しています。
Add and review preconditions on operations that delete, overwrite, rewrite history, or resolve a caller-supplied name to a filesystem path — refusing instead of warning, placing the guard ahead of the first mutation, structural classification rather than string-prefix matching, name validation plus resolved-path containment as two independent checks, why a guard on the destructive path is invisible to the dry-run, and mutation-testing each half separately. Use when writing or reviewing a `--rebuild`/`--reset`/`--purge` command, a bulk delete, a history rewrite, an `rm -rf`-shaped step, or any code that turns an argument into a file path.
日本語の概要は準備中です。原文の説明を表示しています。
Prevents, detects, and remediates files that should never be committed — secrets (.env, API tokens, hardcoded credentials) and dev artifacts (build output, scratch databases, editor/OS files). Covers .gitignore (and why it does not untrack), git rm --cached, auditing tracked files, history scrubbing, and credential rotation. Use when a repo has committed secrets or junk, when setting up a new repo's ignore rules, or when reviewing what a repo actually tracks.
日本語の概要は準備中です。原文の説明を表示しています。