Blogsmith is an owned AI blog engine that runs inside your own repo. It turns your material — sales-call transcripts, seed themes, or live SEO demand — into topic proposals, drafts the chosen one in your brand's voice with citations, runs a multi-pass quality gate, and opens a pull request or draft article. Never a live post. Claude reads the signal, writes the prose, and scores it for voice and factuality; deterministic scripts do every side effect; a human merges anything that goes live. Unlike a rented content tool, you own it: every brand is a fork you control, every decision is a file in git, and nothing reaches your blog without a person saying yes.
- Owned, not rented. A SaaS content tool is a black box billed per seat. This is the same capability in versioned code — swap a data provider, read every decision, keep your transcripts and copy in a repo you control.
- The model never publishes. Claude mines, drafts and judges; it never opens a live post.
- Quality is enforced, not hoped for. Deterministic gates plus a model judge block customer PII, competitor mentions, fabricated stats and robotic prose before a draft can reach the publish step.
- One engine, many brands — and many destinations. Each brand is a fork of one template; a new brand or a new publishing target is configuration plus one publisher script, not a rewrite.
01 · Why own an AI blog engine instead of renting one
Most AI blog tooling is rented: a console that drafts on a prompt, hides how it decides, and locks your voice and topic history in its own tenant. The real risk: it can push a post live with a model in the loop. Owned as code, the inverse holds — what's mined, how voice is matched, what the gate blocks, and what may be published become things you set and audit. And because each brand is its own build, one engineering investment serves every brand you run, with content and credentials kept apart.
02 · Shape of the system
Everything specific to a brand — its mining mode, publishing target, taxonomy, voice and style, internal links, banned terms, competitor list, byline rules, locale — lives in configuration, not code. The same skills run two ways.
| Mode | How it runs |
|---|---|
| On-demand | Open a brand's clone and drive it from the CLI or desktop app — mine, draft, review, open a PR. Nothing scheduled runs; local reads, a PR or draft at the end. |
| Scheduled | The same skills run unattended on a weekly cron as a mine → draft-review → publish pipeline, toggled on with a single repository variable. |
A brand is a fork of the blogsmith template, so security patches, new review passes and schema fixes flow downstream with a sync — while each fork keeps its own secrets, scoped token and content.
03 · How it works — the pipeline
The loop turns a raw signal into a reviewed, ready-to-merge post — and stops at a human.
- Mine — Haiku reads the brand's signals, clusters them into topic proposals, and dedups against the live blog and the backlog. Output is schema-checked, not freeform text.
- Pick — a person approves a proposal (or the cron auto-picks the redraft queue first, then a fresh idea).
- Draft — Sonnet writes the post in the brand's voice, reading the voice file and the live content schema, with inline citations and a sources block.
- Review — deterministic passes first and the model last, ending in one blocking verdict bound to the draft.
- Publish — a scripted, no-model step opens a pull request (Astro) or creates a draft article (Shopify). It never publishes live.
- Merge — the one human gate. A person merges the PR or publishes the Shopify draft when they're happy.
On a schedule, a blocking review feeds its reason back into the proposal and retries before giving up; the publish step only runs if review passed, so a blocked chain never opens a PR.
04 · Two brand shapes, one pipeline
The same skills branch on two config dimensions — how topics are mined, and where posts are published. Two complete shapes ship today, but the pipeline doesn't care where a post lands: a new destination is a config switch plus one publisher script, not a new pipeline.
| Shape | Mined from | Publishes to | Output |
|---|---|---|---|
| Source-driven · Astro | Owned material — sales-call transcripts and seed themes | An Astro content repo | Pull request |
| Keyword-driven · Shopify | SEO demand — keywords, SERP results, competitor sitemaps | A Shopify store's blog | Draft article |
05 · The quality layer
Deterministic gates first, the model last. The result is a single blocking verdict plus non-blocking warnings surfaced into the PR; any P0 finding hard-blocks, and on a schedule a blocked draft triggers a retry rather than a publish.
| Pass | What it checks | Engine |
|---|---|---|
| Scrub | Strips invisible characters; checks body and footnotes against the competitor list and the customer-name blocklist | Deterministic |
| Metrics | Textual variety and rhythm, plus length, frontmatter and internal-link bands | Deterministic |
| Judge | Voice match, structure, sourcing strength and factuality risk, with semantic backstops for paraphrased PII and competitor mentions | Model · Sonnet |
| Factcheck | Resolves cited claims to their sources, fetches them, and scores how well each is supported | Deterministic + fetch |
The hard-block categories are fixed so the bar doesn't drift: customer PII (blocklist plus a semantic sweep), competitor mentions (body and footnotes), fabricated stats (poorly-supported cited claims), broken frontmatter (schema validation), and robotic prose (flat, mechanical writing — caught by signals calibrated against a real published corpus so house style isn't mistaken for a tell).
Each passing draft is bound to its review. On the Shopify path the publish script refuses to create the draft article unless the review is clear and the draft hasn't changed since. On the Astro path the scheduled gate halts a still-blocking draft before publish, and the output is a pull request a person reviews and merges — so nothing reaches a live post unreviewed either way.
06 · Safe by construction
The non-negotiables — each enforced in code, not convention:
| Rule | What it guarantees |
|---|---|
| No model on the publish path | Mining is structured tool-use with post-validation; publishing is plain API calls. The model drafts and judges — it never opens a live post. |
| No live auto-publish, ever | Every output is a pull request or a draft article. A human merges the one thing that goes live. |
| Injection containment | Untrusted text — transcripts, web pages, SERP results — is fenced and scanned for instruction patterns before the model reads it. |
| Allowlist, never blocklist | Each skill declares exactly the tools it may use; unlisted tools are denied. The miner has no shell or edit access. |
| Brand isolation | Each brand is its own fork with its own secrets and a scoped token; no brand's content or credentials touch another's. |
| Secrets stay out of git | Credentials live only in gitignored env files or the secret store, never in a tracked file. |
07 · Models
Pinned per skill, hardcoded — not config-driven — so the system can't silently drift onto a model the guardrails weren't tuned for. Every model is from Anthropic.
| Model | Role | Default? |
|---|---|---|
| Claude Haiku | Topic mining — structured, schema-checked proposals | Yes |
| Claude Sonnet | Drafting and review | Yes |
| Claude Opus | The hardest single runs — a per-invocation override | Opt-in |
Publishing uses no model in its actor role; the only optional model touch is a one-line PR summary that falls back to a template, so the PR always opens.
08 · Integrations
blogsmith plugs into your publishing target and your demand signals — these are defaults, not requirements.
| Category | Examples |
|---|---|
| Publishing | Astro + CloudCannon, Shopify |
| Source control | GitHub |
| SEO & demand signals | Google Analytics (GA4), Search Console, SERP & keyword data |
| Public research | Hacker News, Stack Exchange, Wikipedia |
Swap any provider for the one you already run, or point it at a publishing target we haven't listed — both are config changes, not a new build. We tailor the set to your stack.
What Blogsmith is, in short
- An owned blog engine. Mine → draft → review → publish-as-draft, in versioned code forked per brand, where Claude does the judgement and scripts do every side effect.
- Safe by construction. A human merges the one thing that goes live; the publish path runs no model, the reviewed draft is bound to what ships, and PII, competitor and factuality gates are enforced in code.
- One engine, any brand or destination. Source-driven Astro and keyword-driven Shopify run on the same skills today.
Same playbook, different surface: Outbound Agent does it for outbound, Marketing Ops for your Google marketing stack.