The first pull request this routine opened showed up in my GitHub notifications while I was in the middle of something else. The title it had chosen for the post was right there in the subject line. I almost closed it.
That's probably the right first instinct. But I looked, and then I kept reading.
Why I set it up
I had four posts published and a growing list of things I'd half-meant to write about. The content wasn't the problem — I was learning things, shipping things, running into enough friction to have opinions. The problem was the blank document. Every time I sat down to start a post, I'd underestimate the activation energy and end up not starting.
What I wanted wasn't an automated blog. I wanted a draft to react to. Something already on paper, already wrong in some interesting way, already there to cut.
Claude Code has a /schedule command that creates recurring cloud agents — tasks that run on a cron schedule, fully autonomously, without you present. Each task is just a markdown file at ~/.claude/scheduled-tasks/<task-name>/SKILL.md. You write it like a detailed spec: what to do, in what order, what constraints to respect, what to never do.
Mine runs every three days. The instructions tell it to research recent work, draft a post, generate a Cloudinary cover image, and open a pull request against main — not merge, open. That last constraint was the first thing I locked down.
The step that actually matters
Before it writes a single sentence, the task searches my recent Claude Code session history. It reads through the actual transcripts of my other conversations — what I built, what broke, what I was poking at — and uses that to pick a topic.
I didn't expect that part to matter as much as it does. Most AI-generated content fails because it's generic: it could have been written by anyone, about anything, at any time. Grounding the draft in real recent activity makes it specific. The draft knows I was looking at something. It's not inventing a premise.
When the session search comes up dry — say, the last few days were light or the conversations were scattered — you can feel it in the draft. The topic gets vague, the framing gets broad. The output quality tracks the input signal more directly than I expected.
What the draft looks like
It needs editing. Sometimes significant editing. The structure is usually reasonable; the specific observations are the part that often needs work, either because the task misread what was actually interesting or because it picked something adjacent to the real thing.
But it's not nothing. Having something to push back against is genuinely easier than facing a blank document. I'll cut two sections, rewrite the opening, and get a post I'd actually publish — in an hour instead of an afternoon. The blank page problem is mostly solved.
The PR format matters here. The task is explicitly forbidden from merging. Every post goes through me. That's not a safety hedge; it's what makes the whole thing usable. Fully automated content would be worse content. The automation handles the part I kept skipping — starting — and I handle the rest.
What caught me off guard
Occasionally the research step finds evidence of the blog post task itself running, and decides that's the most interesting recent topic. Which is what happened this time.
There's something a little recursive about a scheduled agent writing a post about scheduled agents. I'm not sure it's a problem, though. The experience is genuine — I did set this up, I did notice what surprised me, and I do think the PR-not-merge constraint is the decision that makes it work rather than just generating noise. If the draft surfaces something real, the source of the prompt matters less than the content.
The constraint that makes it work
The single design choice that separates "useful automation" from "content I'd be embarrassed to publish" is that nothing gets published without me touching it. Not the topic, not the framing, not the prose. The task opens a PR and stops.
Everything that happens after the PR arrives is still editorial work. The automation is only shortening the path from "I should write about that" to "I have something to work with." That's a smaller win than full automation, but it's the right win. A draft I'll edit beats a blank document by a lot. An auto-published post beats nothing by less than you'd think.
If you want to try the /schedule command, start with the constraint. Decide what the automation isn't allowed to do before you write the rest of the spec. That decision shapes everything downstream.