Claude Code Skills: A Field Report

Quick story. I wrote twelve blog posts with Claude. I was happy. Then I went back through them and... well. Ten out of twelve had the same issues. Bold subheads in front of bullet lists everywhere. Three-item groups at the end of every sentence. And at least once per post: "it's important to note".

The thing is, I had told Claude every time. Don't do this. Stop that. He did stop. But the next session? All of it back. Because every conversation starts at zero. No memory. No learning.

Imagine working with someone who is very good, but every morning has completely forgotten what you discussed yesterday. That's what working with an AI assistant is like. Starting over every day.

At some point I stopped getting annoyed about it. Instead I asked myself: what if I could write my corrections down once and have them just... apply from then on? Not as a system prompt I paste into every session. Not as a CLAUDE.md that eventually gets so long nothing lands anymore.

But as something separate. Something that kicks in automatically when it fits.

The answer: Skills.

What a skill is (and what it isn't)

A skill is, put simply, a Markdown file. With a bit of YAML on top. That sounds unspectacular at first, but here's the trick: you don't invoke a skill. Claude recognizes when one is relevant and loads it.

How does that work? At the top of the YAML there's a description. It doesn't describe what the skill does, but when it should kick in. Claude uses that like a search index. Does the current task match? Skill loads.

---
name: humanizer
description: |
  Detect and remove signs of AI-generated text.
  Use this skill when editing or reviewing text.
---

Below that, normal Markdown. Rules, examples, patterns. Whatever Claude needs to know.

My first skill was the humanizer. 24 patterns of AI-generated text, each with detection rules and before-after examples. "Strip participial constructions." "No rule of three." "If the text contains 'in summary', delete the whole paragraph."

And you know what? It worked. The problem was gone. I didn't have to recite the same corrections every session anymore. They were codified. Claude just applied them.

Not perfect, of course. No skill makes an assistant error-free. But the constant repetition was over.

From a single skill to a whole ecosystem

A single skill is nice. It gets really good when you start thinking in systems. I work with three layers now (and yes, this developed over weeks, not in one afternoon):

First: my own skills. The humanizer for text. A thumbnail generator that builds blog images for me from the command line. 14 SEO skills covering everything Google and AI search engines care about.

Second: process skills. These come from the Superpowers plugin and govern how Claude works. First brainstorming, then a plan, then test-driven development (TDD), then verification. The brainstorming has a hard gate built in. Claude cannot write code before a design exists. Not "shouldn't". Can't. (Okay, technically he could, but he'd have to actively break the rule, and he doesn't.)

Third: community plugins. Skills other people wrote. You install them with one command.

Where this gets really impressive: my SEO setup. I have one skill that fires off six agents in parallel. One checks the technical side, one the content, one the schema markup, one the images, one the AI search optimization, one the sitemap. Twelve skills, one command.

But it isn't perfect. Honestly. I ran the SEO audit on my own site. Some things were right. Some were wrong. And a few things I would have spotted immediately as an SEO person, it missed entirely. Without my expertise, I couldn't have told the right calls from the noise.

Skills make you better at what you already know. If you have no clue about SEO, no SEO skill will save you.

Testing documentation (yes, like code)

Okay, here comes the part that fascinates me most. Sounds odd at first: can you test documentation? Like software?

Yes. You can. The Superpowers framework does exactly that. The idea: first show something is broken. Then show the fix works. Then close the loopholes.

Step one: build a stress scenario. Time pressure, sunk costs, the full program. Then let an agent work the task without the skill. What happens? It skips steps, claims it's done, ships half-baked work. As expected.

Step two: add the skill. Same scenario. Suddenly the agent follows the process. Writes tests before code. Submits designs before implementing.

Step three: look at the excuses the agent invents to bypass the skill. "This is too simple for a design." "I need more context first." Then make those excuses explicitly impossible in the skill.

The Superpowers framework has rationalization tables for this. No joke. Every skill contains a table that maps agent excuses to reality:

| Thought | Reality | | --- | --- | | "It's just a simple question" | Questions are tasks. Check for skills. | | "I need more context first" | Skills tell you HOW to gather context. | | "The skill is overkill" | Simple things become complex. Use it. | | "I'm just doing this one quick thing" | Check BEFORE you do anything. |

So the system tests its own rules with the same methods it tries to enforce. Sounds more complicated than it is: if you want a specific behavior, you write it down, test it, and close the loopholes.

What changed

What does this give me concretely? I don't repeat myself anymore. When Claude gets something wrong, I write it down once and from the next session on it's in. Sounds banal. But once you've corrected twelve articles after the fact, you know what that's worth.

The whole thing isn't perfect. Skills are still just text Claude can ignore. That rarely happens, but it's possible, especially when there are conflicting instructions. My SEO audit missed a few things I would have caught immediately as a pro. That shows the limit.

But the direction is right. I write a correction, and it sticks. Not just today, but next week and beyond.