Claude Code skills: stop onboarding your agent every Monday

Shapovalov Valentine — Wed, 07 Oct 2026 08:53:59 +0000

Writing the same long prompt for the same task every time is like onboarding a new intern every Monday.

Skills are how you stop.

A skill sits somewhere between a program and a prompt. At its core is a SKILL.md file of instructions for one specific job. It can also include reference material, templates, and scripts. The aim is a repeatable workflow, not a guarantee of an identical result.

Claude Code has them. Anthropic published the format as an open standard in December 2025. Codex and Cursor support skills too.

What changes in practice

Think about a skill for writing blog posts. Instead of leaving "write a post" open to interpretation, you can specify a workflow: read your previous posts, check for repeats, look for fresh data, ask a couple of clarifying questions, suggest a few options, then write in your voice. That's the difference between a stranger on the street and an assistant who's worked with you for six months.

Describe the logic once, then invoke it when you need that job done.

A monthly content plan. Sorting a folder full of documents. A proposal tailored to one client.

One skill to start each workflow.

Why skills scale better than one long prompt

The Agent Skills standard uses progressive disclosure: the agent starts with skill names and descriptions, then loads the full instructions when a skill is activated. You can also invoke a skill directly.

That keeps the full procedures out of context until you need them. The names and descriptions still take up space.

For me, that's the reason to keep task-specific procedures in skills. I want the workflow for the current job loaded when I need it, rather than carrying every procedure into every conversation.

Think of a tool as an action with a clear contract, like sending an email. A skill describes the workflow around those actions: what to check, which tools to call, and what the finished result should look like.

Building your first one

The Claude Code documentation explains how to create and invoke skills. There are already skill packs for development, like Superpowers. There are even skills for building skills.

The ones I'd tried felt closer to one-shot generation than to working through the design with a brainstorming partner. I wanted a process that helped me decide what the skill should do before writing it.

So I built my own: SuperSkill Creator. You answer questions, it checks for overlap with existing skills, and it helps you choose ready-made building blocks. Then it writes the skill, pressure-tests it with you, and saves it. The design happens in conversation; you do not have to hand-write the instructions.

If you want agents to take over everyday work and you'd rather not write code, skills are where I'd start. Pick one task you do every week and make it your first skill.

How to tell if your AI agent actually got better

Shapovalov Valentine — Wed, 23 Sep 2026 20:40:15 +0000

People keep asking me how you actually know an agent got better. I collected my answers to the most common questions in one place.

Isn't it obvious from the answers?

No. The agent says "You're booked for Thursday," and that sentence tells you nothing.

Anthropic's guide on agent evals shows it with a flight-booking agent: it may say "Your flight has been booked," but the outcome is whether a reservation actually exists in the database. What counts is the state the agent leaves behind, not what it says.

So the questions that matter are boring. Did the row appear in the database? Did the tool call fire with the right arguments?

A demo watches the reply. An eval watches the system. That is why demos always look great.

Doesn't an LLM judge solve this?

Partly. The judge brings its own bias.

In June a study of 21 LLM judges came out, Claude Opus 4.6 and GPT-5.4 among them. One of the tests: show the judge two answers, then swap their order and ask again. A good judge should not care which one came first.

On the easier benchmark, the median judge flipped its verdict 9% of the time. On the harder one it was 17%, and some judges went as high as 38%. The harder the task, the closer the judge gets to a coin toss.

The unpleasant part is that rerunning does not help. On a rerun, the same judge gives the same verdict roughly nine times out of ten or more, bias included. Stable is not the same as correct, so the only way to catch the bias is to calibrate the judge against human labels.

Should I score from 1 to 10?

Binary. Pass or fail.

The gap between a 3 and a 4 is a matter of taste, and everyone hides their uncertainty in the middle of the scale. A binary verdict makes you name the reason something failed instead of quietly giving it a 7.

How many cases do I need?

Dozens, not thousands. Start with 20 to 50 tasks pulled from real failures.

Thirty ugly cases from production beat a thousand synthetic ones.

So evals come before prompts?

It sounds logical, like TDD. For capabilities it can work: writing the eval first pins down what done means, and the Anthropic guide recommends exactly that.

For failures, no. An LLM can break in practically endless ways, so whatever you write upfront covers the failures you imagined, not the ones that will happen.

For failures the order is different:

ship → read the traces → write an eval for a failure that really happened.

While you are looking at replies, you are not measuring the agent, you are measuring its politeness.

DEV Community: Shapovalov Valentine