Use when the user asks about WordPress codebases (plugins, themes, block themes, Gutenberg blocks, WP core checkouts) and you need to quickly classify the repo and route to the correct workflow/skill (blocks, theme.json, REST API, WP-CLI, performance, security, testing, release packaging).
Use when working with the WordPress Abilities API (wpregisterability, wpregisterabilitycategory, /wp-json/wp-abilities/v1/, @wordpress/abilities) including defining abilities, categories, meta, REST exposure, and permissions checks for clients.
Use when developing WordPress (Gutenberg) blocks: block.json metadata, registerblocktype(frommetadata), attributes/serialization, supports, dynamic rendering (render.php/rendercallback), deprecations/migrations, viewScript vs viewScriptModule, and @wordpress/scripts/@wordpress/create-block build and test workflows.
Use when developing WordPress block themes: theme.json (global settings/styles), templates and template parts, patterns, style variations, and Site Editor troubleshooting (style hierarchy, overrides, caching).
Use when building or debugging WordPress Interactivity API features (data-wp- directives, @wordpress/interactivity store/state/actions, block viewScriptModule integration, wpinteractivity()) including performance, hydration, and directive behavior.
Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing, Query Monitor via REST headers), database/query optimization, autoloaded options, object caching, cron, HTTP API calls, and safe verification.
Use when configuring, running, or fixing PHPStan static analysis in WordPress projects (plugins/themes/sites): phpstan.neon setup, baselines, WordPress-specific typing, and handling third-party plugin classes.
Use for WordPress Playground workflows: fast disposable WP instances in the browser or locally via @wp-playground/cli (server, run-blueprint, build-snapshot), auto-mounting plugins/themes, switching WP/PHP versions, blueprints, and debugging (Xdebug).
Use when developing WordPress plugins: architecture and hooks, activation/deactivation/uninstall, admin UI and Settings API, data storage, cron/tasks, security (nonces/capabilities/sanitization/escaping), and release packaging.
Use when you need a deterministic inspection of a WordPress repository (plugin/theme/block theme/WP core/Gutenberg/full site) including tooling/tests/version hints, and a structured JSON report to guide workflows and guardrails.
Use when building, extending, or debugging WordPress REST API endpoints/routes: registerrestroute, WPRESTController/controller classes, schema/argument validation, permissioncallback/authentication, response shaping, registerrestfield/registermeta, or exposing CPTs/taxonomies via showinrest.
Use when working with WP-CLI (wp) for WordPress operations: safe search-replace, db export/import, plugin/theme/user/content management, cron, cache flushing, multisite, and scripting/automation with wp-cli.yml.
Create WordPress block themes from simple descriptions and deploy them to a local WordPress Studio site, or, generate professional themes through an interactive workflow: describe your site, choose from design options, and preview on a real WordPress installation.
Bold aesthetic direction guidance for web design. Use when making creative decisions about typography, color, motion, spatial composition, and overall visual style. Helps avoid generic "AI slop" aesthetics.
WordPress Full Site Editing (FSE) theme architecture. Use when generating theme.json, block templates, template parts, patterns, and functions.php for WordPress block themes.
MCP server "CF Observability", hosted remotely at observability.mcp.cloudflare.com, as configured in Automattic/mcp-server-gravatar-remote.
★not rated 27▲
+1 1y agoA
tokens not measured
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: