pixfort

View saved version →

---
name: connect-sites
description: Connect a pixfort account and WordPress sites to the pixfort MCP server, select the intended site, or troubleshoot account authorization and site connectivity.
---

# Connect pixfort sites

Follow explicit user instructions over workflow defaults; remain within the available tools and the user's authorized scope.

The plugin registers the remote HTTP endpoint `https://mcp.pixfort.com/mcp`. Account OAuth and WordPress site enrollment are separate. No local server or manually supplied API key is required.

Discover available pixfort tools by their base names; installed namespace prefixes vary. Preserve any explicitly selected connection. Use `pixfort_list_connected_sites` to inspect account enrollment, then `pixfort_get_site_status` to verify actual WordPress reachability. A successful list alone is not a site health check.

The WordPress site should use at least **pixfort Theme version 1.20.2** and **pixfort Core version 4.3.4**. When version information is available, check both versions and advise updating either component if it is below the minimum.

If tools are unavailable or account authentication is required, guide the customer through the client's pixfort plugin connection/authentication UI and pixfort account consent. Never ask them to paste passwords, Application Passwords, OAuth tokens, or authorization callback URLs into chat. Authentication approval remains with the customer.

If no sites are connected:
1. Open or link to [pixfort connected sites](https://pixfort.com/mcp-sites).
2. Have the customer sign in and enter their public HTTPS WordPress site URL under Connect your website.
3. Follow the redirect to WordPress, sign in as an administrator, and approve the `pixfort MCP` application. The dashboard handles the Application Password exchange.
4. Return to the dashboard and verify the connection result. Re-list sites in MCP; refresh/reconnect the client's pixfort authorization if the authenticated site list remains stale.

Public service enrollment does not support localhost or private-network sites. Do not recommend disabling URL protections. If dashboard access is unavailable, report its actual account eligibility message rather than promising access or guessing a subscription requirement.

Select the site matching the user's domain/name. If several candidates remain ambiguous, ask which site to use before site-dependent writes. Pass its returned `site_id` on subsequent site-scoped tools, even when only one exists. Read `pixfort_get_site_status` for site compatibility and available version information. Report the selected URL and verified readiness for the requested operation.

## Diagnose at the failing layer

- MCP OAuth/HTTP 401 or `invalid_grant`: reconnect the pixfort account in the client. Do not revoke the WordPress site merely to repair account OAuth.
- Listed site but WordPress 401/403: inspect the message; use the dashboard's site Reconnect flow for invalid/revoked site credentials or authorization. Do not loop account login for a site permission problem.
- No tools after authentication: refresh client tool discovery or start a new task after plugin installation. Do not claim the plugin is connected until a tool succeeds.
- Missing route/unsupported builder: relay the tool's required pixfort Core/theme/Elementor compatibility guidance. A local element catalog can be available even when the site runtime is incompatible.
- Network failure: report the target and safe error, check site availability through permitted read tools, and stop repeated identical attempts. Never substitute a different customer's site.

Use only safe error text in the handoff. Do not expose credentials from logs or configuration.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: create-website-demo
description: Create a complete multi-page website demo or substantial demo content on a connected pixfort WordPress site, using Elementor schemas, reusable demo sections, site media, and coordinated content planning.
---

# Create a pixfort website demo

Follow explicit user instructions over workflow defaults; remain within the available tools and the user's authorized scope.

Build a coherent website on the user's selected pixfort site. This workflow creates WordPress content through pixfort tools. A standalone coded website is a different task.

## Establish the brief and target

Discover the installed pixfort namespace, list connected sites, resolve the intended site, and verify compatibility with `pixfort_get_site_status`. For connection problems use the sibling [connect-sites skill](../connect-sites/SKILL.md). Keep the returned `site_id` explicit on site-scoped calls.

Use the supplied business, audience, language, visual direction, and requested pages. Ask only for missing details that materially affect the result, especially an ambiguous target site. Infer an appropriate sitemap when none was supplied and state it before building. A useful small business starting point is Home, About, Services, and Contact; adapt the pages and amount of content to the brief.

Inspect existing pages and site styles before creating anything. Reuse work already created for this request. Preserve unrelated pages and existing site settings. Treat a generic request for demo content as permission to create drafts; publication, changing the live homepage, and activating global templates need to be within the user's stated scope. Existing explicit authorization is sufficient; do not add another approval checkpoint.

When browser access is available, get each target page's actual `link` from `pixfort_get_page` or `pixfort_list_pages` and inspect the page before editing it to understand its current layout and the request. For a new page, inspect it after creation and before adding content if its authenticated preview is accessible. Do not infer a URL from its slug.

Maintain a compact local or conversational build ledger: selected site, intended pages, created IDs/slugs/statuses, media IDs, sections completed, latest readback, and remaining work. Record results immediately so an interrupted run resumes without duplicate creation. This ledger is task data, not plugin memory.

## Design and content

Create a shared voice, palette, typography, spacing, and imagery direction using `pixfort_get_theme_styles`. Prefer current color `utility_slug` values. Site-wide branding uses discovered Theme Options, not repeated page-local overrides; change it only when in scope.

Write page-specific copy with clear headings and relevant calls to action. Do not invent real testimonials, customer logos, certifications, prices, addresses, or business claims. Use clearly identified sample material where a demo needs it. Do not present a decorative contact form as a working email integration.

Before each section addition, call `pixfort_search_demo_sections` with a natural-language `query` to find the closest relevant section, even if it is not an exact match. Fetch its exact returned ID with `pixfort_get_demo_section`. Treat the supplied business brief as a request to adapt relevant copy, while preserving the section's layout, unrelated settings, widget types, and public demo image URLs unless the user explicitly requests different media. Build from scratch only when no relevant section exists or the user asks for it. Favor coherent sections over an unrelated mix. Read [builder-and-media.md](references/builder-and-media.md) before assembling or saving sections.

## Build in resumable units

Create each new page with `pixfort_create_content`, `type: page`, and explicit `status: draft` to keep it unpublished. Do not use scheduled or custom public statuses for draft work. Record the returned ID. Inspect its builder state before adding content

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: site-layout
description: Coordinate pixfort website navigation, headers, footers, global styling, and template display conditions using live schemas and version-safe updates.
---

# Coordinate a pixfort site layout

Follow explicit user instructions over workflow defaults; remain within the available tools and the user's authorized scope.

Resolve the selected connected site and use its `site_id` throughout. Inspect the current layout before changes. Apply only the requested global or page-specific scope. Preparing a draft template, publishing it, and activating it are distinct operations; use existing user authorization for each intended outcome.

## Navigation

Read `pixfort_get_menu_schema`, list menus, and resolve named destinations with content discovery. For an existing menu read both `pixfort_get_menu` and `pixfort_get_menu_items`. Use the returned schema/version tokens for every mutation. Read fresh state or use a returned fresh version before the next item change.

Create with `pixfort_create_menu`; use semantic add/update/move fields supported by the live item tools. Do not write native `_menu_item_*` metadata. Preserve unrelated items, unknown settings, and hierarchy. Menu creation does not assign theme locations. A header menu element can reference the discovered menu according to its live schema; do not claim it assigns a WordPress menu location.

## Headers and footers

Resolve names with `pixfort_search_builder_items`, using `item_type: header` or `footer`. Continue automatically for a unique exact match; disambiguate multiple matches instead of guessing IDs.

For headers, read `pixfort_get_header_schema`, `pixfort_list_header_elements`, and the schemas of changed elements. Create an empty draft with `pixfort_create_header_draft`, supplying its title and optional slug/general settings. Use `pixfort_update_header_settings` to change an existing header's title, slug, or general settings.

Use the dedicated tools for each structural change: `pixfort_add_header_column` adds only `topbar_3`; `pixfort_update_header_area` and `pixfort_update_header_column` patch settings on existing targets; `pixfort_add_header_element`, `pixfort_update_header_element`, `pixfort_move_header_element`, and `pixfort_remove_header_element` change one element. Each tool has its own input schema. Do not send an `operation` selector or `operations` array. The former `pixfort_create_header` and `pixfort_update_header` tools are unavailable.

Fetch `pixfort_get_header` immediately before each edit; map its version to `expected_header_version` and include `header_schema_version`. Preserve unrelated and unsupported legacy data. Add a missing third topbar column before adding an element to it, and use the saved element ID for later edits. Serialize changes and inspect between calls: each call saves independently, and edits to an active header can appear immediately. If a response is lost, inspect before retrying an addition. New headers remain drafts while being assembled. Publish through `pixfort_set_header_status` when requested, using the current version.

Check `pixfort_get_site_status` for `pixfooter` in the supported content types. When supported, create a draft footer with `pixfort_create_content` using `type: pixfooter`. Use `pixfort_get_builder_content` and `pixfort_add_builder_content` to populate its Elementor layout, and `pixfort_update_builder_content` for existing elements, using current schema/content versions. Use `pixfort_edit_content` for metadata or publishing when requested; do not send Elementor layout as its HTML content field. On older sites that do not expose `pixfooter` creation, ask the customer to create the empty footer in WordPress and then finish its supported builder content. Do not silently create a regular page as a footer substitute.

The dedicated `pixfort_set_default_website_header` and `pixfort_set_default_website_footer` select global fallbacks. They do not publish templates, change conditions, or gu

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.