When I stumble upon an unsolved or undocumented problem and solve it, I like to document it here.
This blog federates over ActivityPub through Ghost so Mastodon users can follow @index@subaud.io. standard.site is the counterpart for the AT Protocol side: a set of lexicons that describe a blog as records in an atproto repo, the same identity and data layer behind a Bluesky account. Anything
A deploy in one of my CDK projects passed every gate I have — CI, cdk synth, code review — and merged. The CloudFormation stack deployment to AWS failed with: InvalidRequest: Unzipped size must be smaller than 262144000 bytes 262,144,000 bytes is 250 MiB, AWS's hard limit on
The last two posts here were about the skills in this plugin — one learns my writing voice from my published posts, the other revises a draft section by section. Neither can do anything without a way to reach Ghost: to read what I've already posted, create a draft,
Fixing a draft used to mean regenerating the whole post. When a section didn't sound right, the new version would correct it and overwrite three others that were already fine, so I kept a corrected copy open in the Ghost editor, regenerated, and pasted the good paragraphs back
Your writing voice is already on the page. Everything you've published is a record of how you actually write — consistent enough that a tool can learn it from your posts, even if you couldn't spell it out yourself. ghost-blog-mcp is the Claude Code plugin
I've written before about my feature-workflow plugin — capture a feature, plan it, get it reviewed, ship it, mostly one repo at a time. The repos in a couple of my orgs change together, though, and coordinating a change across them in Claude Code kept hitting the same
I built much of my now-playing project with a Claude Code autopilot. I describe a feature, and it gets planned, implemented, reviewed, and shipped without me typing the intermediate steps. To do the implementation and the git work, the autopilot spawns subagents that write to the working tree. When
My now-playing kiosk has a long install document, and it's a long document. Three hundred and ninety-three lines, eight sequential phases, six environment variables that each gate a different optional install path, and a fifty-line section on a particular display whose touch input lives on
Most of the now-playing kiosk was built with my autopilot workflow, which I've written about before. I describe a feature, it gets planned, built, and reviewed, and it ships. For most of the project that's the whole story. But the kiosk's job is
Three patch releases in one evening — how using my own plugin on a real project surfaced a confusing schema field, an internally inconsistent verdict, and the case for state as a first-class concept.