prime-the-agent — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited prime-the-agent (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Version: 1.2.0 Updated: 2026-08-04 Category: workflow Status: stable Requires: Respira for WordPress plugin + MCP server Telemetry endpoint: https://www.respira.press/api/skills/track-usage
A fast, focused session-starter. Run this at the top of any conversation about a WordPress site to prime the agent on how to work with the site correctly. Prevents the single most common failure mode: the agent generating raw HTML instead of using the site's actual page builder.
This skill is not a full site audit. For that, use Site Onboarding or WordPress Site DNA. This is the 30-second preamble before any work.
Since v1.1 it also carries memory across sessions. it reads a per-site brief stored on the site itself at the start, and offers to append what it learned at the end. So the next session, yours, a teammate's, or a different AI client, starts already knowing this site's quirks and the division of labor you prefer, instead of relearning them every time.
As of v1.2, memory is first-class. The brief arrives automatically inside respira_get_site_context under site_memory (no extra call), and learnings are saved with respira_remember. Memory can also carry site rules, and those are enforced by the site itself: a refused write is the site working as designed, not an error to retry.
Use Prime the Agent when:
Skip this skill when:
This skill activates when the user says any of:
Run these steps in order. Step 0 and Step 7 are the memory loop (start and end of session); Steps 1 to 6 are the priming itself. Do not skip steps.
Memory now arrives on its own. When Step 2 calls respira_get_site_context, the response carries a site_memory block: the notes and rules past sessions left behind for this exact site — the division of labor, the quirks, anything learned the hard way. There is no option to fetch and no extra call to make. (The old pattern of reading a respira_site_memory option via respira_get_option is legacy; do not use it.) If you need the full list with entry ids, say to prune a stale note, call respira_list_memory.
If site_memory is empty, there is no memory yet, that is fine, you will create it in Step 7. If it has content, read it before anything else and fold it into how you work below. Two kinds of entries live there:
respira_protected_by_site_rule, that refusal is final: do not retry it, and do not reach for a different tool to make the same change another way. Tell the user which rule blocked it and let them decide.Watch each note's date. if a note looks stale (say it names a builder that Step 3 contradicts), trust the live call and fix the note at the end.
Call respira_get_active_site. If no active site is set or the call fails, stop and ask the user which connected site to work on. Then call respira_list_sites to show options.
Call respira_get_site_context. Capture: WordPress version, PHP version, active theme, plugin count, multisite y/n, site URL.
Call respira_get_builder_info. This returns the active page builder (Elementor, Bricks, Divi, Gutenberg, Oxygen, Breakdance, Beaver, Brizy, WPBakery, Visual Composer, Thrive Architect, Flatsome, Spectra, Kadence Blocks, GenerateBlocks, or SeedProd), its version, and which modules are available.
This is the most important call. Every write to a page must go through this builder's native data structure. The agent's job is not to write WordPress pages — it's to write this builder's pages.
Call respira_get_builder_inline_schemas. This returns the JSON schema for every module type the active builder supports. Keep these in working memory before any write.
Call respira_list_pages (limit 25) and respira_list_custom_posts (limit 10). The agent now knows what pages exist, what custom post types are defined, and roughly how big the site is.
Output a short briefing in this exact shape:
## Primed and ready
**Active site:** {site_url}
**WordPress:** {wp_version} · PHP {php_version} · Theme {theme_name}
**Active builder:** {builder_name} {builder_version}
**Content surface:** {page_count} pages · {custom_post_count} custom posts · {plugin_count} plugins
**Multisite:** {yes/no}
**From memory:** {one-line gist of the site_memory block, or "nothing stored yet, I'll start a brief at the end"}
**Working rules I'll follow on this site:**
- Every page edit goes through {builder_name}'s native modules. No raw HTML.
- Before changing a live page, I'll call `respira_create_page_duplicate` first (SafeEdit).
- I'll use `respira_extract_builder_content` to read pages and `respira_inject_builder_content` to write them whole.
- For element-level changes I'll use `respira_find_element` → `respira_update_element`.
- For new pages from a brief I'll use `respira_build_page`, not `respira_update_page` with HTML.
Ready when you are.Before the session ends, save what you learned so the next session starts smarter. Propose a short, durable summary to the user first. on their nod, call respira_remember once per learning, each as its own small entry. If the user says a stored note is no longer true, remove it with respira_forget (get the entry id from respira_list_memory). Do not write the respira_site_memory option anymore; the first-class tools replaced it.
Keep each entry small and durable:
respira_get_builder_info or respira_get_site_context already returns, anything secret.Refresh anything you re-confirmed this session, and drop only what the user says is no longer true. Never respira_forget a note the user has not contradicted.
Steps 0 and 7 are a loop. The site keeps per-site memory on the site itself, managed by first-class tools: it arrives automatically in respira_get_site_context under site_memory, is written with respira_remember, listed with respira_list_memory, and pruned with respira_forget. Because it lives on the site, it survives stateless sessions and travels: the next conversation, a teammate, or a different AI client all read the same brief.
The old pattern — reading and writing a respira_site_memory option through respira_get_option / respira_update_option — is legacy. Do not use it on current plugin versions; the tools above replaced it.
Four rules keep it safe:
respira_protected_by_site_rule refusal is final: never retry it or route around it with another tool. Surface it to the user. The same holds for access profiles: a site may run in a content or observe profile, and out-of-profile tools are refused server-side. Treat that refusal as an answer, not an error.These are the rules the agent must follow on every WordPress site that uses a page builder. Internalize these before any write operation.
If the active builder is Elementor, the page is a tree of Elementor widgets. If Bricks, it is a tree of Bricks elements. If Divi 5, it is a tree of Divi modules with the v5 catalog. If Gutenberg, it is a tree of blocks. Writing <div> or <section> HTML into the page bypasses the builder's data structure and corrupts the page — the builder won't recognize the content and the editor will show a blank canvas or an unparseable warning.
For the active builder, use this tool stack (in order of preference for each operation):
To read a page:
respira_extract_builder_content (returns the builder's native structure)respira_read_page (returns metadata + content)respira_get_page_outline (returns headings + structure)To find something to edit:
respira_find_element (with text, class, widget type, or ID query)respira_find_builder_targets (returns builder-specific selectors)To change something:
respira_update_element (single element, the most common operation)respira_update_module (for module-level changes — Divi, Bricks)respira_apply_builder_patch (for builder-JSON patches)To write a whole page:
respira_build_page (for new pages from a brief — uses builder schemas)respira_inject_builder_content (for whole-page content drops in builder-native format)Never use:
respira_update_page with raw HTML for content changes. This replaces the entire page body and bypasses the builder — the result is a "code page" with no editable widgets. respira_update_page is only for page title, slug, status, or custom CSS.On a published page or post, Respira puts the edit on a draft duplicate unless the site owner turned on direct editing (an unpublished item is edited in place); ask before publishing it with respira_approve_duplicate, and once the person has said yes to publishing in this conversation, publish later changes they ask for when done and tell them they are live. Show the user the duplicate's preview link and let them approve it before it goes live. Call respira_create_page_duplicate yourself only when you want the copy before the first edit, for example to share a preview or stage several changes. This is SafeEdit, and it has saved more than one customer site from a regret.
respira_get_builder_inline_schemas returns the exact attribute shape for every module the active builder supports. Read it before writing. If a module's schema says padding is a dimension object with unit and value keys, write a dimension object. If it says font_size is an integer, write an integer. Do not improvise.
Every write through Respira creates a TimeSnap automatically. If the user wants to roll back, call respira_list_snapshots then respira_restore_snapshot. You do not need to manually create snapshots — but if a customer is doing something risky (multi-page bulk update), you can take an explicit one with the snapshot helper.
User: "prime yourself for this site"
Agent: (runs Steps 1–6 in order, outputs the briefing)
Then: "What would you like to work on?"
User: "wait, you're writing HTML. I told you we use Bricks."
Agent: (re-runs Step 3 — respira_get_builder_info — confirms Bricks)
Then: "You're right. I'm re-priming. Active builder: Bricks 1.12. From here on every write goes through Bricks element schemas, not HTML. Continuing with [task]."
User: "prime the agent for my blog"
Agent: (runs Steps 1–6)
Notes: For Gutenberg-only sites, "builder-native" means writing block markup (the <!-- wp:paragraph --> comments + serialized block JSON), not raw HTML. The same do-not-write-raw-HTML rule applies — block content is the native structure, not freeform HTML.
This skill records a usage event when it runs. The event captures: active site URL hash, active builder, content-surface counts (pages, custom posts, plugins), success/failure, and total duration. No site content, no user prompts, no tool arguments are sent.
Endpoint: POST https://www.respira.press/api/skills/track-usage
Telemetry can be disabled at the plugin level under Respira → Settings → Privacy → Anonymous telemetry.
The single most common failure mode the Respira team sees in customer support is: an AI agent picks up a conversation about a WordPress site, doesn't check which builder is active, and starts writing raw HTML. The page goes into the database as a blob of HTML that the builder cannot parse. The editor opens to a broken canvas. The customer files a bug report.
This skill prevents that by making "before any work, find out what you're working on" a first-class, named, triggerable workflow. Run it. Then everything else works.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.