When I work on a new problem and the agent struggles with it, I will ask the agent to distill the knowledge and experiences it gained during the session into a skill file. Then I review and publish it depends on the assistant system. I find this is an effective way for the agents to learn new skills, both from its own discoveries but also from my steering and the mistakes it made.

If you work in a niche or on special problems, this template could be useful.

We have an ongoing discussion and some fans of https://microsoft.github.io/apm/

Because it's from Microsoft and sounds sufficiently enterprisey probably.

I don't use skills unless I have something specific to tell the agent. For example, if I want the agent to use Tailwind V3 instead of V4, I'll have a skill for that. Or, if I want the agent to always use the repository pattern for database access, I'll create a skill for that.

I don't need to manage skills files because I have so few of them and they're only a couple lines long.

I have created a little system for this, placed directly in the ~.<youragent>/skills folder.

I have a configuration file of marketplaces and other skills to fetch, it can look like. I have my own marketplaces as well, including ones from my company. I use vercel's tool for managing skills with npx, but to easily handle specifically _which_ skills to fetch, the config file is set up as follows:

  SOURCES = {
    'some-marketplace-name': [
        'some-skill',
        'another-skill',
        'yet-another',
    ],
    'https://designsystem.yourcompany.com': [], (empty list: fetch all skills)
  }

from there I simply run "skills.py" (a single helper) to clean/fetch updated versions of the skills.

Here's how I do it:

- Explanation: https://www.minid.net/2026/7/14/how-to-automatise-with-ai

- Git source: https://github.com/meerita/monorepo-nextjs-golang-rust-pytho...

5 Stages using local GIT (no remote, don't need it) to prevent preloading in the prompt:

1. A single Skill finder skill, loaded in the prompt, prevents having to import all the summaries in the prompt the harness would add. Uses git's own search.

2. Private repo, per agent, contains main (production) and draft-<name of skill> branches.

3. Shared repo, like 2, but general access for all group agents.

4. Fallback mode, search the harness for skills using the harness mechanism when a relevant skill cannot be found.

5. Skill audit cron. Identify junk skills / drafts that have never changed / not in any recent sessions history, and categorise monthly for me to decide.

This means it's compatible with existing skill folders, removal of git and the finder skill is non destructive and critically debloats the prompt of skills that aren't used and lazy loads them when needed.

I commit them to git(so complete team leverages them)., each repo has kind of different skills and the skills are the ones which I update at least twice a week. I’ve skills on how to add instrumentation , debug, code, code review, tech design review etc. I found most of the skills I find on skills.sh are not very useful for me., but I browse occasionally to get some inspiration. One more paradigm I’m seeing good results on adding new skills is ‘how to do X’, for instance ‘how to add logs’., “how to review code” etc., if i’m not able to frame it that way I don’t think it’s a good use case for me to add that skill to the llm arsenal.

Another thing i discovered is less is more (in case of skills as well)., don’t add lots of skills., keep them very handful - I’ve got 9 skills so far (many people have 100s installed from marketplaces and plugins)

I'm on mobile but the first skill I made was a skill improvement skill. This is basically stating that if the AI struggles in another skill but finds a way that the skill it used needs reworking and it needs to do so.

There is a rule to always use this skill and then track notes in a version file. Then back it up in a share folder or external drive.

Skills have made my tools immensely better, cheaper to use and faster. I've also added to it that it should write scripts it can just use in the future to do tasks like query information it needs to answer questions.

I wish there was a better way to share these over a team but I haven't taken that time yet.

Skills that are so generic that you can find them on the internet, and which you think can be replaced by model improvements, are useless, possibly even harmful, considering how much the models get clingy to the context. Useful skills describe workflows specific to your project, and they can live in the project repo for everyone to use and improve.

To the extent that skills are contextual guidance (for this author, this project, etc) and not just (raw) capabilities they are unlikely to be eaten by models.

I maintain all my skill files in a central location (like dotfile management) and have guix home sync it to the skill folders of various harnesses that I'm playing with (codex, pi, antigravity, Claude Code, Deepseek harness, etc). They're set up to be bidirectional links rather than read-only like the default configuration, so I can keep editing them / adding to the corpus from any harness.

This works well for skills since all harnesses expect the same format, but is more annoying for other features.

EDIT: This is actually an example of a potentially useful skill. You might choose to manage your skills slightly differently. All you need to do is write a skill-management skill for your agents to be able to wire things up correctly / access them for edits.

Some other nifty skills/plugins in my experience: render latex equations, cetz diagrams inline, jujutsu, guix, code reviewer, writing feedback.