Teach Claude Your Way of Doing Something, Once

You worked out the right way to ask for something. It took three or four goes, you fixed the wording, and the answer came back exactly as you wanted it. Three weeks later you are typing the whole thing out again from memory, slightly worse.

If that is your week, you are not the only one. The method is the part that took the effort, and the method is the part nothing keeps.

Claude does not remember how you like a job done. Nothing carries between conversations unless you put it somewhere that holds it. A Skill is that somewhere. It is not a cleverer Claude. It is your own method, written down once, in a place Claude reads before it starts.

A Project holds your situation. A Skill holds your method.

These two get confused constantly, and the difference decides which one you actually want. A Project is a room. It holds who you are, what you are working on and the background material, so every conversation inside it starts with the situation already understood. It is right when a whole category of work keeps coming back.

A Skill is narrower than that, and narrower is the point. It holds your approach to one specific job: the role, the exact output shape, the quality bar, the rules. You hand it the one thing that changes, and everything else runs the way it ran last time.

That is the whole promise and it is worth saying plainly. Same input shape, same output shape, on a Tuesday when you are slammed and on a Friday when you are not. Your worst day matches your best day, because the Skill never has a busy day.

Answer six questions before you build anything.

A Skill that drifts is almost always a Skill that was vague on paper first. Six questions catch that, and they take about ten minutes.

• What triggers it. The moment you would reach for it. "When a meeting ends and I have rough notes" is a trigger. "When I need help" is not, and a Skill built on that will never quite fit anything.

• What its one job is. One sentence. If you need two sentences, you have two Skills.

• What the input is. The single thing that changes each run. If running it means assembling four things first, the friction has already beaten you.

• What the output shape is. Exact. "Summarise my notes" gives you a different shape every run. "Two lists: Decisions, and Action Items with an owner and a date" gives you the same shape forever.

• What good looks like. Under a hundred and twenty words. Plain language. No jargon. Whatever your real bar is, written as a sentence rather than held as a feeling.

• What it must never do. The hard boundaries. This is the half almost everyone skips, and it is the half that decides whether you can leave the thing alone.

Look at where those answers land. The job is your Objective. The input and output are your Format. The standards and the boundaries are your Conditions. The worksheet is CROFTC in question form, which is why filling it in feels familiar rather than new.

The block to paste.

Here is the shape, filled in for a job somebody actually has. Swap the content, keep the structure.

• Agent. Standing Skill. Apply this structure to every input. Proceed on wording. Flag gaps instead of filling them. Refuse anything outside this job.

• Context. I run a small online shop and answer buyer questions every day.

• Role. Act as a friendly, honest shop owner.

• Objective. Turn a pasted buyer question into a reply I can review and send.

• Format. A reply under a hundred words, then one line listing anything I should check myself.

• Tone. Warm, clear, never pushy.

• Conditions. Never promise a refund or a date that is not in my input. Flag those for me instead.

Notice what is doing the work there. Nothing in that block is clever. It is the same six letters you would use in a good prompt, plus one line at the top telling the Skill how to behave when something is missing.

Free Claude toolkit. The companion pack for my Claude book is free: ready-made Project instruction templates, and more than five hundred numbered prompts you can copy and paste. No card, and you can leave the list in one click. Get the toolkit →

Narrow beats broad, and it is not close.

The temptation once a Skill works is to make it do more. Resist it. A Skill repeats its instructions exactly, which means it repeats its flaws exactly too. A narrow Skill repeats something good. A broad one repeats mediocrity, on schedule.

Run the one-sentence test. If you cannot say what it does, what goes in and what comes out in a single sentence, it is too big. Split it. A Skill creeping towards "handle my email" wants to be three Skills: one that sorts, one that drafts replies, one that summarises threads.

There is a quieter benefit to keeping them small. When a narrow Skill starts drifting you know exactly which line to change. When a sprawling one misbehaves you cannot tell which of its ten jobs broke.

Write three nevers and one refusal.

A good Skill knows its job. A Skill you can leave alone knows what to refuse. Because it runs with less of your attention on it, the boundaries end up mattering more than the instructions.

Three nevers, specific and absolute. Never invent a fact that is not in the input. Never send anything to a real person. Never promise a price or a date I did not give you.

Then one refusal boundary, which is the line that stops it guessing. If the input is missing, empty, or asks for something outside this one job, do not attempt it. Say what is missing and stop.

Refusing well is a feature. A Skill with no refusal boundary answers everything, and answering everything is exactly how it produces nonsense on the day you are not reading closely.

Test it on three real inputs, then try to break it.

Run it on three genuinely different real inputs and check that the shape holds across all three. Consistency across varied input is the only proof worth having.

Then feed it rubbish on purpose. Empty input. Something off topic. Something missing a key piece. If it guesses instead of refusing, fix the guardrail rather than the output, and run it again.

What this will not do.

A Skill will not improve a method you have not worked out yet. It saves what you give it. Put a vague brief in and you have automated vagueness, which is worse than doing it by hand, because now it is invisible.

It will not handle a job that changes shape each time. Similar is not the same. If the input differs in kind rather than in detail, you want a Project, or honestly just a prompt.

And it will not be called this forever. Skills are a product feature, and product features get renamed and rearranged. The thing underneath, a method saved somewhere that gets read before the work starts, is older than the name and will outlive it.

One thing to do before the next post.

Pick the job you have rebuilt the brief for at least three times. Fill in the six answers on paper, before you open Claude. If any row is hard to answer, that row is exactly where the Skill would have drifted, and fixing it on paper is free.

If you are not sure a Skill is the right rung for that job at all, the tool ladder sorts that in about two minutes.

If you want the whole system rather than one piece of it, that is what I wrote Claude AI Bible (7 Books in 1) for. Seven books in one volume, with the Skill worksheet, twenty-four Skill and Agent templates, the failure rules for anything you leave running, and more than five hundred numbered prompts to copy.

This post is part of my Claude series. The one that started it is Why Claude Gave You a Great Answer on Monday and a Flat One on Tuesday.

Tomasz