Skills Central: A Pragmatic Setup for Reusable AI Skills

If you are following my work, you know that I try to incorporate reusable AI workflows into my projects as much as possible. I’ve been using skills for a while now and in this post, I want to share my pragmatic setup for skills that balances modularity, maintainability, and ease of use in a day-to-day development context.

How the Skills Central repository came to be

During the development of one of my side projects, I found myself referencing the same set of skills that I used already in another project. I realized that I was constantly symlinking the same skills from multiple external repo forks that I cloned locally. I can foresee a future where I have dozens of forked repos that I have to manage and keep in sync with their original source. A maintenance nightmare.

I took a step back and thought about how I could solve this problem. After a short walk and some brainstorming, I came up with the idea of “Skills Central” - a single repository that contains all of the skills that I (want to) use across my projects, organized in a way that makes it easy to find and reuse them. After a quick chat with ChatGPT to discuss the idea and refine some details, I asked it to generate a prompt for Codex to create the initial structure of the repository. You can find the prompt I used and refined with Codex here . Please note that the prompt is quite detailed and specific to my needs, but it can be adapted to fit your own requirements.

The structure of Skills Central

Codex took my prompt and generated the initial structure of my Skills Central repository. Here is how it organized it:

skills-central/
├── .gitignore
├── README.md
├── CONTRIBUTING.md
├── docs/
│   ├── architecture.md
│   ├── imports.md
│   └── usage.md
├── scripts/
│   └── bootstrap-skills.sh
├── templates/
│   └── skill-source-template.md
└── skills/
    ├── stable/
    │   ├── shared/
    │   │   ├── architecture/
    │   │   ├── review/
    │   │   ├── tdd/
    │   │   └── writing/
    │   ├── ai/
    │   ├── dotnet/
    │   ├── maui/
    │   └── swift/
    └── experimental/
        ├── shared/
        │   ├── architecture/
        │   ├── review/
        │   ├── tdd/
        │   └── writing/
        ├── ai/
        ├── dotnet/
        ├── maui/
        └── swift/

Here are the key components of the structure:

• skills-central/: The root directory of the repository.
• scripts/: A directory containing scripts to automate tasks, such as the bootstrap script for symlinking skills. (spoiler - this one will not survive until the end)
• docs/: A directory containing documentation on the architecture, how to import skills, and how to use them effectively.
• templates/: A directory containing templates for creating new skill sources, ensuring consistency across the repository.
• skills/: The main directory where all the skills are stored, organized into stable and experimental categories, and further categorized by domain (e.g., AI, .NET, MAUI, Swift) and shared skills (e.g., architecture, review, TDD, writing).

First Skills: repository management

With this structure in place, I was ready to start populating the repository with skills. I quickly realized, though, that Codex’s own import skills were only available in Codex itself. My goal, however, is to be provider agnostic. I confronted Codex with this problem - and so it came to be that we created a set of skills for importing skills from GitHub repositories and installing them into Skills Central. We also removed the scripts/ folder as it was no longer needed afterwards.

The first important skills were these two:

• github-skill-importer: A skill to import a foreign skill from a GitHub repository into the central repository, copying it into the correct functional category and generating a skill-source.md file.
• project-skill-installer: A skill to install selected shared skills from the central repository into a project’s root skills/ tree, supporting both symlink and copy modes. This skill made the scripts folder with the bootstrap script obsolete, as it provided a more structured and reusable way to manage skill installations across projects.

After these two skills were in place, I was able to easily import skills from other repositories (for example some of the skills Paul Hudson references in his Swift skills repository) and install them into my projects without having to worry about managing multiple forks or symlinks.

But I didn’t stop there. I also created a set of skills for authoring new reusable skills in a provider-agnostic way. On top of this core skill, I built provider-specific add-ons for OpenAI, Anthropic, and GitHub Copilot with the help of Codex. This way, I can ensure that my skill creation process is consistent and efficient no matter which provider I am working with (I tend to switch between them every now and then).

If you want to see the full list of skills and their purposes, you can check out this prompt that will help you to create them for your own setup.

Why not open source it?

You might be wondering why I haven’t open-sourced my Skills Central repository. The truth is, I have considered it, but I have decided against it for now. There are a few reasons for this decision:

• The repo contains a lot of personal and project-specific skills that may not be relevant or useful to others.
• This is just my approach of structuring and managing skills, and it may not be the best fit for everyone. I want to keep it as a personal tool that I can evolve and adapt as my needs change.
• As we live in a fast-paced world of AI and LLMs, I want to keep the flexibility to experiment and iterate on the structure and content of the repository without worrying about breaking someone else’s setup or expectations.

That being said, I am open to sharing specific skills or insights from my setup if there is interest. I also encourage others to take inspiration from my approach and adapt it to their own needs. The goal is to create a system that works for you and helps you to manage your reusable AI workflows effectively, whether that means using a similar structure or coming up with your own unique solution.

With the help of the prompts I used to create my Skills Central repository, you can easily set up your own version of it and start managing your reusable AI workflows in a more organized and efficient way.

How to maintain foreign Skills in the long term?

One of the challenges of using skills from external sources is keeping them up to date and in sync with their original source. To address this, I have implemented the follwing strategy:

• For skills that I import from external repositories, I create a skill-source.md file that contains metadata about the skill, including its original source, the upstream path, imported commit, tag or version, and its import date. This way, I have a clear record of where the skill came from and when it was last updated.
• I give all imported skills a local status (one of mirror, adapted, or forked) that indicates how closely they track the original source. This helps me to prioritize which skills need to be reviewed and updated regularly.
• notes about local modifications and adaptations are also included in the skill-source.md file, so I can easily track any changes I make to the skill and how they differ from the original source.
• Skills with a mirror status will be reviewed for updates on a regular basis to check if there are any new commits or versions in the original source that need to be imported. For skills with an adapted or forked status, I will review them on a case-by-case basis, depending on how critical they are for my projects and how much they have diverged from the original source.
• I plan to extend the meta data in the skill-source.md file to include statistics about the skill’s usage across my projects, such as how many times it has been installed and used, and any feedback or issues that I have encountered with it. This will help me to prioritize which skills to maintain and update based on their importance and impact on my projects - and also to identify any skills that may need to be deprecated or removed if they are no longer relevant or useful.

Conclusion

Skills are powerful tools for reusable AI workflows, but managing them can be challenging. I created the Skills Central repo as a pragmatic solution to this problem in my own projects and in my environment.

I hope that sharing my setup and the thought process behind it can inspire others to create their own systems for managing reusable AI workflows. Whether you choose to adopt a similar structure or come up with your own unique solution, the key is to find a system that works for you and helps you to manage your skills effectively.

What is your approach to managing skills you keep using across projects? Did you choose another solution to solve this problem? I would love to hear about it in the comments or on my social media channels.

As always, I hope this post is helpful for some of you!

Until the next time, happy coding, everyone!

---

Title image note: The title image of this post was generated with the help of AI. It illustrates the concept of a central repository for reusable AI skills, with a visual representation of interconnected nodes representing different skills and their relationships.