Running 4 Sites with 600+ Articles on Autopilot Using Cowork

I run four AI knowledge base sites alongside solo iOS/Android app development: Claude Lab, Gemini Lab, Antigravity Lab, and Rork Lab. Together they hold over 600 articles, published in both Japanese and English.

"How do you manage 4 sites by yourself?" is a question I get a lot. The answer is simple: Cowork's scheduled tasks handle everything.

What follows is the automation system as it actually runs, failures included. If you are considering something similar with Cowork, some of these may save you a weekend.

The 4-Site Setup and the Problem

Here's what I'm running:

That's over 1,100 entries across 4 sites (counting both languages). The tech stack is identical across all sites: Next.js 16 + Tailwind CSS 4 + MDX → JSON precompilation + Cloudflare Pages.

The problem was straightforward: one person physically cannot write daily articles for 4 sites. Each site needs to track the latest AI developments and publish bilingual technical articles. Doing this manually would be unsustainable.

Scheduled Task Architecture

Cowork has a "scheduled tasks" feature that lets Claude autonomously execute tasks on a schedule. I used this to fully automate article generation.

The Task Lineup (Actual Production Config)

I currently have 20+ tasks running. Here are the main ones:

■ Daily article generation (weekdays) — 4 sites × every 6 hours
claudelab-daily-content     : 0:00, 6:00, 12:00, 18:00 (Mon-Fri)
gemilab-daily-content       : 1:00, 7:00, 13:00, 19:00 (Mon-Fri)
antigravitylab-daily-content: 2:00, 8:00, 14:00, 20:00 (Mon-Fri)
rorklab-daily-content       : 3:00, 9:00, 15:00, 21:00 (Mon-Fri)

■ Daily article generation (weekends) — 4 sites × every 4 hours
claudelab-weekend-content     : 0:00, 4:00, 8:00, 12:00, 16:00, 20:00
gemilab-weekend-content       : 1:00, 5:00, 9:00, 13:00, 17:00, 21:00
...

■ Premium article generation (daily)
claudelab-premium-tue     : daily at 4:50
antigravitylab-premium-tue: daily at 4:10
rorklab-premium-tue       : daily at 4:30
gemilab-premium-tue       : daily at 5:30

■ Weekly blog posts (every Friday)
claudelab-weekly-blog       : Friday 10:30
antigravitylab-weekly-blog  : Friday 13:30
rorklab-weekly-blog         : Friday 16:30
gemilab-weekly-blog         : Friday 20:30

■ Maintenance tasks
news-ticker-weekly-update   : Monday 9:00
weekly-reference-update     : Monday 9:09
monthly-reference-update    : 1st of each month 10:00
weekly-premium-showcase     : Wednesday 10:00

Why the Staggered Timing?

The 4 sites' tasks are intentionally offset by 1-3 hours. The reason is simple: distributing Cowork VM resource usage.

When 4 tasks run simultaneously, git clone, npm install, and builds all compete for disk space and CPU. I learned this the hard way in the early days (more on that below).

Skill Files — The Heart of the Automation

Cowork scheduled tasks internally reference a skill file (SKILL.md) that contains the complete execution procedure. Write everything Claude needs to do in here, and it follows the instructions autonomously.

Skill File Structure (7 Steps)

My production skill files follow a 7-step structure:

Step 0: Repository setup (shallow clone → /tmp/repos/)
Step 1: Information gathering (official sources + web search + dedup check)
Step 2: Category selection
Step 3: Content generation (MDX frontmatter + body + quality standards)
Step 4: Quality check (17-item checklist)
Step 5: News ticker update
Step 6: Build & push (generate-content.mjs → count verification → git push)
Step 7: Article update log

Step 0 Is the Foundation of Everything

The most critical step is Step 0, "Repository Setup." This is where I learned the most lessons.

WORK="/tmp/repos/claudelab.net"
 
# ① Disk space check (abort if under 750MB)
FREE_MB=$(df /tmp --output=avail -m 2>/dev/null | tail -1 | tr -d ' ')
if [ "${FREE_MB:-0}" -lt 750 ]; then
  echo "⛔ ENOSPC prevention: /tmp has ${FREE_MB}MB remaining"
  exit 1
fi
 
# ② Shallow clone (minimize transfer)
if [ -d "$WORK/.git" ]; then
  cd "$WORK"
  git pull --rebase origin main
else
  rm -rf "$WORK"
  git clone --depth 1 --branch main \
    "https://${GITHUB_TOKEN}@github.com/user/site.git" "$WORK"
  cd "$WORK"
fi
 
# ③ npm install (with cache)
npm install --prefer-offline 2>&1 | tail -3

Why /tmp/repos/ instead of the workspace folder? Because git lock files on Mac-mounted workspace folders cause Operation not permitted errors. Cowork's VM mounts Mac folders, but .git/index.lock and .git/HEAD.lock sometimes can't be deleted due to permission constraints.

Working in /tmp/repos/ uses the VM's local filesystem, avoiding this entirely. Shallow clone (--depth 1) keeps transfer sizes minimal.

Step 4: The 17-Item Quality Checklist

Auto-generated content that's low quality will drive readers away fast. I defined 17 quality checks in the skill file:

- [ ] Title contains the primary keyword
- [ ] Description is under 160 characters
- [ ] Body is at least 3,000 characters (Japanese)
- [ ] At least 1 code example with comments and expected output
- [ ] At least 3 FAQ items included
- [ ] 2-3 internal links to existing articles
- [ ] Both Japanese and English versions exist
- [ ] English version is naturally written, not a direct translation
- [ ] No "Related Articles" section in the MDX body
  (RelatedArticles.tsx handles this dynamically)
- [ ] No manual MembershipCTA in the body
  (component auto-displays at article end)
...

The last two items are things I messed up repeatedly in the early days. Without these rules in the skill file, Claude would helpfully add a "## Related Articles" section to the article body, causing duplicate displays alongside the component-generated related articles.

Failure #1 — ENOSPC Killed All Tasks Overnight

This was the biggest incident in the first week of automation.

What Happened

Cowork's VM stores working files in /tmp, and when node_modules accumulate for 4 sites, disk space runs out. I woke up one morning to find all 4 sites' scheduled tasks had failed with ENOSPC.

⛔ ENOSPC prevention: /tmp has 312MB remaining — saving article to _pending

The Fix

I added the disk space check to Step 0 (shown in the code above). If free space drops below 750MB, the task aborts gracefully and saves the article data to a _pending folder for manual deployment later.

I also started using npm's cache (~/.npm) with --prefer-offline to dramatically reduce download sizes on each run.

Failure #2 — Git Push Conflicts Ate 4 Articles

What Happened

Overnight, the 4 sites' scheduled tasks ran sequentially, each generating and pushing articles. But a manual push I'd made before bed conflicted with the automated commits, causing rebase failures. By morning, 4 articles had been generated but never pushed.

The tricky part: the /tmp/repos/ working directory gets overwritten by git pull --rebase on the next task run. Unpushed commits simply disappear.

The Fix

I added mandatory pre-push rebase to Step 6 in the skill file, with automatic conflict resolution:

# Always rebase before pushing
git pull --rebase origin main
 
# Auto-resolve rebase conflicts with theirs
if [ $? -ne 0 ]; then
  git checkout --theirs .
  git add .
  git rebase --continue
fi
 
git push origin main

I also added Step 7 for logging, writing logs to the workspace folder (Mac-mounted) so they survive VM resets:

[04:50 JST] claudelab.net
  Title (JA): Claude API ストリーミング実装ガイド
  Slug: claude-api-streaming-guide
  Category: api-sdk
  Status: SUCCESS

Now I just check the log each morning to confirm everything ran properly.

Failure #3 — Duplicate Topics Got Mass-Produced

What Happened

Two weeks into automation, I noticed the article list contained three near-identical articles about "Basic Claude API usage" — each with slightly different titles.

Claude faithfully follows the skill file instructions, but without robust duplicate checking, it'll write about the same topic multiple times.

The Fix

I added full slug extraction to Step 1's information gathering phase:

# Extract all existing slugs to prevent duplicates
node -e "
  const a = JSON.parse(require('fs').readFileSync(
    'src/generated/articles.json', 'utf8'
  ));
  console.log(a.articles.map(x => x.slug).join('\n'));
" 2>/dev/null || \
find content/articles/ja -name "*.mdx" -exec basename {} .mdx \; | sort

With this in the skill file, Claude checks existing articles before writing and avoids covering themes that already exist.

I also added a weekly-updated reference data file (reference_data.md) containing SEO keywords and URLs, so the task prioritizes uncovered keywords.

What Went Right — Automated Premium Articles

Not everything was a failure. Automated premium article generation exceeded expectations.

Each site generates one paid article daily. Articles with premium: true show the first ~10,000 characters for free, with the rest behind a Stripe-powered paywall.

The key was clearly defining quality standards for premium content in the skill file:

| Articles that qualify for `premium: true` |
|---|
| Pro-level implementation guides with detailed code |
| Advanced tutorials (5,000+ characters) |
| Deep-dive API design patterns |
| Monetization & business strategy details |
| Premium prompt collections & templates |

Equally important: SEO/traffic-focused articles are always premium: false. Hitting first-time visitors from search with a paywall increases bounce rate and hurts SEO rankings.

Architecture Overview

Here's the complete flow:

┌─────────────────────────────────────────────────┐
│ Cowork Scheduled Tasks (20+ tasks)               │
│                                                  │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│  │Claude Lab│ │Gemini Lab│ │Antigrav. │ ...     │
│  │ 0:00 base│ │ 1:00 base│ │ 2:00 base│        │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘        │
│       │            │            │                │
│       ▼            ▼            ▼                │
│  ┌──────────────────────────────────────┐        │
│  │ SKILL.md (7-step autonomous pipeline)│        │
│  │                                      │        │
│  │ Step 0: shallow clone → /tmp/repos/  │        │
│  │ Step 1: Web search + dedup check     │        │
│  │ Step 2: Category selection           │        │
│  │ Step 3: MDX article gen (JA + EN)    │        │
│  │ Step 4: 17-item quality checklist    │        │
│  │ Step 5: News ticker update           │        │
│  │ Step 6: Build → git push             │        │
│  │ Step 7: Log to workspace             │        │
│  └──────────────────────────────────────┘        │
│       │                                          │
│       ▼                                          │
│  ┌──────────────────┐                            │
│  │ GitHub → Cloudflare Pages                     │
│  │ git push → auto build → live                  │
│  └──────────────────┘                            │
└──────────────────────────────────────────────────┘

Since Cloudflare auto-builds on git push, the entire pipeline from article generation to production deployment runs unattended.

3 Weeks by the Numbers

Here are the actual results from about 3 weeks of production operation (early March to March 20, 2026):

The 92% success rate honestly has room for improvement. Weekend tasks with 4-hour intervals are particularly prone to disk space issues. I'm planning to add an automated VM cleanup task.

Advice for Getting Started with Cowork Automation

Here's what I learned in 3 weeks of production operation.

1. Don't Try to Make the Skill File Perfect on Day One

My first skill file was about 20 lines. Every time something failed, I added a rule. Now it's 300+ lines. Trying to write the perfect skill file upfront leads to paralysis. Start small and iterate.

2. Always Write Logs to the Mounted Workspace

Cowork's VM resets between sessions. Anything written to /tmp/ disappears. Always write logs to the workspace folder (the Mac-side mount point).

3. Stagger Your Task Schedules

Simultaneous execution means resource contention. Running 4 sites at once guarantees failures. Offset by at least 1 hour, ideally 2.

4. Pre-Push Rebase Is Non-Negotiable

Conflicts between manual commits and scheduled task commits happen constantly. Always include git pull --rebase before push in your skill file.

5. Don't Skimp on the Quality Checklist

Auto-generated content needs stricter quality standards, not looser ones. Items that seem unnecessary at article #5 become critical by article #100.

Wrapping up

With Cowork's scheduled tasks, it's genuinely possible for a solo developer to operate 4 sites with 600+ articles.

But "set it and forget it" will absolutely lead to incidents. Quality standards in skill files, disk space monitoring, git conflict handling, topic deduplication — operational know-how is the real asset.

Don't try to make the skill file perfect from the start. Add one line every time something breaks. After 3 weeks, that becomes a 300-line "personal operations manual."

If you're interested in Cowork automation, start with 1 site and 1 task. Run it for a week, and you'll naturally see what needs to be added to the skill file.