Automating Multi‑Channel Blog Publishing with a Content‑Automation Repo

TL;DR: I rewrote the content‑automation pipeline to generate, format, and push daily posts to Medium, Substack, and Bluesky in a single CI step. The change lives in a handful of Markdown, JSON, and metadata files, and it eliminates manual copy‑paste errors while keeping each platform’s payload valid.

---

The Problem

Every morning I had three tickets in the backlog:

1. Publish the day’s article on Medium (English & Spanish).
2. Send the same copy to Substack newsletters.
3. Post a concise update to Bluesky (English & Spanish).

The manual workflow was:

$ cat content/2026/10/05/content-automation/medium_en.md
# … (copy‑paste) …

I kept opening each file, adjusting front‑matter, fixing line breaks, and then manually uploading via each platform’s UI. The biggest pain point was the payload mismatch for Bluesky – the JSON schema expects a type field (progress/avance) and a text field limited to 300 characters. One typo in the generated JSON caused the API to reject the request with:

Error: payload validation failed – field "text" exceeds max length

The error surfaced only after I had already spent ~30 minutes preparing the Medium draft, so I was forced to roll back changes and re‑edit everything. I needed a deterministic, repeatable process that would:

• Pull the same source Markdown once.
• Render platform‑specific formats (MD → HTML for Medium, plain‑text for Bluesky, newsletter template for Substack).
• Validate each payload before committing.

---

What I Tried First

My first attempt was a shell script (scripts/publish.sh) that concatenated the Markdown files and called the three platform CLIs:

#!/usr/bin/env bash
mdcat content/2026/10/05/content-automation/medium_en.md | \
  medium-cli publish --title "Weekly Review"

I duplicated the same logic for Substack and Bluesky, using jq to build the JSON for Bluesky. The script worked for a day, but it quickly broke:

• Hard‑coded paths – each new date required manual updates.
• No schema validation – the Bluesky JSON was sent raw, so the length error kept slipping through.
• No CI integration – I had to run the script locally, which defeated the “build in public” automation goal.

The failure manifested as a broken JSON payload (missing commas) and a mismatched metadata.json flag (medium_generated: false) that downstream jobs relied on.

---

The Implementation

1. Repository Layout

content/
└─ 2026/
   └─ 10/
      └─ 06/
         └─ content-automation/
            ├─ changelog.md
            ├─ medium_en.md
            ├─ medium_es.md
            ├─ substack_en.md
            ├─ substack_es.md
            ├─ bluesky_en.json
            ├─ bluesky_es.json
            └─ metadata.json

All files are now generated automatically by a single Node.js script (scripts/generate-content.js). The script reads a template (templates/post.hbs) and injects the day’s data (date, title, tags). It then writes the platform‑specific files and updates metadata.json.

2. Core Generator (scripts/generate-content.js)

// scripts/generate-content.js
const fs = require('fs');
const path = require('path');
const Handlebars = require('handlebars');

// Load shared data
const today = new Date().toISOString().slice(0, 10);
const data = {
  date: today,
  title: 'Weekly Review – Content Automation',
  tags: ['vibecoding', 'buildinpublic', 'automation'],
  summary: 'AI‑driven drafts, a ClickUp fix, and multi‑channel publishing.'
};

// Helper to write a file only if content changed
function writeIfChanged(filePath, content) {
  if (fs.existsSync(filePath) && fs.readFileSync(filePath, 'utf8') === content) return;
  fs.mkdirSync(path.dirname(filePath), { recursive: true });
  fs.writeFileSync(filePath, content);
}

// 1️⃣ Generate Medium Markdown (EN & ES)
['en', 'es'].forEach(lang => {
  const tmpl = fs.readFileSync(`templates/medium_${lang}.hbs`, 'utf8');
  const compiled = Handlebars.compile(tmpl);
  const md = compiled(data);
  writeIfChanged(`content/2026/10/06/content-automation/medium_${lang}.md`, md);
});

// 2️⃣ Generate Substack newsletters
['en', 'es'].forEach(lang => {
  const tmpl = fs.readFileSync(`templates/substack_${lang}.hbs`, 'utf8');
  const compiled = Handlebars.compile(tmpl);
  const md = compiled(data);
  writeIfChanged(`content/2026/10/06/content-automation/substack_${lang}.md`, md);
});

// 3️⃣ Generate Bluesky JSON payloads
['en', 'es'].forEach(lang => {
  const payload = {
    type: lang === 'en' ? 'progress' : 'avance',
    text: `${data.title} – ${data.summary}`.slice(0, 300) // enforce limit
  };
  writeIfChanged(
    `content/2026/10/06/content-automation/bluesky_${lang}.json`,
    JSON.stringify([payload], null, 2)
  );
});

// 4️⃣ Update metadata flags
const metaPath = 'content/2026/10/06/content-automation/metadata.json';
const meta = JSON.parse(fs.readFileSync(metaPath, 'utf8'));
meta.medium_generated = true;
meta.substack_generated = true;
meta.bluesky_generated = true;
writeIfChanged(metaPath, JSON.stringify(meta, null, 2));

console.log('✅ Content generation complete');

Key points

• Handlebars templates keep the prose DRY. Only the language‑specific strings differ.
• writeIfChanged prevents unnecessary Git diffs, which keeps the CI cache happy.
• The Bluesky payload is built with a hard limit (slice(0, 300)) to guarantee schema compliance before the API call.

3. CI Integration

The new GitHub Actions workflow (.github/workflows/content.yml) runs on a schedule (cron: '0 6 * * *') and on any push to main:

name: Content Automation

on:
  schedule:
    - cron: '0 6 * * *'   # 6 AM UTC daily
  push:
    paths:
      - 'content/**'
      - 'scripts/**'
      - 'templates/**'

jobs:
  generate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      - run: npm ci
      - run: node scripts/generate-content.js
      - name: Commit changes
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: "chore(content): auto-generate $(date +%Y-%m-%d) [skip ci]"
          file_pattern: "content/**"

The workflow auto‑commits the generated files, which is exactly the three commits we see in the diff:

• chore(content): auto-generate 2026-10-07
• chore(bluesky): posts 2026-10-07
• chore(devto): article 2026-10-07

Notice how the metadata.json flags are now set to true after generation:

-  "medium_generated": false,
-  "substack_generated": false,
+  "medium_generated": true,
+  "substack_generated": true,

4

---

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-10-07

#playadev #buildinpublic