What this prompt does
This prompt scaffolds a WordPress plugin named [plugin_name] that [plugin_purpose], built with a proper object-oriented architecture. It produces PSR-4 autoloading, a main plugin class with activation and deactivation hooks, an admin page with [admin_sections] via the Settings API, REST endpoints from [api_endpoints], a custom database table [db_table] with a migration/upgrade system, a [shortcode_name] shortcode, a [block_name] Gutenberg block, AJAX handlers, WP-CLI commands for [cli_commands], and full i18n with a .pot file.
The structure works because it treats a plugin like real software, not a single procedural file. PSR-4 autoloading and a class-based core keep it testable and standards-compliant as it grows. The [db_table] definition drives the migration system so schema changes upgrade cleanly, and [api_endpoints] plus [cli_commands] give the plugin both a programmatic and a command-line surface. It also includes PHPUnit setup, GitHub Actions CI, and a readme.txt for WordPress.org.
When to use it
- You're starting a plugin and want OOP structure with PSR-4 autoloading from line one
- You need a Settings API admin page with
[admin_sections]instead of hand-rolled forms - You're exposing functionality through REST endpoints from
[api_endpoints] - You need a custom
[db_table]with a migration and upgrade system - You want WP-CLI commands for
[cli_commands]like exports and cleanup - You're aiming for WordPress.org submission and need a
readme.txt, tests, and CI
Example output
Expect a plugin skeleton: a PSR-4 directory layout, a main class with activation/deactivation hooks, a Settings API admin page, registered REST routes, a custom table with a versioned upgrade routine, a registered shortcode and Gutenberg block, AJAX handlers, WP-CLI command stubs, a .pot translation template, a PHPUnit test setup, a GitHub Actions workflow, and a WordPress.org readme.txt.
Pro tips
- Make
[plugin_purpose]concrete — a sharp purpose produces a focused class structure instead of a grab-bag of features - Define
[db_table]columns explicitly so the migration system generates the right schema and upgrade path - Keep
[api_endpoints]RESTful and predictable; the generated permission callbacks are a baseline you must review for security - Use
[cli_commands]for the operational tasks you'll actually run, like exports and purges, not speculative ones - Verify the i18n wrapping is complete before shipping — generated
.potfiles sometimes miss strings in newer code paths - Run the included PHPUnit and CI setup early so the plugin stays maintainable as you extend it
