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.
Pacing rule applies. After each step, pause. Review what you’ve learned. Update your working model before calling the next ability. Do not batch all steps into a single burst — the pacing rule exists because reading too fast produces hallucinations about what you’ve found.
The Protocol
1
Site Health Check
Get the overall site health status and run a pulse check. This surfaces critical issues before you touch anything else.
site-health/status
site-health/pulse
2
Discover 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
3
Map 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-map
content/list-structure
4
Audit 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
5
Read Taxonomy Structure
List categories and tags in use. The term counts tell you where content is concentrated.
taxonomies/discover
taxonomies/list-terms
6
Survey 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-active
themes/design-snapshot
7
Check Abilities Suite Status
If the Knowledge Layer is active, run knowledge/boot for a site-aware orientation document. Check suite status for enabled modules.
suite/get-status
knowledge/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.
When to stop. If 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 |
Related
Read-only agent — uses this protocol
Deep system audit after initial read
Steps 2–3 use these abilities
The behavioral protocol behind step pacing