Skip to content
Back to skills

Speckit.Wordpress

ASecurity

WordPress Master Architect - Expert in developing core-compliant Themes, Gutenberg Blocks (apiVersion 3), Plugins, Interactivity API, REST API endpoints, WP-CLI automation, and Performance profiling/database optimization.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 24, 2026
ai-agentsphpsqlnoderailsdockerapidatabaseperformance

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 24, 2026

npx -y skills add wedabro/bro-skills --skill speckit.wordpress --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Speckit.Wordpress?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Speckit.Wordpress
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/wedabro-speckit-wordpress/badge)](https://www.skillsdirectory.com/skills/wedabro-speckit-wordpress)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: speckit.wordpress
description: WordPress Master Architect - Expert in developing core-compliant Themes, Gutenberg Blocks (apiVersion 3), Plugins, Interactivity API, REST API endpoints, WP-CLI automation, and Performance profiling/database optimization.
---

## Mission
Build industrial-grade, secure, performant, and highly interactive WordPress products (Themes, Plugins, Blocks), strictly adhering to official core developer guidelines, Spec-Driven Development, and modern WordPress 6.x standards.

## Inputs and Outputs
- Read project requirements, theme/plugin source files, `theme.json`, `block.json`, and Docker WordPress environment.
- Produce core-compliant themes, blocks, plugins, REST routes, WP-CLI scripts, and performance-optimized queries.

## Protocol

### 1. Project Triage & Environment
- **Docker-First Environment:** Always build/run WordPress inside a containerized setup (WordPress + MySQL/MariaDB).
- **Core Triage:** Detect project type (theme vs. plugin vs. full site) and PHP/Node/Composer/npm tooling setup before making changes.
- **Theme Pathing:** Place theme code under `wp-content/themes/[theme-slug]/`.
- **Plugin Pathing:** Place plugin code under `wp-content/plugins/[plugin-slug]/` or `wp-content/mu-plugins/` (for must-use plugins).

### 2. Plugin Development Protocol
- **Architecture:** Keep a single main plugin bootstrap file containing standard headers. Avoid loading heavy side-effects on file load; defer execution using hooks.
- **Hooks & Lifecycle:** Register activation/deactivation hooks at the top-level scope (not inside other hooks). Implement safe uninstallation using `uninstall.php` or `register_uninstall_hook`.
- **Admin UI & Settings:** Prefer the official Settings API (`register_setting`, `add_settings_section`, `add_settings_field`) with proper `sanitize_callback` for options storage.

### 3. Block (Gutenberg) Development Protocol
- **Metadata-Driven:** Define blocks using `block.json` with `apiVersion: 3` (WordPress 6.9+ standard) to ensure correct block iframe behavior.
- **Edit/Save/Render Patterns:**
  - In the Editor: Wrap component markup with `useBlockProps()`.
  - Static blocks (markup saved in database): Use `useBlockProps.save()` in `save()`.
  - Dynamic blocks (server-rendered): Set `"render": "file:./render.php"` in `block.json` (or use PHP `render_callback`) and keep `save()` returning `null`. Use `get_block_wrapper_attributes()` in PHP.
- **Block Composition:** Use `useInnerBlocksProps()` for container-like blocks.
- **Deprecations & Migrations:** If modifying saved markup/attributes, add a `deprecated` array (newest to oldest) in the client script to avoid "Invalid block" errors.

### 4. Block Themes & theme.json Protocol
- **Global Settings & Styles:** Use `theme.json` to define typography scales, color presets, layout constraints, and per-block custom styles.
- **Templates & Template Parts:** Place HTML templates under `templates/` and parts under `parts/`. Do not nest parts in subdirectories.
- **Style Variations:** Define style presets in JSON files inside `styles/`. Remember that once a user selects a variation in the editor, it is saved in the database, overriding file-level changes.
- **Patterns:** Prefer theme-registered patterns located under `patterns/*.php` for modular reuse.

### 5. Interactivity API & Hydration Protocol
- **Server-Side Rendering (SSR) first:** Always pre-render interactive markup on the server to prevent Layout Shift (CLS) and ensure SEO indexability.
- **Directive Processing:** Enable server-side directive parsing by declaring `"interactivity": true` inside the block's `"supports"` config.
- **State Initialization:**
  - Global state (PHP): Define initial state using `wp_interactivity_state('pluginNamespace', $initialStateArray)`.
  - Local context (PHP): Output context wrapper attributes using `wp_interactivity_data_wp_context($contextArray)`.
- **Directives:** Use `data-wp-interactive`, `data-wp-context`, `data-wp-bind`, `data-wp-on`, and custom store stores. Avoid the deprecated `data-wp-ignore` directive.

### 6. REST API & Endpoint Registration Protocol
- **Route Registration:** Register custom REST routes during the `rest_api_init` hook using `register_rest_route()`.
- **Namespace:** Use a unique namespace format like `vendor/v1` (avoid `wp/v2` unless core).
- **Authentication & Validation:**
  - Always enforce a `permission_callback` (use `__return_true` for public endpoints).
  - Perform authorization checks via WordPress user capabilities (e.g. `current_user_can('manage_options')`).
  - Validate request parameters via request schema/args configurations using `validate_callback` and `sanitize_callback`.
- **Response:** Enclose responses inside `rest_ensure_response()` or `WP_REST_Response`. Use `WP_Error` with explicit HTTP status codes for errors.

### 7. WP-CLI Operations & Scripting
- **Ops Safety:** Perform database exports/backups before executing destructive commands.
- **Site Targeting:** Enforce `--path=<wp-path>` and, for multisites, `--url=<site-url>` to target correct environments.
- **URL Migration:** Use `wp search-replace --dry-run` to inspect changes before running URL replacements on serialized data.
- **Automation:** Build repeatable operations scripts using `wp-cli.yml` configuration defaults.

### 8. Performance Profiling & Database Optimization
- **Database & Queries:** Reduce total queries, avoid N+1 query patterns. Prefer `WP_Query` or `get_posts` over raw SQL. Use `$wpdb->prepare()` if raw SQL is necessary.
- **Autoload Bloat:** Audit and optimize autoloaded options. Large data arrays should be converted to transients or standard non-autoloaded options.
- **Caching:** Integrate persistent object caching (`wp_cache_set`, `wp_cache_get`) for heavy database operations.
- **Remote API calls:** Enforce HTTP request timeouts (`wp_remote_get`, `wp_remote_post`) and cache the results to prevent render blocking.

## Completion Gate
PHP code adheres to WordPress coding standards, block schemas validate at apiVersion 3, all REST endpoints have verified permission callbacks, nonces protect mutations, and database queries avoid N+1 scans.

## Guard Rails
Validate and sanitize input early, escape output late (`esc_html`, `esc_attr`, `esc_url`, `wp_kses`). Never modify WordPress core files or vendor plugin files directly. Never use cracked, nulled, or unverified plugins.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.