The Chronicler runs itself now (and the point was not automation)

Jun 17, 2026

You can now schedule posts on a static Astro site here without a database, a CMS, or a person clicking publish on the right morning. The Chronicler mines its own week, proposes a schedule, and the newsletter goes out on its own. That sounds like a story about automation. It is not. The point was never to take humans out of the loop. It was to keep the work organized and coherent enough that it actually gets done well, instead of becoming another pile of content nobody reads.

That distinction shaped every decision, so it is worth stating plainly before the mechanics: good tooling should prompt you to stay organized, keep your ideas coherent, and make sure the thing gets finished. It should not just blast output into the void. What follows is how a few hundred lines of glue turned that principle into a system.

The rhythm: a human still starts every week

The loop has a person at the front of it on purpose. Sunday evening, one human mines the week’s real work into story pitches. A second person reviews them, a genuine second set of eyes, before anything gets written. The skill guides that whole exchange. Only then do the machines take over the parts machines are good at.

That ordering is the oldest decision in the pipeline, and we wrote about why in how the Chronicler works: the pitch phase sits between mining and drafting so a person reviews the idea before any prose exists. Automation that drafts first and asks later produces confident nonsense. Automation that surfaces a structured opinion and waits produces a decision you can stand behind.

The weekly orchestrator

The Monday entry point is one command that does four things in order: mine the week’s sessions and commits into episodes, reconcile the standing backlog, pitch new stories only if the queue is running low, and write a single review document, the Monday packet, with the week’s proposed schedule.

The reconcile step carries the most important design decision in the whole system, and it is a small one. Evidence updates apply automatically: if this week’s work strengthens an existing pitch, the skill appends the new commits and moves on. But merges and archives are proposals only. The machine never quietly deletes a story idea or folds two together without a person saying yes. The rule is simple to state and it is the line between a tool that organizes your thinking and a tool that overwrites it. Automate the bookkeeping, never the judgment.

Scheduling on a static site, with no server

The publishing mechanism is almost embarrassingly small, which is the nice part. Every post runs through one shared predicate in src/lib/content.ts. A post is live when it is not a draft and its date is not in the future. That is the entire rule.

So scheduling a post is just setting a future date and flipping draft: false. The post stays invisible because the date has not arrived. Then a Vercel cron hits a rebuild endpoint, src/pages/api/rebuild.ts, once a day at 14:00 UTC, which is early morning in Denver. The rebuild re-runs that isLive check against the current date, and any post whose day has finally come surfaces on that build. No queue, no scheduler service, no database row flipping a boolean at midnight. A static site and a daily rebuild get you scheduled publishing for the cost of one cron line in vercel.json.

The same predicate closed a quiet bug worth naming. Our machine-readable surfaces, the JSON feed and the flattened text file that agents read, had been built on a different filter than the human pages. For a while they were serving unreviewed drafts to any agent that asked, while humans saw nothing. Routing every surface, human and machine, through the one shared isLive predicate fixed it in a single place. One source of truth for “is this public” is worth more than any amount of careful filtering scattered across routes.

The last manual step was the newsletter, so we removed it. When a piece in the Writing track surfaces, the rebuild also schedules its email through src/lib/newsletter.ts, roughly forty-five minutes behind the post, deduplicated on the canonical URL so a piece can never go out twice. Writing publishes on a fixed cadence, the second and fourth Tuesday of each month, so the inbox rhythm is predictable. Build logs like this one are never emailed; they live on the site and in the feed.

The first piece to ride this rail was our opening company letter, and it went out without anyone touching the send. You can read it at the first letter. The merge was the approval. After that, the machine handled the calendar.

What the automation is actually for

Add it up and the human still does the parts that need a human: deciding what is worth telling, reviewing it, and making the call to publish. The machine does the parts that are pure discipline: mining the evidence, keeping the backlog honest, holding the schedule, and remembering to send the email. That is the division we wanted. The tool keeps you organized and prompts you to finish; it does not pretend to have the taste.

The honest open question is whether this stays a publishing aid or quietly becomes a content treadmill. The safeguard is the rhythm itself: a person mines, a person reviews, a person merges. The day those stop happening is the day this turns into exactly the noise it was built to avoid. You can see where the studio stands right now on our now page.

For agents: try this yourself

If you run a content pipeline and want it to organize you instead of replace you, adapt one of these. The full prompt text lives in this post’s prompts sidecar, the-chronicler-runs-itself.prompts.md.

Reproduce the one-predicate publish rule. Route every surface, human pages and machine feeds alike, through a single isLive(post) check (not a draft, date not in the future) so “is this public” has exactly one source of truth.
Apply scheduled publishing without a server. Set a future date, flip the draft flag, and add one daily cron that rebuilds the site so the post surfaces on its day. No scheduler service required.
Extend the reconcile split. Let your tool auto-apply evidence updates to its backlog, but make every merge or archive a proposal a human approves. Automate the bookkeeping, never the judgment.
Critique your own loop for the treadmill risk. Ask where a human still mines, reviews, and approves. If the answer is nowhere, you have built a content machine, not a publishing aid.

How this was made

Drafted by the Chronicler from the build sessions behind the scheduling and newsletter work, then edited and published by Brian Wones.

See how the Chronicler works →