bump-required-versions

name

bump-required-versions

description

Bump the minimum required versions that mthds-agent enforces at runtime — the Claude Code mthds plugin, pipelex (and pipelex-agent, same package), plxt, and the Codex app. Use when the user says "bump required versions", "bump min pipelex version", "bump minimum plxt version", "raise minimum plugin version", "bump min codex version", "update required versions", "set min pipelex to X.Y.Z", "bump min mthds plugin version", or any variation of changing one or more of these floors. Trigger even when the user names only one of the targets — this skill handles partial updates.

Bump Required Versions

Updates the minimum version constraints that this mthds-agent release enforces against:

• The Claude Code mthds plugin (when running inside Claude Code) — MIN_PLUGIN_VERSION in src/agent/plugin-version.ts.
• The pipelex PyPI package (provides both the pipelex and pipelex-agent binaries) — PIPELEX_PKG.version_constraint in src/agent/binaries.ts.
• The pipelex-tools PyPI package (provides the plxt binary) — PIPELEX_TOOLS_PKG.version_constraint in src/agent/binaries.ts.
• The Codex app (the codex CLI itself, checked best-effort by codex apply-config and doctor) — MIN_CODEX_VERSION in src/agent/codex-version.ts.

The constants in those files are the single source of truth. Tests import the constants directly, so bumping these values does not require test edits — the test suite re-exercises the new floor automatically.

Why each lives where it lives

• MIN_PLUGIN_VERSION enforces the opposite direction from the package constraints: the agent checks the plugin is recent enough. The plugin's own min_mthds_version (in mthds-plugins/targets/defaults.toml) enforces the agent is recent enough. Both versions get bumped on coordinated releases — but this skill only bumps the agent side. The plugin side has its own skill (bump-mthds-version in mthds-plugins).
• The BINARY_RECOVERY map keys binaries (pipelex, pipelex-agent, plxt), but each entry spreads a shared *_PKG constant. The package constants own the version constraint, so the pipelex and pipelex-agent binaries cannot drift apart even by accident — there is only one line to edit.
• MIN_CODEX_VERSION is not a BINARY_RECOVERY entry because Codex is not uv-installable: detection shells out to codex --version and stays silent when the binary is missing. Below the floor the check emits a warning (CODEX_VERSION_TOO_OLD); the same module also hard-errors below CODEX_PLUGIN_HOOKS_MIN (0.131, where plugin-bundled hooks cannot load at all) — that second constant is a fixed historical boundary of Codex itself and is never bumped by this skill. MIN_CODEX_VERSION is a bare X.Y.Z string, not a >= range.

Workflow

1. Determine which targets to bump and to what

If the user already specified targets and versions (e.g. "bump pipelex to 0.24.0 and plxt to 0.4.0"), use them.

Otherwise, ask which of the targets to bump:

• plugin — the Claude Code mthds plugin floor (MIN_PLUGIN_VERSION)
• pipelex — the pipelex PyPI package floor (covers both the pipelex and pipelex-agent binaries)
• plxt — the pipelex-tools PyPI package floor (covers the plxt binary)
• codex — the Codex app floor (MIN_CODEX_VERSION)

Then for each chosen target ask for the new version (semver X.Y.Z).

Show the current values first by reading:

• src/agent/plugin-version.ts — find export const MIN_PLUGIN_VERSION = ">=X.Y.Z"
• src/agent/binaries.ts — find PIPELEX_PKG and PIPELEX_TOOLS_PKG, each with a version_constraint: ">=X.Y.Z" field
• src/agent/codex-version.ts — find export const MIN_CODEX_VERSION = "X.Y.Z" (bare version, no >=)

2. Sanity-check the requested versions

For each requested bump, verify the new version is strictly greater than the current floor. Bumping to the same value is a no-op; bumping below is almost certainly a mistake — confirm with the user before proceeding if they ask for a downgrade.

3. Apply the edits

The constraint format in both files is a npm-semver range: ">=X.Y.Z" (note the >= prefix and the surrounding quotes).

• plugin → edit the MIN_PLUGIN_VERSION constant in src/agent/plugin-version.ts (one line).
• pipelex → edit PIPELEX_PKG.version_constraint in src/agent/binaries.ts (one line). Both pipelex and pipelex-agent binaries pick this up automatically via the spread.
• plxt → edit PIPELEX_TOOLS_PKG.version_constraint in src/agent/binaries.ts (one line).
• codex → edit the MIN_CODEX_VERSION constant in src/agent/codex-version.ts (one line, bare "X.Y.Z" — no >= prefix).

Each constant lives in its own block at the top of binaries.ts; use the constant name and the surrounding as const; line to make the Edit unambiguous.

4. Verify with make check

Run make check from the mthds-js repo root. This builds the project and runs the test suite; tests assert against the imported constants, so a successful run confirms the bumps are coherent.

If checks fail, report the errors. The most likely cause is a hardcoded "above the constraint" version in a test that is now below the new constraint — fix by raising that hardcoded test version, not by reverting the bump.

5. Report

Summarise what changed:

plugin:        OLD → NEW
pipelex:       OLD → NEW   (also applied to pipelex-agent)
plxt:          OLD → NEW
codex:         OLD → NEW

Then remind the user to:

• Add a CHANGELOG.md entry under the next release describing the bumps and why (e.g., a feature in the new pipelex version that mthds-agent now relies on). The v0.5.0 entry's plugin bump note is a good template.
• Coordinate the plugin side if MIN_PLUGIN_VERSION was bumped: the matching min_mthds_version in mthds-plugins/targets/defaults.toml typically needs to point at the upcoming mthds-agent release for the cross-check to make sense. That edit happens in the mthds-plugins repo, not here.

Do not commit or create a release — leave that to the user (or to the release skill).