Summary
On Windows, gemini's user-global skill destination is ~/.agents/skills/graphify/SKILL.md — byte-identical to the agents platform's destination on every OS. Two platforms that install different skill files share one path, so installing one silently replaces the other, and uninstalling one deletes the other's install along with its references/ and version stamp.
graphify/install.py::_platform_skill_destination:
if platform_name == "gemini":
if project:
return (project_dir or Path(".")) / ".gemini" / "skills" / "graphify" / "SKILL.md"
if platform.system() == "Windows":
return Path.home() / ".agents" / "skills" / "graphify" / "SKILL.md" # <-- line 74
return Path.home() / ".gemini" / "skills" / "graphify" / "SKILL.md"
...
if platform_name == "agents":
# The generic Agent-Skills target: project ./.agents/skills, global the
# spec's user-global ~/.agents/skills (read by `npx skills` and compliant
# frameworks), NOT amp's ~/.config/agents/skills.
if project:
return (project_dir or Path(".")) / ".agents" / "skills" / "graphify" / "SKILL.md"
return Path.home() / ".agents" / "skills" / "graphify" / "SKILL.md" # <-- line 108
They are not merely similar paths: the two install different content. _copy_skill_file special-cases gemini to ship skill.md, while agents ships its own skill-agents.md bundle:
skill_file = "skill.md" if platform_name == "gemini" else _PLATFORM_CONFIG[platform_name]["skill_file"]
Consequences on Windows
graphify install --platform gemini then --platform agents (or the reverse) leaves one SKILL.md; the second install silently overwrites the first, and the shared .graphify_version stamp then describes whichever ran last.
graphify uninstall --platform gemini removes ~/.agents/skills/graphify/SKILL.md, its references/, and its stamp — i.e. the agents installation — and then _remove_skill_file walks the emptied parents away with rmdir.
- The reverse holds too: uninstalling
agents removes the gemini user-global skill.
Neither command warns, and neither is scoped to the platform the user named.
This looks like the same class #2694 and #2777 are about (installs and version stamps leaking across platform boundaries), just reached through a shared destination rather than a shared stamp.
Every gemini/agents install-scope test on Windows shows it
These are currently failing on v8 @ 4fca621, all for this one reason — the tests assert the POSIX layout (~/.gemini/skills/graphify) while the install lands in ~/.agents/:
FAILED tests/test_install_references.py::test_gemini_install_references_all_resolve
FAILED tests/test_uninstall_scope.py::test_bare_call_still_removes_global[gemini]
FAILED tests/test_uninstall_scope.py::test_remove_user_skill_opt_in_with_project_dir[gemini]
with the install itself reporting the shared path:
references -> ...\test_gemini_install_references0\.agents\skills\graphify\references
skill installed -> ...\test_gemini_install_references0\.agents\skills\graphify\SKILL.md
graphify section written to ...\test_gemini_install_references0\GEMINI.md
The test job runs ubuntu-latest only, where line 74 is unreachable, so none of this is visible in CI.
What I am unsure about
I could not find the rationale for line 74 in the history — it arrived with cc2d3c1 (the install.py extraction) already in this form, and unlike the neighbouring hermes branch, which cites #1403 for using %LOCALAPPDATA%, it carries no comment or issue reference.
So I do not know which of these you intend:
- Gemini CLI on Windows really does read
~/.agents/skills. Then the destination is right and the collision is the bug: _remove_skill_file needs to not delete a directory another platform owns, and install should warn (or refuse) when the target already holds a different platform's skill. The three tests above are then also wrong to hardcode .gemini and should ask _platform_skill_destination.
- It is a leftover and gemini should use
~/.gemini/skills/graphify on Windows like everywhere else. Then the fix is deleting those two lines, and the tests are already correct.
Happy to send a PR for whichever you prefer — say which and I will open it. I did not guess, because (1) and (2) produce opposite changes to the same tests, and picking wrong would bake the wrong layout into the suite.
Environment
|
|
| graphify |
v8 @ 4fca621 (0.9.44) |
| Python |
3.12, Windows 11 |
Summary
On Windows,
gemini's user-global skill destination is~/.agents/skills/graphify/SKILL.md— byte-identical to theagentsplatform's destination on every OS. Two platforms that install different skill files share one path, so installing one silently replaces the other, and uninstalling one deletes the other's install along with itsreferences/and version stamp.graphify/install.py::_platform_skill_destination:They are not merely similar paths: the two install different content.
_copy_skill_filespecial-cases gemini to shipskill.md, whileagentsships its ownskill-agents.mdbundle:Consequences on Windows
graphify install --platform geminithen--platform agents(or the reverse) leaves one SKILL.md; the second install silently overwrites the first, and the shared.graphify_versionstamp then describes whichever ran last.graphify uninstall --platform geminiremoves~/.agents/skills/graphify/SKILL.md, itsreferences/, and its stamp — i.e. theagentsinstallation — and then_remove_skill_filewalks the emptied parents away withrmdir.agentsremoves the gemini user-global skill.Neither command warns, and neither is scoped to the platform the user named.
This looks like the same class #2694 and #2777 are about (installs and version stamps leaking across platform boundaries), just reached through a shared destination rather than a shared stamp.
Every gemini/agents install-scope test on Windows shows it
These are currently failing on
v8@4fca621, all for this one reason — the tests assert the POSIX layout (~/.gemini/skills/graphify) while the install lands in~/.agents/:with the install itself reporting the shared path:
The test job runs
ubuntu-latestonly, where line 74 is unreachable, so none of this is visible in CI.What I am unsure about
I could not find the rationale for line 74 in the history — it arrived with
cc2d3c1(theinstall.pyextraction) already in this form, and unlike the neighbouring hermes branch, which cites #1403 for using%LOCALAPPDATA%, it carries no comment or issue reference.So I do not know which of these you intend:
~/.agents/skills. Then the destination is right and the collision is the bug:_remove_skill_fileneeds to not delete a directory another platform owns, and install should warn (or refuse) when the target already holds a different platform's skill. The three tests above are then also wrong to hardcode.geminiand should ask_platform_skill_destination.~/.gemini/skills/graphifyon Windows like everywhere else. Then the fix is deleting those two lines, and the tests are already correct.Happy to send a PR for whichever you prefer — say which and I will open it. I did not guess, because (1) and (2) produce opposite changes to the same tests, and picking wrong would bake the wrong layout into the suite.
Environment
v8@4fca621(0.9.44)