I often see organizations overcomplicate setting up a company-wide skills repository. The conversation moves to marketplaces, platforms, licenses, and distribution before anyone has written a useful skill. I'd start with a KISS approach: keep it simple.

The reason to build one is fairly practical. People know how to prepare a proposal, handle an incident, or onboard a colleague, but much of that knowledge lives in their heads. Colleagues have to find the right person and ask. Agents need those instructions made accessible too.

A skills repository is a specific kind of knowledge vault: it holds instructions for how the company's workflows should be done. Writing down the process and judgement makes that knowledge available to colleagues and gives agents something they can interpret and follow.

Organize it around the work people do, rather than dividing it by technical and nontechnical roles or by department. I expect technical and domain boundaries to start fading to some extent anyway. Start with shared knowledge that everyone can use and contribute to.1

It should become more useful as people use it,2 spot gaps, and improve it. I'd keep that knowledge somewhere portable, because we'll probably want it longer than we'll stick with any particular agent. I'm also a fan of sharing it across teams so people can learn from each other's approach.

keep the setup simple

You can get quite far by keeping your skills in a Git repository and making it easy for people to use and improve them through their agent. Use the Git service you already have, whether that's GitHub, Bitbucket, or GitLab.

The repository can hold lots of skills. The average user only needs two entry-point skills installed in their agent.3

The first explains where the repository is and how to read its index. The agent checks which skills are available, reads the relevant instructions, and uses them for the task. Tell it your role and team to help it choose, without restricting it to your team's folder.

The second explains how to update the skills and the governance around changes. Someone can say, “Add a buddy meeting to our onboarding process,” and the agent creates a branch, edits the skill, updates the index, and opens a pull request. The team that owns the skill reviews it. Business users can contribute what they know without learning Git commands.

Your agent needs repository access and the tools to read files and propose changes. Set up permissions and branch protection to enforce who can approve and merge. The two skills describe the workflow; they don't provide those permissions.

start with a repository and an index

I put together Rubber Duck Industries Skills, a small example for a fictional company. Its structure looks roughly like this4:

company-skills/
├── README.md
├── AGENTS.md
├── company-skills/
│   └── SKILL.md
├── company-skills-updater/
│   └── SKILL.md
├── company-wide/
│   └── summarize-meeting/
│       └── SKILL.md
└── hr/
    └── prepare-onboarding-plan/
        └── SKILL.md

Each skill is a folder with a SKILL.md containing its name, when to use it, and instructions. Templates and references can go alongside it. That's the Agent Skills format.

The README.md lists the skills, what they're for, which team owns them, and where to find them. The AGENTS.md tells agents how to maintain the repository, including keeping that index up to date when a skill changes.

Copy the example into your company's repository, replace the company name and URLs in the two entry-point skills, and swap the sample skills for a few real ones. The repo includes an employee setup prompt you can adapt.

Ask someone who knows a process to explain it to their agent, with an example of a good result. Turn that into your first skill. Leave live company data in its existing systems; the instructions can explain where to find it.

how to use it

With the routing skill named company-skills, you can ask Claude Code: /company-skills prepare an onboarding plan. Skills can be invoked by name, and the router reads the index and loads the relevant instructions. Where persistent memory is supported, ask: “Remember that our company guidance is available through /company-skills. Use it when we're doing company work, and check its current index.”

Working directly with Git can be a technical hurdle. A setup prompt can walk people through connecting their account, installing the two skills, and saving that preference. It should also tell the agent to ask whether a correction is just for the current task or should be shared with the team. Shared changes go through company-skills-updater as a pull request for review.

notes

  1. I've always valued sharing knowledge. If you're considering separate repositories by department or role, ask why a company-wide one wouldn't work. Have a strong reason for splitting it. ↩

  2. As more people use and update the skills, agree who owns them, who reviews changes, and who can approve them. ↩

  3. Installing a skill helps the agent discover it. You can also point it at the instructions directly: “Read this skill and follow it.” With the necessary access and tools, it can use either approach. ↩

  4. I like department folders with shared company skills. Use whatever hierarchy works for your team. ↩