Every week my content system outlines the blog, drafts the posts, critiques them, and queues the publish, and I touch it once, on Saturday morning. Here is the whole machine mapped stage by stage, including the parts that broke.
One vault, two runtimes
The shape first, then the parts.
Everything runs on one Obsidian vault. Plain markdown files, no database, no queue service. Every post is a file, and every file carries a status field in its frontmatter: outline, drafted, scheduled, posted. That status field is the API. Each stage of the machine reads files at one status and writes them back at the next. No stage calls another stage. They only ever talk through the files.
Two runtimes work the vault. Claude Code handles the jobs that need code and network: publish scripts, image rendering, watchers. Cowork, the desktop agent, handles the jobs that are pure reading and judgment: outlining, drafting, critique. Both read and write the same files. Neither one is the source of truth. The vault is.
That is the whole architecture. Everything below is stations along the line.
Sources in: what feeds the machine
Three inputs feed the vault.
The weekly note. Every week I write down what shipped, what broke, stories worth telling, observations, and hot takes brewing, plus an anti-topics list of stuff that must not get drafted. Written by hand, on purpose.
The saved-posts analyst. Whenever I clip a LinkedIn post I like with the Obsidian Web Clipper, a daily routine reads the clip, writes a structured swipe note on the craft, and downloads the post image the same day. That last part matters: a clipped post hotlinks its image to a URL that expires in months. Download the asset the day you capture it or lose it.
The trend feed. A routine that collects what the industry is currently saying, so counter-takes push against the real orthodoxy instead of a remembered one.
The honest ranking: the hand-written weekly note is the highest-value input in the system, and nothing automates it. The machine turns raw material into drafts. It cannot make the raw material.
The production line
The factory pass runs Thursday to Friday, station by station.
Thursday, the outliner. It reads the weekly note and the idea backlog and fans them into blog outlines: title, hook, a value proposition naming who the post is for and what shifts for them, and the section beats. An outline with no clear value gets flagged for me instead of padded into a draft.
Friday early, the drafters. The blog drafter expands each outline into a full draft, beat for beat. Thirty minutes later the LinkedIn drafter derives the week's short posts from the deepest one, so the week is one idea atomized, not six unrelated takes.
Friday mid-morning, the critic. It rereads every draft against the voice rules and writes editor notes into the file: weak lines, banned words, claims missing a source.
Friday late morning, the image step renders and attaches the visuals.
Each station is a scheduled routine. Each reads files at one status and leaves them at the next. Pretty much a factory: you work on the machines, and the products come out.
The one human gate
Then everything stops and waits for Saturday morning.
By the time I sit down, every draft is written, critiqued, and illustrated. My pass is voice and judgment only. Read every line, fix what does not sound like me, flip the status. No outlining, no formatting, no chasing. One sitting.
The gate is manual on purpose, and it stays manual even though automating it is one flag away. I made the full case for that in its own post. The short version: automate the work, keep the door.
Publish and watch
Statuses drive the exits.
A blog post flipped to scheduled gets picked up by a routine that opens a pull request on the site repo on GitHub. LinkedIn drafts land in Postiz, queued per channel. The newsletter goes out on Resend. Watchers close the loop: when the world confirms a thing went live, the watcher flips the file to posted.
Here is the receipt from when that broke. One watcher matched posts at a single status and quietly skipped the rest. Eleven posts were live on LinkedIn while the vault called them stuck, and the posted count read 7 when the true number was 18. That bug is now a rule in this system: test a watcher against the live system it watches, not against the vault. The vault only knows what got written into it.
Steal the minimum version
You do not need my whole line to start. You need four things.
One folder of markdown files. One status field in the frontmatter. One scheduled routine that reads files at one status and writes them at the next. One weekly review block where you read what it made and flip the statuses yourself.
Start with the single routine that removes the step you hate most, and prove it end to end before you build the next station. And whenever a migration plan hands you an infrastructure prerequisite, test the smallest version before you accept it. Mine insisted nothing could move without putting the whole vault in git. That was only true for cloud runs. A local pilot proved it wrong in minutes.
I keep the stage checklist for this system, statuses and all, as a one-pager that goes out with The Production Layer, my newsletter at timurtek.com. Subscribe and steal it.
The machine is not the model. It is a folder, a status field, and a review block that respects your Saturday. Build the folder first.
