The Agentic
WordPress
Prompt Book

Chapter 01 · The category

Agentic WordPress

For twenty years, working on a WordPress site meant operating it: logging in, finding the right screen, learning the builder. Agentic WordPress is what happens when your site stops being something you operate and starts being something you talk to. You describe the outcome. An AI agent, connected to your live site, does the work in your page builder's own format, with an undo button under everything.

That category did not exist, so Respira became the first tool built for it. Not a chatbot bolted onto a dashboard, and not a code generator that hands you HTML to paste: an infrastructure layer that gives Claude, ChatGPT, and any MCP-capable agent real, structured, reversible access to live WordPress sites. One honest note on scope: most of this guide is the discipline of agentic WordPress, and the discipline is true with any MCP-capable tool. Where something is Respira-specific (the skills catalog, staged approvals, snapshots, Earn), it is named as such.

Chapter 03 · First ten minutes

The first ten minutes on a new site

The primer covers the session. This is the checklist for a site you have never touched before, agency-suggested, distinct from the primer because it runs once per site, not once per session.

• Which site am i actually connected to? if you manage more than one, confirm before you start: "what site am i connected to right now, and what's its URL?" copy
• Builder and plugin inventory. "what page builder is this site using, and what plugins are active?" copy
• Cache stack. "is there a caching plugin or CDN in front of this site?" Respira purges every major caching plugin automatically after a live write, so this is about knowing whether a CDN edge cache or host-level cache sits outside that reach.
• Staging availability. "does this site have a staging environment, and is it connected to Respira too?" if yes, rehearse a risky change there first; if no, duplicate-before-edit is doing that job on production.
• Backup status. "when was this site last backed up, outside of Respira's own snapshots?" snapshots cover page content; they are not a substitute for your host's or plugin's full-site backup.

Five questions, one time per site. After that, the primer takes over for every session.

Chapter 05 · Anti-patterns

The four anti-patterns

• Asking for raw HTML. It renders, but your visual builder can't edit it. Ask for the page or section instead; if you have an HTML prototype, say "convert this HTML into my builder's format".
• Skipping the read step. "Change the second section" makes the agent guess. "Read the page structure, then change the section with the testimonials" never misses.
• Editing live without a net. With default settings, edits stage on a duplicate you approve. If you enabled direct editing, say "duplicate the page first" on anything you'd mind losing.
• One giant ask. "Redesign my whole site" produces mush. "Let's start with the homepage hero" produces results, and momentum.

Chapter 05 · The safety net

The safety net

Three layers, on by default: duplicate-before-edit (writes stage on a copy; you approve in Respira → Changes before anything replaces the original), snapshots (full-page writes snapshot first; "undo that" restores, "what changed?" diffs), and approval for destructive operations (deletions require an explicit yes).

The phrases that drive it: "undo that last change", "show me what changed", "restore the version from before we started". The full trust model is in the docs.

If you manage more than one site, add a fourth phrase to the rotation: "confirm which site you're connected to before you do anything". Respira can tell you exactly which site is active and list every site you have access to; asking costs one message and is the whole guard against writing to the wrong client's site.

Chapter 06 · Recipes

Worked recipes

Eight end-to-end recipes for the highest-value jobs. Anything in [brackets] is yours: replace it with your own words before pasting. The first recipe is shown filled in with real words below its template, so you can see the shape.

Every recipe has the same four parts, and once you see them you can write your own: the read step ("read my homepage structure"), the change (described by outcome, not mechanism), the boundary (what must not move), and the staging clause ("stage it for my approval"). A fifth habit belongs right after the write lands: read it back and diff it. staging catches intent before a change goes live; it does not catch a write that landed wrong or silently dropped an element. "read that page back and tell me what changed against what i asked for" copy costs one extra message and catches the failure mode staging cannot.

Chapter 07 · Your builder

Your builder, specifically

Every prompt in this book works on all sixteen builders; Respira translates to whatever your site runs. But each builder has one or two things worth knowing when you phrase an ask. Not sure what you're on? Start with: "what page builder is this site using, and what can you do with it?" copy

How you'd know a write did not fully land: a Divi build that drops elements returns a hard error instead of a false success (a tripwire compares what was written against what was asked); an Elementor write touching a widget type outside Respira's supported catalog is refused up front rather than silently dropped; and every builder-content write echoes back exactly how many elements it received and persisted, so a truncated request is visible in the response, not just in the rendered page. The read-back-and-diff habit from the recipes chapter is still worth doing regardless, since these guards catch dropped structure, not a wrong color or a mistyped word.

Chapter 08 · Cheat sheet

Builder cheat sheet

You never write these payloads by hand; your agent does. This table exists so that when you look over its shoulder, you know what "correct" looks like for your builder. One universal rule: the canonical nesting key is children, and for Divi the natural vocabulary (rows, cols, modules) works too, at any depth, on both Divi 4 and Divi 5.

Builder-specific notes worth knowing: Divi 4 has a per-attribute writer, so give modules admin labels while building and later edits become one-liners. Elementor keeps everything in a hidden field, which is why hand-editing the page content does nothing. Bricks has the deepest tool set here (global classes, theme styles, components). Gutenberg is WordPress-native and round-trips most forgivingly. The ebook has the full sheet per builder with payload examples.

Multilingual sites (WPML, Polylang): Respira has a dedicated tool for duplicating a page or post across your configured language variants and keeping the translation relationships intact, so a builder write on a multilingual site does not mean redoing the work per language by hand. Ask for it directly: "duplicate this page across all our configured languages".

Chapter 09 · Skills

The skills catalog: 37 jobs, already packaged

A skill is a ready-made, tested playbook for a whole job: you install or paste it into your AI client once and trigger it with a sentence. All of them ship in every Respira plan, browsable under Skills in your dashboard. This is the full catalog, so you know what you never have to prompt from scratch.

The pattern for all of them: install or paste the skill, then ask in plain English. "run the conversion audit on my homepage". The skill carries the expertise so your prompt doesn't have to. Migrations create draft duplicates for review; nothing replaces a live page without your approval.

Chapter 10 · Playbooks

Playbooks: teach your site a repeatable job

When you and your agent work out a workflow you'll want again, you don't have to re-explain it next month. Ask the agent to save it as a playbook: a named, typed sequence of steps stored on your site itself. Once saved, it shows up as a tool the agent can run on demand.

Playbooks are validated when they're saved, not when they run: a step that references a missing tool or a missing argument is rejected on the spot with a message telling the agent exactly what to fix, so a broken playbook can't sit there looking healthy. "List my playbooks" and "delete the playbook called X" work the way you'd expect. This is a newer feature; skills are the curated library, playbooks are the ones you grow yourself.

Chapter 11 · Agencies

Run a business on it

Agencies were the first to figure out what agentic WordPress changes: the same job, done well, in a fraction of the hours you used to bill. Two features inside Respira exist for exactly that shift.

Between the reports and the numbers, the invoice writes itself, honestly.

Chapter 11 · Honest limits

What agentic WordPress can't do yet

An honest guide names its edges. These are the real limits today, stated plainly so you can plan around them instead of discovering them mid-project.

• Undo is per page, not per element. A snapshot captures and restores a whole page. "Undo that" rolls the page back; it cannot surgically revert one module while keeping the three edits after it. If you need fine-grained history, work in smaller sessions: more snapshots, smaller blast radius.
• Media files are not versioned. Snapshots cover page structure and content, not the image binaries themselves. If the agent replaces an image, the old file still exists in your media library, but there is no automatic "restore the previous image here". Deleting media requires an explicit yes for exactly this reason.
• Very large single builds hit the AI client's own ceiling, not Respira's. A 300-element page described in one tool call can exceed what the model is willing to write in one response; some clients then quietly trim the call. Respira reports exactly how many elements arrived, and the reliable pattern is chunking: build the skeleton, then append a few sections per request. A dedicated streaming build mode is on the roadmap; i haven't shipped that yet.
• One builder is read-only, and a few have caveats. SeedProd is audit-only today. The per-builder section names each caveat where it lives, so there are no surprises.
• The agent can still misunderstand you. No tool fixes an ambiguous ask. The primer, the read-first habit, and staged approvals exist because language is lossy. The safety net is what makes that survivable.

If a limit here disappears in a future release, this page is where that gets recorded first.

Reference · FAQ

Frequently asked questions