[Consult] How to make a skill only active in a project

[NorthLin]

I got a local skills folder ~/skills, there are many skills in it.
I hope all my project inherit all global skills, and pick one or more skills from ~/skills.
Now I have two ways:

1. use include filter in project, but I must update all projects after adding new global skill if so
2. use exclude filter in project, but I must update the project if new skill is added into ~/skills

Is there any good practice in this scenario?

[runkids]

Thanks for the clear write-up! Both options get painful because every skill lives in one pool and each project filters it. Keeping the two kinds of skills apart avoids filters entirely.

First: you may not need per-project skills at all

Agents only read each skill's short description up front and load the full skill when it's relevant. If your skill count is modest, putting everything in the global source and running skillshare sync once is the simplest setup. Every project sees everything, and nothing needs maintaining.

If some skills really should be project-only

1. Keep the shared skills in your global source (~/.config/skillshare/skills). They sync to folders like ~/.claude/skills, which every project already reads, so a new shared skill reaches all projects with one skillshare sync. No project config changes.

2. Keep ~/skills as a plain folder outside the global source, and install picks into each project from it:

   cd my-project
   skillshare init -p                  # once per project
   skillshare install ~/skills/foo -p
   skillshare sync -p

   A project gets only what you installed into it, so adding a skill to ~/skills changes nothing until a project opts in.

3. After editing a skill in ~/skills, refresh the projects that use it:

   skillshare update --all -p

No include/exclude lists to keep in sync either way. More in Project Mode Workflow.

Let me know if your setup differs from what I assumed!

[NorthLin]

Thank you for your reply!
Yes, I agree that due to the on-demand loading mechanism of skill, most of the time we should place them in a global directory like '~/.claude/skills', but my situation is probably like this:
I have Project A and Project B, and I wrote deployment skills for them respectively. Both projects are deployed through a command called sdpcli, but there are some differences in the sequence of ci and verification steps in the middle. Therefore, I'm worried that the description might be somewhat similar to causing the final agent to find the wrong skill. This is the reason why I didn't put them in the global skill.
I could have manually written the required skills respectively in the.claude/skills section under these two project paths, but then I couldn't see them on the shareskill page. For me, being able to manage these Skillks uniformly on shareskill would make me more comfortable, so I'm asking a question.
Just now I found that the skills installed from shareskill all start with "". Therefore, when I imported the skills under ~/skills, I configured a link name," local skills ". Eventually, the soft links generated by these skills will all be prefixed with this name. In this way, I can do two things through regular expressions:
Import the global skill
2. Import the skills I need for the current project

This achieved the effect I wanted

[runkids]

Nice, that's a clean setup! Using projects with an include per project is exactly what that page is for. And thank you for sharing the whole story, the two deploy skills, why they can't live side by side, and the screenshot. I'm genuinely curious how people organize their skills with skillshare, and real setups like this are the most useful thing I get to see.

Two things worth checking so it keeps working as your library grows:

1. Keep local_skills__* out of your global targets. Your global source now contains the project deploy skills too, so a global target like ~/.claude/skills picks them up unless it filters them out. Since avoiding the mix-up between the two deploy skills was the whole point, exclude them there:

   skillshare target claude --add-exclude "local_skills__*"
   skillshare sync

   (Repeat for each global target.) .skillignore isn't the right tool here, because it would hide them from your projects as well.

2. _* only matches tracked repos. The leading _ comes from installing with --track. A skill installed without it (for example skillshare install owner/repo/skill) has no prefix, so it won't match _* and won't reach the project. If you add one later, add its name to the project's include list as well.

If anything else about your workflow feels clumsy, I'd love to hear it.

[NorthLin]

OMG you're completely right, thx for your reminding!
I need to think again about how to do it better..

[NorthLin]

Eventually, I plan to filter out local skills for each target based on your suggestion. As for the skills installed through other channels, make sure they are in the track status
I will close this discussion, thx for advicing again🙇‍♂️