Build a WooCommerce store

Describe the catalogue. Watch it get built.

One brief names your products, their options, pricing logic and imagery. The agent then works through 54 typed WooCommerce abilities in dependency order: taxonomy first, attributes and terms next, parent products, then every valid variation, and reads the storefront back so you can see what a customer will actually get.

Catalogue brief

This is the whole input.

Paste this into Claude Code, Cursor, Codex or any connected client. Fill the bracketed fields; leave [CONFIRM] on anything you have not verified and the agent will stop rather than invent it.

Paste into your AI client

PROJECT TYPE: STORE CATALOGUE
STORE: [STORE NAME] selling [PRODUCT FAMILY] to [CUSTOMER TYPE].
SOURCE DATA: [SPREADSHEET / SUPPLIER SHEET / EXISTING SITE]: treat it as the only source of truth for names, SKUs, prices and stock.
TAXONOMY: Build the category tree first: [TOP-LEVEL CATEGORIES] with [SUBCATEGORIES]. Add tags only where they describe a real filter shoppers use.
ATTRIBUTES: Global attributes for [SIZE / COLOUR / MATERIAL / FORMAT] with the exact term lists supplied. Do not create per-product attributes where a global one belongs.
PRODUCTS: [N] simple products and [N] variable products. Each needs description, short description, price, SKU, stock behaviour, category, image and gallery.
VARIATIONS: Generate only combinations that genuinely exist. Missing price, SKU or stock for a variation is a stop, not a guess.
SHIPPING CLASSES: [CLASS NAMES] applied to [WHICH PRODUCTS].
STATUS: Create everything as draft or private first. I will approve before anything is visible.
VERIFY: After the run, read the saved products back, list anything that failed, and check the storefront for the three products I name.
CONFIRM: Prices, stock counts, weights, dimensions, certifications, delivery times and product claims are [CONFIRM] unless present in the source data.

One prompt from you becomes hundreds of typed ability calls from the agent, each one checked against your WordPress capabilities, the active safety profile and the confirmation rules before it runs.

What happens next

The run, step by step

Nothing here is a black box. Every step is a typed call you can see in the change log afterwards.

  1. 1

    Reads the store before it writes

    The run opens with woocommerce-check-setup, which reports the WooCommerce version, whether HPOS is enabled, the block checkout state, currency, default country and the detected extensions. That answer shapes everything after it.

  2. 2

    Builds the taxonomy in dependency order

    Categories, then tags, then shipping classes. Products created before their category exists end up orphaned, so the agent never starts with products even when the brief lists them first.

  3. 3

    Creates global attributes and their terms

    Size, colour, material: created once as global pa_ attributes with their full term lists, so variations can reference them and shoppers get working filters instead of thirty per-product duplicates.

  4. 4

    Creates parent products, then valid variations only

    Each variable product is created first, then every variation is added with an explicit mapping for each variation-enabled attribute. A combination with no price or SKU in the source stops the run for that product rather than shipping a broken variation.

  5. 5

    Imports and attaches media

    Images come in through import-media-url, get attached, and are set as featured or gallery images. Alt text is written from the product data, not left blank.

  6. 6

    Reads the result back

    The agent re-reads the saved products, compares them against the source rows, and reports the diff: what was created, what was skipped, and which fields it refused to guess.

Plugins it can drive

It works with what you already run.

WPPilot Pro ships 53 integration families. A module only registers once its plugin is detected on the site and a Pro licence is active.

Commerce

WooCommerce (54 abilities, HPOS-aware)

Storefront pages

ElementorBricksDivi 5Oxygen 6BreakdanceBeaver BuilderWPBakeryEtchMosaicWoodMart

Product data

ACFACPTMeta BoxPodsJetEngine

Search visibility

Yoast SEORank MathAIOSEOSEOPress

Under the prompt

The abilities this run actually calls

Real registered ability names from the shipped plugin source. Each one has a schema, a permission check and a risk classification.

woocommerce-check-setupwoocommerce-create-product-categorywoocommerce-create-product-attributewoocommerce-create-product-attribute-termwoocommerce-create-productwoocommerce-create-product-variationwoocommerce-create-product-tagwoocommerce-create-product-shipping-classwoocommerce-edit-productwoocommerce-list-productswoocommerce-get-store-settingswoocommerce-create-couponwoocommerce-sales-summaryimport-media-urlset-featured-image

Where it stops

What stays yours.

Speed is only useful if you can trust the result. These are real constraints in the plugin source, not a disclaimer paragraph.

Read the security model
  • Payments, tax rates, shipping zones and store settings stay yours. Those surfaces are read-only in WPPilot. The agent can report what is configured, and cannot change it.
  • Product types are simple and variable. Grouped and external products are not part of the current module.
  • Large catalogues run as a resumable batch. Writes are capped at 120 per minute per credential, so a 400-SKU import is a paced job you can watch, not a single silent transaction.
  • Refunds, order status changes and review deletion are classed destructive: they need an explicit confirmation flag every time, in every safety profile that allows them at all.
  • A successful ability call is not a completed transaction. Payment, tax, email and fulfilment behaviour still has to be tested against sandbox providers.

Questions

Build a WooCommerce store, answered

Can it really build a whole catalogue from one prompt?

Yes. One prompt from you becomes hundreds of typed ability calls from the agent. You write the brief once; the agent creates the categories, attributes, terms, products, variations and media one governed call at a time, and reports what it could not resolve.

Will it set up payments and shipping too?

No, and it will tell you so. Store settings, payment gateways, tax rates and shipping zones are read-only surfaces in WPPilot. The agent reads them to make correct decisions about the catalogue, then leaves the money configuration to you.

What happens to products it cannot complete?

They stop. A variation with no price, a product with no SKU, a certification claim that was not in the source data. The agent reports it as unresolved instead of inventing a value. That is the difference between a catalogue you can ship and one you have to audit line by line.

Does it work with HPOS?

Order reads go through wc_get_orders(), which is HPOS-agnostic, and the setup check reports whether HPOS is enabled on your install before anything runs. Test the exact combination of WooCommerce version and extensions on staging first.

Can it work on a live store?

It can, and Production Safe is the default profile for exactly that reason. Start on staging with a dedicated credential, create as draft, approve, then repeat the run against production once you have seen the output.

Your site · your policy · your AI client

Send the brief. Get the woocommerce store.

Install WPPilot Free to connect your AI client, then add Pro for the builder, commerce and plugin modules this run depends on.