Maintaining and Sharing Skills

By the Syncfusion DevTutorials team · Last updated October 22, 2026

Keeping shared skills healthy: owners and versions, patch/minor/major changes, changelogs, turning feedback into one fix, retiring old skills safely, and one reviewed team library.

Shared Skills Need Care

A team skill library = one shared place where the team keeps its skills. In this lesson, you will learn how to keep shared skills healthy. You will also learn how to share them with the whole team.

Writing a skill is only the start.

Once a team uses it, people depend on it.

So every change can help people, or break their work.

For example:

• Someone renames a heading, and a script stops working.
• A skill stays silent, and nobody says why.
• An old skill keeps winning over its better replacement.

Simple lesson: a shared skill needs an owner, a version and a plan for change.

A Real-World Example

A school kitchen shares one recipe book.

Each recipe has a cook in charge of it.

When a recipe changes, the cook writes the date and what changed.

Old recipes are marked "Do not use, see page 12" before they are torn out.

Your skill library works the same way.

Click the button and open the Library tab.

• Folder: one folder per skill, with SKILL.md inside.
• Front matter: the name and description everyone's agent reads.
• Extra files: references and scripts the skill points to.

Simple lesson: every skill in the library is a small product that other people use.

What You Will Learn

In this lesson, you will learn:

1. How to give each skill an owner and a version.
2. When a change is a patch, a minor or a major change.
3. How to write a short changelog.
4. How to turn feedback into one clear fix.
5. How to retire an old skill safely.
6. How to keep one shared library with reviews.

Owner and Version

Every shared skill needs two extra facts.

• Owner = the person or team who reviews changes and answers questions.
• Version = a number that says which copy of the skill you have.

You can keep both in the front matter, under metadata:

---
name: ui-review
description: Reviews UI components, screens and styles for accessibility ...
metadata:
  version: "1.3.0"
  owner: design-systems
---

Why both matter:

• If a reply is bad, the version tells you which copy made it.
• If you have a question, the owner tells you who to ask.

Simple lesson: no owner means nobody fixes it, and no version means nobody can trace it.

Patch, Minor or Major

A version has three numbers, like 1.3.0.

Each kind of change moves a different number.

• Patch (1.3.0 → 1.3.1) = a fix. Nothing people use changes.
• Minor (1.3.1 → 1.4.0) = something new is added. Nothing breaks.
• Major (1.4.0 → 2.0.0) = something people or scripts use breaks.

Important: ask one question. Can people keep using the skill without changing anything? If not, it is major.

Watch three changes to the shared ui-review skill:

Renaming one output heading broke a reply that used to pass. That is why it was a major change.

Simple lesson: the version number warns people before a change surprises them.

Turn Feedback Into One Fix

Feedback = notes from people who used the skill.

Collect it where people already work, like a pull request comment or a team chat.

Then do three things:

1. Reproduce the request in the lab.
2. Tag the layer that failed, like Activation or Instructions.
3. Fix the most common layer first, one change at a time.

Watch four notes about ui-review become one fix:

Two notes had the same cause. One small change to the description fixed both.

Click the button and open the Activation tab.

• Score: ui-review stays below the line for this request.
• Words: "accessible" and "page" are not in its description.

Before you change anything, save a baseline of your evals:

• Baseline: the results before your change.
• After: run the evals again and compare.

Simple lesson: fix the most common problem first, and test before and after.

Retire Old Skills Safely

Sometimes a skill is no longer needed.

Maybe a better skill replaced it.

But do not delete it on day one.

That is because a missing skill fails silently. The agent just answers without it.

A safe plan:

1. Week 0: mark it "Deprecated" in the description and name the replacement.
2. Week 0: add a "Do not use for ..." sentence, so new requests go to the replacement.
3. Week 2: check if it still fires. Tell anyone who still uses it.
4. Week 4: remove it in a pull request. Note it in the changelog.

Watch the old component-builder step aside for react-component:

The old skill was blocked first. It was removed only when nothing used it.

Simple lesson: deprecate, point to the replacement, check, then remove.

One Shared Library

A team library keeps all shared skills in one place.

Start simple:

• One repository with a folder per skill.
• One index file (README.md) that lists each skill with its owner and version.
• Clear names that say the job, like api-endpoint, not helper or misc.
• Small skills that each do one job, instead of one giant skill.

Every change goes through a pull request, like code:

• The owner reviews it.
• The evals run, and the results go in the pull request.
• New scripts, links or tool access get a security check.
• The version goes up, and the changelog gets a line.

Simple lesson: treat shared skills like shared code: one place, clear owners, and reviews for every change.

TL;DR

1. Team skill library = one shared place for the team's skills.
2. Owner = who reviews changes and answers questions.

3. Version = which copy of the skill you have.

   • Patch = a fix.
   • Minor = something new, nothing breaks.
   • Major = something people or scripts use breaks.
4. Changelog = a short list of what changed, newest first.

5. Feedback = real requests that went wrong.

   • Reproduce, tag the layer, fix the most common one.
6. Retire = deprecate first, point to the replacement, remove later.
7. Review = every change goes through a pull request with evals.

Common Mistakes

Check Your Understanding

Exercises

What to Remember

• Give every shared skill an owner and a version.
• Patch = a fix. Minor = something new. Major = something breaks.
• Write a short changelog, newest first.
• Reproduce feedback, tag the layer, and fix the most common problem first.
• Retire old skills step by step. Never delete on day one.
• Keep one shared library, and review every change in a pull request.

Next: Everyday Skill Patterns. You will see ready-to-adapt skills for the work developers do every day.