agentsclimarketplace

Version checker

Skill jsynowiec/claude-toolkit/plugins/stackshift/skills/version-checker

My personal collection of plugins that extend Claude Code with specialized agents, skills, and commands.

Install
npx -y skills add jsynowiec/claude-toolkit --skill version-checker

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Determines latest stable or LTS versions of runtimes (Node.js, Python) and packages (npm, PyPI), checks EOL status, identifies upgrade paths, and looks up the VS Code compatibility matrix. Use when checking if project versions are outdated, need upgrading, or determining minimum VS Code engine version after a runtime change.

SKILL.md

5.5 KB, as published. Nobody here has run it

Check only the runtimes or packages the caller asks about. Do not scan all dependencies unprompted.

Detecting Local Versions

Inspect only the files relevant to the requested check:

Node.js runtime

  • .node-version / .nvmrc — plain text, single version string
  • package.json — engines.node field (semver range)
  • package.json — volta.node field (exact version, set by Volta)
  • .tool-versions — line starting with nodejs

Python runtime

  • .python-version — plain text, single version string
  • pyproject.toml — project.requires-python field (PEP 440 specifier)
  • .tool-versions — line starting with python

npm packages

  • package.json — dependencies and devDependencies version ranges

PyPI packages

  • pyproject.toml — project.dependencies and project.optional-dependencies
  • requirements.txt / requirements-*.txt — pinned or ranged versions

VS Code extension engine

  • package.json — engines.vscode field (semver range, e.g., ^1.96.0)

If multiple sources conflict, report the discrepancy.

The patterns above cover JavaScript/TypeScript (Node.js, npm), Python, and VS Code extension ecosystems. For other runtimes or package registries, apply the same approach: check local version files and query the ecosystem's machine-readable registry endpoint following the same patterns shown here.

Looking Up Latest Versions

Run scripts/fetch-version.sh (located in this skill's directory) via Bash. It fetches registry APIs using curl and jq, returning only the needed fields as key=value lines.

The nodejs-eol and python-eol subcommands default to supported versions only. Use this default — it keeps output concise. Pass --all only when historical or already-EOL'd version data is explicitly needed.

Node.js runtime

  1. Run scripts/fetch-version.sh nodejs-releases — returns latest_current, latest_current_date, latest_lts, latest_lts_codename, latest_lts_date.
  2. Run scripts/fetch-version.sh nodejs-eol — returns ----separated records with cycle, eol, lts, latest for currently-supported versions only. Add --all for the full historical list.

Python runtime

  1. Run scripts/fetch-version.sh python-releases — returns latest_current (newest bugfix-active version, e.g. 3.14.x) and latest_lts (second-newest bugfix-active version, e.g. 3.13.x).
  2. Run scripts/fetch-version.sh python-eol — returns ----separated records with cycle, eol, latest for currently-supported versions only. Add --all for the full historical list.

npm packages

  1. Run scripts/fetch-version.sh npm <package> — returns latest.

PyPI packages

  1. Run scripts/fetch-version.sh pypi <package> — returns latest, requires_python.

VS Code compatibility matrix

  1. Run scripts/fetch-version.sh vscode-compat <component> <version> — where <component> is node, electron, or chromium and <version> is a major (22) or major.minor (22.16), optionally v-prefixed. Returns oldest_vscode (the first VS Code release bundling that version), oldest_vscode_<component> (the exact component version in that release), oldest_vscode_created_at, and newest_vscode (the latest VS Code release still on that version).

Use this when modernizing VS Code extensions to determine the minimum engines.vscode value required after upgrading a bundled runtime. For example, after upgrading from Node 20 to Node 22, run vscode-compat node 22 to find the oldest VS Code version that ships Node 22.x.

Fallback

If any script invocation outputs a line starting with error:, fall back to direct fetching:

  1. Call ToolSearch with query select:WebFetch to load the tool schema.
  2. Read references/known-endpoints.md for the endpoint URL and response schema.
  3. Use WebFetch to fetch the endpoint and extract the needed fields from the JSON response.

Assessing EOL Status

  • For runtimes: cross-reference with endoflife.date API (https://endoflife.date/api/{product}.json).
  • A version is EOL if its eol date is in the past relative to today.
  • Flag versions entering EOL within the next 6 months as "approaching EOL."

Output Format

Present results using this structure:

## Summary
1-2 sentence overview of findings.

## Findings
For each checked item:
- **Item name** (e.g., Node.js, react, Flask)
  - Current: <local version or range>
  - Latest LTS: <version> (if applicable)
  - Latest stable: <version>
  - EOL status: <active | approaching EOL (date) | EOL since (date)>
  - Recommended target: <version>

## Recommendations
Actionable next steps, ordered by priority (EOL items first, then outdated items).

Rules

  • Fetch live data for every check. Do not rely on training data for version numbers.
  • If a fetch fails, report the failure and the URL attempted. Do not guess.
  • Distinguish between LTS and Current/stable where the ecosystem makes that distinction (Node.js). For ecosystems without an LTS concept (PyPI packages), report only latest stable.
  • When the local version satisfies the latest LTS or stable, say so explicitly — do not suggest unnecessary upgrades.

Gives 0 of the 12 instructions most quality gates skills give

Counted across 1,195 of the 2,094 authors here whose files we hold, read 2026-08-06

  • read the output and check the exit codein 55 of 1195, across 14 files
  • verify requirements using a line-by-line checklistin 53 of 1195, across 12 files
  • identify the verification command proving the claimin 53 of 1195, across 12 files
  • run the full verification commandin 51 of 1195, across 11 files
  • verify output confirms the claimin 49 of 1195, across 10 files
  • check version control diff after agent delegationin 45 of 1195, across 5 files
  • state claim with evidencein 43 of 1195, across 3 files
  • run the test suitein 32 of 1195, across 24 files
  • keep state in memory by defaultin 27 of 1195, across 6 files
  • make prototype runnable with one commandin 26 of 1195, across 5 files
  • detect the package manager from lockfilesin 24 of 1195, across 5 files
  • produce a verification reportin 23 of 1195, across 12 files

Said here and by no other author read

  • Check only requested runtimes or packages
  • Do not scan all dependencies unprompted
  • Inspect only files relevant to the requested check
  • Report discrepancies if sources conflict
  • Fetch live data for every version check
  • Do not rely on training data for version numbers

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.