Should You Have Your Own Agent Skills?

This article is translated by AI, if have any corrections please let me know.

I often see discussions like “this tool is amazing,” but after actually using another person’s Agent Skill, it usually doesn’t feel quite right, and the results don’t match expectations. On top of that, letting arbitrary people provide your Agent Skills is quite dangerous from a security perspective, since we authorize Agents to do many things—far more dangerous than regular software tools.

Beyond security, there are many other reasons why having your own set of Agent Skills is a better approach.

Customization

When I first saw the concept of Agents emerging, the first thing that came to mind was “customization.” As software engineers designing software, we often have to find a balance among users, creating software that works for everyone. This is because resources are limited, and we can hardly satisfy everyone.

But Agents can help anyone write code to solve problems, which means a vast number of scenarios can be customized—including learning. The learning barriers that previously required a private tutor can now be customized with AI assistance (you can read AI Skills Worth Investing in 2026 for more on this).

From this perspective, if you want AI to help you work effectively, you should turn your workflows into reusable prompts that let AI handle things with habits similar to yours. This makes it easier to spot errors and achieve the same quality you would produce yourself.

In my use of Claude Code, I have a coding-skills setup that turns my frequently used /write, /fix, and /refactor actions into commands. Whenever I’m implementing something, I always start with /write ....

Although Claude Code no longer distinguishes between Slash Commands and Skills, the underlying prompt composition is still different. As of version 2.1.37, Commands still use <command-message> wrapping.

This type of Agent Skill is typically for personal use only. Others usually find it awkward to use, but it’s also less prone to errors (because the constraints are clear and highly customized).

Ability

Another type is the more “general-purpose” scenario. The foundation of current AI is the LLM (Large Language Model), which is never short on knowledge. But how to guide that knowledge out is where the real skill lies.

When discussing Agent Skills, most people think of this type—concepts like “the ability to create PDF files.” It’s similar to having “knowledge” but not knowing how to apply it, making the knowledge completely useless. Therefore, “using knowledge” is a critical ability.

In my coding-skills, the reason I put Clean Architecture, Testing, and similar categories in the ./skills directory is exactly this. First, I expect AI already knows what Clean Architecture and Test-Driven Development are—the training data certainly includes these concepts.

But when practicing Test-Driven Development, which type of test should I write? How do I determine whether something is suitable for testing? These aren’t purely knowledge problems—they’re skills accumulated through experience and practice.

This is the kind of information Agent Skills should contain. I should tell the AI that when I practice Test-Driven Development, I first write a failing test (Red), then implement to make it pass (Green), then refactor (Refactor), and that I prefer starting with integration tests, and so on.

Different people and different teams won’t necessarily do it this way, so it’s just “customization” with a broader scope—possibly applicable to an entire team or company.

The remaining purely tool-based usage represents the most universal skills, but you’ll find they “rarely get used” because these skills are so generic that there are almost no conditions to trigger them.

Skill Set {#skill set}

Thinking from the perspectives of security and customization, you’ll find that other people’s skills are mostly not useful, and mixing them together creates conflicts. Since everyone is customizing with different criteria, AI has an even harder time distinguishing which skill’s instructions to follow. You’d be better off having your own skill set.

Basically, following the workflows from the customization stage and the skills from the ability section, we can arrive at the reasoning that “doing something well requires both skills and processes.” How to organize and apply skills is designed by workflows, while the abilities needed in each process and their details are provided by skills.

In coding-skills, if you use the /write command to start a development task, you’ll find it roughly works like this:

• Browse the current project (for example, git log and reading source code)
• Clarify the implementation problem
• Select skills from the “skill rules”
• Create a plan based on the skill’s knowledge
• Execute the plan

The “skill rules” section explains which rules suit which scenarios. For example, clean-architecture is only needed when creating docs/architecture.md or making significant structural changes. Most of the time, testing and principles handle things.

So every time you use the /write command, it naturally incorporates testing and follows principles (usually SOLID principles), making the entire development workflow more focused on “what needs to be done.”

Having your own skill set means defining your own way of working. If you can’t decide how to work or what knowledge to use, can you really call yourself a professional?