I built a podcast RSS feed block in Telex last week. I needed it for a project, and within minutes I had a working proof of concept, an RSS block that pulled in episodes with custom style settings. Telex is incredible for that moment when you have an idea and need to see it working in the editor immediately.
But then I wanted to push it further. Add typography controls, get a border around the episode embed, offer list and grid layouts. That’s where things got complicated, not because the idea was hard, but because I was spending more time wrestling with the tool than building the thing.
That experience pushed me to explore a completely different approach, and it changed how I think about AI-assisted WordPress development.
What Telex Does Well
I want to be clear: Telex is light years ahead of where it started. When I need to validate an idea or create a proof of concept, it’s the first place I go. I’ve built a Scroll on Hover Image block, a Site Wide Counter block, a Parallax Video Background block, and more, all with Telex, all from natural language prompts. For getting an idea into the block editor fast, nothing else comes close.
The speed of going from “what if WordPress had a block that does X” to seeing it live in the editor is genuinely impressive. If you haven’t tried Telex yet, you should.
Where I Hit the Wall
The RSS block pushed me past what Telex handles smoothly. When I asked for typography controls, I got a custom-built collection of settings that weren’t standard WordPress core components. After a lot of back-and-forth, and two additional prompts with screenshots showing exactly what WordPress core typography settings look like, we eventually got there. The end result was perfect, but it felt like something a WordPress-specific tool should get right on the first try.
The border control was even harder. I wanted a border around the podcast episode embed, but Telex kept targeting the wrong element. I had to open the browser inspector myself, find the correct class in the code, and feed that back into the prompt.
Then came the error loops. When I remixed the project to add new features without losing my original version, I hit a critical error screen that no amount of “fix with AI” could break out of. The original working version broke too. Deleting the playground state fixed it, but it’s the kind of thing that stops your momentum cold when you’re in a flow.
The bigger pattern was the workflow itself. Every iteration meant manually testing in the editor, copying code files, pasting them into Claude for review, getting new prompts back, and returning to Telex. It worked, but it was siloed. Each tool lived in its own world, and I was the only thing holding it all together.
As I put it at the time: if Telex is building WordPress blocks specifically, all WordPress skills should be inherent. You shouldn’t need to teach a WordPress block builder how WordPress works.
A New Project Needed a New Approach
That realization arrived right as I was starting Block Bits, a WordPress plugin that brings animated React components from reactbits.dev into the Gutenberg block editor as extensions to the blocks you already use. Toggle on a shimmer effect for your headings, add animated backgrounds to Group blocks, make your navigation menu flow. No custom blocks cluttering your inserter.
This wasn’t a proof of concept anymore. This needed a plan, and a toolchain that could execute it.
The Stack That Changed Everything
Rich Tabor’s agent skills collection and his post about Ralph changed everything for me. I’d been using AI tools in isolation, but Rich showed me how to connect them through structured workflows. The PRD agent, the Ralph story files, the WordPress-specific skills, they weren’t just better prompts. They were a system for turning planning into building, and building into shipping. That’s what I needed for Block Bits.
Here’s what my workflow looks like now, and why it feels fundamentally different.
Planning: Cowork + Rich Tabor’s PRD Agent.
I described the plugin scope in a single conversational prompt, six features with technical constraints and the React Bits URLs I wanted to integrate. Cowork’s PRD agent produced a comprehensive product requirements document covering plugin identity, WordPress component standards, feature specs, architecture, and accessibility requirements. Seven rounds of refinement later, I had a PRD that would make any product team proud. Then Cowork generated eight Ralph JSON story files, structured specifications with testable acceptance criteria that Claude Code can execute sequentially.
Building: Claude Code + WordPress Agent Skills.
Claude Code reads the Ralph story files and implements each user story in priority order, marking stories as passing when acceptance criteria are met. Rich Tabor’s WordPress Agent Skills give it deep knowledge of WordPress block development patterns, and a ReactBits MCP server gives it direct access to component source files for reference. It’s not guessing at how WordPress works; it knows.
Testing: WordPress Studio.
A symlink connects the repo to a local WordPress site. Every change Claude Code makes is immediately testable in a real WordPress environment. No copying files, no switching contexts.
Debugging: Claude Desktop + Claude in Chrome.
This is where it gets wild. My first feature, Shiny Text, is a pure CSS shimmer effect, and Claude Code nailed it on the first round because the structured PRD and Ralph stories gave it clear specifications to work from. But the shimmer wasn’t rendering in the block editor. From the code alone, everything looked correct. Claude in Chrome entered the editor for me, inspected the live DOM, and found the issue in minutes: WordPress 6.9 renders blocks inside an iframe, and the CSS was loading in the parent frame instead of inside the iframe where blocks actually render. It gave me the Claude Code prompt to fix it, and now it’s perfect.
That’s a bug that’s invisible from code alone. You need eyes on the running application.
The Real Shift
The difference isn’t just better tools. It’s that I’m no longer the bridge between disconnected systems.
With Telex, I was copying code, pasting it into Claude for review, getting prompts back, testing manually, and repeating. Every tool lived in its own silo, and I was the one holding everything together.
Now, I’m orchestrating an integrated team. Cowork plans, Claude Code builds, Chrome debugs, Studio tests. Each tool does what it does best, and they connect through structured artifacts. PRDs become stories, stories become code, code becomes a working plugin.
The funny thing is, this is exactly what I already do as a project manager. I coordinate between designers, developers, and stakeholders every day. The AI stack just made me faster at it. I’m doing the same work, scoping features, writing requirements, reviewing implementations, testing results, but the cycle time collapsed from days to hours.
Telex is still where I’ll go when I have a quick idea to validate. That hasn’t changed. But when I need to go from idea to production, the path is clear now: plan in Cowork, build with Claude Code, debug with Chrome, test in Studio.
I leveled up. And I still haven’t written a single line of code.
What tools are you using for WordPress development right now? Have you tried combining AI tools into a workflow, or are you still working with them one at a time? I’d love to hear what’s working for you, and where you’re hitting your own ceiling.