Review WordPress code for security and API compliance

Acts as a judgment-layer review pass over generated or changed WordPress plugins, themes, and blocks - applied after a first implementation pass, or as a standing review when the user asks to audit or rate existing code. It exists because AI-written WordPress code fails in specific, repeatable ways: raw echo of request data, AJAX handlers with neither a nonce nor a capability check, SQL built by string interpolation, English hardcoded into user-facing strings, posts_per_page => -1 on a site with a million posts, and hand-rolled replacements for APIs core already ships - each looking fine in a demo and failing in production. Security rules are must-fix, no exceptions: every variable crossing into HTML output goes through the context-correct esc_html()/esc_attr()/esc_url()/wp_kses_post() (data for inline JS goes through wp_json_encode() + wp_add_inline_script() instead, since esc_js() is legacy); request superglobals go through wp_unslash() first, then a type-correct sanitizer, never the other way around; every state-changing form handler, AJAX endpoint, or REST route needs BOTH a capability check (current_user_can()) and a nonce (check_admin_referer()/check_ajax_referer()/a real REST permission_callback) - a nonce alone is not authorization, and a REST permission_callback of __return_true on a writing route fails review outright; and every $wpdb query with a variable goes through $wpdb->prepare() placeholders, never interpolation.

A second tier of core-API-discipline rules catches silent failures rather than exploits: using wp_remote_get()/wp_remote_post() instead of curl, wp_enqueue_script()/wp_enqueue_style() instead of echoed tags, WP-Cron/Action Scheduler instead of hand-rolled scheduling, and verifying every hooked function actually exists in the supported WP/PHP versions before calling it - a hallucinated hook fails silently in WordPress with no error and no behavior, which is specifically dangerous because nothing surfaces the mistake. Every public name (functions, options, meta keys, script handles, AJAX actions, REST namespaces) must carry the project's own prefix, and every working PHP file needs its ABSPATH guard. Internationalization rules require the context-correct wrapper (__()/_e()/_x()/_n()/the esc_*__() combos) with a literal text domain matching the plugin slug, translator comments on every placeholder, _n() for plurals rather than a hardcoded singular/plural ternary, and no sentence assembly by string concatenation - these become blocking, not advisory, the moment the project is multilingual (WPML/Polylang/multisite). Performance rules ban posts_per_page => -1 and query_posts() outright, require 'fields' => 'ids'/'no_found_rows' => true when applicable, require cache priming instead of a meta lookup inside a loop, and require transients/object cache with a deliberate TTL behind any expensive remote call or computation.

Before delivering, the skill runs an explicit self-check: grep the diff for echo/print/<?= and confirm every output is escaped; grep for $_POST/$_GET/$_REQUEST and confirm unslash-then-sanitize-then-nonce-then-capability; grep for $wpdb-> and confirm every variable sits behind a placeholder; check every user-facing string is wrapped and every text domain is a literal; check every hook/function was actually verified to exist; check for unbounded queries, uncached remote calls, or unconditional enqueues; check every new public name carries the project prefix; and ask whether the code would survive WPCS (WordPress-Extra + WordPress-Security) without unjustifiable warnings. In review mode it instead walks a structured five-pass checklist (security, API/hook correctness, i18n, performance, packaging hygiene) and produces a findings report grouped by file, security-first, citing file and line, ending with an overall merge/fix-first/do-not-merge verdict.

Use it when reviewing generated or changed WordPress code - plugins, themes, blocks - before it ships, triggered reactively after an agent writes, edits, or reviews code touching WordPress APIs (hooks, custom post types, REST endpoints, database queries, block editor integrations). Pair it with a companion clean-code-guard skill when installed, since that owns generic code quality while this owns the WordPress-specific layer, and hand off to a woo-guard skill for WooCommerce-specific HPOS/CRUD/checkout rules when that code is in scope. The skill is explicit about what it does NOT do: it does not run PHPCS, PHPStan, or Plugin Check itself (use the project's own tooling for mechanical verification - this is the judgment layer above it), it does not decide plugin architecture or business logic, and it does not replace a dedicated test-quality guard. Its authorized-use banner requires reviewing only WordPress code and environments the user owns or is explicitly authorized to assess, and any command that would probe, exploit, change, persist on, or extract data from a live target requires the exact target, explicit written-authorization confirmation, and a stated expected effect before running - absent that confirmation it stays read-only and defensive.

Input is the generated/changed WordPress code (a diff or target files) plus the project's own CLAUDE.md/AGENTS.md, phpcs.xml/WPCS config, and composer.json, which win on any conflict with the skill's own defaults - including the project's established naming prefix and minimum supported WP/PHP versions. Output in guard-pass or live mode is the code itself with violations fixed before delivery; output in review mode is a structured findings report in a fixed format (**Rule N violation** in path/file.php:<line> with What/Risk/Fix), grouped by file, security findings first, ending with at most three positives worth keeping.

Covers WordPress's own core APIs directly - escaping/sanitization functions, the nonce and capability lifecycle, REST permission_callback and args schema validation, $wpdb->prepare(), wp_handle_upload(), WP_Query flags, transients and the object cache, and JS i18n via wp_set_script_translations() - and expects WPCS (WordPress-Extra/WordPress-Security) as the mechanical baseline it judges above, not a replacement for.

Developers and coding agents shipping WordPress plugins, themes, or blocks who need a systematic guard pass against the specific security, i18n, and performance mistakes AI-generated WordPress code repeatedly makes. Community-sourced from amElnagdy/guard-skills, added 2026-07-13.