Building an Automated Zenn Publishing Pipeline with Claude Code

TL;DR

I hit a posting limit on Zenn while stockpiling technical articles. As a solution, I built a cron-based pipeline that uses claude -p to perform a holistic polish of all articles and automatically publishes just one per day.

The Trigger: Hitting Posting Limits

I was documenting insights gained from development using Claude Code. When I tried to publish over 10 drafts at once, Zenn's posting limit was triggered.

It turns out the system restricts multiple git pushes within a short timeframe.

Before: Manual Publishing

Write article → Manually change to published: true → git push → Next article...

Problems:

• Cannot publish multiple articles at once
• Can only check for duplication and consistency article by article
• Cannot predict when posting limits will hit

After: Automated Pipeline

[Daily at 12:02 cron]
  → brushup_articles.sh (Holistic polish of all articles with claude -p)
  → auto_publish.sh (Change only one to published: true → push)

Polishing: Holistic Review of All Articles

The key here is not "reviewing article by article," but "taking a holistic look at all stockpiled articles at once."

I pass all published: false articles to claude -p and have it review them based on the following seven criteria:

1. Stand-alone readability — Is it understandable without prerequisite knowledge of the series?
2. One theme per article — Split if multiple themes are mixed.
3. Episode-first — Does it start with a concrete episode rather than abstract theory?
4. Generalize proper nouns — Replace company-specific project names with generic expressions.
5. Before/After — Is the change clear?
6. Numbers — Does it include quantitative results or effects?
7. Title — Is the title click-worthy?

By viewing all articles at once, I can decide to merge duplicate themes or split articles. Global optimization, impossible with individual reviews, becomes possible.

Automatic Publishing: One Per Day

The auto_publish.sh script follows a simple logic:

1. Find one article with published: false.
2. Change it to published: true.
3. git commit & push.

By limiting it to one per day, I reliably avoid the posting limit.

Report Generation: Asynchronous Updates

If there are items to report—such as integrations, splits, or major revisions—during the polishing process, the script outputs a file to the reports/ directory. I can check these in the next interaction.

Structure

zenn-content/
  articles/          # Zenn articles (published: true/false)
  scripts/
    auto_publish.sh   # Automated daily publishing for one article
    brushup_articles.sh  # Article polishing with claude -p
  reports/            # Polishing reports

crontab:

2 12 * * * /path/to/auto_publish.sh

Three Key Lessons

1. Solve constraints with systems: Instead of a manual workaround for posting limits, I implemented a permanent solution using cron and scripts.
2. Global optimization over local optimization: By viewing all articles at once rather than reviewing them individually, I can make informed decisions about removing duplicates, merging, and splitting content.
3. Integrate polishing into the workflow: By forcing execution via cron before every publication, I ensure that quality is continuously improved.

Conclusion

The posting limit ended up being the catalyst for building a better operational workflow. Constraints are opportunities to create new systems.