Choosing the Right Owner

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

Choosing who owns each rule and task: prompts, AGENTS.md, skills, scripts and MCP tools. Five questions to find the owner, the cost of always-on text, one owner per rule, and plugins that share skills and tools.

An owner is the one place where a rule or a task lives. In this lesson, you will learn the five owners an agent uses. You will also learn to pick the right one.

A skill is useful.

But a skill is not the answer to everything.

Some rules must apply to every task.

Some checks must be exact.

Some tasks need live data from another system.

For example:

• "Always use pnpm" is a rule for every task.
• "Sort the imports" is an exact check.
• "Read the database schema" needs live data.

None of these should be a skill.

Simple lesson: give every rule and every task exactly one owner.

A Real-World Example

A restaurant has a few kinds of guidance.

• The staff handbook applies every day. Wash your hands. Lock the door.
• A recipe card applies only when you cook that dish.
• A thermometer gives an exact number.
• The supplier delivers the fresh food.

Nobody pastes every recipe into the handbook. Agents work the same way.

Click the button and open the Route tab.

• Situation: a real task from a frontend team.
• Owner: pick who should own it.
• Why: read the reason after each pick.

Simple lesson: not every repeated task is a skill.

What You Will Learn

In this lesson, you will learn:

1. The five owners: prompt, AGENTS.md, skill, script and MCP tool.
2. Five questions that find the right owner.
3. Why always-on text costs tokens on every request.
4. How to remove rules that are written twice or that disagree.
5. How plugins share skills and tools as one package.

The Five Owners

Each owner is good at one kind of job.

• Prompt = your message in the chat. It is used once.
• AGENTS.md = a file at the root of the repo. It loads on every task.
• Skill = a folder with a SKILL.md. It loads only when a request matches.
• Script = code, such as a linter or a formatter. It gives an exact result.
• MCP tool = a tool the agent can call. It reads live data or takes an action.

Many coding tools read a project instructions file. AGENTS.md is a common name. Some tools also use their own file, such as CLAUDE.md or .github/copilot-instructions.md.

Simple lesson: each owner does one job well. Use the owner that fits the job.

Five Questions Find the Owner

Ask these questions in order.

Stop at the first yes.

1. Is it needed only once? Use a prompt.
2. Is it exact and mechanical? Use a script.
3. Is it true for every task? Put it in AGENTS.md.
4. Does it need live data or an action? Use an MCP tool.
5. Does it have repeated steps? Make a skill.

Sometimes two answers are yes.

For example, "fix failing tests" needs a tool to run the tests. It also needs the team's steps to fix them.

That is a skill + MCP tool.

Watch six real situations go through the questions:

Only one of the six became a plain skill.

Simple lesson: a skill is the last question, not the first.

Click the button and open the Route tab.

• Rules: "Never commit secrets" applies to every task.
• Checks: finding API keys is exact work for a script.
• Reviews: a full security review is a skill.

Simple lesson: one topic, like security, can need three owners.

What Should Not Be a Skill

A skill costs time to write and keep up to date.

So do not make one when another owner fits better.

Do not make a skill for:

• A one-off question. A prompt is enough.
• A rule for every task. It belongs in AGENTS.md.
• An exact check. A script never miscounts.
• Live data on its own. A tool fetches it. A skill cannot.
• A creative task with no fixed steps. There is nothing to save.

Simple lesson: make a skill only for repeated steps with a checkable result.

Always-On Text Costs Tokens

AGENTS.md loads on every request.

So every line in it costs tokens every time.

A skill is different.

Only its name and description load at the start. Its body loads only when it fires.

Watch what happens when a team moves two workflows out of AGENTS.md:

The rename did not need the workflows. After the move, it did not pay for them.

Important:

• Keep short rules for every task in AGENTS.md.
• Move task workflows into skills.
• Add one line that points to the skills folder.

Simple lesson: if a line is needed only sometimes, it should not load every time.

One Owner per Rule

The same rule in two places will drift apart.

Two places that disagree are worse.

For example:

• AGENTS.md says the tests use Vitest.
• The react-component skill says Jest.

The agent may pick one, then the other. You cannot predict which.

To fix this:

• Name each fact once, usually in AGENTS.md.
• In the skill, write "use the project's test runner".
• Do not copy always-on rules into a skill.

Simple lesson: one fact, one owner, no copies.

Skills, Tools and Plugins

A skill knows how to do a task.

A tool does things: it reads data and takes actions.

MCP (Model Context Protocol) = a standard way to give tools to an agent.

Many tasks need both.

For example:

• Bug triage: an issue tracker tool fetches tickets. The skill holds the triage rules.
• Endpoint design: a database tool reads the schema. The skill holds the naming rules.
• UI build: a design tool reads the frame. The skill holds the team's conventions.

When a skill uses a tool, name the tool in a workflow step:

## Workflow
1. Use the issue-tracker tool to fetch today's new tickets.
2. For each ticket, write a summary, a severity and an owner.
3. Use the format in templates/triage.md.

Give a skill only the tools it needs. A read-only database tool is enough to design a query.

Some tools let a skill list its safe tools in front matter, such as allowed-tools. Check your tool's docs.

A plugin = one package that holds skills, MCP servers and commands.

A teammate installs it once and gets the whole kit, at the same version.

Watch a plugin being put together:

The skills give the know-how. The servers give the hands.

Click the button and try all 18 situations.

• Aim: 15 or more right.
• Misses: read the reason on each one.

Simple lesson: skills and tools work best together, and a plugin shares them as one.

Skills Working Together

Some jobs need two skills, one after the other.

For example, a release needs release notes and a commit message for the version bump.

Do not put both jobs in one skill. Let one skill hand off to the next.

Hand-off = the last step of one skill names the next skill to use.

## Workflow
1. Group the commits.
2. Write the release notes.
3. Then use commit-writer for the version bump commit.

Watch a hand-off, and a bad one:

The Skill Lab runs one skill per request, so it does not follow a hand-off. To see each part, run the first skill, then run the second skill with its own request.

Three rules keep hand-offs safe:

• One job per skill. Point to the other skill. Do not copy its rules.
• One way only. If A hands off to B, B must not hand back to A. That is a loop.
• Each skill works alone. Someone may ask for just a commit message.

Sometimes a skill is the wrong helper. Two other agent features can do the job:

Context window = everything the agent can see at one time. A subagent gets its own, so the main chat stays small.

Simple lesson: chain skills one way, and use a subagent for big side work or a hook for things that must always run.

Common mistakes

Check Your Understanding

Exercises

These exercises help you give each rule and task the right owner.

Press Check when you are ready. Use Show Hint if you get stuck.

Further Reading

• The MCP course shows how to build and connect MCP servers, the tools your skills can use.

What to Remember

• Every rule and every task needs one owner.
• Prompt: one-off questions.
• AGENTS.md: short rules for every task.
• Skill: repeated steps that load only when needed.
• Script: exact, mechanical checks.
• MCP tool: live data and actions. Many tasks need a skill plus a tool.
• Plugin: one package that shares skills and tools.
• Always-on text costs tokens on every request. Keep AGENTS.md short.
• Remove copies and clashes. Do not count on one file winning.

Next: Diagnosing Skills. You will learn to find why a skill fails, one layer at a time.