Context to skill: the method

There is a fast way to build a skill and a right way, and they are not the same.

The fast way is to think of a task, ask Claude to build a skill for it, and start using it. It will produce something that looks finished. The right way starts one step earlier — with understanding the task well enough that the skill captures what actually works, not what you assumed would work.

The rule underneath the whole method is blunt: if you automate before you understand, you just move the mess faster. A skill repeats whatever you put into it. Encode a shaky process and you do not fix it — you reproduce it, at speed, with your name on every output.

So the method goes the other way. From understanding, to a skill that holds up.

Step 1: Do the task by hand first

Before you encode anything, do the task — or recall doing it — in enough detail that you could narrate every step. If the task is new to you, do it manually once or twice first. You cannot automate a process you have not actually run; you can only automate your guess about it.

This is not wasted time. The manual pass is where you discover the steps that are not written down anywhere — the check you always do, the source you always cross-reference, the judgment you make without noticing.

Step 2: Separate the stable process from the judgment

Now split what you did into two piles.

The stable process — the steps that are the same every time. Pull these inputs, in this order. Produce this structure. Format it this way. This is what a skill handles reliably.

The judgment — the steps that depend on context only you hold. Which finding matters most for this audience. Whether this is ready to send. What the data actually means for this situation. These do not get automated away; they get protected. A good skill does the stable work and then pauses for you at the judgment points.

Getting this split right is the real skill of building skills. Everything else is mechanics.

Step 3: Capture the context once — including what to ask you

A skill is only as specific as the context you give it. Write down, once, the things that make the output yours: the audience, the voice and tone, the constraints, the standing facts about your work.

Then add the part most people miss. The model solves the problem you hand it — it will not raise the thing you forgot to include. So build the clarifying questions into the skill: the two or three things it should always ask you before it runs ahead. "Who is this for?" "What is the one point you want to land?" That way the missing context surfaces every time, by routine, instead of leaking into a confident, wrong output.

Step 4: Keep it short and single-purpose

When a skill runs, its full instructions load into Claude's working context and stay there for the rest of the session — so length has a real cost. Resist the urge to make one skill do everything. One skill, one core task. If the task is large — a process with twenty or thirty steps — that is a sign it should become a few focused skills that hand off to each other, not one sprawling one. (The series returns to chaining later; for now, keep each skill to one job.)

Step 5: Plan, then build

Only now do you build. With the process understood, the judgment points marked, the context captured, and the questions defined, the actual construction is the easy part — Claude can help you write the skill itself. The work that made it good already happened, on paper, before you touched the tool.

Design first is not enough

You will hear, correctly, that "design is the hard part" and that you should plan before you build. True — but incomplete. Planning a task you have never actually done is still guesswork, just better organised. The difference that matters is designing from understanding: the process you encode is one you have run by hand and seen work. That is what separates a skill that holds up under real use from one that produces something plausible and slightly wrong, every time, until you stop trusting it.

What comes next

You now have the method. The next part gets concrete about the artifact itself — what a good skill is actually made of, why short and single-purpose matters more than it sounds, and how to keep a skill efficient enough to trust.

Next in this series: Part 3 — Anatomy of a good skill