Files
dotfiles/.agents/skills/bump-pinned-version/SKILL.md
T
noconnorandClaude Opus 4.8 485e267565 .agents/: add skills for working on this repo
Five skills covering this repo's own conventions: adding a bootstrap
module, adding a CLI to bin/, bumping a pinned version, adding an MCP
server, and verifying a module change.

Lives in .agents/skills/ because opencode discovers that path natively
alongside .opencode/skills/ and .claude/skills/, making it the most
tool-neutral of the three. Distinct from the repo's skills/ tree, which
ships to every covert-gpt user via sync.sh; these stay in the checkout.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-13 13:10:18 -04:00

3.0 KiB

name, description
name description
bump-pinned-version Use when upgrading a pinned version anywhere in this repo — a CLI in bin/install.sh, NODE_VERSION in node/install.sh, or an npm-pinned MCP server in mcp-config/opencode.gateway.json. Covers where the pins live, how to verify the new release actually exists, and the supply-chain reasoning behind pinning.

Bumping a pinned version

Everything in this repo is version-pinned on purpose. Nothing floats.

Where the pins live

Pin Location Shape
CLI tools bin/install.sh ver=v1.2.3 inside each install_<name>()
Node.js node/install.sh NODE_VERSION="v24.18.0"
MCP servers mcp-config/opencode.gateway.json ["npx", "-y", "pkg@0.0.10"]
oh-my-zsh, Docker zsh/, docker/ installed from upstream scripts — not pinned

Grep before assuming: grep -rnE 'ver=|_VERSION=|@[0-9]+\.[0-9]+' --include='*.sh' --include='*.json'

Why these are pinned

npx -y <pkg> executes whatever the registry serves at that moment. The MCP servers receive your Gitea and Proxmox tokens ({env:GITEA_KEY} and friends are passed into the spawned process), so an unpinned server is a live supply-chain path to your credentials. node/install.sh says this out loud in its header. A version bump is a supply-chain decision, not a chore — when bumping an MCP server or Node itself, skim the upstream changelog for a maintainer change or a new network dependency, and say what you found.

Doing the bump

  1. Verify the release exists before editing. Don't trust the model's memory of version numbers — check upstream (gh release list, the GitHub releases page, npm view <pkg> versions, or nodejs.org/dist).
  2. Verify the asset URL still resolves. Projects rename assets between releases. Build the exact URL the script will request and check it:
    curl -fsSLI "https://github.com/derailed/k9s/releases/download/v0.51.0/k9s_Linux_amd64.tar.gz"
    
    A 404 here becomes a hard bootstrap failure under set -eu.
  3. Match the upstream tag exactly — v1.2.3 vs 1.2.3 matters, because have_version string-compares against the .versions stamp. Get it wrong and the tool reinstalls on every single bootstrap, silently.
  4. Bump one thing per commit. When a box breaks after a bootstrap, the commit log should say which upgrade did it.

Verifying

The .versions stamp is what makes the bump observable:

cat ~/.local/bin/.versions/<tool>    # old version
./bin/install.sh                     # should download, not skip
cat ~/.local/bin/.versions/<tool>    # new version
./bin/install.sh                     # should now say "already installed"

If the second run re-downloads, the ver= string and the stamp disagree — that is the tag-format bug from step 3.

For an MCP server bump, restart opencode and confirm the server actually comes up. A dead MCP server is reported only as missing tools, so it looks like a model problem rather than a version problem.