Version 1 of my brand blueprint skill missed positioning gaps I could catch in 30 seconds by reading the draft.
Version 14 catches gaps I miss. That took about a year, and honestly most of it was me learning what a skill is for, not learning the tool.
People ask how long it takes to build an AI skill. About a week for the first version, in my experience. The real question is how long it takes to build one that holds up, and that answer is 14 versions. So here is what each stretch of the changelog taught me, because the lessons are more useful than the file.
TLDR
- Version 1 of any skill will be a long prompt in disguise. That is fine. Ship it and let it fail.
- The middle versions are where every failure becomes a rule. That is progress right up until the rules outnumber the judgment.
- My rulebook peaked at 285 rows. The output peaked earlier.
- The last 4 versions took rules out and put approved examples in. That is where it started catching what I couldn't.
- Nothing about this was fast, and I don't think it should have been.
Version 1 Took a Week and Missed the Obvious
The first one was, if I'm honest, a very long prompt with a job description on top. Read the intake, write the blueprint, follow this structure, sound like this.
It took about a week because I kept running it, reading the output, and adding a sentence to fix whatever I saw. By the end of the week the output was passable. Passable is what got me into this, actually. The custom GPTs I inherited were passable too. I've written about that moment in why proof of work beats credentials. Passable is where most coaches and consultants stop, because passable feels like it worked.
What version 1 could not do was notice a positioning gap. It would write a confident brand purpose for a restaurant that conceded the market was crowded and then never named what made this one different. I could see it instantly. The skill could not, because I hadn't told it what a gap looked like. I'd only told it what a blueprint looked like.
Versions 2 to 6: Every Failure Became a Rule
This is the stretch that felt most productive, and it was productive, up to a point.
The method was simple. A draft came back wrong. I wrote down why. The why became a rule in the skill. Next draft, that failure was gone. My email skill went through the exact same arc and is on version 6 today, and I mean it when I say versions 1 through 5 were not waste. Each failure became a permanent rule. I've written about why revision notes should become rules, not tickets, and this is the phase where I learned that the hard way.
Around version 4 I added the first anti-patterns. Not "do this" but "here is a real paragraph that got rejected, and here is why." That single change did more than the previous 3 versions combined. Models are good at "not like that" when you show them the "that."
By version 6 the skill was catching most of what I had already caught once. Which sounds like the goal. It isn't. It means the skill was exactly as good as my worst past mistakes, and no better.
Versions 7 to 10: The Rulebook Ate the Skill
Here is where it went sideways, and I didn't notice for months.
Every client ruling got appended. Nothing got reconciled. The rules registry started at 108 rows and grew to 285. Banned words, fixed shapes, character caps, section order, a checklist for every section. The skill file read like a compliance document.
And the output got worse. Not dramatically. Just flatter. Copy that satisfied every rule and made nobody want to eat at the restaurant. My read, after enough of those: the longer the skill and the more rules it carries, the worse the output. Rules train checklist thinking, and checklist thinking produces checklist writing.
There was a second problem hiding in there. Giving the model a word count is a big reason its output bloats. It treats the number as the requirement instead of the ceiling, and pads to hit it. A coach I work with put it plainly when a report I built for him grew to almost 20 pages: half of it was fluff, and no one was going to read all of it.
Version 10 was the biggest skill file I've ever written and I'd be embarrassed to show it to you.
Versions 11 to 14: Fewer Rules, Better Examples
The rebuild started with a question I should have asked at version 2: which of these 285 rules actually changed an output?
Most didn't. So I compressed the whole registry into 12 pages. Then I did something that felt backwards. I put 5 approved documents above the 12 pages. Real client work, approved and shipped, with the comments still on it. The rule now reads that where the examples and the rulebook disagree, the examples win.
Anything a script could check faster than me came out of the file entirely. Character counts became a script that prints ALL PASS or lists the failures. The page container became a template. What stayed in the skill was 3 questions the draft gets read back through, and honestly those 3 questions do more than the 285 rows ever did.
Version 14 is the first one that caught a gap I had missed. A brand purpose section that read fine on its own and, next to the approved examples, was clearly the generic version of a move 25 out of 37 past documents had already made. I hadn't seen it. The examples had.
What 14 Versions Actually Taught Me
A few things, and I'll keep them short because I think the changelog already made the argument.
- The first version should be fast and bad. A week is fine. Perfectionism at version 1 is how people never ship version 2.
- Rules are how you stop repeating mistakes. Examples are how you start exceeding yourself. You need both, and the ratio should tilt toward examples over time.
- If the file is growing every month, something is wrong. A healthy skill gets shorter as the scripts around it get longer.
- Version numbers are honest in a way that "it works now" is not. Keep them.
I don't think a coach or consultant needs 14 versions. I needed 14 because I was learning what the thing was while building it. You get to start at roughly version 8, because the shape is known now. That is genuinely the whole reason I write these.
If you've made it this far and you're still opening a blank chat window and typing "write me a post," I can't help you.
Just kidding. That's exactly who I built this for. Send me 1 piece of your work and you'll get a finished asset back in your voice within 48 hours, produced by a skill that has already made its 14 mistakes so yours doesn't have to.
FAQs about iterating AI skills
How long does it take to build an AI skill?
About a week for a first version that produces passable output, based on the 50+ I have built. A version that catches things you would miss yourself takes months of iteration, because the reference library and verification loop only get good by absorbing real failures.
How do I know when a skill is done?
It is never done, but it is stable when 2 things are true: it passes your folder of known-bad inputs, and a month of client feedback produces no new rules. If you are still adding rules every week, it is not stable yet.
Why did adding more rules make the output worse?
Rules push a model toward compliance rather than judgment. Past a certain point the draft satisfies every constraint and loses the quality none of the constraints describe. Approved examples carry that quality. Scripts carry the mechanical checks. The skill file should hold only what needs judgment.
Should I keep old versions of a skill?
Yes. Keep every version and the input that broke it. When a new version ships, run the old failures through it first. Version history is the cheapest form of quality control you own.