Claude Code Writes My Blog. I Do Three Things.

You want a blog that ranks and sounds like you. You also run a business, so you write one post a month, then none. Or you hand it to an AI tool and get 1,500 words that could have been written by anyone about anything.

So I built the blog as a pipeline. Claude Code agents plan the site, interview me, write, animate, check and stage every post. A daily build publishes it on its date. I stand at three points in the line, and none of them involves typing an article.

On 22 October the pipeline wrote six articles in one day, from one plan and one interview. Before the plan and the interview existed, my measured pace was 14 posts in seven weeks. Someone automating their own blog asked me how it works, so this is the whole thing, in seven steps, with the real files.

From keyword to live page

1. 1Plan the siteagent
2. 2Score the planme
3. 3Interviewme
4. 4Write from filesagent
5. 5Scenes and coveragent
6. 6Machine checksagent
7. 7Draft PRagent
8. 8Approveme
9. 906:12 buildmachine

3 of 9 need a human. The other six never wait for one.

Why one big “write me a post” prompt does not work

The normal way is one prompt: a topic in, a post out. It fails for three reasons, none of them the model.

The topic is a guess. Nobody checked whether anyone searches for it, whether vendors you cannot beat own the results page, or whether another of your posts already targets it.

The facts are the model’s. It has never run your ad account. Every number it adds is borrowed or made up.

Nothing checks it. The prompt does not know how long a ranking post in your space is, which words you never say, or that a client’s name slipped into a caption.

Google’s guidance on AI-generated content does not care who typed the words, only whether the page helps or exists to game rankings. A generic post fails that test with or without AI. So the job is to give the agents a plan, my real knowledge and a gate.

What you are building

Five pieces. Each one is a file or a skill, and each one is replaceable.

1. A strategy skill that turns your positioning into a keyword set, a URL map, a dated schedule and one brief per article.
2. A review page where you score the plan before anything gets written.
3. An interview agent that asks you the questions the articles need answered, out loud.
4. An article skill that owns the how: worktree, outline, prose, animated scenes, screenshots, cover, checks, draft pull request.
5. A publish gate: a draft flag, a date, and a daily build that releases posts and tells the search engines.

A skill, in Claude Code, is a folder with a SKILL.md that loads when the work it describes comes up (the format is documented here). The article rules load when an article is being written and cost nothing in any other session.

Step 1: Plan the whole site before writing one post

The first skill never writes an article. It decides which articles should exist.

It starts from one positioning sentence. Mine, verbatim: “Solo growth operator helping B2B and expert-led businesses turn marketing into a predictable revenue engine.” From that it builds seed groups, pulls autocomplete suggestions from Google and Bing, dedupes them, flags junk, and screens the survivors against a live results page.

On the 22 October run: 40 seeds, 18,753 raw suggestions, 5,712 unique, 58 targets screened against the top ten results and the People Also Ask box, 48 passed. A target fails when the page one results belong to someone you will not beat on that query: software vendors, platforms, schools. “Best AI marketing tools” failed. So did “how to sell online courses”. Cost: zero, the sources are free. Full method: the Claude Code SEO strategy.

The plan, 22 October

0

autocomplete suggestions from 40 seeds

0

unique after dedupe

0

screened against a live results page

0

passed: worth a page of their own

Cost of the whole run: $0. Autocomplete endpoints and search results pages only.

Then it groups the winners into clusters: one hub page plus the support pages that link to it. It writes a URL map with one head term per URL, so my posts never fight for the same query, a schedule at a pace I approved (one or two a day), and a JSON brief per article: title, description, definition, H2s, five FAQ pairs, links, and the claim each scene must make.

Every brief faces the finished post’s gate, minus the word count, before it may exist. The bands in that gate are measured, not invented: a blog post here is 2,100 to 2,700 words of body, 9 to 12 H2s, 8 to 12 internal links, 3 to 6 external, five FAQ answers of 40 to 90 words.

Step 2: Score the plan on one page

The plan is a list of 59 articles. I do not read 59 briefs in a chat window. The strategy run builds a review page instead: one item per cluster, where my vision for that topic goes in the comment, and then one item per article with its target query and its date.

I score, kill and comment, then paste the JSON back. It is the same score-the-batch page I use for every batch my agents make.

Reviewing the plan is where the real decisions happen: which term I own, which pages die, which new service gets a cluster. No script makes those calls.

This is my first station, once per plan.

Step 3: Get interviewed by an agent

An article without your knowledge is the generic post. Typing that knowledge out is the part everybody skips. So I talk instead.

The plan produces a question sheet: 49 numbered questions, grouped by article topic, each tagged as a Belief question (I want a stance) or a Detail question (I want a number, a step, a real account). A script reads that sheet and creates a voice agent on ElevenLabs Agents, so editing the sheet and rerunning it keeps the two in sync. The agent is a podcast host called Sam. Its instructions are short and strict:

Ask the questions below in order, one at a time, word for word, then stop talking and listen.
He thinks out loud and pauses. Never interrupt a pause. Never finish his sentences.
After each answer you may ask ONE short follow-up, only if he skipped a concrete number,
step or real example ("What was the actual number?", "Give me one account where that happened.").
Your turns are one or two sentences. No praise, no summaries of what he said, no "great answer".
If he says "skip" or "next", go to the next question.
Every tenth question or so, say which number you are on so the edit can find it.

I record it in OBS. The 22 October session ran 24 minutes and 46 seconds. An agent pulls the transcript through the API, maps each answer to its question and writes an answers file. Anything I add afterwards in chat goes into the same file under “Written answers”.

The same file has a section called “Fact corrections”, and it is the most important one. On camera I gave one account’s result from memory. The published case study had a different number. The answers file now says: use the case study, never the spoken figure. A transcript is a draft of my memory. A file I already published is the record.

Host agentWhat was the actual number? Give me one account.

Me, on cameraThe number I remember from that account.

later, in the answers fileThe figure on the pageFact corrections: use the case study. Do not quote the spoken figure.

This is my second station. One interview feeds a batch.

Step 4: Hand one article to one skill

Writing starts with a card on my board or one line in chat, and there are two ways in.

Planned: “write the article for this brief”. The brief comes from Step 1 and the answers file from Step 3.

Autonomous: “write a blog post about X”, where X is a topic, a folder, a URL or a brain dump. No plan, no interview. The facts come from the files X points at and, where the disk has nothing, from primary sources it finds and links. Anything it cannot source becomes an open item for me, never an invented fact. This post ran that way, and so did the first one this skill ever wrote.

Either way the blog-article skill owns the how, end to end.

It isolates itself. Several agents work on the site repo at the same time, so the skill creates its own git worktree on a fresh branch from origin/main before it touches a file.

It reads the rules first. The rulebook, my copy rules file, and the newest post, to copy its shape and never its words.

It takes facts from disk only. The brief, the answers file, the skill or the client report being written about, the published case studies. Every number in the prose must point at a file, and the run notes keep a list called “Sources of every number” with the file next to each figure.

It outlines before prose. Slug, title, the definition sentence, five takeaways, the H2 list, and the claim each scene makes. The scene claims come first. The skill says it in one line: “If a scene has no claim it does not exist.”

It writes a tutorial by default. Numbered steps, a code block where a step has an artifact, and a closing prompt a reader can paste into Claude Code. That shape is my rule from the first run on 11 September: teach people to do the thing, “less about hitting people in the head with knowledge”.

It builds the visuals. Four to seven animated scenes whose captions carry the claim in words, because captions are what search engines read. Two or three screenshots of real reports, with names and client domains rewritten in the page before capture. An HTML cover rendered in my own Chrome, no image model.

Each post is an MDX file in an Astro content collection, so an agent can write, diff and review it like code.

Step 5: Check it, then gate it for leaks

I do not count words. A script does.

_check_post.py measures the description against its band, the body against 2,100 to 2,700 words, the H2 count, the five FAQ answers and whether the visible FAQ is byte-identical to the one in the structured data, dashes (zero allowed), six banned minimizer words, and it fetches every external link and expects a 200.

Then the site is built with the draft flag flipped locally and flipped back after. The skill checks the built page: scene count, FAQ schema, blog card, sitemap entry, every internal link. It reads the markdown copy every post gets for AI agents. Then it pins each scene to the top of a browser tab, waits about seven seconds, screenshots it and confirms nothing is still invisible. That last check exists because a scene can pass the build and never animate at all.

Then the sensitive content and security gate. Nothing gets committed until it passes, and a blocker is fixed, never waived:

1. Leak audit. The publish-audit skill I run before any public repo, on a folder holding only this article’s files. It hunts credentials, private paths and endpoints, my own identity, a list of private names, and every client without a public case study. On the score-the-batch post it caught a post id from my scheduler in the copy and screenshots taken from real accounts.
2. Images, by eye. A script cannot read pixels. Every screenshot and the cover get checked for names, emails, logos, account IDs, open tabs and notification toasts.
3. Prospect-safe numbers. No losses, no churn, no revenue of mine, nothing that identifies a client’s results.
4. Code a stranger will run. Every code block, and the paste prompt at the end, will run in someone else’s agent. No secrets, no internal URLs, nothing destructive, and nothing that publishes, sends or spends.

The result goes into the run notes, with every warning and why it is fine.

$ python scripts/_check_post.py what-is-a-revenue-engine-in-marketing --links

desc 156 (band 140-158)

em/en dashes: 0

body words: 2607 (band 2100-2700)

H2 11 faq 5 answer words [56, 51, 49, 52, 58]

200 x 4 external links

$ publish-audit <score-the-batch article only>

FOUND a post id from the scheduler in the copy

FOUND screenshots taken from real accounts

both fixed before I saw the draft

Then a second read. A fresh agent gets the draft and the source files, not the writer’s reasoning, and flags every number or claim that does not match. Nothing gets added to the post: no citations, no private sources, the result stays in the notes. A checklist then catches undefined jargon, filler lines and lines about the site itself. On 22 October a coordinator did that by hand and found something in all six articles. Long runs go inside a goal with auditors.

Step 6: Stage a draft and stop

The skill commits with draft: true, pushes the branch and opens a pull request. It writes a NOTES.md: timeline, the source of every number, the gate result, traps, and open items for me. Then it opens the post in a new tab in my browser.

The rule in the skill is one line, in bold: never flip draft, never merge, never deploy.

This is my third station. I read the post the way a reader will, in the tab. Every rule I state while reading becomes a saved rule the same turn, so the next article does not need the same comment. Facts I correct go into the article.

On 11 September I read the first draft this skill ever wrote and asked for a how-to instead of an explainer. It was rewritten that evening and live that night: Meta Ads CAPI using Claude Code.

Step 7: Let a daily build publish it

When I approve, the skill lists every scheduled post and asks me the date: today, the next free day, or another. Then it flips the draft flag, links the post from two related posts so it is never an orphan, merges, and checks the live URL.

One file decides whether a post is public. It has two gates, and a post needs both:

export function isPublished(data, on = cutoff()) {
  if (data.draft) return false;        // "not finished"
  return data.publishedAt <= on;       // "not yet"
}

A post dated tomorrow is absent from today’s build: no page, no blog card, no sitemap entry. The site is static, so something has to rebuild every day. That is a GitHub Actions workflow on a cron at 06:12 UTC, plus every push to main.

on:
  schedule:
    - cron: "12 6 * * *"   # not on the hour: the shared cron queue is busiest then
  push:
    branches: [main]

After the deploy, the same workflow sends only the changed URLs to IndexNow for Bing and the others. The Google half waits on a key I have not set, so Google finds new posts through the sitemap. Google deprecated the old sitemap ping in 2023, so code still calling it does nothing.

One trap worth stealing: the first version decided what changed by comparing the sitemap’s lastmod. A CI checkout restamps every file, so every page looked modified, and the first real deploy submitted 26 URLs instead of one. It now uses the frontmatter dates, which a checkout cannot move.

06:12 UTC, every day

Tue 27 Oct3 postslive

Wed 28 Oct1 postlive

Thu 29 Oct1 postlive

Tue 3 Nov1 postlive

Wed 4 Nov1 postlive

Thu 5 Nov1 postlive

IndexNow: changed URLs only

Every post also ships a clean markdown copy at the same URL ending in .md, which is how the prompt below works.

What you get

The repo holds 24 English posts, this one too. Five are approved and dated, the last on 5 November, and the build releases them without anyone touching anything. Six were written on 22 October from one plan and one 25-minute interview.

My time per post is reading it.

The less obvious result: every comment I make on a draft becomes a rule in the skill, and every trap an agent hits becomes a line, so the SKILL.md reads like a list of scars. The sensitive content gate in Step 5 is one of those scars.

Hand it to Claude Code

The skills are mine and private, but this page is the spec. Open Claude Code in your site’s repo and paste this.

Read https://rodrigonask.com/claude-code-automated-blog-writing-pipeline.md in full. It describes an agent blog pipeline in seven steps.

Build the same pipeline for my blog, adapted to my stack: the three skills below, and a daily build that releases future-dated posts if my site has no scheduler (propose it, wait for my yes). Before writing anything, ask me, one question at a time:
1. My positioning in one sentence, and who the buyer is.
2. Where posts live (repo, CMS), how a post is published today, and whether a daily build or scheduler exists.
3. Which words I never use, and two posts of mine that sound like me.

Then build three skills in my Claude Code skills folder, and save my answer to question 3 as a copy rules file every skill reads first.

1. Strategy skill.
   - Expand seeds through Google and Bing autocomplete. Drop junk: wrong buyer (consumers when I sell to businesses), wrong country, jobs, definitions for students.
   - Screen each target on a search results page (I used Brave; engines rate-limit, so space the fetches out and retry once). It fails when page one belongs to vendors, platforms, marketplaces or schools. If a fetch is blocked, mark it UNSCREENED and judge intent by reading the query; never pretend it was screened.
   - One head term per URL in a url-map.csv, a dated schedule.csv, and one JSON brief per article with: slug, title, description, definition, takeaways (3 to 5), h2 (list), faq (5 q and a), internal_links, external_links, scene_claims. Numbers in the brief are drafts until the interview or a file confirms them.
   - A brief gate script. Print the checks it actually runs, by name. Never print a check count you did not implement.

2. Interview sheet skill: numbered questions per brief, each tagged Belief (a stance) or Detail (a number, a step, a real case). I answer in writing, or, if I ask for it, out loud to a voice agent that reads the sheet. Answers go in answers.md under the question number, plus a "Fact corrections" section where a file overrules what I said.

3. Article skill, with two ways in.
   - Autonomous: "write a blog post about X" (a topic, a folder, a URL, a brain dump). No plan, no interview. Facts from the files X points at, and where there are none, from primary sources found on the web, each one linked.
   - Planned: "write the article for brief <slug>", using the brief and answers.md.
   - A git worktree per post if several agents share the repo, a plain branch if not.
   - Facts only from those sources. Anything the post needs that is not there becomes a TODO for me, never an invented fact.
   - Outline and the claim of each visual first. Animated components if my site supports them; otherwise a captioned image or figure, with the claim in the caption.
   - Internal links only to pages that already exist: service pages first, sibling posts as they go live.
   - A check script in Python, standard library only: description 140 to 158 characters, body inside a word band, H2 count, 5 FAQ answers of 40 to 90 words identical in frontmatter and body, zero em or en dashes, zero of "just, quick, simple, seamless, unlock, leverage" plus my never-words, every external link returning 200. Start with these bands: 2,100 to 2,700 body words, 9 to 12 H2s, 3 to 6 external links. Once three pages rank for my head terms, measure them and replace mine.
   - A sensitive content and security gate before any commit, written as a script plus a checklist: scan the post and its files for secrets and API keys, emails and phone numbers, private file paths, internal URLs and localhost addresses, customer or client names from a list I give you, and my never-share terms. Look at every image yourself for names, emails, logos, account IDs, open tabs and notifications. No losses, churn or revenue figures of mine unless I approve them. Every code block and prompt in the post must be safe for a stranger's agent to run: no secrets, nothing destructive, nothing that publishes, sends or spends. Keep the client list in a private file outside any repo that goes public. A finding blocks the commit until fixed.
   - A second read before I see the draft: a fresh agent checks every number and claim against the source files (no citations added to the post), then a checklist for undefined jargon, filler lines and lines about the site itself.
   - A publish step that runs only when I say publish: list the scheduled posts, ask me the date (today, next free day, another), link the post from two related posts, then merge and check the live URL. The post never mentions what was removed; that goes only in the notes.
   - Stage it: commit with draft: true on its branch, open a draft pull request if a remote exists, and give me a preview (my dev server, or a local HTML file).

Then prove it, twice:
- Autonomous: ask me for one topic, write that post with the article skill, run the check script and the gate until both pass, and stage it as a draft.
- Planned: run the strategy skill on 5 seeds, pick the first brief, write me 10 interview questions for it and wait for my answers, then write, check, gate and stage that post the same way.

Never publish, merge or deploy. Stop at the draft and show me the preview.

When not to do this

If you publish once a month, skip Step 1. Write the briefs by hand and keep the rest.

Run the autonomous mode only on topics your files already cover. With no files behind it, it writes the generic post with better links.

If your site cannot hold a post back by date, keep the publish step manual. Scheduling on a static site only works because something rebuilds every day; take that away and a future date silently publishes nothing.

This pipeline sits inside a bigger setup. The context diet is why the article rules live in a skill and not in the file every session loads, Safe to Close is how I know an agent’s worktree is clean before I close the chat, and the advisors that interrupt me are the same idea applied to my calendar. The operating model behind all of it is agentic marketing. If you want the same system running on your ads instead of your blog, see the service tiers or book a working session with me. Results from real accounts are in the case studies, and every other build is on the blog.