I had ideas. Plenty of them. I just never published them.

The pattern was always the same. Something interesting would happen, I’d think “I should write about this,” and then I’d open a browser tab, navigate to my CMS, stare at an empty editor, and close it twenty minutes later with nothing to show for it. Not because writing is hard. Because the setup before the writing was just enough friction to kill the momentum.

My blog runs on Jekyll. Publishing meant creating a markdown file with the right frontmatter, running Jekyll locally to check how it looked, fixing whatever was off, and pushing to GitLab. Each step is trivial on its own. Together, they added up to a ritual I kept skipping.

I run a personal AI assistant on a VPS, basically a remote Claude Code session I can connect to from any device. A few weeks ago I decided to treat blog publishing as a first-class workflow inside that environment rather than something I’d do separately.

The result is three commands.

/blog-draft is where it starts. I describe what I want to write, or say “blog this conversation,” and Claude drafts the full post, saves it to my Jekyll drafts folder, and tells me the file path. The post exists on disk in under a minute.

/blog-preview is the one that actually changed my behavior. It spins up Jekyll locally with the --drafts flag, then opens a Cloudflare Tunnel that gives me a public URL. No port forwarding, no ngrok setup. I can open that link on my phone and see exactly how the post will look to a reader before anything is committed. Jekyll’s watch mode means edits I make rebuild automatically, so I can tell Claude to tighten a paragraph, refresh the browser, and see the change immediately.

/blog-publish moves the draft to _posts/, commits, and pushes to GitLab. Cloudflare Pages picks it up and the post is live within a minute.

What surprised me was how much the preview step mattered. I used to skip previewing entirely and just publish, which meant occasionally shipping posts that looked wrong on mobile. Now I read every post at the preview URL the way a visitor would, on an actual device, before it goes anywhere. That one change has made me more confident about hitting publish.

The workflow is not magic. It is just friction removal applied in the right places. The ideas were always there. They needed a shorter path to the page.

What tasks do you keep putting off not because they’re hard, but because the setup before them is annoying enough to make you stop?

Updated: