How I Set Up a Simple Blog Workflow with OpenClaw

I’ve been spending more time trying to properly understand OpenClaw and find real ways to use AI that actually fit how I work. One of the first things I wanted to do was build out a blog workflow around it.

Not in the fully hands-off, “AI posts directly to the site” sense. I’m not that interested in that. I wanted something a bit more useful than that, and a bit more controlled too.

The blog itself is deliberately simple. It was built with Codex, using Eleventy, with posts stored as markdown files. That part matters, but only because it gives me a lightweight base to work from. The more interesting part is what happens around the writing process itself.

Once the site was in place, the next step was working out how I actually wanted to use OpenClaw as part of writing and publishing. That mattered more than I expected.

It would have been easy to just tell Codsworth (my name for my OpenClaw) to write posts and drop them straight into the site, but that didn’t feel like the right setup. It saves time, but it also removes a layer of intention from the process, and I didn’t want that. So instead, I spent some time talking through the workflow first.

What I’ve ended up with is something that feels practical enough to use, while still keeping me in control of what gets published. The rough flow now is that I send over an idea, Codsworth asks follow-up questions if needed, and then I get back a rough direction for the article before any full draft gets written.

That early step is useful because it gives me a chance to steer the piece before too much time gets spent on it. I can agree with the angle, change the emphasis, or push it in a different direction if needed. Once I’m happy with that, the full post gets written in my own tone of voice, in markdown, for the site.

After that, it still doesn’t go straight live. The draft goes onto a separate branch and into a pull request, which gives me a proper review step. Netlify preview branches make that easier as well, because I can look at the post properly as part of the site before anything gets merged.

That manual approval part is important. I’m happy to use AI to help me think, draft, structure and speed things up. I’m less interested in removing review from the process entirely. So the workflow has a few deliberate checkpoints built in: first I approve the rough idea, then I review the full draft, then I review the PR and preview before anything gets merged.

That means the process is assisted, but not automatic in a careless way. I think that balance is probably where a lot of this becomes useful. If the tooling is too manual, you stop using it. If it’s too automatic, you stop trusting it. This sits somewhere in the middle, which feels right for now.

It also gives me room to change things as I go. I’m treating this as a workflow I’ve now put in place, not some finished system that will never change. I’ll probably tweak parts of it over time as I use OpenClaw more and get a better feel for what’s genuinely helpful and what just sounds clever on paper.

That’s part of the reason I wanted to do it this way in the first place. I’m not really trying to build a perfect AI blogging machine. I’m trying to understand the tooling properly, use AI more deliberately, and build small workflows that are actually worth keeping. This is one of the first of those.

I’ll write separately about how I set up OpenClaw itself, because that deserves its own post.