Page Template Library Bootstrapper

Version: 1.0.0 Updated: 2026-05-24 Category: workflow Status: stable Requires: Respira for WordPress plugin 7.1+ + MCP server

Description

Most WordPress sites have a few "canonical" page patterns the team builds over and over: the case study layout, the service page layout, the landing page hero + 3 sections + CTA layout, the team-member single layout. This skill captures those patterns as re-usable playbooks using the new v7.1 MCP tools (respira_create_playbook, respira_list_playbooks, respira_update_playbook).

Once captured, future page-generation skills (or the user directly) can spawn a new page from a playbook in seconds, on-brand, with the right structure — no more "build it from scratch every time."

What it produces

A library of named playbooks on the site, each describing:

1. Structure — the section pattern (hero → 3-up grid → quote → CTA, etc.)
2. Components per section — which builder modules/widgets to use
3. Tokens used — references to the site's design system (primary color, heading typography, etc.)
4. Variable slots — the fields the user fills in when spawning a new page from this playbook (title, hero image, key stat, body copy, etc.)
5. Builder lock — which page builder this playbook targets (a Bricks playbook isn't portable to Elementor)

When to Use

• Setting up a new site that will repeat similar page types (agency portfolio sites: case studies repeated; SaaS sites: feature pages repeated)
• After building 3+ pages with the same pattern manually — capture the pattern so the next one is instant
• Migrating from "every page hand-built" to a templated workflow
• Auditing an existing site — if you find 8 pages following the same loose pattern, capture it as a playbook so future pages snap

Trigger Phrases

• "save this as a template"
• "create a playbook from this page"
• "capture this layout"
• "make a reusable template from this"
• "build a page template library"
• "save this page pattern"
• "extract the playbook"

Execution Workflow

Step 1 — Confirm site + builder

Call respira_get_active_site and respira_get_builder_info. Playbooks are builder-specific. Note the active builder — the playbook will be locked to it.

Step 2 — Identify the source page

Two modes:

Mode A — Capture from an existing page. User says "save this page as a template." Get the page ID from the conversation context or ask the user which page (respira_list_pages for selection).

Mode B — Capture from a pattern across multiple pages. User says "all our case studies follow the same pattern — capture it." Call respira_list_custom_posts(post_type=case_study) (or respira_list_pages filtered by parent or template). Sample 3–5 of them and identify the common structure.

Step 3 — Extract the structure

For Mode A (single page):

1. respira_extract_builder_content(page_id) — get the builder-native structure
2. Walk the tree, identify the section pattern (hero / stats / 3-up / quote / CTA / etc.)
3. Note which modules each section uses
4. Identify variable content (what should be a slot) vs static content (what's structural)

For Mode B (pattern across pages):

1. Extract each sample page's structure
2. Diff them. Sections present in all samples → structural. Sections present in some → optional. Sections unique to one → user-specific content (slot candidates).
3. The common spine becomes the playbook structure. The variable parts become slots.

Step 4 — Identify slots

Slots are the fields the user fills in when spawning a new page from the playbook. Typical slots:

• Title slot (almost always)
• Hero image slot
• Hero subtitle slot
• Headline slot (the H1)
• Body content slot (long-form text region)
• Key stat slots (numbered stats with labels)
• CTA text slot + CTA URL slot
• Related items slot (a list — for related case studies, etc.)

Each slot has a type (text / image / number / URL / repeater) and an optional default value.

Step 5 — Pull design system tokens

If respira_get_option('respira_design_system') returns a saved design system, reference its tokens in the playbook. E.g. instead of hard-coding #2563EB, reference {design_system.colors.primary}. The playbook becomes drift-resistant — if the design system updates, every page spawned from the playbook reflects the new tokens.

Step 6 — Propose the playbook to the user

Output the proposed playbook shape:

## Proposed playbook: `case_study_v1`

**Targets:** Bricks 1.12 (locked)
**Sections:** 5 — Hero / Stats / Body / Quote / CTA
**Design system bound:** yes (uses primary, secondary, accent + heading typography)

### Slots (the user fills these when spawning a new page)

1. **client_name** (text, required) — e.g. "Acme Studio"
2. **hero_image** (image, required) — full-width hero
3. **subtitle** (text, optional) — short kicker above the H1
4. **headline** (text, required) — the H1
5. **stats** (repeater × 3, required) — number + label per stat
6. **body** (long_text, required) — the main case study narrative
7. **client_quote** (text, optional) — pulled quote from the client
8. **client_quote_author** (text, optional)
9. **cta_text** (text, default: "Start a project") — final CTA button
10. **cta_url** (url, default: "/contact/")

### Structure (the section spine)

1. **Hero** — full-width, centered. Uses `subtitle` + `headline` + `hero_image`.
2. **Stats** — 3-up grid. Uses `stats` repeater. Colors from design system.
3. **Body** — single-column, max-width 720px. Uses `body`.
4. **Quote** — large pull quote. Uses `client_quote` + `client_quote_author`. Optional — skipped if `client_quote` empty.
5. **CTA** — centered, on accent background. Uses `cta_text` + `cta_url`.

Ask: "Save this playbook? Anything to change?"

Step 7 — Persist the playbook

After confirmation, call respira_create_playbook with the structure + slots + design-system bindings.

Then: "Playbook `case_study_v1` saved. To spawn a new case study from it, say: `build a new case study from playbook` or call `respira_get_playbook('case_study_v1')` and then `respira_build_page` with the slot values."

Step 8 — Optional: spawn one sample

Offer to spawn one new page from the playbook immediately as a sanity check. Use realistic but generic slot values (no real customer names). User confirms it renders correctly → playbook is verified.

How other skills use playbooks

A future skill ("spawn a page from playbook X") can:

1. Call respira_get_playbook(slug) to get the structure + slots
2. Collect slot values from the user
3. Call respira_build_page with the playbook structure populated with the slot values
4. Resulting page is on-brand (design system bound), correctly structured, and ready for content

The playbook + design system + brand voice trio is the foundation for the whole content-generation suite. Build this once per site, harvest forever.

Hard rules

• Playbooks are builder-specific. A Bricks playbook cannot be applied to an Elementor site. The skill must record the builder lock and refuse to spawn against a different builder.
• Playbooks reference the design system by token name, not by hex value. This makes them drift-resistant.
• Slot names use snake_case. Slot types are constrained to: text, long_text, image, url, number, boolean, repeater.
• A playbook with zero slots is useless. Refuse to save a playbook with no slots — that's not a template, that's a copy of an existing page.
• Never overwrite an existing playbook silently. Use respira_list_playbooks to check for a same-slug existing playbook; if found, show the diff and ask before updating.
• Sample entries spawned from a playbook use generic personas (BrandQ, agency-A). Never real customer names.

Telemetry

Records: site URL hash, builder, playbook slug, slot count, structure section count, whether design system was bound, whether sample spawn succeeded, success/failure. No slot names, no slot values, no playbook content sent.

Endpoint: POST https://www.respira.press/api/skills/track-usage