Installing a skill takes one command. Your agent picks up a new trick, and you move on.
I install other people's skills all the time, and I've written plenty of Builder's. But a skill you install and never change is someone else's taste, frozen on the day they wrote it. The skills that make me better at my job are the ones I keep rewriting.
If you haven't used them yet, a skill is a folder of instructions, usually one Markdown file, that your agent loads when a task calls for it. My post on agent skills, rules, and commands covers the mechanics.
My skills kept getting worse
A while back I wrote a skill that helps me draft Builder articles. It handles the research, a rough first draft, the diagrams, ideas for the hero image, and the publishing steps, and I rewrite by hand from there. The first run was decent. I edited the draft, published it, and felt great about how much busywork it took off my plate.
The next week I ran it again, read the result, and thought: this isn't good enough. The skill must be broken.
The skill hadn't changed. I had. That's how it got worse: by not moving at all. A week of writing, editing, and getting feedback had moved my bar, and the skill was still sitting where I'd left it.
I'd built it for automation, and automation assumes the target holds still. Mine moves every time I learn something. So when a skill starts to look bad, I now read that as news about me: I grew, and the skill hasn't caught up yet.
Squiggly lines only an AI could love
I have a diagrams skill that draws figures in code, with a separate style for each place I publish. The Builder style makes figures in Excalidraw, the open-source whiteboard with the hand-drawn look. I was happy with them.
Then I showed one to Apoorva, Builder's brand and creative designer, who draws a lot of the hero images on this blog. She said the lines were pretty squiggly for a smart AI. She asked me to calm the squiggle down, go a bit thicker on the lines, and use more icons from Tabler, an open-source icon set.
Right away, my skill was deficient. That's great news. It means I'd just learned three things about drawing, and all three were specific enough to write down.
So I tried putting all three in the skill. Tabler's robot went in right away. The lines took longer. I tried three steps toward steadier, thicker strokes, and every one made my diagrams look chunky. Side by side, I could see the problem was narrower than the line itself: the one thing the picture was about, the agent, wasn't bold enough. So the skill now draws a cover's subject heavier than everything around it and leaves every other line alone. Here's an excerpt of what changed in the skill:
Then I reran the same figure from the same input.
I hadn't noticed how timid my agent looked until someone with a trained eye pointed at it. Now I look for it. I've already promised Apoorva my next diagram for another critique. Encoding our newfound knowledge into skills is how we keep raising the bar, even when everyone else already has AI superpowers.
Hand edits are gold
I don't make much purely by hand anymore. The agent drafts, and I steer. But after the agent reaches its limits, I still jump in and rewrite a few sentences and nudge some lines.
Those edits are the most valuable things I make, because each one marks a decision the skill couldn't make yet. With your own edits, I recommend you:
- Save the output before you touch it.
- Edit it by hand, and save the result. Now you have a before and an after from one input.
- Ask what your edit knows that the skill doesn't. Have the agent compare the two versions and name the difference in plain words, then add that to the skill.
- Rerun the skill on the original input. If the new output lands near your edit, the skill learned it. If not, the rule is still too fuzzy. So, rinse and repeat.
Without step four, you're only collecting opinions. Anyone can write "make it punchier" into a skill. Rerunning the same input tells you whether the skill learned the specific thing you did. Each rerun also becomes a checkpoint, a record of where your taste was that day. If your skills live in Git, every old version is still there, so you can run last month's skill and today's on the same input and compare. An agent can run that comparison for you, but you pick the winner, since it's your taste you're tracking. I hate starting over, and this way I don't have to.
For writing, I do all of this in Agent-Native Content, because I want to see exactly what my agent is doing to my words. It's free and open source, and I work on it every day as I learn to write and engineer better. For each draft, I decide whether the agent leaves comments, proposes suggested edits I accept or reject one at a time, or applies changes directly. I make my own hand edits as suggestions too, so the agent can read the before and after of every change I make.
When we launched our article on agent loops a small model can finish, my agent drafted the X post and I approved it. Then, right before posting, I rewrote it anyway:
- The opening question, "Are you paying for your biggest model on jobs a cheap one could finish?", became a claim: "Cheaper AI models can do waaaay more than you think. You're probably overpaying for your tokens."
- "One of OpenAI's smaller models" became "GPT Luna."
- "By our rough estimate" disappeared, and the price got its own line.
My agent's notes said a question makes a good opener. My edit added three things the notes didn't know yet: a blunt claim works too, naming the model beats describing it, and a number needs one hedge at most. All three now live in the notes my agent reads before it writes launch copy.
Teach how you decide
Write "open with a blunt claim" into a skill, and every launch post after that opens with a blunt claim. Agents take named examples literally. And a skill that piles up every lesson gets long, until the agent applies whichever rules it happens to notice.
So I try not to teach my agent "do this every time." I teach it how I'd make the decision. My diagrams skill learned to find the one thing a cover is about and give that the weight. The main file holds the decisions every figure shares, and each place I publish gets its own style file, so the agent only reads the one it needs. I can keep adding what I learn without bloating every conversation.
Your library teaches you your own taste
Keep doing this and you start learning what your taste actually is, in words precise enough for a machine to follow.
For a long time, AI slop code was just a feeling. I knew it when I saw it, but I couldn't say why until I wrote about how to de-slop an AI-generated codebase. Lately I've been reading through the tests in the Agent-Native codebase, and one kind kept showing up: a test that opens a source file as plain text and checks that some string appears in it. It passes when the feature is broken, and it fails when someone renames a variable. My own recent PRs had 186 of them across 42 files.
"Sloppy tests" was a feeling. "A test may not read a source file as text" is a rule a machine can check. In code, we can do even better than skills: we can lint our opinions. A guard now fails any branch that adds one of those tests, so my agents can't write another one, and neither can I.
I don't expect to go back to making everything by hand. Getting better at making things through AI is the new handmade, and a skill library you keep improving is where your hand shows.
The only model that keeps learning
We have a chance to learn more right now than ever. Daniel Miessler, the security researcher who created the open-source AI framework Fabric, noticed this recently: "I know way more about end-to-end development processes and infrastructure and a million other technical topics than I did before AI." He edits far less code than he used to, but he makes far more design decisions, and every one exposes him to more technology.
Our agents don't get that chance. Every new conversation starts from the same checkpoint, and it stays there until a new model ships. When one does, it shows up as a stranger. If what we learn stays in our heads, the agent never benefits. Skills are how it catches up.
That makes a new model a good time to audit your skills. You don't have to switch the day it launches. (Slower deprecations are one perk of open models.) When you're ready, run the same inputs through your skills on both models and decide which outputs you like better. Or ask the new model which it prefers and why, and notice whether you agree. Ask it where your skills fall short, too.
It's easy to feel like a slab of meat that juggles prompts. But we're the only model in the loop that can change in the middle of a conversation, and each of us has an edge the models don't: the niche we've chosen to go deep in.
And now there's an open standard for skills, so we can share that edge. Giving away hard-won knowledge sounds backwards, but open source has always worked that way. If you keep learning, it doesn't much matter who has your old checkpoints. You've already moved past them.
Install skills, then metabolize them
So what about all the cool skills you see on X? I still install them. I just don't stop there. Builder keeps a public skills repo with skills such as comparing competing plans, checking the docs before guessing, recapping a diff visually, and turning a skill into a small app you can see and click around in. Install them and use them on real work:
Then read them. Each one is someone else's checkpoint, the decisions they reached after their own rounds of edits. When you catch yourself fixing what a skill gives you, you've found the spot where their taste and yours split. Use it:
- Save the output and your fix, same as with your own skills.
- Ask what your fix knows that their instructions don't.
- Rewrite the skill in your own words, in your own library. Keep what held up on your work, and cut what didn't.
This is metabolizing a skill. You take it in, break it down, and keep what your work can use.
The skill can't notice for you
AI is all brain, no body. No gut instinct. Once someone writes a rule down, it'll follow that rule about line weight or test files every time. It can't look at a figure and feel that the line is too squiggly for a smart AI.
Apoorva noticed that. Then I did. Then the skill learned it.
That order doesn't change. The skill can learn what you noticed, but you still have to be the one who notices. So save the before, make the edit, teach the skill, and go notice the next thing.
The noticing is what keeps us human.
