Skip to content
Development
Skill

/version-check

Recommend which Claude Code version to run, or whether to update. Use when asked which Claude Code version is best/safe, whether to update now, whether a recent release is buggy, or what changed since the installed version.

From plugin
dx
9.6k9 skills
Install
$ npx -y skills add ykdojo/claude-code-tips --skill version-check --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/version-check

Context preview

The summary Claude sees to decide when to auto-load this skill.

Recommend which Claude Code version to run, or whether to update. Use when asked which Claude Code version is best/safe, whether to update now, whether a recent release is buggy, or what changed since the installed version.

SKILL.md

version-check.SKILL.md
name: version-check
description: Recommend which Claude Code version to run, or whether to update. Use when asked which Claude Code version is best/safe, whether to update now, whether a recent release is buggy, or what changed since the installed version.

Claude Code version check

The goal is a recommendation: stay put, update, or pin to a specific version. Claude Code ships `latest` very frequently (often 1-2x/day), so "best version" is a moving target and the answer is usually a *range*, not a single build.

Heuristics (read first)

  • **`stable` lags `latest` and is NOT an LTS.** The npm `stable` dist-tag is just a pointer that trails `latest` by a handful of patch releases. It can even sit *behind* an important fix release, so "stable" does not mean "most bugs fixed." Don't blindly recommend `@stable`.
  • **Quiet version = good sign.** If nobody is complaining about a recent release, that's a positive signal. A loud pile-on about a specific build is the thing to avoid.
  • **Version comparisons are the strongest signal.** Posts where people compare builds ("X broke Y, rolled back to Z") tell you exactly which release to avoid.
  • **Stay ~a day behind the bleeding edge.** Avoid a release that's only a few hours old - let others surface same-day regressions first.
  • **But a same-day release is fine when the tracker is quiet and it fixes something you're carrying.** If a few hours have passed with no cluster of issues, and the changelog shows it fixing a regression that's live in your installed range, taking it is usually better than waiting. Say plainly what you're trading: a few hours of field time instead of a day.
  • **The real lever is *when* you update, not stable-vs-latest.** Default Claude Code auto-updates to `latest` constantly, which is how you drift onto a same-day regression.

1. What's installed vs what's published

claude --version
npm view @anthropic-ai/claude-code dist-tags --json

`dist-tags` shows `latest`, `stable`, and `next`. Compare against the installed version to see how far ahead/behind each pointer is.

Recent releases and their timestamps (to see how fast things are shipping):

npm view @anthropic-ai/claude-code time --json | python3 -c "import sys,json;d=json.load(sys.stdin);print('\n'.join(f'{k}: {v}' for k,v in list(d.items())[-8:]))"

2. Scan the changelog for regressions in the gap

Fetch the changelog and read the entries *between* the installed version and `latest`. Look for "Fixed ... regression in X" lines - if a recent build introduced a regression that has not yet been fixed, that's the one to avoid.

curl -sL https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md | awk '/## <LATEST>/,/## <INSTALLED>/'

(Substitute the two version numbers.) A release that is mostly "Fixed …" after a noisy one is usually a safe landing spot.

3. Community sentiment (valuable - do this, don't skip it)

GitHub issues (primary - reliable and fetchable)

The most dependable signal. Search recent open bug reports, sorted by reactions:

gh api -X GET search/issues \
  -f q="repo:anthropics/claude-code is:issue is:open created:>=<DATE> label:bug" \
  -f sort=reactions -f per_page=25 \
  --jq '.items[] | "\(.created_at[:10]) +\(.reactions.total_count) c\(.comments) #\(.number) \(.title)"'

(Set `<DATE>` to ~3 days before today.) A version regression shows up as a *cluster* of high-reaction issues filed right after a release. Single reports with 0-1 reactions are noise, not a signal - the tracker always has a steady trickle of those.

Cross-reference titles against the changelog gap: if a top issue is already addressed by a fix/flag in `latest`, that build is *safer*, not riskier. Mostly minor or server-side (API 500/529) issues = quiet release = good sign.

To judge a release that's only hours old, drop `label:bug` and `is:open` and set the date to today - you want everything filed since it shipped, before anyone has triaged or labeled it.

Also check whether the issues are even about the CLI. Clusters about Claude Desktop or the VS Code extension say nothing about whether a Claude Code CLI build is safe.

Reddit (secondary - reachable via the DuckDuckGo hop)

r/ClaudeAI version-comparison threads are valuable, but **Reddit now hard-blocks every direct automated route** - curl (host + container), the WebSearch crawler (denied by user-agent), AND a cold Playwright navigation (network-security challenge page). The reliable way in is the `reddit-fetch` skill's **DuckDuckGo-hop unlock**: navigate Playwright to a `html.duckduckgo.com/html/?q=site:reddit.com/r/ClaudeAI+...` result redirect once, which sets a session cookie, then direct `.json` navigation works:

https://www.reddit.com/r/ClaudeAI/search.json?q=claude+code+update+broke+OR+regression&restrict_sr=on&sort=new&t=week&limit=25

Apply the heuristics above: a positive or quiet recent-update thread is reassuring; a high-score "X is broken" thread names the build to skip.

4. Test the claim instead of arguing about it

When the question is "do I actually need this release to get X" - usually a new model - just run it. A new model is server-side, so it often works on an older client; what the older client gets *wrong* is the metadata around it.

claude -p "Reply with exactly: ok" --model <model-id> --output-format json 2>&1 \
  | python3 -c "import sys,json;u=json.load(sys.stdin)['modelUsage'];print(json.dumps({m:{'contextWindow':v['contextWindow'],'costUSD':v['costUSD']} for m,v in u.items()},indent=2))"

`modelUsage` is the honest answer: it names the model that actually served the turn (ignore the Haiku row, that's the background helper) and reports the `contextWindow` the client is applying. A new model responding on an old client but showing a 200000 window where the changelog promises 1000000 means the model works and the *client* is capping it - which is a concrete, checkable reason to update rather th

Read more
Ships withdx

Here are my tips for getting the most out of Claude Code, including a custom status line script and Claude Code running itself in a container. Also includes the dx plugin: skills for everyday dev workflows.

Get the whole plugin
Stats
9,581
Stars
760
Forks
Active
Maintenance
HTML
Language
3d ago
Last commit
8mo ago
Created

Repo: ykdojo/claude-code-tips