When I stumble upon an unsolved or undocumented problem and solve it, I like to document it here.
A while ago I wrote about a feature-workflow plugin that added structure to how I work with Claude Code (the later update covers where it went): capture an idea, plan it, implement it, ship it. I've kept moving more of the process out of the conversation and
The previous post covered the side project where muda's standard came from. The first pipeline muda ran on after that was an internal platform at work: an AWS CDK app with five Docker images, three ECS services, an AWS Batch compute environment and a small website. A dev
In September a dev deploy of one of my side projects took 29 minutes, and a deploy of a commit that changed nothing updated all 11 of its CloudFormation stacks and rebuilt both of its Docker images. The pipeline had been built the way I build most things now, one
I use more than one Claude subscription. Most of the reason is usage: when one account runs low on its limits, I want to keep working on another. Claude Code normally has one login, so moving to another account means signing out and signing back in through the browser each
Agents need credentials all the time, and when one needs a key, it asks me to paste it into chat. Anything pasted into chat is sent to the model provider and saved in the session log, and I don't want API keys in either place. creel is a
Every machine I set up used to be an imperative pile: a dotfiles repo with an install script, a list of brew install commands, and a few curl | sh lines that had accreted. The trouble with a pile of steps is that it only tells you what to do, never
I have written a lot of posts about individual pieces of how I work, like the terminal, the multi-repo workspaces, the coordination bus, and the harness that drives the model. What I never had was one place that put them together, so when someone asked how I actually work,
When I added OAuth to the MixCraft MCP server, the identity provider was Clerk, and Clerk did the whole job: it was the OAuth authorization server the MCP client talked to, it signed in the user, and it issued the tokens the MCP server verified. The next remote MCP server
The first consumer of my runner-set library — a CDK construct that runs GitHub Actions jobs on Lambda MicroVMs — was another of my own repos, and the migration was done by an AI agent. The Claude session that moved its nine CI jobs onto the runners filed a field report,
I've written about this setup twice: Building my Terminal Setup covered the shell, fonts, and Ghostty, and A tmux Workspace Built Around the Claude Code Autopilot covered the project launcher, worktrees, and per-project tmux servers. Since then the right side of every workspace grew a three-pane