Not everyone needs to go all in on Skills

The faster AI develops, the easier it is to feel a certain pressure:

new concepts, new tools and new ways of working keep appearing. Just as you understand one, there’s the next to learn.

For every one of them, someone tells you it’s important, maybe even that it will change the future of work.

So “I’ll look into it” easily becomes “I must start using it right away.” If others have already started building new workflows and you haven’t found a use case yet, you can’t help wondering:

have I just not really understood it?

If I don’t catch up now, will I slowly fall behind?

That’s how I felt about Skills.

I looked back carefully over my work, trying to find what I should turn into a Skill, and found far fewer truly suitable situations than I imagined.

Apart from a few fairly fixed tasks, what I face is mostly new problems, new material, and judgments that have to be made fresh each time.

But Skills are talked about as so important.

So is it that I don’t know how to use them yet, or that they simply don’t need to be adopted fully by everyone?

Skills solve a specific, repeated problem

As I understand it, a Skill saves a fairly stable method so that AI can use it again when it meets a similar task.

If you put together similarly structured reports every week, check code against the same standards every time, or keep having to remind AI to follow the same brand guidelines, that’s obviously more efficient than explaining again and again.

In a team, the value may be even clearer.

Experience that existed only in one person’s head can be written down, so more people can work in a fairly consistent way.

So I don’t doubt that Skills are useful.

But they’re especially valuable usually under a few conditions:

• the work keeps recurring;
• the method for handling it is fairly stable;
• the result can be checked;
• the method is still worth maintaining in the future.

Some people’s work naturally meets these conditions.

But not all work looks like that.

Tasks where I found a Skill fits

For example, when I keep revising RedNote posts, I often give AI similar feedback:

the title shouldn’t read like a paper abstract;

the whole piece needs one clear main thread;

don’t overturn the parts that hold up just because I pointed out one problem;

separate facts, personal experience and inferences.

At first these were just scattered pieces of feedback on specific posts.

Only later did I notice that some of the requests kept repeating and gradually formed a fairly stable set of review standards.

At that point, turning them into a “RedNote post review” Skill is at least worth trying.

Not because the method is already mature, still less because others should copy it.

But because real repetition came first:

• I keep doing this;
• AI keeps making similar mistakes;
• some of the standards of judgment have stabilized;
• I can tell whether it carried them out properly.

Here a Skill has a clear problem to solve.

It wasn’t created for the sake of learning a new tool.

Some tasks only look repetitive

For example, I also keep analyzing different jobs.

On the surface, I’m doing something similar every time:

read the JD, analyze the fit, find the gaps, adjust the résumé.

It seems very suitable for a Skill.

But when I actually analyze, each role has a different business background, team stage, hiring focus and bar for evidence. Whether my experience supports a particular requirement also has to be judged afresh from this time’s material.

There are of course reusable parts.

For example, checking facts, spotting hiring signals, separating experience I already have from evidence I currently lack.

But if the whole job-judgment process is fixed too early, AI easily keeps giving answers that are familiar and complete, but not necessarily accurate.

The structure may get more and more stable.

The judgment doesn’t necessarily get better.

Some work repeats only in its task name; the most critical way to solve it still depends on the current context.

Product direction, career choices, and posts whose core argument hasn’t been found yet may belong to this kind too.

It isn’t that there’s no method for them at all.

It’s that the most important part hasn’t stabilized enough to be worth packaging as a whole.

Skills usually suit systematized work best

Why does it look like so many people have already gone all in on Skills?

One reason may be that the people publicly sharing these workflows are the ones most likely to benefit from Skills in the first place.

Developers, high-volume content producers, professional builders and teams with clear SOPs often have more repeated steps in their work, and a stronger motivation to systematize them.

The Skills they share may really be very effective.

But what we usually see is the finished version:

• a tidy directory;
• flows that trigger automatically;
• one call that completes what used to take many steps.

What we see less of is:

• how long it took to create and test;
• how many times the rules were changed later;
• how many Skills ended up not being used;
• who maintains them when the task changes;
• how much extra checking wrong invocations added.

Looking only at the finished product, it’s easy to mistake complexity for maturity, and to mistake someone else’s work structure for a required course of your own.

Being able to create it doesn’t mean it’s worth maintaining long term

Creating a Skill isn’t hard anymore.

You can even hand AI your past conversations, have it summarize the rules, and generate a method that looks quite complete.

But a Skill doesn’t naturally understand you better just because it’s used more.

• When the task changes, the rules need adjusting;
• when new exceptions appear, you have to judge whether to change the original method;
• when output quality drops, you also have to recheck where exactly things went wrong.

If a method hasn’t stabilized yet, packaging it only makes it easier to repeat.

Reuse amplifies not only efficiency, but possibly mistakes too.

So what really needs calculating isn’t only how many prompts it saves each time.

It also includes the cost of creating, testing, checking and maintaining it.

For some tasks, explaining again takes only a few minutes, and building a long-term system for them is actually more trouble.

You don’t have to choose between “all in” and “not at all”

I used to tend to see new tools as a multiple-choice question:

• either keep up or fall behind;
• either build a whole set of Skills, or remain at a fairly basic level of use.

But real work isn’t that neat.

I may only need one or two Skills, for the most fixed parts that most easily go wrong repeatedly.

Other tasks that need fresh understanding of the material and fresh judgment can keep using chat and one-off prompts.

I may also just use Skills maintained by a company, a platform or someone else, without needing to create many myself.

Understanding what Skills are, testing one on a real task, and rebuilding your way of working around Skills are three decisions of different weight.

They don’t have to happen at the same time.

Keeping up with AI isn’t adding every new tool to your workflow

AI will keep producing new products, new concepts and new methods.

I still want to know what they can do, and I’m willing to try them on the right tasks.

But understanding a tool doesn’t mean you have to adopt it fully.

In the end it comes back to your own work:

• What existing problem of mine does it solve?
• Will I keep using it?
• Do its benefits really outweigh the cost of learning and maintaining it?

If the answer isn’t clear for now, you can understand first, observe first, even not use it for now.

That isn’t refusing change.

What really needs avoiding is letting the fear of falling behind translate “it’s important” directly into “I must adopt it fully.”

Not everyone needs to go all in on Skills.

What matters more is understanding what they can do and where they fit, and then, based on your real needs, deciding how much room they should take up in your work.