--- name: wordpress-plugin description: Generate a complete, production-ready, enterprise-grade WordPress plugin from scratch — the kind that could be submitted to the WordPress.org repository today. Output is a full file tree with main plugin file, modular OOP classes (Admin, Frontend, Database, AJAX, REST), settings pages using the Settings API, Gutenberg blocks and shortcodes, REST endpoints, custom tables created via dbDelta(), nonce verification, sanitization/escaping/capability checks, prepared statements, asset enqueueing with conditional loading, internationalization with text domain, object-cache-aware queries, PHPDoc on every public method, a README.txt in WordPress.org format, and a complete uninstall.php cleanup script. Follows WordPress VIP coding standards and WordPress Theme/Plugin Review guidelines. Use this skill whenever the user asks to "write a WordPress plugin", "build a WP plugin", "scaffold a WordPress plugin", "create a custom WordPress plugin", "generate a plugin boilerplate", "make me a WordPress plugin that does X", "WordPress plugin from scratch", or anything that involves producing an installable .zip-able WordPress plugin folder. Trigger on phrases like "WP plugin", "wordpress.org plugin", "plugin repo submission", "custom post type plugin", "settings page plugin", "REST endpoint plugin", or "Gutenberg block plugin" — even if the word "WordPress" appears only once. Before generating, the skill MUST collect seven required inputs (plugin name, functionality categories, specific feature detail, target users, admin interface components, frontend display surfaces, third-party integrations) via multiple-choice prompts using AskUserQuestion. Free-text fallback exists only for plugin name and the feature-detail elaboration. --- # WordPress Plugin Generator Generate a complete, enterprise-grade WordPress plugin from scratch. Output is a full directory tree with production-ready PHP, JavaScript, CSS, and metadata files. No placeholders, no `TODO` comments, no missing security measures. The skill takes seven inputs (five via multiple choice, two free-text), infers the plugin slug and architecture from those inputs, and produces every file required to install, activate, configure, and uninstall the plugin on a real WordPress site. ## Workflow 1. **Run the multiple-choice intake.** Use `AskUserQuestion` to ask all seven questions. Two are free-text (plugin name, feature detail). Five are multiple-choice — four `multiSelect: true`, one single-select. 2. **Derive the slug and constants.** From the plugin name, derive `kebab-case` slug, `snake_case` text domain (same as slug), `SCREAMING_SNAKE` constant prefix, and `PascalCase` namespace. 3. **Resolve scope.** From the multiple-choice answers, decide which classes to generate (Admin, Frontend, Database, AJAX, REST), which assets to enqueue, and which integration scaffolds to include. 4. **Generate the full plugin tree.** Every file must be filled in — no `TBD`, no `{placeholder}`, no `// TODO`. 5. **Write to disk.** Default root: `./{plugin-slug}/` in the current working directory. If that directory already exists, write to `./{plugin-slug}-new/` instead and tell the user. 6. **Report back** with the directory path, file count, and a one-line summary. Do not paste full file contents into chat — they are on disk. ## Intake Ask all seven questions in a single `AskUserQuestion` call where possible. The two free-text answers can be a single message asking for them up front; the five multiple-choice questions use `AskUserQuestion`. ### Q1 — Plugin name (free text) ``` What is the plugin called? (e.g. "Acme Bookings", "Smart Redirects Pro", "Membership Tiers") ``` Use this exact name in the plugin header, `Plugin Name:` field, and main display labels. ### Q2 — Functionality (multi-select MC) > Which WordPress mechanisms does the plugin use? Select all that apply. | Option | What it generates | |--------|-------------------| | Custom Post Types & Taxonomies | `register_post_type()` + `register_taxonomy()` with capability mapping | | Settings / Options Page | Full Settings API implementation with tabs and sanitization callbacks | | Gutenberg Blocks | `block.json` + `register_block_type()` + edit.js + save.js + style.scss | | Shortcodes | `add_shortcode()` with attribute sanitization and output escaping | | REST API endpoints | `register_rest_route()` with `permission_callback` + schema | | WP-CLI commands | `WP_CLI::add_command()` with subcommands and synopsis | | Cron / Scheduled tasks | `wp_schedule_event()` + activation hook registration + cleanup on deactivate | | Custom Database Tables | `dbDelta()` schema, charset/collation, indexes, version-bump migrations | | User Roles / Capabilities | `add_role()` + `add_cap()` with proper cleanup on uninstall | | Email Notifications | `wp_mail()` wrapper with templates and HTML headers | | Frontend Forms | Nonced AJAX form with server-side validation | | Dashboard Widget | `wp_add_dashboard_widget()` with cached data fetch | | Import / Export | JSON/CSV export endpoint and import handler with file validation | | Analytics / Activity Logging | Custom log table + admin viewer with filters | | Custom User Meta | `register_meta()` + profile field rendering with sanitization | ### Q3 — Specific feature detail (free text) ``` In 2–4 sentences, describe what the plugin actually DOES at the user level. What problem does it solve? What is the happy-path user flow? (Example: "Lets shop owners offer time-slot bookings on any WooCommerce product. Customers pick a date and slot at checkout; staff see all bookings in a calendar view in WP admin and receive an email when one is made.") ``` This drives the domain logic, naming of classes, and copy in the README.txt. ### Q4 — Target users (single-select MC) > Who is the primary audience using this plugin? Pick one. | Option | Implication | |--------|-------------| | Site administrators only | Generate admin-side features; minimal/no frontend output | | Editors and authors | Generate role-aware capability checks; meta boxes on post screens | | Frontend site visitors | Generate public-facing shortcodes/blocks; minimize admin surface | | Developers (extending via hooks/API) | Generate documented hooks, filters, and REST endpoints; ship a `docs/` folder | | Multisite network administrators | Generate network-activation support, `is_multisite()` branches, network settings page | | Mixed / multiple of the above | Generate full surface (admin + frontend + extensibility) | ### Q5 — Admin interface components (multi-select MC) > Which admin UI components does the plugin need? Select all that apply. | Option | What it generates | |--------|-------------------| | Top-level admin menu | `add_menu_page()` with custom icon (dashicons) | | Submenu under Settings | `add_options_page()` | | Submenu under Tools | `add_management_page()` | | Meta boxes on post types | `add_meta_box()` with nonce + capability check on save | | Custom post type list-table screens | `WP_List_Table` subclass with sortable columns and bulk actions | | Dashboard widget | `wp_add_dashboard_widget()` | | Admin notices | Dismissible notices with user-meta persistence | | Help tabs on plugin screens | `get_current_screen()->add_help_tab()` | | None (frontend-only plugin) | Skip all admin UI scaffolding | ### Q6 — Frontend display surfaces (multi-select MC) > How does the plugin render on the public site? Select all that apply. | Option | What it generates | |--------|-------------------| | Shortcodes | `add_shortcode()` handlers | | Gutenberg blocks | `block.json` + React edit component + save function + frontend `render_callback` | | Classic widgets | `WP_Widget` subclass | | Template tags / functions | Public `acme_render_*()` functions for themes to call | | Auto-injected via `the_content` filter | Filter-based injection with opt-out via post meta | | REST-driven SPA / headless | REST endpoints + minimal client-side fetch demo | | Custom page templates | `page-*.php` templates registered via `theme_page_templates` filter | | None (admin-only plugin) | Skip all frontend scaffolding | ### Q7 — Third-party integrations (multi-select MC) > Which external services or plugins does this integrate with? Select all that apply. | Option | What it generates | |--------|-------------------| | None | Skip integration scaffolding | | WooCommerce | Hooks into WC actions/filters; checks `class_exists( 'WooCommerce' )` before booting integration | | BuddyPress / bbPress | Hooks into BP/bbP actions with `function_exists()` guards | | Advanced Custom Fields (ACF) | Registers field groups via PHP; gracefully degrades if ACF inactive | | Elementor | Custom widget class extending `Widget_Base` | | External REST API | HTTP client wrapper using `wp_remote_get()` / `wp_remote_post()` with retries and error handling | | Stripe or PayPal | Server-side payment intent / order creation with webhook handler | | Mailchimp / ConvertKit / SendGrid | Newsletter signup handler with API key in encrypted option | | Google Analytics / Tag Manager | Frontend tracking snippet enqueue with cookie-consent gate | | OAuth providers (Google, GitHub, etc.) | OAuth callback handler + state nonce + user linking | | Webhooks (incoming) | REST endpoint with HMAC signature verification | | Webhooks (outgoing) | Async dispatcher using Action Scheduler if available, falls back to wp-cron | ## Inference rules From the answers, derive without asking: - **Slug** — `sanitize_title( plugin_name )`. Example: "Acme Bookings" → `acme-bookings`. - **Text domain** — same as slug. - **Constant prefix** — uppercase slug with hyphens → underscores. Example: `ACME_BOOKINGS_`. - **PHP namespace** — PascalCase of slug. Example: `AcmeBookings`. - **Main file name** — `{slug}.php`. - **Singleton class name** — `{Namespace}\\Plugin`. - **Minimum WordPress version** — `6.0`. - **Minimum PHP version** — `7.4` (8.0+ recommended). - **License** — `GPL-2.0-or-later` with `License URI: https://www.gnu.org/licenses/gpl-2.0.html`. ## Required file structure Always produce this baseline tree. Skip files that correspond to unselected features (e.g. no `includes/class-rest-controller.php` if REST endpoints not picked). ``` {plugin-slug}/ ├── {plugin-slug}.php ← main plugin file (header + bootstrap) ├── uninstall.php ← runs on plugin deletion ├── readme.txt ← WordPress.org format ├── readme.md ← GitHub-friendly mirror ├── composer.json ← autoload definition, dev deps optional ├── .gitignore ├── languages/ │ └── {plugin-slug}.pot ← translation template (header populated) ├── includes/ │ ├── class-plugin.php ← singleton, loads other components │ ├── class-activator.php ← activation hook handler │ ├── class-deactivator.php ← deactivation hook handler │ ├── class-i18n.php ← text domain loader │ ├── class-admin.php ← admin pages, menus, settings (if admin features picked) │ ├── class-frontend.php ← shortcodes, scripts, public hooks (if frontend picked) │ ├── class-database.php ← dbDelta schema, migrations (if custom tables picked) │ ├── class-ajax.php ← admin-ajax handlers (if AJAX picked) │ ├── class-rest-controller.php ← REST routes (if REST picked) │ ├── class-cron.php ← scheduled events (if cron picked) │ ├── class-cli.php ← WP-CLI commands (if CLI picked) │ ├── class-roles.php ← role/capability management (if roles picked) │ ├── class-cpt.php ← custom post types/taxonomies (if CPT picked) │ ├── class-meta-boxes.php ← meta box registration (if meta boxes picked) │ ├── class-list-table.php ← WP_List_Table subclass (if list tables picked) │ ├── class-dashboard-widget.php ← dashboard widget (if picked) │ ├── class-notices.php ← dismissible admin notices (if picked) │ ├── class-integration-{name}.php ← one per third-party integration picked │ └── helpers.php ← procedural utilities ├── assets/ │ ├── css/ │ │ ├── admin.css │ │ └── public.css │ ├── js/ │ │ ├── admin.js │ │ └── public.js │ └── images/ │ └── icon.svg ├── blocks/ ← only if Gutenberg blocks picked │ └── {block-slug}/ │ ├── block.json │ ├── edit.js │ ├── save.js │ ├── index.js │ ├── editor.scss │ └── style.scss ├── templates/ ← user-overridable theme templates (if frontend picked) │ └── {feature}-display.php └── tests/ └── README.md ← brief notes on running PHPUnit/WPCS ``` ## Code-generation rules These rules are non-negotiable. Every generated file is held to them. ### Security - **Direct access guard** on every PHP file: `defined( 'ABSPATH' ) || exit;` immediately after the docblock. - **Nonces** on every form, AJAX request, and REST mutation. `wp_create_nonce()` + `check_admin_referer()` / `wp_verify_nonce()` / `permission_callback`. - **Capability checks** before any privileged action: `current_user_can( 'manage_options' )` (or stricter mapped capability for CPTs). - **Sanitization on input** — `sanitize_text_field()`, `sanitize_email()`, `absint()`, `wp_kses_post()`, `esc_url_raw()` matched to the data type. Never store raw `$_POST`/`$_GET` values. - **Escaping on output** — `esc_html()`, `esc_attr()`, `esc_url()`, `wp_kses_post()`. No `echo $var;` — only escaped variables reach the page. - **Prepared statements** — every `$wpdb` query uses `$wpdb->prepare()` with `%s`/`%d`/`%f` placeholders. Never interpolate into SQL. - **REST `permission_callback`** — never `__return_true` unless the route is intentionally public; document why if so. - **Forbidden constructs** — no dynamic code execution helpers, no `extract()`, no `create_function()`, no remote includes, no unsafe deserialization. ### Standards & Style - WordPress Coding Standards (WPCS) compliant. Spaces around array brackets `[ 'foo' ]`, Yoda conditions where applicable, `elseif` not `else if`. - PHPDoc block on every class, every public method, every filter/action. `@since`, `@param`, `@return`, `@throws` where relevant. - Class file naming: `class-{kebab-case}.php`. - PHP open tag only — no `?>` at end of pure PHP files. ### Architecture - Singleton main plugin class with `get_instance()` and a `private __construct()` that wires sub-components. - Composition over inheritance for components — each class accepts its dependencies in the constructor. - Hooks registered in dedicated `register_hooks()` methods on each component, called once from the bootstrapper. - No business logic in the main plugin file beyond constants and the bootstrap call. ### Performance - Object-cache-aware: `wp_cache_get()` / `wp_cache_set()` around expensive queries with the plugin slug as cache group. - Transients for cross-request caching with sensible expirations. - Asset enqueueing is **conditional** — never load admin assets on the frontend, never load on screens that don't need them. Use `get_current_screen()` checks. - Versioned asset URLs (`filemtime()` or plugin version constant) for cache busting. - Dependency arrays passed to `wp_enqueue_*()` — never assume globals. ### Database - Custom tables created via `dbDelta()` (not raw `CREATE TABLE`) with charset/collation from `$wpdb->get_charset_collate()`. - Indexes on every foreign key and every WHERE/ORDER BY column the plugin actually queries. - Schema version stored in an option; activation hook compares it and runs migrations. - `uninstall.php` drops all custom tables, options, user meta, post meta, and scheduled events the plugin created. No orphaned data. ### Internationalization - Every user-facing string wrapped in `__()`, `_e()`, `esc_html__()`, `esc_html_e()`, `_n()`, `_x()`, etc. — with the plugin's text domain (matches slug). - Text domain loaded on `plugins_loaded` via `load_plugin_textdomain()`. - `.pot` file shipped in `languages/` with all extracted strings and full header (Project-Id-Version, Last-Translator, Language-Team, etc.). - Translator comments where placeholders are non-obvious: `/* translators: %s is the user display name */`. ### Documentation - File-level docblocks with `@package`, `@since`, `@license`. - Class-level docblocks describing responsibility and dependencies. - `readme.txt` in WordPress.org format with all required sections: `=== Plugin Name ===`, `Contributors`, `Tags`, `Requires at least`, `Tested up to`, `Stable tag`, `License`, `License URI`, then `== Description ==`, `== Installation ==`, `== Frequently Asked Questions ==`, `== Screenshots ==`, `== Changelog ==`, `== Upgrade Notice ==`. - `readme.md` mirrors the same content in GitHub-friendly markdown. ### Uninstall - `uninstall.php` runs only when invoked by WordPress — guard with `if ( ! defined( 'WP_UNINSTALL_PLUGIN' ) ) { exit; }`. - Removes: all options (`delete_option()`), transients, user meta, post meta, custom tables (`DROP TABLE IF EXISTS`), scheduled cron events, registered roles, registered capabilities. - Multisite-aware: loops over `get_sites()` and runs cleanup per site, plus network options cleanup. ## Main file header template Every plugin's `{slug}.php` opens with this header. Fill in real values — never leave placeholders. ```php `. - Encoding UTF-8, LF line endings throughout. - After writing, print one line to chat: `Wrote {N} files to {path}. Activate via the WordPress admin → Plugins → {Plugin Name}.` - Do NOT paste full source into chat — the user opens the files directly. ## Quality checklist Before declaring done, verify every item: - [ ] All seven intake answers captured (5 multi-choice, 2 free-text). - [ ] Plugin slug, text domain, namespace, and constant prefix all derived consistently from the plugin name. - [ ] Main plugin file has a complete header with no `{placeholder}` text. - [ ] `defined( 'ABSPATH' ) || exit;` guard at the top of every PHP file. - [ ] Every form/AJAX/REST mutation has nonce verification. - [ ] Every privileged action has a capability check. - [ ] Every user input passes through a sanitizer matched to its type. - [ ] Every echoed variable passes through an escaping function matched to its context. - [ ] Every `$wpdb` query uses `$wpdb->prepare()` with placeholders — no string interpolation into SQL. - [ ] Every user-facing string is wrapped in an i18n function with the correct text domain. - [ ] `readme.txt` in WordPress.org format with all required headers populated. - [ ] `uninstall.php` removes every artefact the plugin creates (options, tables, meta, cron, roles, caps). - [ ] Asset enqueueing is conditional — no admin assets on frontend, no public assets on every admin screen. - [ ] Custom tables (if any) use `dbDelta()` with charset/collation and have indexes on queried columns. - [ ] Multisite-aware activation, deactivation, and uninstall when "Multisite network administrators" was selected. - [ ] No `TODO`, no `TBD`, no placeholder text remains in any file. - [ ] Zero filler comments. PHPDoc only where required by standards; no narrative commentary.