Building the machine that writes the blog
A writing workflow becomes a small publishing system with a frontier, a security gate, and exactly one draft in flight.
The development blog now has a writing system, not only a place to put posts. It can turn a coherent range of the game’s history into one draft, check that draft for details that should remain private, open it for human review, and learn from the edits after publication. The goal is irregular but durable writing: enough automation that the history gets covered, with the editorial decision still mine.
Start with the boundaries#
The first plan looked like three passes: narrative, security, voice, then a pull request. Grilling it exposed the state around those passes. What counts as one story, what happens when the newest work is unfinished, how does a rejected draft differ from a forgotten one, and what prevents two sessions from claiming the same commits? Those questions produced a domain model before they produced a skill. A change cluster is the editorial story, its git range is the contiguous evidence, and the registry frontier says how far the blog has covered.
Teach the system the constraints#
Voice and sensitivity needed separate inputs. The voice baseline came from 3,010 author messages extracted locally from conversation exports, reduced to phrasing patterns and then deleted with the source material. The security rules took the opposite approach: concrete identifiers and infrastructure coordinates became literal checks, while broader judgment rules cover secrets, player data, and attack-relevant detail. One tells the agent how the sentences should sound, the other defines what those sentences must not reveal.
One draft means one draft#
The resulting skill is a six-step state machine. Every run first reconciles the previous pull request, then resolves one change cluster, drafts it, sends it through a fresh-context security review, checks voice and structure, and opens a single pull request. The registry’s final draft row is the lock. If that pull request is still open, another run stops; if it merged, the run can propose lessons from the author’s edits; if it closed without merging, the subject remains recorded as rejected so it is not quietly drafted again.
The pull request is the human gate; the registry row is the concurrency gate.
A reminder, not a publishing schedule#
Meaningful changes do not arrive every Tuesday, so the last piece is a conversation-start hook rather than a cron job. It reads the same registry and suggests another run after seven quiet days, at most once per day. An empty registry points toward the approved 32-post backfill, while an open draft points toward review instead of more writing. The machinery is now ready; next is to run the first cluster through it and see how much of this design survives contact with an actual post.