[detkin]

I agree that that works pretty well for developers who work with a code repository everyday. But, if you're working on a mono-repo, you can end up with more skills loading than you'd like pretty quickily.

Have you had success with non-technical people using git as their primary sharing source?

[sdesol]

My extension for pi https://github.com/gitsense/pi-brains solves the too many skills problem and it can be adapted to work with any coding agent that supports hooks like Claude and Codex.

You can find a simple example at https://github.com/gitsense/gsc-rules-demos which shows how skills can be injected when needed. The example is:

"read the file at data/accounting/q1.ledger and explain what this ledger tracks"

If you know what the use needs to read or edit, you can inject knowledge/skills for the agent.

[trollbridge]

Git has easy to use GUI tools, particularly if you’re willing to use GitHub. I have not had trouble getting non technical staff to use it (book editors, graphic designers, writers, copywriters)

[detkin]

Very cool, sounds like you have some technically open-minded co-workers.

Do you just create a claude or codex plugin in git for them? Since they likely aren't working against any code repos?

[est]

yeah skills overwhelming is a problem. Splitting into sub-dirs works for now.

For us it's mostly developers.

[detkin]

That makes sense. The one thing that really bugs me about git sharing is when you have different repos but want to share the same collection of skills. We have three different golang projects/repos. They follow very similar patterns and can share a bunch of skills but I don't want to copy/paste into the different repos and have them drift.

I also like having a system on top that manages our evals so I know when I can retire a skill that isn't pulling it's weight and I can see the usage stats to understand which skills are making a real difference.