Build validated POM builder content
POM builder pages are shortcode structures. An assistant that composes them from memory produces markup that looks right and uses parameters that do not exist; one that reads the schemas first produces markup that works.
This workflow is the difference between those two outcomes.
Requirements
- The POM theme active, so the authoring and theme tools are registered.
- Allow content writes open, for the page itself.
- Scopes covering content, and
pom_theme:readfor theme-side context.
Start from the published prompt
The server publishes two prompts for exactly this:
create_landing_page_with_pom_builder— building a new page.update_pom_builder_page_preserving_structure— editing an existing one without destroying it.
They encode the sequence below. Where one applies, start from it rather than describing the job yourself. See Prompt recipes.
The sequence
1. Read the authoring context.
pom_get_authoring_context returns the editing context, layout rules, recommended shortcodes and the tools to use next, for a given target. It is the orientation step and it answers "what does this site's builder actually look like".
2. Read what is available.
pom_get_available_shortcodes lists the shortcodes registered on this site — not a generic set, this site's.
3. Read the schema for each one you will use.
pom_get_shortcode_schema returns the parameters a shortcode accepts. This is the step that prevents invented parameters, and the one an assistant skips unless told.
4. Compose the content.
5. Validate.
pom_validate_builder_content checks the markup before it goes anywhere near the page. It is read-only and free to repeat.
6. Fix and re-validate until it passes.
7. Write with wp_update_page or wp_create_page.
8. Read the page back, then look at it rendered.
Ask for it as one instruction
Read the authoring context for page 88 and the available shortcodes and their schemas. Then compose the new hero section, validate it, and show me the validation result. Do not write anything until I confirm.
The final clause matters. Without it, an assistant will validate and write in the same turn, removing your chance to look.
Editing an existing page
The specific failure mode is replacing a structured page with a plausible-looking rewrite.
Read page 88 first and show me its existing structure. Change only the hero section. Preserve every other section, its shortcodes and its parameters exactly.
The update_pom_builder_page_preserving_structure prompt exists because this instruction is easy to get wrong and expensive to get wrong.
Where a page uses merge tags, read pom_get_available_mergetags too — an invalid tag renders as literal text rather than raising an error.
Validation is not verification
Passing validation means the markup is well-formed and the shortcodes and parameters exist. It says nothing about whether the layout looks right, the copy is accurate, or the page works on a phone.
After writing:
- open the page on the front end;
- check it at mobile width;
- check any dynamic sections actually populated;
- purge the cache.
Building a page with images
The create_page_with_generated_media prompt covers building a page, uploading images and using them in the layout as one flow. Media upload has its own constraints — see Upload and assign an image.
Common problems
| Symptom | Cause |
|---|---|
| Validation fails repeatedly on the same content | The assistant is using an assumed shortcode vocabulary; send it back to pom_get_available_shortcodes |
| A parameter is ignored | It does not exist in that shortcode's schema |
| Merge tags render as text | The tag is not valid; check pom_get_available_mergetags |
| The layout broke after an edit | Existing structure was replaced rather than preserved |
| The page renders empty sections | Valid markup referencing content that is not there |
| Theme tools are missing entirely | The POM theme is not the active theme |