release-check

# Release Check — Orchard Cutting a release for Orchard is mechanical but easy to half-do (tag without the migration check, bump the version but forget the changelog). This skill is the checklist so nothing slips. It loads only when you're releasing — everyday work doesn't pay for it. ## When this fires You type `/release-check`, or you're about to tag a new Orchard version. ## Checklist Walk these in order. Stop at the first failure, fix it, restart — a release is atomic. 1. **Clean tree, right branch.** `git status` is clean and you're on `main` (or the release branch). No uncommitted work rides along in a tag. 2. **Bump the version.** Update `version` in `pyproject.toml`. Use semver: breaking API/contract change → major; new endpoint/field → minor; fix only → patch. 3. **Migrations present and current.** `alembic check` is clean (no model-vs-history drift), and every new revision has been **applied once against a dump of representative data**, not just an empty DB. `alembic check` proves agreement, not applicability — this step proves applicability. 4. **Verify is green.** Run `scripts/verify.sh` and read the output: `format`, `lint`, `types`, `migrations`, `test` all pass. Within-a-layer green only — also confirm one real request path (TestClient against the full app) still works end to end. 5. **Changelog updated.** Add a dated section to `CHANGELOG.md` for this version: what changed, and call out any **API-contract or migration** change explic...