manage-versionslisted

# Cross-repo version management Every repo in `a-novel` and `a-novel-kit` is independently versioned, and the repos depend on each other (services pin `golib`, `jwt`, each other's `pkg/go`; deployments pin each other's Docker images; clients pin published packages). When a change touches more than one repo, the versions must line up before anything merges to production. This skill governs that. Load it with whichever repo-kind skill applies (`write-go-kit` for a `kit/` change, `write-go-service` for a service change), with `git-conventions` (the breaking-change commit footer) and `implement-feature` (the layered-branch workflow these cross-repo plans extend). --- ## How things are versioned - **Each repo is git-tag semver.** A release is a `vX.Y.Z` git tag pushed on a `master` commit; the next version comes from the commit history since the last tag (`fix:`/`chore:` → patch, `feat:` or an absorbable breaking change → minor). A `!` does **not** force a major here: a major is a planned `vX`-line initiative, never derived from a commit range — `prepare-release` owns that policy and the sizing. The tag push triggers the `release` workflow (`a-novel-kit/workflows/publish-actions/auto-release`), which cuts the GitHub Release and, for service repos, builds and publishes the Docker images / npm packages tagged with that version. - **`go.mod` pins exact released tags.** `github.com/a-novel-kit/golib v0.20.31`, not a range, not a branch. **No `replace` directives**