Menu
Gather the site name and layout preference before building a WordPress site. Run this before creating any new site.
Write editable WordPress block markup for local Studio sites, including core/html limits, block-theme layout rules, full-width sections, validation, and skeleton-first page/CSS recipes.
Choose WordPress plugins and plugin-provided blocks for features that core WordPress blocks do not cover, while keeping generated content editable and avoiding raw HTML fallbacks.
Verify and polish a built or redesigned site by diagnosing rendered-DOM issues against intent and fixing them in a planned, batched screenshot-and-fix loop.
Plan and execute high-quality visual direction for site creation, redesign, layout, typography, color, motion, and visual polish.
Manage a remote WordPress.com site with wpcom_request, including API namespace selection, endpoint discovery, content/template/theme/plugin operations, response-size limits, and visual verification.
Analyze and optimize a WordPress site's category taxonomy. Exports all posts, uses AI to suggest an improved category structure — merging duplicates, retiring dead categories, creating missing ones, writing descriptions, and re-categorizing posts. Run this when the user wants to clean up or improve their categories.
| name | site-spec |
| description | Gather the site name and layout preference before building a WordPress site. Run this before creating any new site. |
| user-invokable | true |
Before creating a new WordPress site, gather the user's basic preferences through a short interactive discovery phase. This produces a Site Spec that guides all subsequent design and development decisions.
Gather preferences through 2 rounds. Keep it concise.
AskUserQuestion constraints: Each call supports 1-4 questions, each with 2-4 options. An "Other" free-form option is automatically provided by the system — do NOT add one yourself. Keep option labels short (1-5 words). Only use AskUserQuestion for questions that have meaningful predefined options. For open-ended questions (like asking for a name), just ask in your text output — the user will type their answer in the prompt.
Ask the user for their business/site name in your text output. Stop here and wait for their reply — do NOT call any tools or continue to the next round. The user needs a chance to type their answer in the prompt.
After the user provides the name, use AskUserQuestion for:
Call site_create with the provided name and use the layout preference to guide all subsequent design decisions.
State the plan as a short Site Spec summary before building, alongside the design direction. The summary MUST include a Functionality & plugins line: review the requested features, load the plugin-recommendations skill, and list the specific plugins the site needs — e.g. WooCommerce for selling products, Jetpack Forms for a contact form — or "None — core blocks only" when nothing beyond static content is required. Install the listed plugins while building (Workflow Step 4); do not silently hand-build static markup for a feature a plugin should provide.
The turn immediately after site_create is the biggest source of perceived hangs. Acknowledge the site in ≤2 lines of prose, then make your next tool call a small one — site_info, or a single ≤50-line first Write. Do NOT scaffold the theme, chain multiple Writes, or write a long design-plan essay in this turn. Grow the build across many small turns (see the "Working cadence" section of the system prompt).
Skipping means skipping the interactive questions only — still produce the Site Spec summary (including the Functionality & plugins line) before building. Do NOT ask questions if:
