Install any skill in seconds. Free to start, no credit card required.
Get Started Free →microsoft/agent-framework-py-release
Use when cutting a Python release for the microsoft/agent-framework monorepo. Triggers on "bump py versions", "cut a python release", "prepare release PR for python", "release py packages", "bump python to X.Y.Z", or similar requests to bump Python package versions and prepare a release PR. Handles all four lifecycle tiers (alpha, beta, rc, released) with CHANGELOG-driven selective bumps, floor bound checks, and post-bump validation.
Passed 14 of 19 test cases with the skill, and 3 of 19 without it.
and 18 more in the full report
12 fixed4 passed either way6 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are cutting release 1.7.0 which advances from 1.6.0. How should the reference links at the bottom of python/CHANGELOG.md be modified?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies inserting a new link for version 1.7.0 comparing python-1.6.0 to python-1.7.0. | Missed | Passed |
| Requires updating the Unreleased compare link to compare python-1.7.0 to HEAD. | Missed | Passed |
The instructions your model reads when the skill loads.
Cuts a Python release PR for the microsoft/agent-framework monorepo.
No more universal lockstep. A package only bumps if it has a CHANGELOG entry this cycle. Draft the CHANGELOG first, then derive the bump list from it.
Exceptions to selective bumping (these stay coupled regardless of per-package changes):
agent-framework is coupled to agent-framework-core via agent-framework-core[all]==X.Y.Z (exact pin in python/pyproject.toml). If core bumps, root bumps. Root may also bump independently for its own changes (docs/metadata/extras).If the user explicitly states which packages to bump (or hands over a PR list per package), treat that as authoritative.
Use python/.github/skills/python-package-management/SKILL.md as the source of truth for lifecycle
version patterns, date-stamp cutoffs, classifier alignment, and internal dependency updates.
For release work, derive the live tier map at release time from python/PACKAGE_STATUS.md and the actual
version = lines in each pyproject.toml. Do not hardcode counts — packages move between tiers.
git log ${LAST_RELEASED_TAG}..${RELEASE_BASE} -- python/.python-package-management
date-stamp rule.If the user states target versions or a date explicitly, use exactly what they said — do not "correct" based on historical timezones.
python/CHANGELOG.md; this workflow creates the entries centrally from merged changes.python-package-management for package lifecycle and versioning rules — do not duplicate thosetest cases passed, vs 3 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.