Skills, or: How to Build Qualitative Automations

The last article in this series ended on a single word: skills.

Once your project stays clean and your knowledge layer compounds, the next move is building the actions that work against that setup — the repeatable patterns that let you operate inside your own system without rewriting them every time. That's what skills are for.

What skills actually are

I think of skills as qualitative automations. Traditional automation is rule-based — if this, then this. Conditionals, regex, deterministic flows. A skill is something different. It's a reasoning framework Claude can apply to a class of situations. It doesn't tell Claude what to do. It tells Claude what to think about, what to notice, what good looks like, what to avoid. Claude does the rest.

Repeatability of judgement, not repeatability of action.

That's also what separates a skill from a template, which is the thing most people imagine when they hear the word. A template gives you the same output every time — feed in slightly different inputs, get back a structured response in a predictable shape. Templates work brilliantly for work where the form matters more than the judgement (i.e. a contract). You should have plenty of them.

But most of the work I actually want to repeat doesn't look like that. Drafting a response to a prospect's email shifts depending on the industry, where they sit in their buying process, what we discussed in the last call, what their politics look like. There's no fixed shape to capture, because the shape is exactly what changes from one instance to the next.

A skill works where a template can't because it's built to bend. Call it seventy percent of the consistency you'd want, with the remaining thirty percent shaped by the situation in front of you. Templates can't bend. Skills are built to.

The anatomy of a skill

Before I get to the part about how skills actually become useful, it's worth being concrete about what one looks like as a file.

A skill at its simplest is a single markdown file — SKILL.md — that lives somewhere Claude can read (usually in Customise > Skills). The file has a few standard ingredients. There's a trigger description at the top, which tells Claude when to activate the skill — usually a paragraph describing the kinds of requests it covers, the phrases that should set it off, and any conditions that should stop it from triggering. Below that, the body of the skill: principles, the steps you'd walk through, anti-patterns, examples, anything that captures how you'd think about the work.

For a simple skill, that's the whole thing. A few hundred lines of markdown, a clear trigger, and you're done.

But skills can get more interesting once you realise the SKILL.md file doesn't have to be the only thing in the room. You can put it in a folder, and that folder can hold supporting material the skill draws on when it runs.

The clearest example from my own setup is a skill I built for generating Lituus-branded documents — proposals, one-pagers, orientation documents, service menus. The folder structure looks something like this:

text
lituus-doc-gen/
├── SKILL.md
├── brand/
│   ├── brand-context.md
│   ├── colours-and-typography.md
│   ├── consulting-services.md
│   └── logos/
└── examples/
    ├── example-proposal.docx
    ├── example-orientation.html
    ├── example-service-menu.html
    └── (a dozen more)

The SKILL.md file is the brain. It tells Claude what kind of document it's making, the structure each format follows, the voice rules, the failure modes to avoid. When the skill runs, Claude reads the SKILL.md first, then pulls in whatever it needs from the supporting folders — brand context for the visual styling, the right example file for the format I've asked for, the consulting services list for whatever I'm proposing.

This nested structure is what unlocks more sophisticated work. The SKILL.md stays focused on how to think about the task. The supporting folders hold reference material — brand assets, worked examples, templates, anything that would otherwise have to be re-explained or re-uploaded every time. The skill becomes a small library that knows how to use itself.

Skills get good through use

If you sit down to build your first skill carefully, here's what tends to happen. You start by workshopping it with Claude. Maybe you ask Claude if there are other cases to consider. It suggests a few, you discuss and agree, Claude folds them in. Claude asks about anti-patterns. You list some. Claude prompts you for edge cases. You find more. Each suggestion is reasonable. Each one makes the skill more thorough. By the time you stop, you've got a long, careful document that looks rigorous and feels finished.

Then you run it twice, notice things that don't quite work, and stop using it. The skill sits in the folder being slightly wrong forever.

The reason it doesn't work is structural. Generative AI is a new domain for most of us, and it's evolving constantly. We can't really predict how a skill is going to land before we run it. The shape of the thing only becomes clear through using it. A skill written carefully up front is full of assumptions you haven't tested yet — about what Claude actually needs to know, about which steps matter, about which anti-patterns are real and which only sound like they should be. Some of those assumptions are right. A lot of them aren't.

There's a development principle I've been carrying through everything I build with Claude Code: lag the architecture. The idea is that you don't design for an abstraction you haven't validated yet. You build the spine, then let real work sharpen it. With software, encoding structure ahead of validated understanding creates waste — and usually forces you to undo and rebuild later. With skills, the same logic applies. The first version of a skill should be deliberately under-engineered. Trigger conditions, the rough shape of what you're trying to do, two or three things you've already noticed matter. That's enough.

Then you use it. The using is what teaches you what the skill should actually be.

Be careful of constraints

There's a wrinkle in this loop worth flagging, because it cost me about a fortnight of mild frustration before I figured out what was happening.

When you tell Claude how something should work, it holds you to it. That's what's great about the tool. It's also, sometimes, what's annoying about it.

Two months ago, I was scoping my first prospective client engagement. They told me they'd already done a lot of discovery work and weren't keen to do more. A mentor suggested this: take the word discovery out of your vocabulary for this conversation. Use diagnostic. Use immersion. Anything that doesn't sound like asking them to repeat work they've already done.

It was good advice for that client. So at the end of the session I asked Claude to update my sales skill to reflect what I'd learned, and it codified the rule cleanly: Louis never uses the word "discovery" in client-facing communications. Use diagnostic, scoping, or immersion instead.

The problem started a week later, when I was talking to a different prospect for whom discovery was the perfectly normal, expected word. Claude refused to use it. I'd write a draft, it would replace discovery with diagnostic. I'd correct it. It would replace discovery with scoping. I'd correct it again. I lost count somewhere around the eighth or ninth time. Honestly, I think it was about the thirteenth correction before I twigged what was happening — the skill is doing exactly what I told it to do, and the rule I told it to hold is wrong as a permanent rule.

So I swore at it (my fiancée finds my arguments with Claude very entertaining), opened the skill, took the rule out, and the problem went away.

The rule was right when I added it — for that specific engagement. It was wrong as a standing instruction. The only way to learn the difference was to run the skill against a different situation and watch where it broke.

Could careful thinking have caught it up front? Probably. But that's not how I tend to work at the moment given the pace AI enables. We move fast, let Claude codify things in the moment, and don't always have the bandwidth to pressure-test every rule against every future case. The pattern surfaced through use because that's the loop that fits the pace.

The architecture that makes it dynamic

The version of skills I've described so far — markdown file, maybe a folder of supporting material — is essentially static. You write the file, Claude reads it, that's the loop. You can edit the file later, but every improvement has to be a deliberate edit to the file itself. Most improvements never get made because the friction is too high. You notice something in a session, you mean to come back and update the skill, the day moves on, you forget. The compounding loop quietly stops compounding.

For the skills doing serious work, I needed something different. I wanted the knowledge inside the skill to be alive — readable fresh every session, updatable in the moment by either me or Claude, evolving across all the surfaces I work on rather than locked to one local file.

The move I made was to invert the structure. The local SKILL.md file isn't where the knowledge lives. It's a router. Around thirty lines. Trigger conditions, and a list of pages in my Notion knowledge base that should be fetched when the skill activates. The actual brain — the principles, the worked examples, the anti-patterns, the running log of what I've learned — lives in Notion, where it can be read fresh every time, updated in the moment, and referenced from any surface that has access to my knowledge base.

The router is static. The brain it points to is alive.

A spectrum of skills

The most discouraging thing about reading about anyone's skills system is feeling like you need to start where they are. You don't. The architecture is the same all the way down — trigger router pointing at a knowledge layer that compounds with use. The difference is depth of accumulated practice, not structural complexity.

A rough sense of what that spectrum looks like in my own setup:

You build the level-one skill first. The more sophisticated ones are what your simpler skills become after a hundred sessions and a real engagement that demands more.

Where this leaves you

Skills are qualitative automations. They encode how you'd think about a class of situations so Claude can reason against your framework instead of starting from a generic baseline. They're how you stop re-explaining yourself.

But the quality part is downstream of use. The artefact you write up front is scaffolding. The skill itself is what emerges through the loop — what you notice, what you log, what you correct, what you sharpen. You can't write a good skill on day one. What you can do is write one that earns the right to be good by day ten.

The move, if you're starting: pick one thing you do repeatedly that you keep re-explaining to Claude. Not the most ambitious thing you can think of. The most repeated thing. Write a skill for it that's deliberately, almost embarrassingly simple — trigger conditions, the rough shape, two or three things you've already noticed matter. Save it somewhere your projects can reach it.

Then use it. Run it. Notice the friction. Correct it as you go. After a couple of weeks you'll have something meaningfully better than what you would have written by thinking harder up front. After a few months you'll have a small set of skills that compound across how you work — and most of the value will come from skills you haven't written yet.