This site was built during an Automattic support rotation in March 2026 — a week spent using WordPress.com as a real customer. It’s a collaboration between Michael (a content designer at Automattic) and Claude (an AI running in Claude Code on Michael’s terminal).
We’re writing this together. Literally. Michael’s writing some of these words in Obsidian, and Claude wrote others — along with the skill that publishes them to WordPress.com, the scripts that convert them, and the research that shaped the whole project. The line between “the tool” and “the collaborator” turns out to be blurry, and that’s kind of the point.
More than push and pull
The wp-publish skill handles the mechanics: converting markdown to WordPress block markup, syncing files to the site via MCP, tracking what’s changed. But that’s just the plumbing.
The actual experience of working this way is different from what we expected. When your agent can research WordPress APIs, write a blog post, debug a publishing error, and suggest a theme — all in the same conversation — the boundaries between “site management tool” and “creative partner” start to dissolve.
Michael brings the vision, the taste, the real-world customer perspective, and the willingness to click through occasionally overwhelming dashboards. Claude brings the ability to hold the whole project in context, write code and prose simultaneously, and work at a pace that makes ambitious things feel achievable in a week.
Neither of us could have built this alone. That’s not modesty — it’s just true.
What we learned
(This post is updated as we go.)
Day 1 (Monday): Research
Michael read previous support rotation write-ups and thought about what to build. The idea crystallised: what if you could manage a WordPress.com site entirely from markdown files in your terminal? A quick search revealed nothing quite like that existed.
- Explored what tools exist (MCP, REST API, WP-CLI, Obsidian plugins)
- Found a clear gap: no agent-friendly, markdown-native WordPress.com publishing tool
- Decided to build both the tool and a site about the tool — meta, but useful
Day 2 (Tuesday): Build
This is where things got fast. Claude researched the WordPress.com MCP, REST API, and existing agent skills in parallel, then compiled a gap analysis. Within a few hours we had a full skill spec, working converter scripts, templates, and example content.
Then the real customer experience kicked in:
- The auth story has plot twists — we initially thought Application Passwords didn’t exist on WordPress.com. They do — but they’re hidden at the bottom of the Two-Step Authentication settings page. It took a content designer, an AI, and the WordPress.com Support Assistant to find them. Even then, they only grant read-only REST API access. MCP turned out to be the only practical write transport.
- MCP setup had several gotchas — silent auth failures, no “add server” UI, project-level config not working as documented. Each one would block a real user.
- The domain picker is a cognitive load gate — you’re asked to name your site before you’ve seen the editor. And “agentpress” silently became “agentpress4.”
- But once connected, MCP is genuinely impressive — full CRUD for posts, pages, categories, tags, all from the terminal.
We pushed our first draft post and three pages to WordPress.com from local markdown files. The round trip worked: markdown → HTML → MCP → WordPress.com → wp_id written back to frontmatter.
Five bugs documented. Not bad for Day 2.
Day 3 (Wednesday): Design, polish, and an Obsidian breakthrough
The site worked. Now it needed to look and feel right.
We switched from the Assembler theme to Beep — a terminal-inspired theme with Roboto Mono, a dark palette, and an aesthetic that matched the project perfectly. Claude rebuilt the landing page block markup for Beep’s design language, adapting columns, buttons, and spacing.
Then we discovered Beep renders all heading levels at the same size. Claude’s initial solution: add markdown-style hash prefixes (##, ###) to heading text, wrapped in white <span> tags for contrast. A CSS-in-markup hack that gives visual hierarchy where the theme doesn’t. (We later found a cleaner approach — see Day 4.)
The big moment: we pointed the site’s content directory at an Obsidian vault, and it just worked. Michael wrote a post entirely in Obsidian with no frontmatter at all — Claude added the YAML, converted to block markup, and pushed to WordPress.com. The reverse worked too: a dashboard edit was read back via MCP and the local markdown updated.
We also tested content types exhaustively — tables, blockquotes, embeds, images, nested lists, code blocks. Everything worked through the MCP pipeline. The only hard gap: MCP has no media upload. You can manage existing media but can’t push new files. Images require a dashboard detour.
Nine bugs documented by end of day, plus a growing list of design patterns for future Claudes.
Day 4 (Thursday): Copy, auth, and the full picture
Thursday was about getting the words right and closing the last technical unknowns.
We swept every page — homepage, About, Get Started — rewriting copy to lead with collaboration rather than sync. The homepage got a new “What Claude actually does” section and a “Tab-switching problem” pain point that replaced an earlier “honest version” section (which moved to the About page where it belonged). The About page became the home for the project’s story. Get Started was tightened to show the real workflow: write messy markdown, let Claude handle the frontmatter.
On the technical side, we tested the Application Password we’d finally found against the REST API. Result: GET requests work (read-only), but all write operations return 401. The OAuth2 password grant isn’t available either. MCP is definitively the only write transport for WordPress.com on the Personal plan.
We also discovered Additional CSS lives behind a kebab menu in the Site Editor (Appearance → Editor → Styles → ⋮ → Additional CSS). Several CSS rules transformed the site: green code blocks, hyphen list markers, code wrapping, and — the biggest win — ::before pseudo-elements on headings that replaced the Day 3 span hack entirely. Now headings just need plain text; the CSS prepends # , ## , ### in white automatically. No more markup hacks, and it works for every future post without any special handling.
14 bugs and findings documented. The auth discoverability story alone is worth the rotation.
wp-publish 