Skills across coding assistants
I love Claude Code, but I use it so much that I regularly exhaust my weekly quota before the week ends. When that happens, I usually switch to other free-tier CLIs, e.g., Google Antigravity, GitHub Copilot, and, just last week, Mistral's Vibe. I really wanted to try Vibe to evaluate the feasibility of moving away from Claude Code in favor of a more sovereign solution.
Vibe only offers a single model by default, Mistral Medium 3.5. It hallucinated results badly, and I noticed it immediately. When I tried to understand what happened, I realized it hadn't triggered any of my lovingly crafted skills. The reason is that Claude Code stores skills in custom locations, in opposition to most other assistants.
I went through each assistant's documentation, so you don't get bitten the same way.
| Assistant | Personal | Project |
|---|---|---|
| Claude Code | ~/.claude/skills |
./.claude/skills |
| Antigravity | ~/.gemini/skills |
./.agents/skills |
| Vibe | ~/.vibe/skills, ~/.agents/skills |
./.vibe/skills, ./.agents/skills |
| Copilot CLI | ~/.copilot/skills, ~/.agents/skills |
./.github/skills, ./.claude/skills, ./.agents/skills |
The specification is pretty clear about it:
| Scope | Path | Purpose |
|---|---|---|
| Project | <project>/.<your-client>/skills/ |
Your client’s native location |
| Project | <project>/.agents/skills/ |
Cross-client interoperability |
| User | ~/.<your-client>/skills/ |
Your client’s native location |
| User | ~/.agents/skills/ |
Cross-client interoperability |
My conclusion is straightforward. Put skills in ~/.agents/skills and ./.agents/skills, then symlink ~/.claude/skills and ./.claude/skills to them. If the .claude/skills folders already exist, move their content to the .agents/skills ones first.
ln -s ~/.agents/skills ~/.claude/skills
ln -s ../.agents/skills .claude/skills # 1
- Run it from the project root
I love Claude Code, but it isn't a good citizen here. That's one more reason for me to try Vibe more seriously.
To go further:
- Agent skills specification: where to scan
- Google: Antigravity App skill locations
- Vibe: skill locations
- Copilot: finding and storing skills
Originally published at A Java Geek on November 8th, 2026.
About the author
Technologist focusing on cloud-native technologies, DevOps, CI/CD pipelines, and system observability. His focus revolves around creating technical content, delivering talks, and engaging with developer communities to promote the adoption of modern software practices. With a strong background in software, he has worked extensively with the JVM, applying his expertise across various industries. In addition to his technical work, he is the author of several books and regularly shares insights through his blog and open-source contributions.
Comments
Join the discussionThe path mismatch is the part I'd keep: Claude Code looks in .claude/skills, and the assistants you switched to were looking in .agents/skills, so Vibe never saw the skills you'd already written.
I'd also keep the practical fix. Put the shared skills in ~/.agents/skills and ./.agents/skills, move anything already in the Claude folders first, then symlink the Claude paths onto them so you are not maintaining two trees.
One small addition after the symlink: start a fresh session in each tool and confirm a skill you know by name actually appears. If an old .claude/skills folder was left in place instead of replaced, the shared skills can still go unseen, and that check is cheaper than finding out mid-task.
Have you found any assistant that still ignores .agents/skills even after the symlink, or does that cover the set you use?
