Initial Read Protocol
A structured boot sequence for AI agents entering an unfamiliar WordPress site. Read-only. Ordered for maximum signal with minimum calls.
Protocol Overview
When you enter a site cold โ no prior context, no knowledge layer, no session history โ this protocol gives you a reliable sequence for building a mental model before taking any action. It covers four domains in order: system health, content structure, active plugins, and theme context.
The order matters. Site health first because it tells you what's broken. Content structure second because it defines the terrain. Plugins third because they reveal capabilities and dependencies. Theme last because it's the most stable and least time-sensitive.
The Protocol
-
1Site Health Check
Get the overall site health status and run a pulse check. This surfaces critical issues before you touch anything else.
site-health/statussite-health/pulse -
2Discover Post Types
List all registered post types. This shapes everything downstream โ you need to know what kinds of content exist before you can query them.
content/discover-types -
3Map Content Structure
Get the site map (page hierarchy) and list top-level post counts by type. Do not read post content yet โ structural metadata only.
content/get-site-mapcontent/list-structure -
4Audit Active Plugins
List all installed plugins, noting which are active. This reveals what modules are available and which Fluent suite products are in play.
plugins/list -
5Read Taxonomy Structure
List categories and tags in use. The term counts tell you where content is concentrated.
taxonomies/discovertaxonomies/list-terms -
6Survey Theme Context
Get the active theme and its design snapshot. Note the block theme status โ this determines whether Blocks module or Theme module abilities are relevant.
themes/get-activethemes/design-snapshot -
7Check Abilities Suite Status
If the Knowledge Layer is active, run
knowledge/bootfor a site-aware orientation document. Check suite status for enabled modules.suite/get-statusknowledge/boot
Pacing Note
The pacing rule is not a performance constraint โ it's an accuracy constraint. When you fire abilities in rapid sequence without reviewing each result, you build a model on top of unread data. The model becomes confident about things you haven't actually seen.
After each step, ask: What did this change about my understanding? If the answer is nothing, something went wrong โ either the ability returned unexpected data or you didn't read the result.
site-health/status returns critical issues, stop after step 1 and surface the problems to the operator. Do not proceed with a structural read if the database is corrupted or core files are modified.All Abilities Used
| Step | Ability | Type | Module |
|---|---|---|---|
| 1 | site-health/status | R | Site Health |
| 1 | site-health/pulse | R | Site Health |
| 2 | content/discover-types | R | Content |
| 3 | content/get-site-map | R | Content |
| 3 | content/list-structure | R | Content |
| 4 | plugins/list | R | Plugins |
| 5 | taxonomies/discover | R | Taxonomies |
| 5 | taxonomies/list-terms | R | Taxonomies |
| 6 | themes/get-active | R | Themes |
| 6 | themes/design-snapshot | R | Themes |
| 7 | suite/get-status | R | Meta |
| 7 | knowledge/boot | R | Knowledge Layer |