.agents/skills: add mz-dbt-release runbook#36637
Conversation
Encodes the three-file release procedure for the dbt-materialize PyPI package: bump version in __version__.py + setup.py, date the Unreleased CHANGELOG entry, commit as `dbt-materialize: release vX.Y.Z` with a `Ship:` URL pointing at the feature/fix PR being released. Also notes which checks (cargo, bin/fmt, bin/lint) do not apply to a version-bump-only PR.
sjwiesman
force-pushed
the
dbt-release-skill
branch
from
cda8e36 to
e30cc7f
Compare
bosconi
left a comment
bosconi
left a comment
There was a problem hiding this comment.
Nicely scoped runbook — accurate where it counts (file paths, the
__version__.py↔setup.py sync rule, the +4/-2 shape across the
three recent releases I checked). Suggestions in-line plus:
Consider scripting the mechanical edits. This procedure is
genuinely mechanical — read current version, bump, write to two
files, insert dated heading. A ~30-line tools/cut_release.py X.Y.Z
would (a) eliminate the version-string drift class of bugs, (b) let
you drop the +4/-2 sanity check entirely, and (c) shrink SKILL.md
to "run the script, then commit". Strict-runbook is defensible (a
human eyeballing each edit is the current shape), but worth a
conscious choice rather than the default. No strong opinion — just
wanted to surface the option.
Co-authored-by: Jon Currey <bosconi@users.noreply.github.com>
3 participants
Summary
Adds an agent skill that documents the mechanical procedure for cutting a
dbt-materializePyPI release: bump the version in__version__.pyandsetup.py, date the## UnreleasedCHANGELOG entry, and open a PR titleddbt-materialize: release vX.Y.Zwith aShip: <url>body.The skill also calls out which Materialize-wide checks (
cargo check,bin/fmt,bin/lint) do not apply to a version-bump-only PR, so future releases don't get blocked on irrelevant pre-commit machinery.Verified end-to-end against the v1.9.10 release (#36636), which followed this exact recipe.
Test plan