Example: A Skill That Saves You the Week

How to choose what deserves a skill

Not everything deserves a skill. There are three requirements, and you need all three:

• You repeat it. Something done just once doesn't need to be packaged up.

• It has steps. If it's a one-line request, just write it out again.

• It has to come out the same every time. This is where a written procedure beats your own memory: the result stops depending on how sharp you happen to feel that day.

Miss one and you have one more file to maintain that gives you nothing back.

The case: the end-of-month summary

Let's take something almost everyone has in some form. Every month-end you put together a summary for a client, and it's always the same steps:

• gather the month's numbers from wherever they live;

• put them in your format, always the same one;

• compare with the previous month and flag anything out of place;

• write two lines of commentary at the top;

• save it under the right name in the right folder.

Five steps, every month, always the same. It has all three requirements.

How we build it

We don't start from a blank file. We open Claude Code and tell it the procedure the way you'd explain it to a new colleague, asking it to turn it into a skill.

It creates the folder and the file. Our job starts after that, and it's three checks:

• Is the folder name the one you'd naturally write? If what's in your head is "closing," don't call it monthly-summary-generator.

• Does the description say what it does and when it's needed, in your own words? It's the line from the last lesson: if you write "handles summaries" here, it will never trigger on its own.

• Are the steps the real ones? This is where your own head matters — the things that are obvious to you, like red numbers always needing a comment, or that client wanting the total net of VAT, it can't guess those.

And the yardstick, here too

Let's add something you learned two chapters ago that makes all the difference in skills: what the right result looks like.

At the bottom of the skill, write the end conditions — "the file exists in the month's folder, it has the name in the agreed format, every deviation over ten percent has a line of commentary." That way, every time you run it, the check is baked into the procedure and you don't have to remember it yourself.

The test run, and the second version

You run it and watch what happens. Nine times out of ten the first version does almost what you wanted: the steps are right, the format is wrong; or it skips the comparison with the previous month because it wasn't clear where to pull the data from.

Don't start over: open the file and fix the line. It's a piece of English text, you fix it like a piece of text.

The skills worth having are the ones tuned up two or three times after watching them work. The first version is a draft; the one you'll use for a year is the third.

And now

With this the second bucket is fully closed: what it knows about you, from permanent instructions all the way to callable procedures.

In the next chapter the question changes: up to now there was always one collaborator at work. What if you needed more? How many you put to work — sub-agents and teams.

Did you get it?

Two minutes, no grade. Trying to answer — even getting it wrong — cements the concepts far more than rereading. Not in the mood? Skip it: the lesson still counts as complete.

1Which of these things deserves a skill?

A complicated thing you did once Something you redo often, with steps, that has to come out the same every time Anything at all: the more skills you have, the better

2Your skill works halfway: it does the right steps but the result isn't in the format you wanted. What do you do?

Delete it and write another one Open the file and fix the wrong part Explain it out loud every time