I Automated 7 Blogs With Claude Code and Came Back to One

I once ran 7 blogs on full auto-publish. The first one I automated worked so well that I got greedy. But at some point the CAPTCHAs started showing up, and that was ultimately what made me shrink 7 back down to 1.

01. It started with automating just one blog

I felt like the tech stack landing on me every day was moving too fast. I wanted it auto-curated to my blog once a day so I could read it on my commute. The goal was simple: "I'd love to wake up to one post already published every morning."

I used Claude Code to chain together every step needed to publish one post. Collecting topics, generating the body, making the image, publishing to Tistory (a Korean blogging platform), all the way to the Telegram notification. The first time I watched one blog run cleanly end to end, I'll be honest, I was thrilled!

02. Here are the Claude Code tools I used at this stage

As I built the automation, I bolted on Claude Code's tools one at a time. Let me lay out which one sits where.

a. CLAUDE.md, the file that stops you repeating yourself

When I first ran Claude Code, I had to reintroduce myself every single day. A new session wasn't my old buddy, it was a complete stranger. Every rule and preference I'd agreed on yesterday was gone.

But once I dropped a single CLAUDE.md file into the folder, I discovered the conventions I'd written got auto-loaded at the start of each new session. Over time my structure naturally hardened into a 5-section skeleton.

# CLAUDE.md (the skeleton I use)

## Identity
This folder runs "[blog name]" / operator: Eddie, solo

## Hard Rules (the absolute line — break it and you've got an incident)
- No auto-publishing (drafts only)
- API keys load only from the secrets/ folder
- Block duplicate publishing of the same post

## Soft Rules (advisory)
- Keep a first-person tone
- Cite at least one official external source
- One post = one topic

## Commands (master index)
| Command       | Description                  |
| /run-daily    | Build the daily publish queue|
| /run-weekly   | Weekly trend roundup         |

## Recent Changes
- 2026-05-XX: Slimmed CLAUDE.md by splitting out Skills

I keep a separate folder per project and manage a separate CLAUDE.md per folder. Even the same Claude behaves with a completely different context the moment the folder changes. The same /run-daily behaves differently depending on the folder!

b. Slash commands, extract the moment you've copy-pasted the same prompt 3 times

The moment I type the same prompt a third time, I pull it out into .claude/commands/ right then. It's partly about time, but mostly because if I accidentally drop one line, the result comes out completely different. I'm running somewhere in the low-to-mid double digits of commands right now, and once it hit nearly 30, four operating rules naturally hardened.

1. Folder = context separation. Each project gets its own commands folder. Otherwise the automation folder's commands leak into the blog folder
2. Consistent name prefixes. Standardizing on run-daily, run-weekly, run-market-daily makes them identifiable at a glance
3. A one-line description meta is mandatory. One line at the top of the .md. Just typing / pops up the catalog, so you don't have to memorize them all
4. Master index = the last section of CLAUDE.md. Every command goes into a one-line table. Even if I forget, the Claude working alongside me doesn't

c. Skills, the CLAUDE.md diet tool

Once my CLAUDE.md got too big, I noticed it loaded in full every new session and the token cost piled up. So I moved the big guides I don't use often (e.g. the blog style guide, the review-gate rules) into Skills. They only get called when needed, so my everyday sessions got lighter.

d. Hooks, for blocking auto-publish incidents

I use Hooks as a decision-level safety net. If I block a risky action like auto-publishing at the PreToolUse stage, the system refuses it even if I absent-mindedly approve. The scariest thing in automation is one user mistake spiraling into N auto-published posts, and you can block that with a single hook.

e. Plugins, only the ones you actually use

I don't get greedy with plugins; I only install the ones I use every day. Install too many and you get slash command collisions and a heavier context. (Spot for the list of plugins you actually use) is roughly what I keep installed and running.

03. Because one ran well, I got greedy and scaled to 7

Watching one blog publish a post by itself every day, I started getting greedy. "If I just clone this as-is, I could run N of them at once, right?" is what crossed my mind. So I scaled up. Dev, real estate, life tips, quizzes, daily life, 7 in total.

I cloned the same automation skeleton at the folder level. With a separate CLAUDE.md, separate commands, and separate secrets per folder, each blog ran independently. 2-3 posts went up automatically every day, and for a while it really did run great.

04. At some point the CAPTCHAs started showing up

I don't remember exactly when it began. Only the Kakao (the auth provider behind Tistory) engineers probably know precisely... but it felt like the CAPTCHAs started appearing around the point I was pushing past 10 posts a day. I don't know the exact threshold, but the frequency clearly climbed as my publishing volume grew.

At first I took it lightly. "If one pops up, I just solve one." But in an automated system, a CAPTCHA isn't a "just solve it once" thing. You can only solve it while a human is watching the screen, but auto-publishing usually runs at dawn or during the commute. You're not going to be sitting in front of the screen at that moment.

05. My first workaround: receiving CAPTCHA screenshots on Telegram

My first workaround was wiring in Telegram. When an auto-publish job hit a CAPTCHA, it sent a screenshot of the screen to Telegram, I'd reply with the CAPTCHA answer, and the job would take it and enter it automatically.

# Telegram CAPTCHA relay (first attempt)

Publish job → detects CAPTCHA
  → captures a screenshot
  → sends it to me via the Telegram bot
  → the bot waits for my reply

My reply ("xyz123") arrives
  → the bot passes the answer to the job
  → the job fills it into the field and submits
  → publishing continues

At first I thought this was clever!! But after running it a few days, the limits were obvious.

• It's not 100% automation. A human still has to step in at one stage, so calling it "automatic" felt like a stretch
• CAPTCHAs have a time limit. If you can't enter it in time, the form expires and solving it is useless
• It's worthless without real-time response. If I'm asleep or in a meeting, my Telegram reply is late. Then even after solving one CAPTCHA, the next step is blocked again

Watching this, I realized for the first time that "spending time trying to solve CAPTCHAs" isn't the real problem. The point isn't to solve the CAPTCHA, it's more important to make sure you never hit one.

06. The scarier part was the auto-retry

One day while I was tinkering with the CAPTCHA workaround, I ran into something scarier. One auto-publish job was running as usual, got blocked by a CAPTCHA, but the job didn't know that and just kept going to the next action. Once, twice, three retries fired off in a row.

I only found out way later when I saw the Telegram notification. By then Kakao had already flagged something like an "abnormal activity" signal. A chill ran down my spine!

That day I learned two things. First, a CAPTCHA naturally disappears on its own once time passes. Second, auto-retry looks like bot behavior and amplifies your block risk. If it hadn't retried, only one job would have failed and that'd be the end of it, but because of the retries my whole account nearly got shaken.

Right there I baked in a "never auto-retry, ever" rule. One publish failure = immediate abort + notify + preserve the HTML, and then nothing else happens. Let the next cycle try again fresh.

I used to think "retry on error" was the default in automation, but in a system with bot-block risk it's the exact opposite. One failure = stop immediately + notify a human was safer. There are environments where stopping fast matters more than solving fast.

07. In the end I shrank 7 blogs down to 1

After the CAPTCHA incident I agonized for a long time. I could have built more sophisticated CAPTCHA-workaround infrastructure, but if I hit the block risk one more time doing that, I figured there'd be no end in sight. And honestly, 6 of the 7 just weren't in my voice. Categories like real estate, quizzes, and daily life were auto-generated sentences I was almost embarrassed to read once!

So I closed 6 and kept 1. The one I kept was the direction I actually wanted to run myself. And even for that one, I dropped 100% auto-publishing and switched to writing with AI's help, then reviewing and publishing myself. The result: my publishing count dropped to less than a seventh, but I stopped being embarrassed by each individual post.

08. The 5 lessons I got from running 7 and coming back to 1

What I got from this one cycle wasn't a simple "CAPTCHA workaround tip." How I view automation itself changed.

1. In automation, incident prevention is priority #1; efficiency is #2

At first I was obsessed with "how often, how much." But after seeing that a single block risk can render all the automation you've stacked up useless, I now look at incident prevention before efficiency. That's exactly why I put Hard Rules at the very top of CLAUDE.md.

2. 100% automation is a trap. Leaving 1% for a human is stronger

Building the CAPTCHA workaround taught me that 100% automation is a fantasy. In places with bot-detection systems, deliberately leaving 1% for a human actually extends the whole system's lifespan. My one blog now runs on AI does 90%, I do 10%.

3. Run 7 blogs on the same AI and they all converge

The most shocking thing about running 7 blogs was that any blog where I didn't bake in my own voice converged to look the same. The differentiation was zero. To bake in your own voice, your own hands have to get involved.

4. Auto-retry is an incident-stacking device

I thought of auto-retry as a "friendly default." But in front of a bot-block system it's the exact opposite. One failure = stop immediately + notify a human was the right answer. Letting the next cycle pick it up fresh was the path that didn't grow the block risk.

5. Publishing is a decision, not a tool

Before automating, I saw "publishing" as just a tool. Once the post was done, it was just the step of calling the publish API. But a year of running this taught me: publishing is the decision stage where you judge whether this post should go out into the world under my name. Automation can't make that decision for you. So now AI writes, and I publish.

09. I came back from 7 to 1, but I have no regrets

I don't think closing 6 blogs was a loss. What I learned about automation systems themselves over that year was huge. How to use CLAUDE.md, how to separate slash commands, how to diet with Skills, what kinds of incidents Hooks block, I learned all of it by running headfirst into it!

I still love automation. The difference is that, unlike before, I head toward not "automating publishing" but "automating everything up to the moment before publishing". That difference is the single most expensive line I bought across a year of trial and error. If you're at the stage of just starting blog automation, I'd recommend finishing one full cycle with a single blog and holding off a beat on the urge to run 7.

Sources: Ediblog — 100% automation doesn't work (old retro) · Claude Code official docs

This is a first-person write-up of a cycle I ran and broke myself over a year. It's not a CAPTCHA-bypass guide or a security-evasion guide. I received no sponsorship of any kind from Anthropic.

---

Original with full infographics and visual structure: https://jessinvestment.com/i-automated-7-blogs-with-claude-code-and-came-back-to-one/