Wiring Claude Code Into My Entire WordPress Workflow
— 2026.03.01Working on multi-repository WordPress projects used to mean constant context switching. My main project, Progress Planner, spans multiple connected repositories: the plugin itself and a licensing/update server. Implementing a single feature often requires changes across both, coordinated API endpoints, and testing the full flow end-to-end.
Over the last few months, I’ve been tweaking and automating my daily workflow so Claude can handle most of this autonomously. Here’s how it works.
The problem: connected repositories, disconnected context
A typical feature request might look like this: “Add a new user recommendation that checks if the site has proper caching configured, then display it in the plugin dashboard.”
Simple enough. But execution means writing the recommendation logic in the plugin, adding an API endpoint on the server that provides caching benchmark data, testing the full flow between the two, debugging whatever PHP errors pop up along the way, and then styling the recommendation card to match the design. Each step requires different context. Different directories. Different browser tabs. Different mental models.
I wanted Claude to understand my entire development environment the way I do.
A project registry MCP server
I built a custom MCP server that maps out my entire development setup. Here’s a simplified version of the config:
{
"groups": {
"my-project": {
"description": "Plugin and server ecosystem",
"rules": {
"git": { "branch_prefix": "username/" },
"post_change": { "run_tools": ["fix-cs", "phpstan"] }
},
"projects": {
"plugin": {
"path": "/path/to/wp-content/plugins/my-plugin",
"url": "http://local.test",
"repo": "MyOrg/my-plugin",
"role": "Free WordPress plugin",
"wp_cli": true
}
// server, licensing portal, etc.
}
}
},
"credentials": {
"group:my-project": {
"username": "dev",
"password": "devpass"
}
},
"error_log": "/path/to/php-fpm.log"
}Now when I tell Claude “implement the caching recommendation in the plugin and add the benchmark endpoint to the server”, it knows exactly where both projects live, their URLs, their GitHub repos, login credentials for each environment, and even that it should prefix branches with my username and run code style fixes after making changes.
The cross-repository awareness is probably the most useful part. Claude can modify files in multiple repos in a single session, understanding how they connect. After changes, the server runs composer fix-cs and phpstan automatically, catching issues before I even review the code. Creating branches, issues, and PRs follows project conventions without me specifying them each time.
For debugging, I can tell Claude to “add traces to the authentication functions” and it injects error_log statements that I can later inspect and clean up. The server also knows where my PHP error log lives, so Claude can check it directly when something breaks.
Adding browser automation
Code changes are only half the story. Testing requires actually using the plugin in a browser — logging into WordPress admin, clicking through flows, inspecting console errors.
I added chrome-devtools-mcp to my stack. Combined with the project registry (which stores admin URLs and credentials), Claude can open my local WordPress sites, log into the admin panel, navigate to specific screens, check for JavaScript errors, and verify UI changes look correct.
A prompt like “test the new dashboard widget on pp” triggers Claude to open the browser, authenticate, navigate to the dashboard, and verify the component renders correctly.
The missing piece: design handoff
Everything worked great for backend features. But frontend work still had a bottleneck: design.
My workflow was painful. Get a Figma design, take a screenshot, paste it into Claude, get back code that’s… close. Then iterate through 5-10 more prompts to get spacing, colors, and typography right. Screenshots lose critical information. Exact hex values. Precise padding. Font weights. Line heights. Claude was guessing at values that were explicitly defined in the design system.
Enter Figma MCP
Figma’s official MCP server changed everything. Setup took two minutes with claude mcp add -s user --transport http figma https://mcp.figma.com/mcp.
After OAuth authentication, Claude can read any Figma file I have access to. When I share a Figma link now, it extracts actual design tokens — Roboto, 16px, weight 400, line-height 22.4px, colors as #1E3A8A instead of “dark blue”, precise 24px padding, 12px gap, even direct URLs to image assets. Not approximations. First-pass code accuracy went from “needs work” to “minor tweaks.”
Putting it all together
The three MCP servers — project registry, chrome-devtools, and Figma — combine into something that feels close to an autonomous development partner. A typical prompt now looks like:
“Pick up issue #142 from the plugin repo. It needs a new recommendation that checks caching status. Here’s the Figma design: [link]. Implement the recommendation in the plugin, add the benchmark endpoint to the server, and test that it displays correctly in the browser.”
Claude creates a branch (prefixed correctly), implements the feature across both repos, runs code quality tools, opens the browser to test, and reports back with a summary. What used to take an afternoon of context-switching now takes one focused prompt and a code review.
The project registry itself is around 1300 lines of TypeScript. Not a massive undertaking. The core insight is that AI coding assistants become dramatically more useful when they understand your specific development environment — not just generic programming concepts. If you’re working with connected repositories, local development servers, or any kind of multi-project setup, a custom MCP server that maps out your world might be worth the afternoon it takes to build one.