Automates package versioning, changelog updates, and GitHub release tagging for Takopi.
Install
mkdir -p .claude/skills/takopi-release && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4947" && unzip -o skill.zip -d .claude/skills/takopi-release && rm skill.zipInstalls to .claude/skills/takopi-release
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Prepare and ship a Takopi release. Use when asked to cut a release, bump release versions, update changelog/spec/readme, tag v<major.minor.patch>, or trigger the GitHub release workflow.Key capabilities
- →Bump project version numbers
- →Update changelog.md with release details
- →Tag releases in Git
- →Refresh lock files
- →Update specification documentation
How it works
It updates version strings across project files, generates changelog entries, and triggers the release tagging process to initiate CI/CD workflows.
Inputs & outputs
When to use takopi-release
- →Bump project version
- →Update changelog for release
- →Tag new Takopi version
About this skill
Takopi Release
Overview
Prepare a tagged release that matches the GitHub Actions release workflow. The workflow requires the tag version to match pyproject.toml. If src/takopi/__init__.py contains a literal __version__ = "...", that literal must also match; current Takopi reads __version__ from package metadata instead.
Workflow
1) Choose version + date
Pick the release version (major.minor.patch) and the release date (YYYY-MM-DD) for changelog/spec headers.
If the current version has a .dev suffix, assume the target release version is the same version without the suffix, as long as that tag does not already exist.
2) Update changelog
Update changelog.md by adding a new top section. Before writing it, study the diff between the previous tag and the new release to rank changes; put user-facing changes first.
## v<major.minor.patch> (YYYY-MM-DD)- Include subsections like
changes,fixes,breaking,docsas needed. - Keep entries short and include PR links when available (match existing style).
3) Bump versions
Update version strings to match the release tag:
pyproject.toml:project.version = "<major.minor.patch>"src/takopi/__init__.py: only update this if it contains a literal__version__ = "<major.minor.patch>"; no change is needed when it usesimportlib.metadata.version("takopi")uv.lock: refresh so the root package version matches (runuv lockoruv sync).
4) Update spec + docs
Update docs/specification.md to match the release:
- Header:
# Takopi Specification v<major.minor.patch> [YYYY-MM-DD] - Replace
Takopi v<old>andOut of scope for v<old>lines with the new version. - Add a changelog entry like
- No normative changes; align spec version with the v<major.minor.patch> release.unless the spec itself changed.
If the release highlights new features, update readme.md accordingly (see v0.9.0 release).
5) Run checks
Run the standard checks before committing:
just check(ruff/ty/pytest)
6) Commit + tag
Commit the release using conventional commits:
- Commit message:
chore(release): v<major.minor.patch> - Tag:
git tag v<major.minor.patch>
Push the tag to trigger .github/workflows/release.yml (build, PyPI publish, GitHub release).
7) Optional post-release bump
If you keep a dev version between releases, bump the minor version (reset patch to 0) and commit (chore: bump version to ...).
Notes
- The release workflow checks that the tag matches
pyproject.toml, and also checkssrc/takopi/__init__.pyonly when it contains a literal__version__string. - Keep dates consistent across
changelog.mdanddocs/specification.md.
When not to use it
- →Non-Takopi projects
- →Manual release tagging without version updates
Prerequisites
Limitations
- →Requires version format compliance
- →Depends on specific file structure
How it compares
It enforces consistency between project metadata and release tags, reducing manual errors in versioning.
Compared to similar skills
takopi-release side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| takopi-release (this skill) | 1 | 3mo | No flags | Intermediate |
| dev | 2 | 6mo | Review | Advanced |
| release-skills | 2 | 3mo | Review | Intermediate |
| http-client-python-bump-and-release | 1 | 6mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
dev
atopile
LLM-focused workflow for working in this repo: compile Zig, run the orchestrated test runner, consume test-report.json/html artifacts, and discover/debug ConfigFlags.
release-skills
JimLiu
Universal release workflow. Auto-detects version files and changelogs. Supports Node.js, Python, Rust, Claude Plugin, and generic projects. Use when user says "release", "发布", "new version", "bump version", "push", "推送".
http-client-python-bump-and-release
microsoft
Create a PR to bump dependencies or release a new version of the http-client-python package. Use when the user wants to bump TypeSpec/Azure-tools dependencies, update peer dependencies, or release a new version of the Python HTTP client.
testing
hw-native-sys
Testing guide and pre-commit testing strategy for PTO Runtime. Use when running tests, adding tests, or deciding what to test before committing.
ci-pr-helper
lance-format
Run local test/style checks and open GitHub PRs for lance-context. Use when asked to run CI-equivalent checks (uv pytest, ruff/pyright, cargo fmt/clippy/test) and then create a PR with a proper title/body.
auto_pr
splendidsummer
auto_pr — an agent skill by splendidsummer.