WooCommerce extensions

When to use it

Build, debug or review WooCommerce extensions: HPOS order access, classic vs block checkout and Store API, gateways, refunds, stock, payment webhooks, Action Scheduler jobs and template overrides. Generic plugin or REST issues go to the plugin and REST skills.

Boundaries and hand-offs

Exploitable authorization/XSS/SQLi in general plugin code to wp-devkit-security-review; REST route design to wp-devkit-rest-api-development; lifecycle or uninstall to wp-devkit-plugin-development; measured slowness beyond Woo internals to wp-devkit-performance-review; data upgrades to wp-devkit-migration-upgrade-review.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:woocommerce-review <target-path>

The short form /wp-devkit:woocommerce requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-woocommerce-dev
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• checkout-blocks-and-store-api.md : read for hook parity, fields, Store API, block payments, totals.
• order-storage-and-hpos.md : read for order CRUD, queries, admin screens, sync and CLI.
• payment-and-job-reliability.md : read for webhooks, inbox/outbox, Action Scheduler.
• payments-refunds-and-stock.md : read for gateway contract, statuses, stock, refunds, money.
• templates-sessions-and-performance.md : read for overrides, fragments, sessions, products.

How a review runs

1. Reproduce or describe the journey. Record checkout type and storage mode; a finding is scoped to the modes evidenced.
2. Trace each order read and write to its object: order CRUD, product CRUD, or a different post type. Direct post-meta use on non-orders is fine.
3. Follow the money path: amount, currency, tax, shipping, coupon, refund. Identify who is authoritative (provider event, order state) at each step.
4. For callbacks and jobs, find the authentication step, the durable acceptance point, the idempotency key and the recovery path for a crash between steps.
5. Compare overrides and extension points with the installed version (template diff, hook table, Store API route source).
6. Confirm each candidate with a code path and, when possible, a runtime check on a disposable store. Otherwise report it as a candidate with the missing evidence. Insufficient evidence is a valid outcome: report what could not be established (provider behavior, live runner, tax jurisdiction) and the check that would settle it.

What you get back

Review: result and reviewed scope first. Each confirmed finding: severity per the contract, file:line, actor, trigger, reachable path, impact (money/stock/data), confidence, minimal fix, regression test. Keep candidates and "not verified" items in a separate list.

Implementation: changed boundaries, behavior before/after, storage/checkout modes covered, commands run with exit status, checks not run, residual risk, rollback note (flag or revert path; data changes need a backup/restore plan).

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.