agr-release

agr Release Process

This skill walks through the full release process for the agr package. The release is tag-driven: pushing a vX.Y.Z tag triggers the GitHub Actions pipeline that runs quality checks, builds the package, publishes to PyPI, and creates a GitHub Release.

Your job is to prepare everything so that when the tag is pushed, the pipeline succeeds on the first try.

Before you start

Verify the preconditions. If any fail, stop and tell the user.

1. Clean working tree — git status should show no uncommitted changes
2. On the main branch — releases should only come from main
3. Up to date with remote — git pull to make sure you're not behind

Ask the user what kind of release this is:

• patch (0.7.10 → 0.7.11) — bug fixes, small changes
• minor (0.7.10 → 0.8.0) — new features, backwards-compatible
• major (0.7.10 → 1.0.0) — breaking changes
• beta (0.7.11b1) — pre-release for testing

If the user already said what type they want, don't ask again.

Step 1: Figure out what changed

Before touching any files, understand what's being released.

# See all commits since the last release tag
git log $(git describe --tags --abbrev=0)..HEAD --oneline

Also check the [Unreleased] section in CHANGELOG.md — it may already have entries. Cross-reference with the git log to make sure nothing is missing. If there are commits that aren't reflected in the changelog, add them.

Group changes into the standard Keep a Changelog categories:

• Added — new features
• Changed — changes to existing functionality
• Fixed — bug fixes
• Removed — removed features
• Docs — documentation-only changes

Step 2: Run quality checks

Run all three locally before proceeding. These are the same checks the CI pipeline runs, so catching failures here saves a round-trip.

uv run ruff check .
uv run ruff format --check .
uv run pytest -m "not e2e and not network and not slow"
uv run ty check

If anything fails, fix it before continuing. The release commit should pass CI cleanly.