People ask me sometimes whether I actually write these posts myself. The honest answer is: yes and no. I write the ideas. I define the voice. I review every draft before it goes live. I built the schedule — 48-plus posts covering specific angles on specific topics. But the production work — the actual writing, formatting, publishing, and social media messages — runs on AI.
I wanted to explain how, because I think it's one of the more practical examples of AI automation I've seen. Not a polished demo. Not a product pitch. Just a real workflow I built for myself, running on two AI "skills" that handle the heavy lifting from idea to published post. You're reading something that was generated exactly this way.
What a skill actually is
Before I get into what the skills do, let me explain what I mean by the word. A skill is a set of standing instructions given to an AI assistant. Instead of explaining what you want every single time, you write the instructions once, save them as a file, and from that point on the AI reads those instructions before starting any work. It's like a detailed checklist that a trained employee would follow — except the employee is Claude, and it pulls up the checklist itself.
The blog has two of them. One writes posts. One publishes them. They're separate by design, because writing and publishing are different jobs with different failure modes. You want a draft to exist and be reviewed before anything gets uploaded to the internet.
The skill that writes posts
When I say something like "write the next blog post," the generator skill kicks in. The first thing it does is check whether I've pasted in notes or a draft alongside my request. If I have, it uses my content as the primary source material instead of working from scratch. This post was generated that way — I wrote a detailed document explaining the two skills, the AI read it, and built the article around it.
If I haven't pasted anything, it goes to the content calendar. There's a spreadsheet tracking every planned post: the topic, the post type, the target publish date, and a short brief on what to cover. The skill finds the first entry in line that hasn't been written yet and pulls all those details.
The blog has four distinct post formats — a short concept explainer, a step-by-step walkthrough, a personal take with honest caveats, and a news-explained-fast format. Each one has a different structure and purpose. The skill picks the right format automatically based on what's in the schedule, then reads the matching HTML template.
Before it writes a single word, it reads a style guide. That guide defines my voice, lists specific words that are never allowed (things that read unmistakably as AI-generated — "delve," "tapestry," "crucial," "groundbreaking," "serves as"), and describes structural patterns to avoid: using exactly three examples because it sounds balanced, cycling through synonyms to avoid repeating a word, opening with "It's worth noting that." These patterns are everywhere in AI-generated text. The guide exists to stop them from showing up here.
Then it writes the full article. Not just the words — the complete web page. Headlines, page structure, search engine meta tags, estimated reading time, author information, and the publish date. Everything the page needs to go live. Once the draft is saved, the spreadsheet is updated automatically: the post moves from "Queued" to "Drafted."
The skill doesn't decide what to write about. The ideas, the angles, the voice rules — all of that came from me. The AI executes the brief. I write the brief.
The skill that publishes them
When I say something like "deploy post 49," the deployer takes a finished, reviewed post and puts it on the internet. The first thing it does is check that two files exist: the article and a featured image. The image is the one part I handle manually — I create it before running the deploy. If either file is missing, the skill stops and tells me what's missing.
When both files are present, the deployer copies them to the web server. The website runs on a machine in my home lab. The skill transfers the files securely to the right folder on that server. Think of it like copying files to a shared drive that the website reads from — except it knows the exact path, the exact server address, and the exact transfer method, so I never have to look any of that up.
After the transfer, it checks the live URL to confirm the page actually loads. Quick sanity check: did everything land where it was supposed to? Then it updates the spreadsheet one more time: the post moves from "Drafted" to "Published."
The last thing it does is write 10 social media messages — each in my voice, each taking a different angle on the same article. One might be a single direct statement. Another might open with a story. Another might challenge an assumption the reader probably holds. I read through all 10 and pick the one that fits the moment, then post it with a link.
That last part might sound like a minor convenience, but writing a single social hook from scratch after an already-long production day is exactly where blog consistency breaks down for most people. Staring at a blank text box trying to be clever after you've just finished an 800-word article is not a fun experience. Having 10 options to choose from takes that friction down to almost nothing.
You don't need a full blog automation pipeline to try this concept. Pick one repetitive task you do the same way every time — a weekly report, a meeting summary, a status update. Write down every step it involves. That document is basically a skill prompt. Paste it into Claude with "Follow these instructions:" at the top and see how far it gets you on the first try. The polish comes later; what you're testing is whether the concept works.
How the two skills connect
The generator saves its output to a specific folder with a predictable filename — something like post-49-how-this-blog-works.html. The deployer knows to look in that exact folder. The content calendar ties them together: the generator marks a post "Drafted," the deployer finds it, publishes it, and marks it "Published." Nothing gets lost between steps because there's a defined handoff.
From my end, the complete workflow looks like this: say "write the next blog post," read the draft, make any edits, create the featured image. Then say "deploy this," pick a social hook, post it.
For a blog that publishes several times a week, that compression is the difference between something that actually ships and something that accumulates as drafts. I've had plenty of "I'll write that later" drafts in my life. Having the production work handled automatically changes the math on what "later" costs.
The honest take
I want to be clear about what this is and what it isn't.
The generator doesn't come up with ideas. Every entry in that spreadsheet — 48-plus posts, each with a specific topic, a specific format, and a specific angle — I wrote. I decided which topics my audience needs to understand, in what order, at what depth. The AI didn't land on "AI for the rest of us" as a positioning. It didn't figure out that most AI content is either too technical or too breathless. Those decisions came from me, and they shape everything downstream.
The voice rules in the style guide exist because AI left to its own defaults does not sound like me. Every word on the banned list showed up in early drafts before I caught it and added it to the list. Getting the posts to sound like a real person — like me specifically — took real iteration. I wasn't just writing instructions; I was debugging them over weeks, reading drafts carefully and figuring out where the tells were sneaking in.
I still read every draft before it goes live. I catch things the skill misses: a sentence that sounds off, a section that buries the most interesting point, an analogy that almost lands but doesn't quite. My edits have gotten shorter as the instructions have gotten better, but I haven't published a post I didn't touch. The skill is good enough that I spend maybe 15 minutes on a draft instead of two hours. That's a meaningful difference, but it's not zero.
What I'm doing isn't replacing judgment with automation. I'm using automation to get my judgment in front of readers more consistently.
Why I'm telling you this
Not to impress you with the tech. I'm sharing it because I think most people have no idea what AI automation actually looks like when someone builds it for real. Not a TED talk, not a LinkedIn post about "the future of work" — just a thing someone made to solve a real problem they had.
The problem I had was simple: I had things to say, but the production work kept getting in the way. Formatting a web page, transferring files to a server, writing the same kind of post header for the fifteenth time, staring at a blank social post — none of that is where my thinking goes. It's just friction between an idea and a reader.
Building the skills took real time upfront. Writing the instructions, testing them, fixing what broke, building the schedule, figuring out the voice rules. That work existed whether I did it once or a hundred times. Doing it once and encoding it permanently is just a better deal.
If you've been using AI as a search box — type a question, get an answer, close the tab — this is what it looks like when you take the next step. You stop asking it things and start giving it jobs. The jobs it's good at are narrow and repetitive: follow this process, fill in these fields, check this URL, write 10 variations of this message. Give it clear instructions and a defined task, and it does that task the same way every time without getting tired of it.
That's not magic. It's just a better checklist.
