We used to publish article after article repeating the same steps by hand: pick a topic, check the facts, generate a cover, translate into 3 languages, publish. After making the same mistake twice, we turned the steps into a written rule. After making a new kind of mistake, we turned the rule into a gate: a step Verboo Code is not allowed to skip. That is a skill.
How do you turn a manual process into an agent skill?
Separate the standard from the flow. The standard is the document that says what a good result looks like: how to write a title, what a CTA is made of, which data needs a source. The flow is the skill Verboo Code actually runs: in what order, which tool to call, which gate to check before moving on. A skill `.md` file starts like this:
---
name: my-skill
description: What it does, and when to use it (Verboo Code reads this line to decide whether to trigger it)
---
# My Skill
## Step 1 - ...
## Step 2 - ...Keeping the two documents separate avoids a concrete problem: if the style rule changes every week and lives inside the skill, the whole skill needs rewriting every week. Kept apart, only the standard changes.
How do you know a skill is ready to run on its own?
It is not, just because it compiles. We tested by publishing real articles in production, one per flow type the skill covers, before letting it choose and publish with nobody watching over it. Only after that did we run it once from start to finish without guiding a single step, to see whether the written instructions were enough without us filling a gap on the spot.
In practice: the first time the skill ran alone, it picked a topic from the queue, verified a claim against a source the instructions did not even mention (a competitor's repository), and fixed that on its own. A sign the general rule ("never invent a command, read the source code") had been written too narrowly the first time.
What broke along the way, and how did it become a rule?
Every row below is a real mistake from one run that turned into a gate in the next version of the skill.
| Before | After | Why |
|---|---|---|
| Topic taxonomy hardcoded in the skill's text | Taxonomy lives only in the editorial queue file, the skill reads from there | The taxonomy changed and the skill kept reading the old one, out of sync |
| Product facts (version, price) written by hand in the skill | A script fetches the fact live before writing | A number typed by hand in a document nobody revisits goes stale and nobody notices |
| Generate the cover and upload it directly | Open the generated file and check the mascot's color before uploading | The image generator ignored the requested color in 2 of 3 attempts |
| Assume each translation's revision is independent | Re-read each language's revision immediately before publishing it | Publishing one translation bumps the others' revision on the same post, even untouched |
Does this pattern hold for any skill you build?
Yes, the 3 principles are not blog-specific. Keep the standard document outside the skill, so changing one does not force rewriting the other. Write an explicit gate for every real mistake found, never a generic rule like "be careful" that nobody can check. And run every rare branch at least once in production before trusting it unsupervised, because the rare branch is exactly what a first reading of the instructions tends to miss.
Testing a skill this way costs a long session, with heavy tool calling and translation repeated across 3 languages until it lands right. On Verboo Code that never turns into a cost decision: plans have no token cap, so the test session does not compete with the production one. Check it out at verboo.ai.
