The Writing Machine

The actual setup behind this newsletter: skills, agents, hooks, and the one button I am not allowed to press.

People who ask how I use AI usually expect an opinion. Here is the wiring instead. A lot of what's below runs on my own laptop inside Claude Code, and every piece exists because something went wrong once.

Four moving parts: skills, agents, hooks, and a local archive. The first three are not metaphors I invented for this page. They are the actual building blocks of Claude Code, the terminal version of the assistant, and they are plain files on disk. They do different jobs described below.

Skills: a written procedure, not a clever prompt

A skill is a markdown file describing a job I do repeatedly. Writing an issue is one. Turning an issue into social posts is another. Closing the week is a third.

Each file has the same fixed sections, and the sameness is the point:

• Trigger: the exact phrases that should start this, and what should not
• Inputs: what must exist before it runs
• Pre-flight: the checks that happen before any work, so it fails early instead of halfway
• Steps: numbered, in order
• Outputs: where the result lands
• Verification: how I know it worked, written as something testable
• Do not use this for: the boundary

That last section does more work than any of the others. A procedure without a stated boundary gets applied to everything and quietly becomes useless.

I add one more section to anything important: Baseline. It records what the model produced for the same request without the skill. If the two are indistinguishable, the skill is ceremony, and I delete it.

Agents: a second reader who cannot see the conversation

The most useful component is also the least glamorous. It is a separate reviewer that judges a finished draft.

It runs in its own context. It does not see the conversation that fine-tuned the text, how long the piece took, which parts I paid extra attention to, or that I am tired and it is late. It receives two things: the draft body, and a file describing my voice.

That file is not adjectives. It is a set of measurable rules taken from my own published work — length bands, how many subheadings, which sentence shapes I fall back on when I am being lazy, the reassuring phrase I reach for when I do not want to commit. The reviewer reads that file at runtime and returns a verdict per rule, with the specific line that broke it.

Separating those two things matters more than the tooling. The rules live in one file that I edit deliberately; the reviewer is a program that reads it. Change the standard in one place and every future draft is judged by the new one.

Drafts fail this. The most useful failure is the one where every individual rule passes, and the piece still comes back weak, because that is the moment I find out I have written something competent about nothing.

Hooks: rules that fire whether I agree or not

Skills and agents are instructions. Instructions get skipped when you are in a hurry. Hooks don't, because they sit between intent and action and can refuse.

Mine are small and boring:

• One watches for any attempt to click Publish or Schedule on my site. It blocks it and prints why. My assistant can write the piece, build the images, and set up the draft. Pressing publish is mine, permanently, and six lines of shell script enforce it rather than a promise.
• One strips typographic tics out of finished documents automatically, so I stop arguing about them.
• One refuses to let stray files land in the wrong folder, because a messy system stops being used.
• One writes a single line to a log whenever something is built or decided, so I can find the session again three weeks later.

The publish hook is the one I would keep if I could only keep one. Not because I would otherwise publish something terrible, but because the boundary between "the machine helped" and "the machine did it" needs to be a wall, not an intention. Anything I only intend gets negotiated away at eleven at night.

The archive is local, and it is read first

Point one of these tools at the internet, and it returns the average of everything already written on a subject. That average is exactly what it sounds like.

Mine reads inward first. A couple of thousand notes — books, arguments I lost, half-formed observations written on trains — sit in a folder of plain text files on my own machine. They are indexed locally: an embedding model running on the laptop, stored in a small database next to the notes, searched offline. Nothing about that archive leaves the house, which is why I am willing to keep the honest notes in it.

When a subject comes up, the first question is not what the world thinks. It is what I have already thought, sometimes years ago, in words I no longer remember writing. A piece that starts there argues from something lived. A piece that starts from a search argues from a consensus I have no stake in, and readers can feel the difference within two paragraphs even when they cannot name it.

What runs without me

Two things run on a timer, and both are more mundane than they sound.

The first watches my inbox. When an idea occurs to me, I type one line into my task list and tag it. Every fifteen minutes, a small script checks whether anything carries that tag. Almost always the answer is no, and nothing further happens, so it can run ninety-six times a day. When the answer is yes, a session starts and picks up the idea. If it recognises what kind of job this is, it does the work and puts the result in a chat channel. If it does not, it asks me one question with numbered options and waits.

The second works overnight, and it's derivative on purpose. Two evenings a week, at eleven, two or three social posts are drafted from fragments of a book I have already written. Nothing is being invented there. A passage that exists in finished form gets compressed for a shorter context and a different audience, then measured against the voice rules like anything else. In the morning I read them on my phone, numbered. Approving one is a reply in that same thread: the word yes and the draft number I want. That reply is the only thing standing between a draft and the publishing queue.

That distinction is worth holding on to. There is a large difference between a machine producing new claims in my name and a machine making a smaller version of something I already stood behind. Only the second is running here, and that's why I can leave it unattended overnight.

That reply is rarely a bare "yes, 2". There is nearly always something I want changed first, and the correction takes a sentence. It is exactly the amount of friction this deserves.

The pattern is the same in both, and it is the only scheduling principle I would defend: the system runs right up to the last reversible step and stops. Whatever comes back from me, a correction or a go-ahead, is the shortest part of the process. Without it, nothing moves.

The issues themselves live in a small database with their status, date and structure, because a pipeline you have to hold in your head is a pipeline you will drop in week nine. And where there is no interface left, there is a browser: my publishing platform withdrew the API I was using, so drafts now get assembled by driving a logged-in browser window, click by click. Inelegant, and it works, which describes most of this system.

If you want one of your own

None of this required writing software. Everything above is text files in folders, plus a handful of short shell scripts, and it is worth knowing which is which before you start.

Skills are Markdown files in a skills folder. Each describes one job, and the assistant reads the relevant one when the situation matches the trigger you wrote at the top. If you can explain a task to a competent new colleague in a page, it can be a skill.

Agents are separate assistants with their own instruction file and their own working memory. You hand one a task, it works out of sight, and you get back its report rather than everything it read along the way. That isolation is the feature: my draft reviewer is a good judge precisely because it never saw me writing.

Hooks are shell scripts registered in a settings file and attached to a moment: before a tool runs, after a file is written, when a session ends. A hook that exits with the right code cancels the action. This is where the publish blocker lives, and it is about fifteen lines of script in total.

Connections to your own tools come through a small protocol with servers for things like a task manager, a calendar, or a notes folder. That is how an idea in my task list becomes work without me copying anything by hand.

Scheduling is not part of the assistant at all. It is the ordinary scheduler your computer already has, starting the assistant without a screen at a fixed time.

Order matters more than inventory. Start with one skill you genuinely do every week, and write its verification section first so you have to say out loud what a good result looks like. Add a hook only after you have caught yourself breaking your own rule once, because a rule you have never broken does not need enforcement, and you will resent the friction. Agents and scheduling come last, when the manual version works, and the repetition is the only thing left to remove.

Two warnings. The names and details will drift as the tools change, so treat the shapes as durable and the specifics as perishable. And every piece you add is a piece you maintain. Written instructions do not break loudly when they go stale; they expire quietly, which I have written up separately as The Groundskeeper. The version of this setup that survived a year is a fraction of what I built, and what I deleted was mostly clever.

The part that does not scale

None of the above decides what is worth writing about.

Retrieval, argument, inspection, scheduling: it all happens after somebody noticed something. Noticing is not a task you can hand over. No system tells me the meeting I walked out of angry contained the idea, or that the confident thing I said on Tuesday was wrong by Thursday.

The machine will also produce an opinion on request. It will be plausible, balanced, and worth nothing, because the value of an opinion comes from someone standing behind it who can be wrong in front of you.

So the constraint on this newsletter was never how fast I could write. It was how often I have something worth saying, and that number has not moved.