release-check

# Release check — $ARGUMENTS The release workflow is triggered by a published GitHub Release (see `.github/workflows/release.yml`). `publish-core` runs first, then `publish-cli` and `publish-connectors` in parallel. Every package needs its own version bump + CHANGELOG entry + passing tests before you tag. Parse `$ARGUMENTS` as `<package> <new-version>` (e.g. `core 0.3.2`, `openai 0.2.0`). ## Locate the package | Package | Path | |---|---| | `core` | `libs/core` | | `cli` | `cli` | | any connector | `libs/connectors/<name>` | ## Checklist Run each step. Stop and report on the first failure. 1. **Version bump.** Read `<path>/pyproject.toml`. If `version` != `$2`, edit it to `$2`. 2. **Core dependency pin (connectors only).** Confirm `genblaze-core>=<x>` is at or above the currently published core version. If `core` is also being released in this wave, the connector pin should match. 3. **Entry point sanity (connectors only).** Confirm the `[project.entry-points."genblaze.providers"]` line exists and the module/class is importable: `python -c "import genblaze_<name>; <name>.<Class>()" || true` (instantiation may require credentials — just check the import). 4. **Tests.** `cd <path> && pytest -v` must pass. 5. **Lint.** `ruff check <path>` and `ruff format --check <path>` must pass. 6. **Typecheck (core only; connectors optional).** `mypy <path>/genblaze_*/ --ignore-missing-imports`. 7. **Build check.** `cd <path> && python -m build && twine check dist/*` — validates wheel metadata before PyPI sees it. 8. **CHANGELOG.** Confirm `CHANGELOG.md` has an entry for version `$2` scoped to this package. If missing, draft one from `git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || echo HEAD~30)..HEAD -- <path>`. 9. **Doc freshness.** For connectors: confirm the matching section in README.md and any `docs/features/provider-system.md` entry is accurate for `$2`. ## Report A pass/fail table, then the exact next commands: ``` git add <path>/pyproject.toml CHANGELOG.md git commit -m "release: <package> v<new-version>" git push ``` This gate gets one package release-ready within a wave — it does not tag or publish. The actual tag/release/publish flow is wave-level, not per-package (the workflow's `validate-version` job requires the tag to be `v<wave>`, the CHANGELOG's most recent version heading — see RELEASING.md's versioning policy); a tag shaped `<package>-v<new-version>` will not trigger it correctly. Once every package in the wave is ready, cut the release with `/prepare-release`, which also fixes the `--notes-from-tag` bare-body trap this skill previously suggested here.