Summary
The skill-version mismatch warning (_check_skill_version, graphify/__main__.py:122) fires on any version difference and always advises Run 'graphify install' to update. But when the installed skill is newer than the running package, that advice doesn't update anything — graphify install copies the package's (older) bundled skill over the newer one and re-stamps .graphify_version, i.e. it silently downgrades the skill to make the warning go away.
I hit this as a contributor (my skill was stamped from a dev checkout at 0.9.2 while my installed CLI was an older published build), so I'm not sure whether this direction of mismatch is expected/handled — hence an issue rather than a PR.
What I saw
$ graphify --version
warning: skill is from graphify 0.9.2, package is 0.8.27. Run 'graphify install' to update.
graphify 0.8.27
$ graphify install
skill installed -> /Users/.../.claude/skills/graphify/SKILL.md
$ cat ~/.claude/skills/graphify/.graphify_version
0.8.27 # <- skill went 0.9.2 -> 0.8.27; warning now silent
So following the warning's own advice moved me from the 0.9.2 skill to the 0.8.27 skill.
Why
_check_skill_version compares installed != __version__ and prints the same "run install to update" line regardless of direction:
if installed != __version__:
print(f" warning: skill is from graphify {installed}, package is {__version__}. Run 'graphify install' to update.")
The docstring says "Warn if the installed skill is from an older graphify version", but the code never checks which side is older. And install always writes the package-bundled skill + stamps __version__ (__main__.py:334), so in the skill-newer-than-package case it's a downgrade.
The actual trigger (env, for context)
My CLI is a stale uv tool — installed as graphifyy pinned at 0.8.27, while PyPI's latest graphifyy is 0.9.3. The genuine fix for me is uv tool upgrade graphifyy (then graphify install), not the graphify install the warning suggested.
Question
Is the warning meant to fire (and recommend install) when the skill is newer than the package? If not, would it make sense to make it direction-aware — e.g. when skill > package, suggest upgrading the package (uv tool upgrade … / pip install -U …) instead of install, so users (and contributors with dev skills) don't get silently downgraded?
Happy to send a PR if you'd like it changed.
Summary
The skill-version mismatch warning (
_check_skill_version,graphify/__main__.py:122) fires on any version difference and always advisesRun 'graphify install' to update. But when the installed skill is newer than the running package, that advice doesn't update anything —graphify installcopies the package's (older) bundled skill over the newer one and re-stamps.graphify_version, i.e. it silently downgrades the skill to make the warning go away.I hit this as a contributor (my skill was stamped from a dev checkout at 0.9.2 while my installed CLI was an older published build), so I'm not sure whether this direction of mismatch is expected/handled — hence an issue rather than a PR.
What I saw
So following the warning's own advice moved me from the 0.9.2 skill to the 0.8.27 skill.
Why
_check_skill_versioncomparesinstalled != __version__and prints the same "run install to update" line regardless of direction:The docstring says "Warn if the installed skill is from an older graphify version", but the code never checks which side is older. And
installalways writes the package-bundled skill + stamps__version__(__main__.py:334), so in the skill-newer-than-package case it's a downgrade.The actual trigger (env, for context)
My CLI is a stale uv tool — installed as
graphifyypinned at 0.8.27, while PyPI's latestgraphifyyis 0.9.3. The genuine fix for me isuv tool upgrade graphifyy(thengraphify install), not thegraphify installthe warning suggested.Question
Is the warning meant to fire (and recommend
install) when the skill is newer than the package? If not, would it make sense to make it direction-aware — e.g. whenskill > package, suggest upgrading the package (uv tool upgrade …/pip install -U …) instead ofinstall, so users (and contributors with dev skills) don't get silently downgraded?Happy to send a PR if you'd like it changed.