Skip to content
Skillpedia
APIs & servers (backend)48k · #4579

woo-guard

Reviews WooCommerce extensions, payment integrations, and order or product logic.

What it does

This agent checks if code for online stores built with WooCommerce is secure and up-to-date. It ensures the code works correctly with the latest WooCommerce versions, especially regarding payments, shipping, and how orders are processed.

When to use it

  • ✓When reviewing new or changed code for a WooCommerce store.
  • ✓Before publishing a new feature or update for a WooCommerce store.
  • ✓When the code interacts with the order, payment, or checkout system.

Example of what to ask your AI

“Review this code to ensure it's compatible with the latest WooCommerce versions and follows security best practices.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/woo-guard/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/sickn33/agentic-awesome-skills/blob/main/plugins/agentic-awesome-skills-claude/skills/woo-guard/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

The agent analyzes the code to make sure it uses the correct functions to access and save order and product data, and that payment and checkout validations are done server-side.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add sickn33/agentic-awesome-skills --skill woo-guard

Or download just the file:

curl -L https://raw.githubusercontent.com/sickn33/agentic-awesome-skills/main/plugins/agentic-awesome-skills-claude/skills/woo-guard/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

Woo Guard

You are reviewing generated or changed WooCommerce code before it ships. Apply the rules below as a guard pass after the first implementation pass. WooCommerce is a moving platform — order storage changed engines, checkout changed frameworks — and code written from memory targets the WooCommerce of three years ago. With money on the line, "works on my demo store" is not a standard.

These rules exist because AI agents produce WooCommerce code with systematic failures: order meta read through get_post_meta() (broken on HPOS stores), products updated by direct meta writes that skip lookup tables and hooks, checkout validated only in JavaScript, prices computed in floats, and woocommerce_* hooks registered before confirming WooCommerce is active.

When to Use

Use this skill when reviewing generated or changed WooCommerce code — extensions, payment and shipping integrations, checkout customizations, and order/product logic — before it ships. Activate it reactively after an agent writes or modifies WooCommerce hooks, HPOS logic, or checkout flows.

How to use this skill

Guard-pass mode (recommended): after WooCommerce code has been generated or edited, apply the rules to the diff or target files, then run the self-check before delivery.

Live mode (explicit): when the user invokes this skill before writing WooCommerce code, apply the same rules while writing, then run the self-check before delivery.

Review mode (the user asks you to review or audit WooCommerce code): walk references/review-checklist.md and produce a structured findings report. Do not edit code in review mode unless asked.

Security floor — these hold in all WooCommerce code, at maximum severity, because money is on the line:

  • Escape all output with the context-correct esc_* function.
  • wp_unslash() then sanitize all request data before it touches logic.
  • Capability check plus nonce on every state change.
  • $wpdb->prepare() for every query containing a variable.

If wp-guard is installed, run it alongside for the full WordPress layer.

Adapt to the project first

  1. Read the project's agent instructions and the extension's declared WooCommerce version range. Project conventions win on conflict.
  2. Determine the order storage mode this code must support: HPOS, legacy posts, or both (the default assumption is both).
  3. Determine the checkout in play: Blocks/Store API, legacy shortcode checkout, or both. Hooks for one do not fire in the other.
  4. Check whether WooCommerce activity is guarded: feature checks or class_exists( 'WooCommerce' ) before any wc_* call or woocommerce_* hook.

The Rules

Order and product data — must fix

  1. Orders are not posts. Access orders only through the CRUD API: wc_get_order(), wc_get_orders(), $order->get_meta(), $order->update_meta_data() + $order->save(). Forbidden on order data: get_post_meta(), update_post_meta(), WP_Query/get_posts() with post_type => shop_order, and direct $wpdb joins on postmeta. These work on legacy stores and silently break on HPOS stores. Details: references/hpos-and-crud.md.

  2. CRUD objects, getters/setters, then save. Products, customers, and coupons go through their CRUD objects (wc_get_product(), setters, ->save()). Direct meta writes skip lookup-table sync, skip the hooks other extensions rely on, and skip cache invalidation. Stock changes go through wc_update_product_stock() semantics; order state changes through $order->update_status() — which fire the emails and hooks the store expects.

  3. Declare feature compatibility. Any extension touching orders declares HPOS compatibility (FeaturesUtil::declare_compatibility( 'custom_order_tables', … )); any extension touching checkout declares cart_checkout_blocks compatibility (or incompatibility, honestly). A missing declaration shows every store owner a warning banner with your plugin's name on it.

Checkout and money — must fix

  1. Checkout validation is server-side. Validate at woocommerce_checkout_process (legacy) or through Store API extension schemas (Blocks). JavaScript validation is UX, never security. Know which checkout the store runs and wire both when the extension claims general compatibility.

…

FAQ

Why shouldn't I use `get_post_meta()` to access order data?

In newer WooCommerce versions (HPOS), orders are no longer stored as regular posts. Using `get_post_meta()` can cause the code to stop working correctly on those stores.

What does 'validate checkout server-side' mean?

It means that important checks to ensure an order can be completed (like stock availability or payment information) should be done on the server, not just in the client's browser. This is crucial for security.

Why should code declare compatibility with HPOS and checkout blocks?

Declaring compatibility informs WooCommerce and other developers that your code has been tested and works with the newer ways of managing orders (HPOS) and the modern checkout system (blocks), preventing warnings and issues for the store owner.

Details

Original description by the author

Review generated or changed WooCommerce extensions, payment and shipping integrations, checkout customizations, and order or product logic.

repo: sickn33/agentic-awesome-skills

Popularity

GitHub stars
48k
Ranking position
#4579
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills