← ClaudeAtlas

vibey-releasinglisted

Release-please workflow, Conventional Commits, and publishing to PyPI. Read before cutting a release.
adammatthewsteinberger/vibey · ★ 3 · AI & Automation · score 70
Install: claude install-skill adammatthewsteinberger/vibey
# vibey releasing Vibey uses **release-please** for automated semantic versioning and changelog generation, triggered by Conventional Commits. ## Conventional Commits (enforced) Every commit message must follow Conventional Commits format. A pre-commit hook rejects anything else: ``` feat: add support for GitHub Actions deployment fix: prevent race condition in lease renewal docs: update handoff protocol spec chore: bump dependencies test: add property test for rotation fairness ``` **Scopes are optional** but recommended for large changes: ``` feat(domain): add media provider round-robin cursor fix(cli): correct --cwd handling in run command ``` **Breaking changes** carry a `!` or a `BREAKING CHANGE:` footer: ``` feat!: require Python 3.12+ BREAKING CHANGE: Python 3.11 is no longer supported. ``` **Why this matters:** release-please parses commit messages to determine version bumps (`fix` → patch, `feat` → minor, `BREAKING CHANGE` → major) and generate changelogs. A malformed commit breaks the release automation. ## Release workflow 1. **Merge to `develop`** — feature PRs squash into `develop`. 2. **`develop` → `main`** — when ready to release, merge `develop` into `main` via a merge commit (never squash). 3. **Release-please PR** — on push to `main`, the `release-please.yml` workflow creates or updates a release PR. It: - Bumps version in `pyproject.toml` - Updates `CHANGELOG.md` - Tags the release 4. **Merge the release PR** — merging it creates