You do not need any of these. They just save you the first hour.

Build a complete website for [BUSINESS NAME], a [SITE TYPE] in [CITY/REGION] serving [WHO THEY SERVE].

Build it with core Gutenberg blocks only, so it works on any theme and stays editable in the block editor.

Page plan: use the one matching the site type, and adapt it:

ACCOUNTING / PROFESSIONAL SERVICES
Home · Services (bookkeeping, tax, payroll, advisory) · About + team credentials · Pricing (three tiers, "from" prices) · Contact · Privacy Policy
Tone: precise, calm, trustworthy. No hype. Never invent tax figures, rates, deadlines or regulatory claims, write [CONFIRM: …] instead.

RESTAURANT / HOSPITALITY
Home (hours prominent) · Menu (sections, prices, dietary markers) · About + chef · Book a table · Contact (hours per day, parking, accessibility)
Tone: warm but concrete, describe food by ingredient and preparation, not adjectives. Hours, menu and booking must be one click from anywhere.

AGENCY / STUDIO
Home · Services (what is included, process, timeline) · Work (three case studies: problem, approach, result) · About · Contact with budget and timeline fields
Tone: confident, specific, outcome-led. Write [CONFIRM: metric] rather than inventing results.

CLINIC / HEALTH PRACTICE
Home · Services (what each treatment involves, duration, aftercare) · Team with qualifications · New patients (what to bring, fees) · Contact + emergency info
Tone: reassuring and plain; assume the reader is anxious. Make no claims about outcomes and never imply a treatment cures anything. Registration numbers and regulatory text stay as placeholders.

PORTFOLIO / INDIVIDUAL
Home · Work (four projects: brief, approach, outcome) · About · Contact
Tone: first person, direct, short sentences. Keep it small. The job is to show work.

E-COMMERCE
Home · Shop landing · About · Shipping & returns · FAQ · Contact
Tone: plain and specific. Do not invent shipping times, prices or return windows, use [CONFIRM: …].

Rules for the whole build:
- Create everything as drafts. Publish nothing without asking me.
- Real, specific copy for this business, never filler text.
- Use the site's existing theme, colours and fonts.
- Add each page to the main navigation in the order listed.
- Anything you are not certain of goes in as [CONFIRM: …] rather than a plausible guess.
- When you are done, list every page you created with its edit link.

Create a new draft page titled "[PAGE TITLE]" using core Gutenberg blocks only.

How the write works, so you do not get halfway and stall:
1. wppilot/create-post, create the draft first. It defaults to draft; leave it there.
2. wppilot/gutenberg-create-pending-batch: core blocks cannot be written straight from the server, because the block editor's own JavaScript is what validates and serialises them.
3. wppilot/gutenberg-add-pending-change, queue the block tree against the new post.
4. wppilot/gutenberg-enable-batch-finalization, then wppilot/gutenberg-get-finalization-url, send me that link. I open it in a browser and the batch commits.

Blocks to use, and nothing else:
core/group, core/columns, core/column, core/heading, core/paragraph, core/buttons, core/button, core/image, core/list, core/separator, core/spacer, core/quote, core/cover.

Structure:
- Hero: core/cover or core/group with an H1, one supporting sentence, one core/buttons
- Three core/columns, each a core/heading H3 plus two sentences
- A core/quote with a real, attributed quotation, or omit the section entirely
- Closing core/group with the same call to action as the hero

Rules:
- Real, specific copy about [WHAT THE PAGE IS FOR]. No filler text, no invented statistics, no fake testimonials.
- Anything I have not told you, prices, credentials, client names, numbers, goes in as [CONFIRM: what is missing].
- Set the H1 once. Every other heading is H2 or lower, in order.
- Do not publish, and do not touch the theme, the menu or any other page.

When the batch is queued, give me the finalization link and tell me exactly what is in it.

Inventory the page [PAGE TITLE] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/get-content, the stored post and its metadata
2. wppilot/gutenberg-get-content, the parsed block tree
3. wppilot/get-page-snapshot, what the page actually renders
4. wppilot/list-revisions, how recently it was edited and by whom

Report back:
- The block tree, summarised section by section, naming the actual block types used
- Any block that is not a core block, and which plugin registers it
- Any block holding content that should be shared instead of duplicated
- Broken or empty blocks, missing image alt text, heading levels out of order
- Anything that would break if this page were rebuilt from scratch

Do not propose fixes yet. I want the picture first.

Tell me the state of the Block Editor Queue on this site.

Call:
1. wppilot/gutenberg-list-pending-batches, every batch and its status
2. wppilot/gutenberg-get-pending-batch, the contents of any batch that is not finalised
3. wppilot/gutenberg-get-finalizer-runtime, whether the finalizer can actually run here

For each unfinalised batch, tell me:
- Which post or template it targets, and whether that target still exists
- What the change would do, in plain language
- Which agent or session created it, and when
- Whether it is safe to discard

Do not finalise, delete or modify anything. Queued changes are not live until the whole batch commits, so an old batch is a decision waiting for me, not a fault.

Read the page "[PAGE TITLE]" on this site and rewrite its text for clarity.

Keep:
- The existing block structure and layout exactly as it is
- All links, images and buttons

Change:
- Shorten sentences, cut filler, use plain language
- Keep the same meaning and any factual claims
- Match the tone of the rest of the site

Show me a before/after of each block you would change, and wait for my approval before saving anything.

Review the 20 most recent published posts on this site and report on:

- Posts with no excerpt
- Posts with no featured image
- Titles longer than 60 characters
- Posts that have not been updated in over a year
- Any obviously broken or placeholder content

Do not change anything. Give me a table sorted by how much each post needs attention.

Take my draft post "[DRAFT TITLE]" and make it publishable:

- Add clear H2 and H3 headings so it can be skimmed
- Write a 25-word excerpt
- Suggest a focus keyword and check the title supports it
- Add two or three internal links to relevant existing posts on this site
- Flag anything that reads as unfinished

Keep it a draft. List every change you made.

Create a reusable Gutenberg pattern called "[PATTERN NAME]" for [WHAT IT IS FOR, e.g. a testimonial card].

- Core blocks only
- Sensible placeholder text that shows how it should be filled in
- Works at mobile and desktop widths

After creating it, tell me how to insert it in the editor.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/elementor-check-setup
2. wppilot/elementor-get-content
3. wppilot/elementor-get-schema
4. wppilot/elementor-get-style-schema
5. wppilot/elementor-list-global-classes
6. wppilot/elementor-list-variables
7. wppilot/elementor-list-v3-styles
8. wppilot/elementor-list-dynamic-tags

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Elementor has no template ability in this module. Headers, footers and single-post templates stay manual, do not claim to have built them.
- Check the v4 Atomic surface in the setup report before choosing a style path. On a v3-only install, use v3 colours and typography and leave global classes alone.
- elementor-set-content replaces the whole document. Read it with elementor-get-content first or the parts you did not mention are gone.
- Clear the document cache after a structural write, or the editor shows the previous tree.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill elementor-build-page before it starts.

Build [PAGE TITLE] in Elementor as a draft.

Call in this order:
1. wppilot/elementor-check-setup
2. wppilot/elementor-get-content
3. wppilot/elementor-get-schema
4. wppilot/elementor-get-style-schema
5. wppilot/elementor-list-global-classes
6. wppilot/elementor-list-variables
7. wppilot/elementor-list-v3-styles
8. wppilot/elementor-list-dynamic-tags

Then write with:
- wppilot/elementor-set-content
- wppilot/elementor-edit-element
- wppilot/elementor-delete-element

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Elementor has no template ability in this module. Headers, footers and single-post templates stay manual, do not claim to have built them.
- Check the v4 Atomic surface in the setup report before choosing a style path. On a v3-only install, use v3 colours and typography and leave global classes alone.
- elementor-set-content replaces the whole document. Read it with elementor-get-content first or the parts you did not mention are gone.
- Clear the document cache after a structural write, or the editor shows the previous tree.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill elementor-build-page before it starts.

Establish the shared design system in Elementor before any page work.

Read what already exists:
- wppilot/elementor-get-content
- wppilot/elementor-get-schema
- wppilot/elementor-get-style-schema
- wppilot/elementor-list-global-classes
- wppilot/elementor-list-variables
- wppilot/elementor-list-v3-styles
- wppilot/elementor-list-dynamic-tags

Then define, using:
- wppilot/elementor-create-global-class
- wppilot/elementor-apply-global-class
- wppilot/elementor-create-variable
- wppilot/elementor-create-v3-color
- wppilot/elementor-create-v3-typography

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Elementor has no template ability in this module. Headers, footers and single-post templates stay manual, do not claim to have built them.
- Check the v4 Atomic surface in the setup report before choosing a style path. On a v3-only install, use v3 colours and typography and leave global classes alone.
- elementor-set-content replaces the whole document. Read it with elementor-get-content first or the parts you did not mention are gone.
- Clear the document cache after a structural write, or the editor shows the previous tree.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill elementor-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/bricks-check-setup
2. wppilot/bricks-get-content
3. wppilot/bricks-list-elements
4. wppilot/bricks-list-global-classes
5. wppilot/bricks-list-variables
6. wppilot/bricks-list-color-palette
7. wppilot/bricks-list-theme-styles
8. wppilot/bricks-list-components
9. wppilot/bricks-list-dynamic-data

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Bricks separates global classes from theme styles. Classes belong on elements; theme styles set the defaults everything inherits. Do not solve a theme-style problem by adding a class to forty elements.
- bricks-patch-elements changes named elements in place. Prefer it over bricks-set-content when the page already exists and only part of it is wrong.
- Components are the reuse primitive. Anything appearing three times or more should be a component before the third instance, not after.
- Template conditions are read through bricks-list-template-condition-schema first. Guessing a condition shape is how a header ends up on every archive.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill bricks-build-page before it starts.

Build [PAGE TITLE] in Bricks as a draft.

Call in this order:
1. wppilot/bricks-check-setup
2. wppilot/bricks-get-content
3. wppilot/bricks-list-elements
4. wppilot/bricks-list-global-classes
5. wppilot/bricks-list-variables
6. wppilot/bricks-list-color-palette
7. wppilot/bricks-list-theme-styles
8. wppilot/bricks-list-components
9. wppilot/bricks-list-dynamic-data

Then write with:
- wppilot/bricks-set-content
- wppilot/bricks-insert-content
- wppilot/bricks-patch-elements
- wppilot/bricks-remove-content

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Bricks separates global classes from theme styles. Classes belong on elements; theme styles set the defaults everything inherits. Do not solve a theme-style problem by adding a class to forty elements.
- bricks-patch-elements changes named elements in place. Prefer it over bricks-set-content when the page already exists and only part of it is wrong.
- Components are the reuse primitive. Anything appearing three times or more should be a component before the third instance, not after.
- Template conditions are read through bricks-list-template-condition-schema first. Guessing a condition shape is how a header ends up on every archive.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill bricks-build-page before it starts.

Establish the shared design system in Bricks before any page work.

Read what already exists:
- wppilot/bricks-get-content
- wppilot/bricks-list-elements
- wppilot/bricks-list-global-classes
- wppilot/bricks-list-variables
- wppilot/bricks-list-color-palette
- wppilot/bricks-list-theme-styles
- wppilot/bricks-list-components
- wppilot/bricks-list-dynamic-data

Then define, using:
- wppilot/bricks-create-global-class
- wppilot/bricks-apply-global-class
- wppilot/bricks-create-variable
- wppilot/bricks-add-color-palette-entry
- wppilot/bricks-create-theme-style

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Bricks separates global classes from theme styles. Classes belong on elements; theme styles set the defaults everything inherits. Do not solve a theme-style problem by adding a class to forty elements.
- bricks-patch-elements changes named elements in place. Prefer it over bricks-set-content when the page already exists and only part of it is wrong.
- Components are the reuse primitive. Anything appearing three times or more should be a component before the third instance, not after.
- Template conditions are read through bricks-list-template-condition-schema first. Guessing a condition shape is how a header ends up on every archive.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill bricks-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Bricks for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/bricks-get-content
- wppilot/bricks-list-elements
- wppilot/bricks-list-global-classes
- wppilot/bricks-list-variables
- wppilot/bricks-list-color-palette
- wppilot/bricks-list-theme-styles
- wppilot/bricks-list-components
- wppilot/bricks-list-dynamic-data

Then build and scope with:
- wppilot/bricks-list-templates
- wppilot/bricks-create-template
- wppilot/bricks-list-template-condition-schema
- wppilot/bricks-set-template-conditions

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Bricks separates global classes from theme styles. Classes belong on elements; theme styles set the defaults everything inherits. Do not solve a theme-style problem by adding a class to forty elements.
- bricks-patch-elements changes named elements in place. Prefer it over bricks-set-content when the page already exists and only part of it is wrong.
- Components are the reuse primitive. Anything appearing three times or more should be a component before the third instance, not after.
- Template conditions are read through bricks-list-template-condition-schema first. Guessing a condition shape is how a header ends up on every archive.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill bricks-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/divi-check-setup
2. wppilot/divi-get-content
3. wppilot/divi-get-style-schema
4. wppilot/divi-list-global-colors
5. wppilot/divi-list-variables
6. wppilot/divi-list-global-presets
7. wppilot/divi-get-global-fonts
8. wppilot/divi-list-library-items
9. wppilot/divi-list-theme-builder-templates

Report back:
- The module tree, summarised by section, with the module types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single module that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Presets are the point of Divi 5. Set a default preset per module type before building, and every module placed afterwards inherits it. That is the difference between a Divi site and a Divi mess.
- divi-create-theme-builder-template creates header, body and footer layouts with their assignment conditions. Read the existing assignments first; a body template with a broad condition silently replaces every single post.
- Library items are for genuine reuse. A library item used once is a layout with extra steps.
- This module targets Divi 5. On a Divi 4 install the setup check reports it, stop rather than writing a tree the editor cannot open.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill divi-build-page before it starts.

Build [PAGE TITLE] in Divi 5 as a draft.

Call in this order:
1. wppilot/divi-check-setup
2. wppilot/divi-get-content
3. wppilot/divi-get-style-schema
4. wppilot/divi-list-global-colors
5. wppilot/divi-list-variables
6. wppilot/divi-list-global-presets
7. wppilot/divi-get-global-fonts
8. wppilot/divi-list-library-items
9. wppilot/divi-list-theme-builder-templates

Then write with:
- wppilot/divi-set-content
- wppilot/divi-add-module
- wppilot/divi-edit-module
- wppilot/divi-move-module
- wppilot/divi-delete-module

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Presets are the point of Divi 5. Set a default preset per module type before building, and every module placed afterwards inherits it. That is the difference between a Divi site and a Divi mess.
- divi-create-theme-builder-template creates header, body and footer layouts with their assignment conditions. Read the existing assignments first; a body template with a broad condition silently replaces every single post.
- Library items are for genuine reuse. A library item used once is a layout with extra steps.
- This module targets Divi 5. On a Divi 4 install the setup check reports it, stop rather than writing a tree the editor cannot open.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill divi-build-page before it starts.

Establish the shared design system in Divi 5 before any page work.

Read what already exists:
- wppilot/divi-get-content
- wppilot/divi-get-style-schema
- wppilot/divi-list-global-colors
- wppilot/divi-list-variables
- wppilot/divi-list-global-presets
- wppilot/divi-get-global-fonts
- wppilot/divi-list-library-items
- wppilot/divi-list-theme-builder-templates

Then define, using:
- wppilot/divi-create-global-color
- wppilot/divi-set-global-fonts
- wppilot/divi-create-global-preset
- wppilot/divi-apply-global-preset
- wppilot/divi-set-default-preset
- wppilot/divi-create-variable

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Presets are the point of Divi 5. Set a default preset per module type before building, and every module placed afterwards inherits it. That is the difference between a Divi site and a Divi mess.
- divi-create-theme-builder-template creates header, body and footer layouts with their assignment conditions. Read the existing assignments first; a body template with a broad condition silently replaces every single post.
- Library items are for genuine reuse. A library item used once is a layout with extra steps.
- This module targets Divi 5. On a Divi 4 install the setup check reports it, stop rather than writing a tree the editor cannot open.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill divi-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Divi 5 for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/divi-get-content
- wppilot/divi-get-style-schema
- wppilot/divi-list-global-colors
- wppilot/divi-list-variables
- wppilot/divi-list-global-presets
- wppilot/divi-get-global-fonts
- wppilot/divi-list-library-items
- wppilot/divi-list-theme-builder-templates

Then build and scope with:
- wppilot/divi-list-theme-builder-templates
- wppilot/divi-create-theme-builder-template

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Presets are the point of Divi 5. Set a default preset per module type before building, and every module placed afterwards inherits it. That is the difference between a Divi site and a Divi mess.
- divi-create-theme-builder-template creates header, body and footer layouts with their assignment conditions. Read the existing assignments first; a body template with a broad condition silently replaces every single post.
- Library items are for genuine reuse. A library item used once is a layout with extra steps.
- This module targets Divi 5. On a Divi 4 install the setup check reports it, stop rather than writing a tree the editor cannot open.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill divi-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/breakdance-check-setup
2. wppilot/breakdance-get-element-tree
3. wppilot/breakdance-get-element-schema
4. wppilot/breakdance-list-element-types
5. wppilot/breakdance-list-global-classes
6. wppilot/breakdance-list-variables
7. wppilot/breakdance-list-templates
8. wppilot/breakdance-list-dynamic-data-fields

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Read breakdance-get-element-schema for every element type you intend to place. Breakdance element settings are deeply nested and a plausible-looking guess produces an element that renders empty.
- breakdance-list-element-types is the vocabulary check. If the element you want is not in that list, the installed edition does not have it, say so instead of substituting.
- Form submissions contain personal data. Keep that surface read-only unless there is a specific, stated reason.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill breakdance-build-page before it starts.

Build [PAGE TITLE] in Breakdance as a draft.

Call in this order:
1. wppilot/breakdance-check-setup
2. wppilot/breakdance-get-element-tree
3. wppilot/breakdance-get-element-schema
4. wppilot/breakdance-list-element-types
5. wppilot/breakdance-list-global-classes
6. wppilot/breakdance-list-variables
7. wppilot/breakdance-list-templates
8. wppilot/breakdance-list-dynamic-data-fields

Then write with:
- wppilot/breakdance-set-content
- wppilot/breakdance-add-element
- wppilot/breakdance-edit-element
- wppilot/breakdance-move-element
- wppilot/breakdance-delete-element

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Read breakdance-get-element-schema for every element type you intend to place. Breakdance element settings are deeply nested and a plausible-looking guess produces an element that renders empty.
- breakdance-list-element-types is the vocabulary check. If the element you want is not in that list, the installed edition does not have it, say so instead of substituting.
- Form submissions contain personal data. Keep that surface read-only unless there is a specific, stated reason.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill breakdance-build-page before it starts.

Establish the shared design system in Breakdance before any page work.

Read what already exists:
- wppilot/breakdance-get-element-tree
- wppilot/breakdance-get-element-schema
- wppilot/breakdance-list-element-types
- wppilot/breakdance-list-global-classes
- wppilot/breakdance-list-variables
- wppilot/breakdance-list-templates
- wppilot/breakdance-list-dynamic-data-fields

Then define, using:
- wppilot/breakdance-create-global-class
- wppilot/breakdance-create-variable
- wppilot/breakdance-edit-global-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Read breakdance-get-element-schema for every element type you intend to place. Breakdance element settings are deeply nested and a plausible-looking guess produces an element that renders empty.
- breakdance-list-element-types is the vocabulary check. If the element you want is not in that list, the installed edition does not have it, say so instead of substituting.
- Form submissions contain personal data. Keep that surface read-only unless there is a specific, stated reason.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill breakdance-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Breakdance for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/breakdance-get-element-tree
- wppilot/breakdance-get-element-schema
- wppilot/breakdance-list-element-types
- wppilot/breakdance-list-global-classes
- wppilot/breakdance-list-variables
- wppilot/breakdance-list-templates
- wppilot/breakdance-list-dynamic-data-fields

Then build and scope with:
- wppilot/breakdance-list-templates
- wppilot/breakdance-create-template
- wppilot/breakdance-list-template-conditions
- wppilot/breakdance-set-template-conditions

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Read breakdance-get-element-schema for every element type you intend to place. Breakdance element settings are deeply nested and a plausible-looking guess produces an element that renders empty.
- breakdance-list-element-types is the vocabulary check. If the element you want is not in that list, the installed edition does not have it, say so instead of substituting.
- Form submissions contain personal data. Keep that surface read-only unless there is a specific, stated reason.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill breakdance-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/oxygen-check-setup
2. wppilot/oxygen-get-element-tree
3. wppilot/oxygen-list-element-types
4. wppilot/oxygen-get-element-schema
5. wppilot/oxygen-get-global-class-schema
6. wppilot/oxygen-list-global-classes
7. wppilot/oxygen-list-variables
8. wppilot/oxygen-list-templates
9. wppilot/oxygen-list-template-conditions

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Oxygen 6 is the unified engine. Never emit Oxygen Classic shortcodes. They are not the same data model and the editor will not reconcile them.
- Global classes carry the design system here. Create the class, then apply it; do not inline the same declarations onto siblings.
- Template conditions in Oxygen are ordered and specific-wins. List the existing conditions before adding one or the new template quietly loses to an older catch-all.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill oxygen-build-page before it starts.

Build [PAGE TITLE] in Oxygen 6 as a draft.

Call in this order:
1. wppilot/oxygen-check-setup
2. wppilot/oxygen-get-element-tree
3. wppilot/oxygen-list-element-types
4. wppilot/oxygen-get-element-schema
5. wppilot/oxygen-get-global-class-schema
6. wppilot/oxygen-list-global-classes
7. wppilot/oxygen-list-variables
8. wppilot/oxygen-list-templates
9. wppilot/oxygen-list-template-conditions

Then write with:
- wppilot/oxygen-set-content
- wppilot/oxygen-add-element
- wppilot/oxygen-edit-element
- wppilot/oxygen-move-element
- wppilot/oxygen-delete-element

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Oxygen 6 is the unified engine. Never emit Oxygen Classic shortcodes. They are not the same data model and the editor will not reconcile them.
- Global classes carry the design system here. Create the class, then apply it; do not inline the same declarations onto siblings.
- Template conditions in Oxygen are ordered and specific-wins. List the existing conditions before adding one or the new template quietly loses to an older catch-all.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill oxygen-build-page before it starts.

Establish the shared design system in Oxygen 6 before any page work.

Read what already exists:
- wppilot/oxygen-get-element-tree
- wppilot/oxygen-list-element-types
- wppilot/oxygen-get-element-schema
- wppilot/oxygen-get-global-class-schema
- wppilot/oxygen-list-global-classes
- wppilot/oxygen-list-variables
- wppilot/oxygen-list-templates
- wppilot/oxygen-list-template-conditions

Then define, using:
- wppilot/oxygen-create-global-class
- wppilot/oxygen-apply-global-class
- wppilot/oxygen-create-variable
- wppilot/oxygen-edit-global-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Oxygen 6 is the unified engine. Never emit Oxygen Classic shortcodes. They are not the same data model and the editor will not reconcile them.
- Global classes carry the design system here. Create the class, then apply it; do not inline the same declarations onto siblings.
- Template conditions in Oxygen are ordered and specific-wins. List the existing conditions before adding one or the new template quietly loses to an older catch-all.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill oxygen-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Oxygen 6 for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/oxygen-get-element-tree
- wppilot/oxygen-list-element-types
- wppilot/oxygen-get-element-schema
- wppilot/oxygen-get-global-class-schema
- wppilot/oxygen-list-global-classes
- wppilot/oxygen-list-variables
- wppilot/oxygen-list-templates
- wppilot/oxygen-list-template-conditions

Then build and scope with:
- wppilot/oxygen-list-templates
- wppilot/oxygen-create-template
- wppilot/oxygen-set-template-conditions

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Oxygen 6 is the unified engine. Never emit Oxygen Classic shortcodes. They are not the same data model and the editor will not reconcile them.
- Global classes carry the design system here. Create the class, then apply it; do not inline the same declarations onto siblings.
- Template conditions in Oxygen are ordered and specific-wins. List the existing conditions before adding one or the new template quietly loses to an older catch-all.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill oxygen-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/wpbakery-check-setup
2. wppilot/wpbakery-inspect-page
3. wppilot/wpbakery-get-content
4. wppilot/wpbakery-list-elements
5. wppilot/wpbakery-get-element-schema
6. wppilot/wpbakery-list-templates

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- WPBakery stores layouts as shortcodes. Malformed nesting does not error, it renders as visible shortcode text on the front end, so verify the saved output rather than trusting the write.
- There is no global class or variable system here. Consistency comes from templates and from not inventing per-element styling.
- wpbakery-edit-elements changes several elements in one call. Use it rather than a loop of single edits when the change is uniform.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill wpbakery-build-page before it starts.

Build [PAGE TITLE] in WPBakery as a draft.

Call in this order:
1. wppilot/wpbakery-check-setup
2. wppilot/wpbakery-inspect-page
3. wppilot/wpbakery-get-content
4. wppilot/wpbakery-list-elements
5. wppilot/wpbakery-get-element-schema
6. wppilot/wpbakery-list-templates

Then write with:
- wppilot/wpbakery-set-content
- wppilot/wpbakery-add-element
- wppilot/wpbakery-edit-element
- wppilot/wpbakery-edit-elements
- wppilot/wpbakery-move-element
- wppilot/wpbakery-delete-element

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- WPBakery stores layouts as shortcodes. Malformed nesting does not error, it renders as visible shortcode text on the front end, so verify the saved output rather than trusting the write.
- There is no global class or variable system here. Consistency comes from templates and from not inventing per-element styling.
- wpbakery-edit-elements changes several elements in one call. Use it rather than a loop of single edits when the change is uniform.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill wpbakery-build-page before it starts.

Establish the shared design system in WPBakery before any page work.

Read what already exists:
- wppilot/wpbakery-inspect-page
- wppilot/wpbakery-get-content
- wppilot/wpbakery-list-elements
- wppilot/wpbakery-get-element-schema
- wppilot/wpbakery-list-templates

Then define, using:
- wppilot/wpbakery-set-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- WPBakery stores layouts as shortcodes. Malformed nesting does not error, it renders as visible shortcode text on the front end, so verify the saved output rather than trusting the write.
- There is no global class or variable system here. Consistency comes from templates and from not inventing per-element styling.
- wpbakery-edit-elements changes several elements in one call. Use it rather than a loop of single edits when the change is uniform.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill wpbakery-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in WPBakery for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/wpbakery-inspect-page
- wppilot/wpbakery-get-content
- wppilot/wpbakery-list-elements
- wppilot/wpbakery-get-element-schema
- wppilot/wpbakery-list-templates

Then build and scope with:
- wppilot/wpbakery-list-templates
- wppilot/wpbakery-create-template
- wppilot/wpbakery-apply-template

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- WPBakery stores layouts as shortcodes. Malformed nesting does not error, it renders as visible shortcode text on the front end, so verify the saved output rather than trusting the write.
- There is no global class or variable system here. Consistency comes from templates and from not inventing per-element styling.
- wpbakery-edit-elements changes several elements in one call. Use it rather than a loop of single edits when the change is uniform.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill wpbakery-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/beaver-builder-check-setup
2. wppilot/beaver-builder-get-layout
3. wppilot/beaver-builder-list-templates
4. wppilot/beaver-builder-list-global-colors

Report back:
- The node tree, summarised by section, with the node types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single node that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Beaver layouts are trees of rows, columns and modules, addressed as nodes. Use the node abilities to change one thing; beaver-builder-set-layout replaces the entire stored layout.
- Applying an existing template is usually faster than composing a layout from scratch. List the templates before deciding which job this is.
- Global colours and typography are site-wide. Editing one is a design-system change, not a page edit.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill beaver-builder-build-page before it starts.

Build [PAGE TITLE] in Beaver Builder as a draft.

Call in this order:
1. wppilot/beaver-builder-check-setup
2. wppilot/beaver-builder-get-layout
3. wppilot/beaver-builder-list-templates
4. wppilot/beaver-builder-list-global-colors

Then write with:
- wppilot/beaver-builder-set-layout
- wppilot/beaver-builder-add-node
- wppilot/beaver-builder-edit-node
- wppilot/beaver-builder-move-node
- wppilot/beaver-builder-delete-node

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Beaver layouts are trees of rows, columns and modules, addressed as nodes. Use the node abilities to change one thing; beaver-builder-set-layout replaces the entire stored layout.
- Applying an existing template is usually faster than composing a layout from scratch. List the templates before deciding which job this is.
- Global colours and typography are site-wide. Editing one is a design-system change, not a page edit.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill beaver-builder-build-page before it starts.

Establish the shared design system in Beaver Builder before any page work.

Read what already exists:
- wppilot/beaver-builder-get-layout
- wppilot/beaver-builder-list-templates
- wppilot/beaver-builder-list-global-colors

Then define, using:
- wppilot/beaver-builder-create-global-color
- wppilot/beaver-builder-edit-global-color
- wppilot/beaver-builder-edit-global-typography

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Beaver layouts are trees of rows, columns and modules, addressed as nodes. Use the node abilities to change one thing; beaver-builder-set-layout replaces the entire stored layout.
- Applying an existing template is usually faster than composing a layout from scratch. List the templates before deciding which job this is.
- Global colours and typography are site-wide. Editing one is a design-system change, not a page edit.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill beaver-builder-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Beaver Builder for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/beaver-builder-get-layout
- wppilot/beaver-builder-list-templates
- wppilot/beaver-builder-list-global-colors

Then build and scope with:
- wppilot/beaver-builder-list-templates
- wppilot/beaver-builder-create-template
- wppilot/beaver-builder-apply-template

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Beaver layouts are trees of rows, columns and modules, addressed as nodes. Use the node abilities to change one thing; beaver-builder-set-layout replaces the entire stored layout.
- Applying an existing template is usually faster than composing a layout from scratch. List the templates before deciding which job this is.
- Global colours and typography are site-wide. Editing one is a design-system change, not a page edit.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill beaver-builder-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/mosaic-check-setup
2. wppilot/mosaic-get-element-tree
3. wppilot/mosaic-check-design-system
4. wppilot/mosaic-list-utility-classes
5. wppilot/mosaic-list-variables
6. wppilot/mosaic-list-components
7. wppilot/mosaic-list-templates
8. wppilot/mosaic-list-template-assigns

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Mosaic styling is utility-class based. Create the utility class, set its style, then apply it, do not push the same declarations onto each element.
- Component instance overrides are deliberate exceptions. If you find yourself overriding the same property on every instance, the component itself is wrong.
- Template assignment is separate from template creation. A created template does nothing until mosaic-set-template-assign gives it a target.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill mosaic-build-page before it starts.

Build [PAGE TITLE] in Mosaic as a draft.

Call in this order:
1. wppilot/mosaic-check-setup
2. wppilot/mosaic-get-element-tree
3. wppilot/mosaic-check-design-system
4. wppilot/mosaic-list-utility-classes
5. wppilot/mosaic-list-variables
6. wppilot/mosaic-list-components
7. wppilot/mosaic-list-templates
8. wppilot/mosaic-list-template-assigns

Then write with:
- wppilot/mosaic-add-element
- wppilot/mosaic-edit-element
- wppilot/mosaic-move-element
- wppilot/mosaic-delete-element

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- Mosaic styling is utility-class based. Create the utility class, set its style, then apply it, do not push the same declarations onto each element.
- Component instance overrides are deliberate exceptions. If you find yourself overriding the same property on every instance, the component itself is wrong.
- Template assignment is separate from template creation. A created template does nothing until mosaic-set-template-assign gives it a target.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill mosaic-build-page before it starts.

Establish the shared design system in Mosaic before any page work.

Read what already exists:
- wppilot/mosaic-get-element-tree
- wppilot/mosaic-check-design-system
- wppilot/mosaic-list-utility-classes
- wppilot/mosaic-list-variables
- wppilot/mosaic-list-components
- wppilot/mosaic-list-templates
- wppilot/mosaic-list-template-assigns

Then define, using:
- wppilot/mosaic-create-utility-class
- wppilot/mosaic-set-utility-class-style
- wppilot/mosaic-edit-theme-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Mosaic styling is utility-class based. Create the utility class, set its style, then apply it, do not push the same declarations onto each element.
- Component instance overrides are deliberate exceptions. If you find yourself overriding the same property on every instance, the component itself is wrong.
- Template assignment is separate from template creation. A created template does nothing until mosaic-set-template-assign gives it a target.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill mosaic-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Mosaic for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/mosaic-get-element-tree
- wppilot/mosaic-check-design-system
- wppilot/mosaic-list-utility-classes
- wppilot/mosaic-list-variables
- wppilot/mosaic-list-components
- wppilot/mosaic-list-templates
- wppilot/mosaic-list-template-assigns

Then build and scope with:
- wppilot/mosaic-list-templates
- wppilot/mosaic-create-template
- wppilot/mosaic-set-template-assign

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Mosaic styling is utility-class based. Create the utility class, set its style, then apply it, do not push the same declarations onto each element.
- Component instance overrides are deliberate exceptions. If you find yourself overriding the same property on every instance, the component itself is wrong.
- Template assignment is separate from template creation. A created template does nothing until mosaic-set-template-assign gives it a target.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill mosaic-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/etch-check-setup
2. wppilot/etch-get-content
3. wppilot/etch-get-styles
4. wppilot/etch-list-stylesheets
5. wppilot/etch-list-components
6. wppilot/etch-list-templates

Report back:
- The node tree, summarised by section, with the node types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single node that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- etch-create-template writes a real WordPress wp_template post. This is the only module in WPPilot that can, so an Etch site can have its block-theme templates built by an agent where others cannot.
- Stylesheets are the cascade here, not per-node styling. Put shared rules in a stylesheet and let nodes reference it.
- Etch can define the content model as well as the layout: post types, taxonomies and field groups. Propose the model and wait for approval before creating it; retro-fitting a field group onto live content is the expensive mistake.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill etch-build-page before it starts.

Build [PAGE TITLE] in Etch as a draft.

Call in this order:
1. wppilot/etch-check-setup
2. wppilot/etch-get-content
3. wppilot/etch-get-styles
4. wppilot/etch-list-stylesheets
5. wppilot/etch-list-components
6. wppilot/etch-list-templates

Then write with:
- wppilot/etch-set-content
- wppilot/etch-add-node
- wppilot/etch-edit-node
- wppilot/etch-move-node
- wppilot/etch-delete-node

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- etch-create-template writes a real WordPress wp_template post. This is the only module in WPPilot that can, so an Etch site can have its block-theme templates built by an agent where others cannot.
- Stylesheets are the cascade here, not per-node styling. Put shared rules in a stylesheet and let nodes reference it.
- Etch can define the content model as well as the layout: post types, taxonomies and field groups. Propose the model and wait for approval before creating it; retro-fitting a field group onto live content is the expensive mistake.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill etch-build-page before it starts.

Establish the shared design system in Etch before any page work.

Read what already exists:
- wppilot/etch-get-content
- wppilot/etch-get-styles
- wppilot/etch-list-stylesheets
- wppilot/etch-list-components
- wppilot/etch-list-templates

Then define, using:
- wppilot/etch-create-style
- wppilot/etch-create-styles
- wppilot/etch-create-stylesheet
- wppilot/etch-edit-stylesheet

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- etch-create-template writes a real WordPress wp_template post. This is the only module in WPPilot that can, so an Etch site can have its block-theme templates built by an agent where others cannot.
- Stylesheets are the cascade here, not per-node styling. Put shared rules in a stylesheet and let nodes reference it.
- Etch can define the content model as well as the layout: post types, taxonomies and field groups. Propose the model and wait for approval before creating it; retro-fitting a field group onto live content is the expensive mistake.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill etch-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Etch for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/etch-get-content
- wppilot/etch-get-styles
- wppilot/etch-list-stylesheets
- wppilot/etch-list-components
- wppilot/etch-list-templates

Then build and scope with:
- wppilot/etch-list-templates
- wppilot/etch-create-template
- wppilot/etch-duplicate-template
- wppilot/etch-edit-template

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- etch-create-template writes a real WordPress wp_template post. This is the only module in WPPilot that can, so an Etch site can have its block-theme templates built by an agent where others cannot.
- Stylesheets are the cascade here, not per-node styling. Put shared rules in a stylesheet and let nodes reference it.
- Etch can define the content model as well as the layout: post types, taxonomies and field groups. Propose the model and wait for approval before creating it; retro-fitting a field group onto live content is the expensive mistake.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill etch-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/theme-bridge-check-setup
2. wppilot/theme-bridge-list-customizer-settings
3. wppilot/theme-bridge-list-block-assets

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- A block theme keeps its design in theme.json and its layout in templates. WPPilot writes neither: there is no theme.json writer, and wp_template is refused by the generic content wrapper.
- What is reachable is the registered Customizer surface plus the block assets inventory. Everything else on a block theme is a Gutenberg queue job with a human finalising in a browser.
- Say that boundary out loud at the start. A block-theme user who expects an unattended rebuild is going to be disappointed at the end instead of informed at the beginning.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill theme-bridge-build-page before it starts.

Establish the shared design system in Block themes before any page work.

Read what already exists:
- wppilot/theme-bridge-list-customizer-settings
- wppilot/theme-bridge-list-block-assets

Then define, using:
- wppilot/theme-bridge-update-customizer-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- A block theme keeps its design in theme.json and its layout in templates. WPPilot writes neither: there is no theme.json writer, and wp_template is refused by the generic content wrapper.
- What is reachable is the registered Customizer surface plus the block assets inventory. Everything else on a block theme is a Gutenberg queue job with a human finalising in a browser.
- Say that boundary out loud at the start. A block-theme user who expects an unattended rebuild is going to be disappointed at the end instead of informed at the beginning.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill theme-bridge-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/theme-bridge-check-setup
2. wppilot/theme-bridge-list-customizer-settings
3. wppilot/theme-bridge-list-block-assets

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Blocksy exposes its options through the Customizer, so the bridge reaches the registered settings and nothing more. The Blocksy Pro option store is not a writable surface here.
- Blocksy content is block content. Layout changes go through the Gutenberg queue, not through this module.
- Read the current settings and report them before changing any, because a theme setting takes effect immediately and has no draft state.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill theme-bridge-build-page before it starts.

Establish the shared design system in Blocksy before any page work.

Read what already exists:
- wppilot/theme-bridge-list-customizer-settings
- wppilot/theme-bridge-list-block-assets

Then define, using:
- wppilot/theme-bridge-update-customizer-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Blocksy exposes its options through the Customizer, so the bridge reaches the registered settings and nothing more. The Blocksy Pro option store is not a writable surface here.
- Blocksy content is block content. Layout changes go through the Gutenberg queue, not through this module.
- Read the current settings and report them before changing any, because a theme setting takes effect immediately and has no draft state.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill theme-bridge-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/theme-bridge-check-setup
2. wppilot/theme-bridge-list-customizer-settings
3. wppilot/theme-bridge-list-block-assets

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Neve is reachable through its registered Customizer settings. Header and footer builder stores that Neve keeps private are not writable through the bridge.
- Page content on a Neve site is block content and belongs to the Gutenberg queue.
- Check the setup report for the Neve edition before assuming an option exists; Pro-only settings are absent rather than empty on a free install.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill theme-bridge-build-page before it starts.

Establish the shared design system in Neve before any page work.

Read what already exists:
- wppilot/theme-bridge-list-customizer-settings
- wppilot/theme-bridge-list-block-assets

Then define, using:
- wppilot/theme-bridge-update-customizer-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Neve is reachable through its registered Customizer settings. Header and footer builder stores that Neve keeps private are not writable through the bridge.
- Page content on a Neve site is block content and belongs to the Gutenberg queue.
- Check the setup report for the Neve edition before assuming an option exists; Pro-only settings are absent rather than empty on a free install.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill theme-bridge-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/theme-bridge-check-setup
2. wppilot/theme-bridge-list-customizer-settings
3. wppilot/theme-bridge-list-block-assets

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- WoodMart Theme Settings, Header Builder, Layout Builder and the slider stores are private. The bridge reaches only the registered writable theme settings, so do not claim any of those four are editable.
- Identify which editor actually owns the page body first, Gutenberg, Elementor or WPBakery, and use that module for layout work.
- WooCommerce remains authoritative for catalogue and transactions on a WoodMart store. Theme settings never change price, stock or checkout behaviour.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill theme-bridge-build-page before it starts.

Establish the shared design system in WoodMart before any page work.

Read what already exists:
- wppilot/theme-bridge-list-customizer-settings
- wppilot/theme-bridge-list-block-assets

Then define, using:
- wppilot/theme-bridge-update-customizer-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- WoodMart Theme Settings, Header Builder, Layout Builder and the slider stores are private. The bridge reaches only the registered writable theme settings, so do not claim any of those four are editable.
- Identify which editor actually owns the page body first, Gutenberg, Elementor or WPBakery, and use that module for layout work.
- WooCommerce remains authoritative for catalogue and transactions on a WoodMart store. Theme settings never change price, stock or checkout behaviour.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill theme-bridge-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/generatepress-check-setup
2. wppilot/generatepress-list-elements
3. wppilot/generatepress-get-element
4. wppilot/generatepress-list-element-conditions
5. wppilot/generatepress-get-customizer-schema
6. wppilot/generatepress-get-settings
7. wppilot/generatepress-list-modules

Report back:
- The element tree, summarised by section, with the element types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single element that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- GeneratePress Elements are hooks, headers and layouts with display rules. Read the rules on an existing element before adding another that competes with it.
- generatepress-apply-site imports a whole Site Library design and overwrites Customizer settings. It needs GeneratePress Premium, explicit confirmation, and its rollback is partial. Treat it as a first-run action on an empty site, never a redesign tool.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill generatepress-build-page before it starts.

Build [PAGE TITLE] in GeneratePress as a draft.

Call in this order:
1. wppilot/generatepress-check-setup
2. wppilot/generatepress-list-elements
3. wppilot/generatepress-get-element
4. wppilot/generatepress-list-element-conditions
5. wppilot/generatepress-get-customizer-schema
6. wppilot/generatepress-get-settings
7. wppilot/generatepress-list-modules

Then write with:
- wppilot/generatepress-create-element
- wppilot/generatepress-edit-element
- wppilot/generatepress-delete-element

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- GeneratePress Elements are hooks, headers and layouts with display rules. Read the rules on an existing element before adding another that competes with it.
- generatepress-apply-site imports a whole Site Library design and overwrites Customizer settings. It needs GeneratePress Premium, explicit confirmation, and its rollback is partial. Treat it as a first-run action on an empty site, never a redesign tool.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill generatepress-build-page before it starts.

Establish the shared design system in GeneratePress before any page work.

Read what already exists:
- wppilot/generatepress-list-elements
- wppilot/generatepress-get-element
- wppilot/generatepress-list-element-conditions
- wppilot/generatepress-get-customizer-schema
- wppilot/generatepress-get-settings
- wppilot/generatepress-list-modules

Then define, using:
- wppilot/generatepress-set-settings
- wppilot/generatepress-add-font
- wppilot/generatepress-list-fonts

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- GeneratePress Elements are hooks, headers and layouts with display rules. Read the rules on an existing element before adding another that competes with it.
- generatepress-apply-site imports a whole Site Library design and overwrites Customizer settings. It needs GeneratePress Premium, explicit confirmation, and its rollback is partial. Treat it as a first-run action on an empty site, never a redesign tool.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill generatepress-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in GeneratePress for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/generatepress-list-elements
- wppilot/generatepress-get-element
- wppilot/generatepress-list-element-conditions
- wppilot/generatepress-get-customizer-schema
- wppilot/generatepress-get-settings
- wppilot/generatepress-list-modules

Then build and scope with:
- wppilot/generatepress-list-elements
- wppilot/generatepress-create-element
- wppilot/generatepress-set-element-conditions

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- GeneratePress Elements are hooks, headers and layouts with display rules. Read the rules on an existing element before adding another that competes with it.
- generatepress-apply-site imports a whole Site Library design and overwrites Customizer settings. It needs GeneratePress Premium, explicit confirmation, and its rollback is partial. Treat it as a first-run action on an empty site, never a redesign tool.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill generatepress-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/kadence-check-setup
2. wppilot/kadence-get-theme-json
3. wppilot/kadence-get-settings
4. wppilot/kadence-list-customizer-settings

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- kadence-get-theme-json is read-only and says so. There is no theme.json writer here, so global style changes are a manual job.
- Page content on a Kadence site is block content. That goes through the Gutenberg queue, not through this module.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill kadence-build-page before it starts.

Establish the shared design system in Kadence theme before any page work.

Read what already exists:
- wppilot/kadence-get-theme-json
- wppilot/kadence-get-settings
- wppilot/kadence-list-customizer-settings

Then define, using:
- wppilot/kadence-edit-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- kadence-get-theme-json is read-only and says so. There is no theme.json writer here, so global style changes are a manual job.
- Page content on a Kadence site is block content. That goes through the Gutenberg queue, not through this module.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill kadence-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/spectra-one-check-setup
2. wppilot/spectra-one-list-templates
3. wppilot/spectra-one-list-style-variations
4. wppilot/spectra-one-get-color-palette
5. wppilot/spectra-one-list-patterns

Report back:
- The template part tree, summarised by section, with the template part types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single template part that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- spectra-one-apply-design is the only writer of wp_global_styles anywhere in WPPilot, and it replaces wholesale rather than merging. Read the current palette and variation first, and treat it as a destructive design change.
- Style variations are the cheap, reversible move. Try applying one before writing a bespoke design.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill spectra-one-build-page before it starts.

Build [PAGE TITLE] in Spectra One as a draft.

Call in this order:
1. wppilot/spectra-one-check-setup
2. wppilot/spectra-one-list-templates
3. wppilot/spectra-one-list-style-variations
4. wppilot/spectra-one-get-color-palette
5. wppilot/spectra-one-list-patterns

Then write with:
- wppilot/spectra-one-edit-template-part

Sections, in order:
[LIST EACH SECTION AND WHAT IT HAS TO DO]

Art direction:
- Palette: [COLOURS]
- Type: [PAIRING]
- Avoid: [WHAT WOULD LOOK WRONG HERE]

Rules:
- Reuse the classes, variables and shared styles you found in the inventory step. Create a new one only when nothing existing fits, and tell me what you created.
- Any fact I have not given you, prices, credentials, client names, statistics, dates, goes in as [CONFIRM: what is missing]. Never fill the gap with something plausible.
- Leave it as a draft.

Specific to this builder:
- spectra-one-apply-design is the only writer of wp_global_styles anywhere in WPPilot, and it replaces wholesale rather than merging. Read the current palette and variation first, and treat it as a destructive design change.
- Style variations are the cheap, reversible move. Try applying one before writing a bespoke design.

Stop before: publishing, changing template conditions, editing anything site-wide, or enabling a form notification. Report what you built, what you reused, what you created and every [CONFIRM] you hit.

Loads the bundled skill spectra-one-build-page before it starts.

Establish the shared design system in Spectra One before any page work.

Read what already exists:
- wppilot/spectra-one-list-templates
- wppilot/spectra-one-list-style-variations
- wppilot/spectra-one-get-color-palette
- wppilot/spectra-one-list-patterns

Then define, using:
- wppilot/spectra-one-set-color-palette
- wppilot/spectra-one-apply-style-variation
- wppilot/spectra-one-apply-design

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- spectra-one-apply-design is the only writer of wp_global_styles anywhere in WPPilot, and it replaces wholesale rather than merging. Read the current palette and variation first, and treat it as a destructive design change.
- Style variations are the cheap, reversible move. Try applying one before writing a bespoke design.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill spectra-one-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Spectra One for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/spectra-one-list-templates
- wppilot/spectra-one-list-style-variations
- wppilot/spectra-one-get-color-palette
- wppilot/spectra-one-list-patterns

Then build and scope with:
- wppilot/spectra-one-list-templates
- wppilot/spectra-one-edit-template-part

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- spectra-one-apply-design is the only writer of wp_global_styles anywhere in WPPilot, and it replaces wholesale rather than merging. Read the current palette and variation first, and treat it as a destructive design change.
- Style variations are the cheap, reversible move. Try applying one before writing a bespoke design.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill spectra-one-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/astra-check-setup
2. wppilot/astra-list-modules
3. wppilot/astra-list-customizer-settings
4. wppilot/astra-get-settings
5. wppilot/astra-get-color-palette
6. wppilot/astra-get-header-layout
7. wppilot/astra-get-footer-layout
8. wppilot/astra-list-hooks

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Astra configures the frame, not the page content. Whichever builder owns the page body is a separate job with separate abilities.
- Customizer settings apply site-wide and take effect immediately. There is no draft state for a theme setting, read the current value and report it before changing it.
- Hooks can inject markup into every matching route. Check the display rules before creating one.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill astra-integration before it starts.

Establish the shared design system in Astra before any page work.

Read what already exists:
- wppilot/astra-list-modules
- wppilot/astra-list-customizer-settings
- wppilot/astra-get-settings
- wppilot/astra-get-color-palette
- wppilot/astra-get-header-layout
- wppilot/astra-get-footer-layout
- wppilot/astra-list-hooks

Then define, using:
- wppilot/astra-set-color-palette
- wppilot/astra-set-typography
- wppilot/astra-edit-settings

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Astra configures the frame, not the page content. Whichever builder owns the page body is a separate job with separate abilities.
- Customizer settings apply site-wide and take effect immediately. There is no draft state for a theme setting, read the current value and report it before changing it.
- Hooks can inject markup into every matching route. Check the display rules before creating one.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill astra-integration before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in Astra for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/astra-list-modules
- wppilot/astra-list-customizer-settings
- wppilot/astra-get-settings
- wppilot/astra-get-color-palette
- wppilot/astra-get-header-layout
- wppilot/astra-get-footer-layout
- wppilot/astra-list-hooks

Then build and scope with:
- wppilot/astra-list-page-headers
- wppilot/astra-create-page-header
- wppilot/astra-edit-page-header

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- Astra configures the frame, not the page content. Whichever builder owns the page body is a separate job with separate abilities.
- Customizer settings apply site-wide and take effect immediately. There is no draft state for a theme setting, read the current value and report it before changing it.
- Hooks can inject markup into every matching route. Check the display rules before creating one.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill astra-integration before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/oceanwp-check-setup
2. wppilot/oceanwp-list-modules
3. wppilot/oceanwp-list-customizer-panels
4. wppilot/oceanwp-get-settings
5. wppilot/oceanwp-list-library-items
6. wppilot/oceanwp-get-page-overrides
7. wppilot/oceanwp-list-hooks

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- OceanWP page overrides mask global settings. When a global change appears not to work, check the overrides on that page before assuming the write failed.
- Enable only the modules the work needs. Every enabled module is more CSS and JS on every page.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill oceanwp-build-page before it starts.

Establish the shared design system in OceanWP before any page work.

Read what already exists:
- wppilot/oceanwp-list-modules
- wppilot/oceanwp-list-customizer-panels
- wppilot/oceanwp-get-settings
- wppilot/oceanwp-list-library-items
- wppilot/oceanwp-get-page-overrides
- wppilot/oceanwp-list-hooks

Then define, using:
- wppilot/oceanwp-set-customizer-settings
- wppilot/oceanwp-set-typography-preset

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- OceanWP page overrides mask global settings. When a global change appears not to work, check the overrides on that page before assuming the write failed.
- Enable only the modules the work needs. Every enabled module is more CSS and JS on every page.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill oceanwp-build-page before it starts.

Create a [HEADER / FOOTER / ARCHIVE / SINGLE] template in OceanWP for [WHAT IT SHOULD COVER].

First, read what is already assigned:
- wppilot/oceanwp-list-modules
- wppilot/oceanwp-list-customizer-panels
- wppilot/oceanwp-get-settings
- wppilot/oceanwp-list-library-items
- wppilot/oceanwp-get-page-overrides
- wppilot/oceanwp-list-hooks

Then build and scope with:
- wppilot/oceanwp-list-library-items
- wppilot/oceanwp-apply-library-template

Before writing anything, tell me:
- Which templates already match the routes I named, and which one currently wins
- What this new template would take over, route by route
- What happens on routes I have not mentioned

Rules:
- A template change is not a page change. If the proposed conditions touch a route I did not ask about, stop and say so.
- Build the template inactive or unassigned first where the builder allows it, then assign after I approve the conditions.
- Reuse the existing design system rather than styling the template in isolation.

Specific to this builder:
- OceanWP page overrides mask global settings. When a global change appears not to work, check the overrides on that page before assuming the write failed.
- Enable only the modules the work needs. Every enabled module is more CSS and JS on every page.

Stop before: assigning conditions I have not approved, editing a template that is already live, or deleting an existing template because the new one supersedes it. After it is assigned, verify a representative page from every affected route and report what changed on each.

Loads the bundled skill oceanwp-build-page before it starts.

Inventory [PAGE OR POST] before anything is changed. Read only, make no writes in this run.

Call in this order:
1. wppilot/avada-check-setup
2. wppilot/avada-get-theme-options
3. wppilot/avada-list-global-colors
4. wppilot/avada-list-sliders
5. wppilot/avada-list-portfolio-items
6. wppilot/avada-list-hooks

Report back:
- The setting tree, summarised by section, with the setting types actually used
- Which shared styles, classes or settings this page depends on
- Anything defined inline on a single setting that should be shared
- Anything referencing content or fields that no longer exist
- What would break elsewhere if the shared parts were edited

Specific to this builder:
- Avada cannot build pages through WPPilot. There is no Fusion Builder element tree, no template creation and no page-building skill in this module. Anything that needs a layout built has to happen in Fusion Builder by hand.
- What this module does well is configuration: theme options, global colours and typography, and reading sliders, portfolio items and hooks.
- If a request needs a page composed, say so plainly and offer the theme-configuration work that is actually available.

Do not propose fixes yet. I want the picture first.

Loads the bundled skill avada-integration before it starts.

Establish the shared design system in Avada before any page work.

Read what already exists:
- wppilot/avada-get-theme-options
- wppilot/avada-list-global-colors
- wppilot/avada-list-sliders
- wppilot/avada-list-portfolio-items
- wppilot/avada-list-hooks

Then define, using:
- wppilot/avada-set-theme-options
- wppilot/avada-edit-global-color
- wppilot/avada-edit-global-typography

What I want defined:
- Colours: [ROLE: VALUE: background, surface, text, muted text, accent, border]
- Type: [DISPLAY / BODY / UI, with the scale]
- Spacing: [RHYTHM]
- Anything else this site repeats: [LIST]

Rules:
- Name things by role, not by appearance. A token called accent survives a rebrand; one called blue does not.
- If a token already exists for a job, use it rather than adding a near-duplicate. Show me the near-duplicates you found.
- These are site-wide changes. Show me the full proposed set and wait for approval before writing any of it.

Specific to this builder:
- Avada cannot build pages through WPPilot. There is no Fusion Builder element tree, no template creation and no page-building skill in this module. Anything that needs a layout built has to happen in Fusion Builder by hand.
- What this module does well is configuration: theme options, global colours and typography, and reading sliders, portfolio items and hooks.
- If a request needs a page composed, say so plainly and offer the theme-configuration work that is actually available.

Stop before: writing anything I have not approved, renaming a token something else already references, or deleting a token that is still in use. After approval, write them and report exactly what was created, renamed or left alone.

Loads the bundled skill avada-integration before it starts.