How I moved monthly data refreshes, audits and a daily AI review off a laptop that was often closed, onto GitHub Actions: measuring access first, secrets that never pass through the assistant, one lock and a tested calendar, state kept in git, and the risk review that should have come before the merge.
Between January and September 2026, I led the upgrade of an editorial application’s rich-text editor from CKEditor 5 v26 to v47.3: about 55 in-house plugins, 53 sub-PRs and 683 files. Here is what we learned, from the bare-editor strategy to the bugs only real typing revealed, the AI tooling that made it repeatable, and the two CKEditor issues it led to.
At work I’m running a CKEditor 5 migration from v26 to v47 across some twenty in-house plugins. Instead of tracking it all by hand, I wrote ckeditor_audit: a read-only MCP server that sorts every plugin into four migration statuses, flags what’s live in production, searches the code with ripgrep + ast-grep, and cuts the AI token bill by 80 to 95%.
Composable Claude Code skills turned a pile of unreviewed real-estate listings into a repeatable pipeline: one skill reviews a single listing, another loops over a site, a third fans out across all sites — each with its own guardrails and an audit gate before anything publishes.
How I built a schema-driven MCP server that lets an AI assistant manage many heterogeneous WordPress sites through a single typed interface — architecture, trade-offs and lessons learned.