What is the difference between discovery and activation?

Discovery finds installed skills. Activation picks one for a request.

Discovery runs scripts. Activation reads files.

Activation happens when you install a skill

Two skills keep firing for each other's requests. What is the best fix?

Make each description different and add a 'Do not use' sentence

Make both descriptions longer with the same words

You copy a 'manual only' setting from one tool into another tool. What may happen?

The other tool ignores the setting without a warning

Activation and Descriptions

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

How agents find installed skills and pick one for a request: matching descriptions, writing what/when/when-not descriptions in users' words, fixing overlapping skills, calling skills by name and manual-only skills.

How the Agent Picks a Skill

Activation = the agent choosing one skill for your request. In this lesson, you will learn how that choice is made. You will also learn to write descriptions that make the right skill fire.

Before an agent can pick a skill, it must find it.

Then it compares your request with every skill's description.

The skill with the best match fires.

So the description decides almost everything.

For example:

A clear description fires for the right requests.
A vague description never fires.
Two similar descriptions fight over the same request.

Simple lesson: the agent picks skills by their descriptions. Write them with care.

A Real-World Example

A hospital has a board at the front desk.

It says "Dr. Shah: bones and joints. Dr. Lee: skin."

A patient says "My knee hurts." The receptionist sends them to Dr. Shah.

If the board said "Dr. Shah: helps people", the patient could go anywhere.

The agent is the receptionist. Your descriptions are the board.

Score a request in the lab

Click the button and open the Activation tab.

Bars: each skill's score for your request.
Line: the score a skill needs to fire.
Words: the matching words that raised the score.

Try other wordings, like "check my PR" or "look over this diff".

Simple lesson: every request that misses is a word you could add to the description.

What You Will Learn

In this lesson, you will learn:

How the agent finds installed skills.
How it matches a request to a description.
How to write a description in three parts.
How to stop two skills from fighting.
How to call a skill by name.
Which skills should be manual only.

About the lab's scoring

The Activation tab uses simple scoring.
Each matching word adds 1.
A word after "Do not use" takes points away.
Real agents let the model read the descriptions. That is smarter, but the idea is the same.

Finding Skills

Discovery = the agent finding which skills are installed.

When a session starts, the tool looks in its skills folders.

Each folder with a SKILL.md becomes one line in the catalog.

Most tools look in two places:

Project folder: a skills folder inside the repository. Everyone who clones the repo gets it.
Personal folder: a skills folder in your home directory. Only you get it, in every project.

Some tools also load skills from plugins or from an organisation folder.

Important: check discovery first.

Type / and look for the skill in the menu.
Or ask the agent "Which skills do you have?"
If it is missing, check the folder, the file name and the front matter.

Simple lesson: a skill that is not found can never fire.

Matching a Request

The agent reads your request next to the catalog.

It looks for the description that fits best.

It looks for meaning, but shared words still help a lot.

Automatic activation: the agent compares a request with every description in the catalog, loads the SKILL.md of the best match and follows it. Calling a skill by name skips the matching step.

Watch a skill that never fires, then gets fixed:

Only the description changed. The skill went from silent to firing.

Simple lesson: use the words your users type, not only your team's words.

Writing a Good Description

A good description has three parts:

What: what the skill does. Example: "Plans unit and integration tests for a function."
When: when to use it, in users' words. Example: "Use when someone asks what to test or which cases to cover."
When not: nearby jobs that belong elsewhere. Example: "Do not use for release notes or PR review."

Where do users' words come from?

Old chat requests.
Pull request comments.
Issues and support tickets.

Keep it short.

The agent reads every description for every request.

One or two sentences are usually enough.

Find a silent skill

Click the button and open the Activation tab.

test-planner: it should fire, but it stays below the line.
Fix: open it in the Library tab. Add "which cases to cover" to its description. Press Save.
Retry: run the same request again.

Simple lesson: say what, say when, say when not.

Write the description last.

Once the steps are done, you know exactly what the skill does.

When Two Skills Fight

Overlap = two skills whose descriptions share many words.

When they overlap, the agent may pick the wrong one.

Watch two changelog skills fight over one request:

One "Do not use" sentence moved the request to the right skill.

Ways to stop overlap:

Different nouns: "diff, pull request" for one skill, "markup, CSS" for the other.
"Do not use" sentence: name the other skill's job.
Drop shared words: remove words like "code" that add nothing.

UI review or component builder?

Click the button and open the Activation tab.

ui-review and react-component: both talk about components.
Watch: which one wins, and which words decided it.

Simple lesson: test the other skills' requests too. A skill that steals work is as bad as a silent one.

Calling a Skill by Name

Sometimes you already know which skill you want.

Then you can call it by name.

Syncfusion Code Studio: type / in chat and pick the skill.
Claude Code: type /skill-name, like /pr-review src/api.
GitHub Copilot: type /skill-name.
OpenAI Codex: type $skill-name, or use /skills to pick one.

Calling by name skips the matching step.

So it is a great way to test a skill's steps.

Watch the three ways a skill can be picked:

The first uses the description. The second skips it. The third blocks automatic use.

Pick a skill by name

Click the button and open the Run tab.

Skill menu: picking pr-review works like calling it by name.
Result: it loads even if the request does not match the description.

Important: if a skill works by name but not by itself, fix the description. The steps are fine.

Giving the Skill Its Input

When you call a skill by name, you can add text after the name.

That text is the input.

/release-note-helper v3.1 gives the skill the version v3.1.
/pr-review src/api gives the skill the folder to review.

How the input reaches the skill:

Claude Code: the text after the name fills $ARGUMENTS. Put $ARGUMENTS in SKILL.md where the input should go.
Other tools: the agent reads the rest of your message as the input.

What if you give no input?

$ARGUMENTS is empty. A good skill then asks for it. It does not guess.

Simple lesson: the text after the skill's name is its input. If the input is missing, the skill should ask.

Try it in the lab. The request starts with /release-note-helper, so the skill fires by name. No score is needed. Then type the same request in the Run tab and press Show the prompt to see where v3.1 goes.

Call a skill by name, with input

Manual-Only Skills

Some skills should never run by themselves.

For example:

Deploying to production.
Deleting data.
Sending messages to customers.

You can mark these as manual only:

Claude Code: disable-model-invocation: true in the front matter.
OpenAI Codex: allow_implicit_invocation: false in the skill's agents/openai.yaml file.

A manual-only skill is left out of matching. You must type its name.

These settings are different in each tool.

A tool usually ignores a setting it does not know. It gives no warning.

So a setting copied from another tool may do nothing.

Keep risky actions behind permissions and confirmations too.

Simple lesson: risky skills should run only when someone names them.

Try it: open commit-writer in the Library tab and add disable-model-invocation: true under its description. Press Save. Now "commit message for these changes" fires nothing, but /commit-writer still works.

Make a skill manual-only

Common mistakes

Mistake	Wrong idea	Correct idea	What goes wrong
Fixing activation first	"The skill does not fire, so the description is wrong."	Check that the skill is found first.	You edit a description the agent never sees.
Team words only	"Our name for the task is enough."	Use the words users type.	The skill stays silent.
No "Do not use" sentence	"Each skill is clearly different."	Name the nearby job of the other skill.	Two skills fight, and the wrong one fires.
Testing one wording	"It fired once, so it works."	Try many wordings and other skills' requests.	Misses and wrong picks go unnoticed.
Risky skill on automatic	"It will only fire when I mean it."	Make deploy and delete skills manual only.	Something runs by accident.
Copying tool settings	"This setting works everywhere."	Check each tool's docs.	The setting is ignored without warning.

Check Your Understanding

Exercises

What to Remember

Discovery finds the installed skills. Check it first.
Activation matches your request to a description.
Write descriptions in three parts: what, when, when not.
Use the words your users type.
Two similar skills fight. Add a "Do not use" sentence.
Calling a skill by name skips matching. Use it to test the steps.
Make risky skills manual only. Settings differ between tools.

Next: Skill Installation. You will learn where skills live, and how to check that one loaded.