What skills actually are

There is a word that shows up often in conversations about agents, prompting workflows, and model-assisted automation: skills.

And, as with many things in AI, it often gets stretched to mean several different things at once. In some contexts it becomes a polished label for any long prompt. In others it starts to sound almost like a way of “installing capabilities” inside the model. Neither reading is especially useful.

The most practical definition I have found is much less dramatic and much more useful: a skill is packaged operational knowledge for a recurring class of tasks.

It is not magic. It is not training. It is not a new personality. It is mostly a way of capturing judgment so the model has a better shape for approaching work that comes back again and again.

The important part is not length, but structure

What usually makes a skill useful is not that it is long. It is that it organizes a way of working well.

That often means combining several things in one place: context, activation criteria, steps, constraints, quality thresholds, common mistakes, and sometimes examples. Not because every skill needs all of those pieces, but because worthwhile tasks rarely depend on a single instruction. They depend on sequence and judgment.

If a task requires the right order of operations, respect for certain limits, a clear quality bar, and awareness of recurring failure modes, there is a good chance a skill can help.

That is why a Markdown file can be enough. Not because Markdown itself is special, but because it gives you a simple, maintainable format for describing process, expectations, and good practices without adding infrastructure too early.

What a skill does well

A good skill reduces ambiguity.

That is, to me, its main job. It does not make a badly designed task intelligent. It does not replace the judgment of the person designing the system. But it does help recurring work run with more consistency.

If an agent needs to review interfaces, analyze a migration, run a technical checklist, or transform content under a defined standard, a skill can keep each run from starting from zero. Instead of assuming the model will simply “figure out how to do it,” you give it a more deliberate working shape.

That matters most in tasks that are not purely mechanical but are also not fully open-ended. There is a large middle ground where a single-line prompt is too weak, but building a dedicated tool would be too much. Skills tend to fit well there.

What a skill is not

It is just as important to be explicit about limits, because the moment something works reasonably well it becomes easy to ask too much from it.

A skill is not model training. It does not change weights or install new internal capabilities. It is not fine-tuning. And even if it sometimes looks impressive from the outside, it is not a magical layer that turns a mediocre process into a great one just by being written down more neatly.

It is also not just a bag of tips. If a skill collapses into generic advice like “be clear,” “think step by step,” or “focus on quality,” it usually adds very little. For it to matter, it needs to translate experience into operating instructions: what to inspect, in what order, under what limits, and with what definition of acceptable output.

And perhaps most importantly, a skill does not replace system design. If the task itself is poorly defined, if the context arrives incomplete, or if the desired output is still vague, adding more text will not fix the real problem.

When skills genuinely help

They work best in tasks that repeat and where performance depends less on “having a brilliant idea” and more on applying a process well.

Design reviews, code audits, migrations with multiple checks, content preparation under a clear voice, and research flows with a repeatable framework all fit this pattern. In those cases there are nuances worth capturing once and reusing later.

They also help when several people — or several agents — need to share a similar way of working. A skill becomes a small container for judgment: it does not guarantee perfection, but it makes it more likely that the result lands within a reasonable range.

A very natural use case is to treat the skill as a reusable context asset in LangChain. The skill is still text, but now it is text with structure and intent. For example, you can store it as a Markdown file and load it into the system message so the agent does not have to improvise from scratch each time.

# Skill: review-ui

Use this skill when you need to review an interface before implementation.

## Goal
- detect issues in hierarchy, density, and clarity
- propose concrete improvements rather than generic advice

## Rules
- start with structure before decoration
- do not suggest animation if the real problem is layout
- prioritize high-impact, low-noise changes

Then use it from LangChain in a very direct way:

import { readFile } from 'node:fs/promises'
import { ChatPromptTemplate } from '@langchain/core/prompts'
import { ChatOpenAI } from '@langchain/openai'

const skill = await readFile('./skills/review-ui.md', 'utf8')

const model = new ChatOpenAI({
  model: 'gpt-4.1-mini',
  temperature: 0,
})

const prompt = ChatPromptTemplate.fromMessages([
  [
    'system',
    `You are a senior product designer. Follow this skill precisely:\n\n${skill}`,
  ],
  [
    'human',
    `Review this landing page proposal. I want feedback on visual hierarchy, spacing, clarity of message, and CTA quality. Return observations and a short prioritized improvement list.`,
  ],
])

const chain = prompt.pipe(model)
const result = await chain.invoke({})

console.log(result.content)

There is nothing especially mysterious happening here. The skill does not turn into an executable module or a new internal model capability. It is still context. The difference is that the context is now more deliberate, reusable, and shaped around a concrete way of working.

When they are the wrong tool

Not every task deserves a skill.

If something is obvious, short, and one-off, adding a specialized instruction layer can create more friction than value. The same happens when a task changes so much from case to case that the procedure stops being reusable. In those situations what looked like a skill slowly turns into a longer and longer document that becomes less and less useful.

Another common mistake is using skills to compensate for a weak system design decision. If what you really need is a tool, a function, a deterministic transformation, or an automatic validation step, it is usually better to build that than to describe it narratively and hope the model performs it the same way every time.

The same applies in LangChain. If what you actually need is stable data access, strict validation, API calls, deterministic branching, or transformations that should not depend on interpretation, the answer is not to keep making the skill more detailed. The answer is to model the graph better, introduce tools, or move part of the work outside the model.

Not everything should be solved with prompting.

The sign that a skill is well designed

There is a simple test: after reading it, the model should have fewer useless degrees of freedom, not more.

A good skill does not remove judgment entirely, but it does direct it. It reduces predictable errors. It makes the quality bar explicit. It orders the work. And it makes clear when the procedure applies and when it does not.

If, after writing it, everything still feels vague and open to too many interpretations, you probably have not defined a skill. You have simply added more text around a task that still needs design.

A calmer way to think about skills

I like to think of them this way: a skill is a small reusable unit of operational knowledge.

No more than that.

It is not trying to replace judgment. It is trying to package part of it so you do not have to rediscover it every time.

And that may be the most useful filter for deciding whether something deserves to become a skill at all: if writing it down is not capturing a real way of working better, then you probably do not need a skill. You need to think about the task more clearly.