Field Notes #005 — There’s a small tax most people are paying every week and don’t notice, because it’s spread out across a hundred tiny moments. This is about the one move that cancels it. — Dakota

Here’s a question worth sitting with: how many times have you typed roughly the same instructions into an AI?

Not the exact same thing. The same shape. “Take this and turn it into that — keep it short, professional, here’s the format I like, oh and don’t forget to…” You type some version of that paragraph, you tweak it a little, and ten minutes later you’ve got what you wanted. Then next week the same job shows up and you type the paragraph again. Slightly different. You forget one of the rules. The output comes back a little off from last time. You fix it.

That’s the tax. It’s not big in any single moment. It’s that you’re paying it forever.

Fluid speech vs. solid systems

The way I think about it now is the difference between explaining a recipe out loud and handing someone a recipe card.

Explaining it out loud sounds like this: “Okay, mix the… well, get the eggs to soft peaks first, then fold — gently — and the oven should be hot, like, pretty hot, and don’t open the door, and how long was it again?” It works. You’ll probably get a soufflé. But it comes out a little different every time, and you have to be standing there narrating it.

The recipe card sounds like this:

Perfect Soufflé

Preheat oven to 375°F. Grease the ramekins.

Whisk egg whites to soft peaks. Fold into the base — gently.

Bake 15 minutes. Do not open the door.

Serve immediately.

Same knowledge. But now anyone can run it, it comes out the same every time, and nobody has to stand there narrating. That move — from fluid speech to a solid system — is the entire idea behind a Skill.

A Skill is just a saved set of instructions for a specific job that Claude runs on demand. Instead of typing the paragraph every time, you trigger the Skill. It already knows the steps, the tone, the tools, and the rules. It’s the recipe card, written once.

Prompt, CLAUDE.md, or Skill? The decision nobody teaches

Everyone explains how to build one of these. Almost nobody explains when it’s worth it. And that’s actually the only question that matters, because there are three places instructions can live and most people only ever use one of them.

The one-off prompt. You type it, it runs, it’s gone. Lives in the moment, costs you nothing to set up. Perfect for a unique task you’ll never repeat. Bad for anything recurring, because “lives in the moment” also means you re-type it every time.

The always-on instructions file (in Claude Code this is a file called CLAUDE.md — think of it as a standing brief the AI reads at the start of every session). Great for global rules: who you are, how you like things, broad context that should apply to everything. But here’s the catch nobody mentions — it’s always loaded. Every word you put in there is read on every single task, whether that task needs it or not. That’s constant weight. Stuff a hundred specialized procedures in there and you’re briefing the AI on how to write invoices while it’s trying to draft an email.

The Skill. This is the one people skip, and it’s the one that changes everything. A Skill loads only when you call it. Zero weight on every other task. It can be enormous and detailed — fifty steps, strict rules, specific formats — and it costs nothing until the moment you actually need it. Then it loads, runs, and gets out of the way.

That last property is the whole unlock. It means you can build dozens of heavy, specialized procedures without the AI getting slower or dumber at everything else. Each one sits on the shelf until called.

The triage test

So when do you actually build one? You don’t need a Skill for everything. Run it through three questions:

Is this a one-off? → Just prompt it. Done. Move on.
Will you repeat it (say, weekly or more)? → Now we’re interested.
Do the exact steps and the consistency actually matter? → If yes, build the Skill.

That’s it. Repeats often and the shape matters → build it. Anything else → just prompt. Most people get this backwards: they grind out the same paragraph by hand fifty times (should’ve been a Skill) while over-engineering setups for things they’ll do once (should’ve just prompted).

What’s actually inside one (no code required)

Here’s the part that surprises people: building a Skill takes zero code. You’re not programming. You’re filling in four plain-English blocks:

Inputs — what information needs to be handed over?
Steps, in order — what’s the exact sequence of actions?
Rules — what are the constraints, the tone, the things to never do?
Output shape — what does the finished product look like?

That’s the recipe card. Describe those four things in plain English and you have a Skill. (In Claude Code there’s even a helper that scaffolds the file for you — you just describe the job.)

Let me make this concrete with two easy ones.

Easy example #1: the Friday Recap

Every Friday I want a clean summary of the week — what got done, what’s stuck, what’s coming. Without a Skill, here’s the prompt I’d be re-typing every single Friday:

“Here are my rough notes from the week. Turn them into a recap. Keep it to five bullets max, plain language, no corporate filler. Lead with wins, then what’s blocked, then what’s next. Each blocked item needs a name next to it. Keep the whole thing under 150 words so I can paste it straight into an email.”

Every Friday. Same paragraph, slightly different, occasionally forgetting the “name next to blocked items” rule and getting a useless recap back.

As a Skill, that paragraph becomes a recipe card I write once:

Skill: Friday Recap

[Inputs]
- My rough notes from the week (pasted in, or a link to the notes doc)

[Steps in order]
1. Read the notes and pull out: wins, blockers, what's next.
2. Write a recap in that order — wins first, blockers second, next steps last.
3. For every blocker, attach the name of whoever owns it.

[Rules]
- Five bullets max. Plain language. No corporate filler.
- Under 150 words total.
- If a blocker has no owner listed, flag it instead of guessing.

[Output shape]
- An email-ready recap I can paste and send. Nothing else.

Now Friday sounds like: “run the Friday recap, here are my notes.” One line. It comes out the same shape every week, it never forgets the owner rule, and if I ever hand this off to someone else on the team, they get the exact same recap I would’ve written. The judgment I baked in once now runs forever.

Notice what happened: the long paragraph didn’t disappear — it got promoted. It moved from something I re-type to something the system holds.

Easy example #2: transcript → follow-up email

Here’s a second one, because it shows off a different part. After a call, I want a follow-up email drafted from the transcript. The job is always identical in shape, which is exactly the signal that it should be a Skill:

Skill: Call Follow-Up

[Inputs]
- The call transcript (or recording link)
- Who the email is going to

[Steps in order]
1. Pull the decisions made and the action items agreed to.
2. Draft a short follow-up email that restates them clearly.
3. List action items as "Owner — task — by when."

[Rules]
- Warm but brief. Under 150 words.
- Never invent a commitment that wasn't actually said on the call.
- Always end with one clear next step.

[Output shape]
- A ready-to-send email draft. Do NOT send it — show it to me first.

Look at the last rule. That one matters more than it looks.

Baking safety into the card

Anything that touches the real world — sending an email, posting something public, moving money, deploying a change — should never fire on its own. The fix is built right into the Skill: you tell it to draft and stop, or you set it so the Skill will only run when you call it by name. It won’t trigger off a casual sentence. You have to say the name on purpose.

That’s the quiet genius of writing the rules down. Safety isn’t a thing you have to remember in the moment and hope you catch — it’s baked into the card. The recap Skill is safe to let run loose. The follow-up Skill drafts and waits. The “send the invoice” Skill only moves when I say its name out loud. The behavior I want is written into the procedure itself, every time, whether I’m paying attention or not.

Why this compounds

One recipe card is a convenience. A shelf full of them is a different kind of thing.

Because Skills load only when called, there’s no ceiling. You can have a Friday recap, a call follow-up, a “turn this doc into a checklist,” a “draft the weekly numbers” — a dozen, two dozen — and none of them slow down the others or clutter the AI’s head. Each one is a job you figured out the right way to do exactly once, now available as a single word, forever, at basically zero marginal cost.

That’s the actual shift, and it’s got nothing to do with having a smarter AI. The model is the same model everyone else is using. The edge is that you sat down one time and wrote the work down — the steps, the tone, the rules, the format — in a form something else can run. Almost nobody does this. So almost everybody keeps being the recipe card: standing there, narrating the soufflé, every single time.

Try this

You don’t need to read another thing to start. Pick one task you do every week that always takes the same shape — the report, the recap, the same kind of email, the same cleanup. Write down its four blocks in plain English:

Inputs — what does it need?
Steps — what’s the exact order?
Rules — what are the constraints and the tone?
Output — what does “done” look like?

That’s a Skill. That’s the whole thing. The hard part was never the AI — it’s that nobody ever sits down for one afternoon and writes down how their own work actually runs. Do it once for one task. Then notice how it feels the next time that task comes around and all you have to say is its name.

If you build one — or you’ve already got a shelf of them — I’d genuinely like to hear what you put on yours. — Dakota · @xovionai