Build your first skill

The fastest way to understand skills is to build one. This part takes a single recurring task and turns it into a working skill, end to end. Pick a real task of your own as you read and do it alongside.

Step 1: Pick the right first task

Choose a task that is recurring, well understood, and context-heavy — the kind where you keep re-explaining the same things. Good first candidates: a weekly status report, a meeting summary, a content brief, a recurring stakeholder update.

Avoid the temptation to start with your hardest, highest-stakes work. You want a task where you already know what good looks like, so you can judge whether the skill is doing it right. The complex stuff comes later, once you have a feel for how skills behave.

Step 2: Run the method on it

Before you build anything, run the method from Part 2 on your chosen task:

• Do it by hand in enough detail to narrate every step.
• Mark the judgment points — the steps that need your context and should pause for you.
• Capture the context — audience, voice, constraints, standing facts.
• Write the questions the skill should ask you before it runs.

Do this on paper or in a quick note. This is the part that makes the skill good; the rest is assembly.

Step 3: Let Claude help you author it

You do not have to hand-write the skill from a blank file. Describe the task to Claude — the process you mapped, the judgment points, the context, the questions — and ask it to draft the skill for you. Depending on how you use Claude there may be a built-in helper for creating skills; either way the move is the same: you bring the understanding, Claude assembles the structure.

Review what it produces against your map. Make sure the description says clearly what the skill does and when to use it, the instructions read as standing rules, and your clarifying questions are in there.

Step 4: Save it where it will be found

Where you save a skill decides who can use it:

• Personal — available to you, across your own work. This is where most first skills live.
• Shared — saved where your team or a specific project can reach it, so it becomes a shared asset rather than a personal helper.

The exact mechanism depends on how you use Claude, and the proper way to share across a team — versioning, review, who owns it — is a Track 4 topic. For your first skill, personal is the right choice; you can promote it once it has proven itself.

Step 5: Test on real work, then iterate

Run the skill on one real instance — an actual report, an actual meeting. Watch what it does: does it ask the right questions, pull from the right places, pause where it should?

It will not be perfect the first time. That is not a failure of the skill; it is how skills are built. Note what is off, adjust, and run it again. A useful habit while you refine: give the model more room to think when you are tuning the skill, and keep it light when you are just brainstorming ideas for it.

Most skills are a few iterations away from genuinely useful. The people who give up are usually the ones who expected version one to be finished.

What comes next

You have a working skill. The last part of this series is the one that separates a skill you can rely on from one that quietly causes problems: owning the output, validating it, and knowing why a skill is never truly "done."

Next in this series: Part 5 — Own it, don't trust it