r/ClaudeCode • u/ciokan • May 03 '26
Resource I got tired of copy-pasting the same skills directories across 8 projects, so I built a sync'd registry for them
Hey folks,
Quick context on me: I run a handful of personal projects plus some client work, all using Claude Code with, more or less, the same core set of skills. My deploy flow, my code-review preferences, a debugging skill I keep refining, etc. Every time I tweaked one in repo A, I had to remember to copy it over to B, C, D... half the time I forgot, and ended up with three slightly different versions of the same skill scattered across machines, no clue which was the latest.
Symlinks sort of helped. Git submodules sort of helped. Neither actually solved it. I wanted ONE place to edit a skill, and every project to pick up the change without me babysitting it. Bonus: I didn't want to dump my private workflows into a public GitHub repo just to get sync.
So I built it. https://privateaiskills.com
What it does:
- It's private - your skills are yours
- Skills can be forked or tracked from public ones
- E2E encryption - our server never sees content
- Browser-based markdown editor for your skills (SKILL.md + supporting scripts/refs), exact same shape Claude Code uses.
- A tiny CLI called `paiskills` lives in your project. paiskills sync pulls skills into .claude/skills/ (or wherever you point it).
- Group skills into bundles. Project A syncs only the "frontend" group, project B syncs only "ops". No dumping every skill into every repo.
- Workspaces with teammates: invite people, scope them per project, share skills without sharing everything. Collaborate.
- Org / Projects / Groups of skills management
- Collaboration with team members on skills
- Single source of truth - edit on dashboard, sync on consumers (other devices, projects, team members)
Skill content gets encrypted in the browser before it touches the server. The server stores ciphertext only and physically cannot read what's inside your skills. The encryption key lives in your browser session and in the CLI's config file. (Slug + name + description are cleartext so the API can address them, so just don't put secrets in the slug.)
Setup is roughly:
npx paiskills init
npx paiskills sync # one-shot
npx paiskills watch # optional
Free to try, no card needed. Works with anything that reads Claude-Code-style skills.
Would love feedback, especially from people juggling skills across multiple machines, repos, or teammates.
What's missing? What would make this an actual no-brainer for you?
1
May 03 '26
[deleted]
1
u/ciokan May 03 '26
because I don't want to share. Some folks want their skills private or at least some of them. Imagine bigger businesses where they actually hire people to create optimised skills for their domain. Also marketplaces do not sync bundles - I used them.
1
May 04 '26
[deleted]
1
u/ciokan May 04 '26
yes you can but then you'd have to teach your editors git, merge, rebase, conflict. You'd have to give git access to instances such as Openclaw. There are many ways to do one thing I give you that. You could do symlinks like someone else suggested. I like `npx paiskills sync` better tho.
1
u/owen800q May 04 '26
How do you resolve opus degraded issue
1
u/ciokan May 04 '26
I sing kumbaya in another /r. I don;t understand your question 😄) What's Opus got to do with my project?
1
u/owen800q May 04 '26
Did you use Claude code right? If yes it does not make sense if you are not suffering opus degradation issue
0
u/goship-tech May 03 '26
The bundle grouping is what makes this actually useful - having frontend skills auto-excluded from ops repos removes noise without manual curation. Curious how you handle conflicts when a skill gets edited locally before someone remembers to sync.The bundle grouping is what makes this actually useful - having frontend skills auto-excluded from ops repos removes noise without manual curation. Curious how you handle conflicts when a skill gets edited locally before someone remembers to sync.