How Minn Admin got built
Minn Admin is a from-scratch replacement for the WordPress admin, built as a single-page app. This reads one day of that build, the day its writing editor took shape. Almost every instruction arrived with a screenshot.
The route, plotted
Eight waypoints across four days, from a clean install to a shipped release. Hover any marker to read the direction that set it, and how it steered the build.
A day of relentless iteration
By day three the app already stood up, themed and routing. This day was about the writing experience. The author opened not with a fresh idea but by handing the agent its own notes, a live post to work against, and a short list of exact pain points.
I'd to work on editor improvements. Anything in our notes? If so feel free to work on them. Here are a few pain points… When using the "/" to pick a block, I have to use my mouse to pick one. I'd like to be able to continue typing to select one of them.
That is the method in one message. Point at a real artifact, list what is wrong, and let the agent work the list. From there, nearly every instruction rode in on a screenshot.
A screenshot turns "this is broken" into a shared, precise fact. A typical one:
Found a bug. When I attempt to put an image here: [Image #4] It shows up above that position for some reason, not where the marker was typed out. [Image #5]
The most consequential instruction of the day was not a fix. It was a decision to stop borrowing from WordPress and build the piece properly:
Rather then bounce out to WordPress Edit Media, can we build our own version of the media editor?
The author also reversed himself without ceremony. Spell check was turned off, then a few hours later turned back on:
I think I was wrong about spell check. Can we revert that? It seems like the block editor is cleaver and only sometimes shows the spellcheck marks.
With an agent, a reversal costs a sentence, so trying the wrong thing first is cheap. By evening the editor had crossed a line:
The editor is starting to feel like something I can really use over the default block editor… it already feels lightyears ahead. What do you think? Maybe we could write a longterm plan for the Minn Admin Editor?
What came next
Minn Admin came together in four days. The session openers trace the shape: stand it up, give it a real design, sharpen the editor, then ship and extend.
Start from zero. "I have a clean WordPress site here locally." A fresh install, nothing to port.
Give it a real design. "I'd like to create this as a custom theme… Use the claude_design MCP." The look came from a design file, not hand-written CSS.
Review and merge. Accept the pull request from the previous session, then keep building on it.
Sharpen the editor. A full day on the writing experience. Custom blocks, image handling, embeds, and a lot of screenshots.
Add the management surfaces. "Can we add filters to plugins and themes?" The admin beyond the editor.
Make it work on mobile. A responsive pass over the single-page app.
Ship, then chase a prod bug. "I just deployed v0.7.0 and discovered a bug on my production site." Shipped software, real feedback.
Extend it. A research project for a potential plugin adapter. The platform starts reaching past itself.
What to borrow
Minn Admin is a UI-heavy build, and the direction shows it. If you want to shape a polished interface with an agent, these are the moves that carried this one.
The author aimed the agent at a live post URL and a screenshot for nearly every change. "Fix this" had an exact target. One day of the build carried 24 screenshots, and the whole build carried 106.
When WordPress's own media dialog got in the way, the instruction was not to style it. It was to replace it: "can we build our own version of the media editor?" Own the surfaces you touch every day.
Spell check went off, then back on once it proved wrong. With an agent, changing your mind costs a sentence, so it is fine to try the wrong thing first and learn from the screenshot.
Only after the editor felt usable did the author add Playwright tests and bake the version bump into the release process. Tooling followed conviction, not the other way around.
If you built this again
Knowing what a day of screenshots taught this editor, here is how you would start a similar one. Copy a prompt and adapt it.
Front-loads the markdown, keyboard, and custom-media decisions the original build reached one screenshot at a time.
Names the screenshot-driven loop and the editor-frontend parity rule up front, instead of discovering them.
Bakes in the release automation the original build only added after several manual releases.
This recap is the output of an editor pass over the project's agent transcripts. A deterministic extract (command-center flow --editor) pulls the direction, the agent trace, and the embedded screenshots from the most representative session. A single model pass captions each image and writes the narrative.
Every quoted heading is verbatim, typos and all. Landmark captions were recovered from images embedded in the transcript, then summarized. The originals are never reproduced or shared.