The Prompt Log, No. 04: Why I Turned My Style Guide Into a Skill
A recurring feature on building Workforce Rewired with AI, in public, in real time.
TL;DR: I use AI to help write this newsletter, and I keep a document of writing rules it has to follow. Last time I said that document was the big win. It was, and it was not the last step. I turned the document into something called a skill, a helper the AI can pick up and run on its own. Here is what a skill is in plain terms, why it beats a document the AI only reads, and why I kept the document anyway.
Last time, I said the document was the win
I write this newsletter with help from AI, and I am open about it. To keep the writing sounding like me and not like a machine, I wrote down my rules: no dashes stuck in the middle of sentences, no corporate filler, name real people instead of a vague “everyone.” All of it went into one document. Before the AI writes a word for me, it reads that document.
In the last Prompt Log I called that document the thing that mattered most, and I stand by it. Writing your rules down once, in one place, beats retyping them every time you sit down to work. That document was a middle step, though. There was a better version above it, and it has a name.
What a skill actually is
Two pieces of jargon first, in plain terms.
A task is a job I set up once that the computer runs on a timer. Picture a recurring calendar reminder, except instead of nudging me, it does the work itself. One of mine writes a research briefing every morning at 7:31 while I am getting ready for the day.
A skill is a small helper I install once that knows how to do one specific job. Compare it to a plain document. A document is a rulebook on a shelf. For it to help, someone has to remember it is there, pull it down, read the whole thing, and apply it correctly. A skill is more like a referee. The referee already knows the rules and blows the whistle as the game goes, every time, without anyone asking them to go study the book first.
My writing rules used to be the rulebook. Now they are the referee. Same rules. One version sits there waiting to be read; the other one steps in and does the checking.
The three ways I have kept my rules
I got here in three steps, in order.
The first way is to type the rules into every job by hand. My morning briefing still works this way, and I will point out the mess it makes in a minute.
The second way is to write the rules in one document and tell each job to go read it. This is the step I bragged about last time. One copy, kept in one place. It felt like the finish line.
The third is the skill itself. Instead of telling a job to go read my rules, the job calls the skill by name. The skill already carries the rules and knows the checks: read the draft, hunt for the dashes, catch the filler, fix what is wrong, read it again. A document you have to read and a helper that does the reading for you are two different things, and the space between them is what this issue is about.
Why the referee beats the rulebook
A document sits still and waits. A skill acts. That gap showed up in four ways once I made the switch.
It actually does the checking. My document lists what to avoid. That is useful and completely passive. The AI still had to open it, read all of it, and figure out how to apply each rule to whatever I was writing. The skill carries the rules and the how-to together. It knows dashes are banned, and it goes looking for them and pulls them out.
You call it by name, so nothing breaks. A document only helps if the job knows the exact spot on the computer where the document is saved. Those directions are fragile. A few of mine still point to folders from old work sessions that are long gone, broken until something trips over them. A skill answers to its name, so there is no fragile address to get wrong. Any new job I build can use it right away.
The skill only opens when it is needed, which keeps it cheap. AI reads by the word, and reading costs money and time. A document that a job reads gets opened in full on every single run, start to finish, whether the job needs all of it or not. Mine started at six lines and grew into a full guide plus a checklist, and every job that read it paid for the whole thing every time. A skill keeps only a one-line summary of itself on hand and opens the full instructions when it is actually used. Same rules, a fraction of the cost. The bigger the guide gets, the more that matters.
And it does not get tired on a long day. Buried instructions get skimmed. When a job is long and I have asked for a dozen things, “oh, and also read this file and follow it” is the part that slips. A referee does not skim. It runs the same checks whether it is the first job of the morning or the last thing before I hit send.
All three still live in my files
I can show you all three steps, because they are all sitting in my task folder right now.
The morning briefing is step one. Part of it still spells out my writing rules by hand, right there in the job. When I sharpen a rule somewhere else, the briefing keeps its old copy until I remember to go fix that one spot myself.
My weekly-article job is step three. The writing check is a single line: call the skill. Tucked under that line is a backup plan, in case the skill is ever unavailable: go read the document by hand instead. That backup is step two, kept as a spare. It is a fossil of the days when reading the document was the whole plan.
The document and the skill are partners
Turning my document into a skill surprised me in one way. It did not throw the document away. The skill reads it.
When my writing referee runs, the first thing it does is open my rules document and treat it as the boss. The document still holds the rules. The skill is the thing that carries them out, every time, on time, whether I am there or not. I still change one document to change a rule. The skill is how that change actually reaches the page without me carrying it there by hand. The rulebook and the referee are different jobs, and I needed both.
Here’s how you take action
If you use AI for anything you do more than once, here is the path, in order.
Get your rules out of your head and into one document. If you keep retyping the same instructions every time, stop, and put them in a single file you can point to. This alone is a big step, even if you never go further. For how to set up your core instructions and tasks in the first place, look back at my earlier Prompt Log on building the system.
Notice what you have written down twice. Any instruction you have typed into more than one place is ready to become a skill. Two copies is the warning sign, because two copies is where they start to drift apart.
Turn the document into a skill when it is really a set of steps. Tell Claude what skill you want to build and have it interview you for all the details. A list of do’s and don’ts can live in a document. A process, an actual set of checks you run against your work, wants to be a skill, because a skill carries out the steps for you.
Keep the document. The skill reads it and leaves it in place. Keep one clean copy of your rules, and let the skill be the thing that carries that copy into everything you make.
The machine repeats itself perfectly, which is both the gift and the trap. It will run whatever I give it a thousand times without complaint, the good rules and the stale ones alike. My job is no longer writing the instructions over and over. It is keeping one clean copy of them and choosing the helper that runs it. The tools do the running. I decide what the rules say.
The Prompt Log is a recurring feature of Workforce Rewired. Published when there’s something honest to say about the process. If you’re moving your own rules from a document into something that runs them, I’d like to hear what broke first: christina@workforcerewired.co