versioninglisted

Establish or maintain version certainty in a repo; one canonical VERSION stamped into every independently-deployed artifact, each made self-reporting, with a drift check. Use when setting up versioning in a new project, when asked "are we current / what's deployed?", when adding a version field/endpoint, or when build/deploy artifacts can silently drift out of sync.
srfinch17/peckworks-skills-laboratory · ★ 0 · AI & Automation · score 72

Install: claude install-skill srfinch17/peckworks-skills-laboratory

# Versioning: know what's actually deployed The failure this prevents: a repo ships several artifacts that deploy on **separate steps** (compile/flash, bundle upload, server restart, container redeploy), and *nothing* reports which version of each is actually live. You're left guessing whether a change landed. A hardcoded `version: "1.0.0"` that never changes is worse than nothing; it looks like a signal but isn't. ## The pattern (portable across any repo) 1. **One canonical source of truth.** A single `VERSION` file (SemVer) at the repo root. Nothing else is authoritative; everything is *stamped from* it. 2. **Enumerate the deployable artifacts**: the things that ship independently. Ask: "what are the separate deploy steps, and could each carry a different version?" Each one is an artifact. (Examples: firmware, a static web bundle, an API server, a DB migration set, a CLI binary, a published package, a container image.) 3. **Give each artifact a self-report channel**: a way to ask the *running/deployed* thing its version: a `/status` or `/version` endpoint field, a served `version.json`, a runtime-read manifest, a `--version` flag, an image label, a `__version__`. 4. **Stamp** `VERSION` into each artifact's source (a script that writes the header/manifest/ constant). Generated files carry a "do not edit by hand" banner. 5. **Add an automatic build marker where it's free**: e.g. a compiler's `__DATE__ __TIME__`, a build-time git SHA, an image digest