fix: detect skill/CLI version drift between npm and Claude Code plugin installs - #289
Open
ayushsingh82 wants to merge 2 commits into
Open
fix: detect skill/CLI version drift between npm and Claude Code plugin installs#289ayushsingh82 wants to merge 2 commits into
ayushsingh82 wants to merge 2 commits into
Conversation
…n installs webcmd ships skills/ through two channels: an npm symlink (always in sync with the running package) and a Claude Code plugin-cache copy that's version-pinned and only refreshed by `claude plugin update`. Since only the CLI's own version nags on update-check, a user can end up running a newer CLI against older skills with no signal, producing confidently wrong commands. Add findSkillVersionDrift(): when both channels are present on disk and the plugin-cache version differs from the running CLI, webcmd doctor now reports it with the fix command. Fixes agentrhq#274 (item 2, the doctor drift check)
Related to agentrhq#274 item 3: docs:/chore: commits don't cut a release-please version, so a skill edit under those prefixes never reaches the Claude Code plugin install path even though npm users get it for free via the symlink.
Contributor
🟠 Maintainer review suggested — low confidenceThe automated review could not reach a fully supported conclusion. This review is advisory and does not block merging. |
Author
|
Fixes #274 (items 2 and 3) — @ankitranjan7 adds the doctor drift check plus the CONTRIBUTING.md note. Ready for review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Webcmd ships
skills/through two channels: an npm symlink (always in sync with the running package) and a Claude Code plugin-cache copy that's version-pinned and only refreshed byclaude plugin update. Since only the CLI's own version nags on update-check, a user can end up running a newer CLI against older skills with no signal, producing confidently wrong commands.findSkillVersionDrift(): when both channels are present on disk and the plugin-cache version differs from the running CLI,webcmd doctornow reports it with the fix command (claude plugin update webcmd@webcmd). This is item 2 from the issue — the cheapest check that catches the actual broken state.docs:/chore:commits don't cut a release-please version, so a skill fix landed under those prefixes never reaches plugin users even though npm installs pick it up for free.Item 1 (
webcmd updatepassthrough toclaude plugin update) is left for a follow-up since it's more invasive (shelling out to another CLI) and this PR already covers the two lower-risk, high-value pieces.Fixes #274 (items 2 and 3)
Test plan
npx tsc --noEmitsrc/skill-version-drift.test.tscovering: drift reported when both channels present and versions differ, no drift when versions match, no drift when only one channel is installed, and picks the highest of several installed plugin-cache versions.src/doctor.test.tsstill passes unchanged (23/23) — the new field doesn't affect existing report assertions.