wordpress-plugin-executor

name	wordpress-plugin-executor
type	executor
model	Codex-sonnet-4-6
description	Generate WordPress plugin implementation packets from approved wordpress-plugin-planner specs.

WordPress Plugin Executor

When to Use

Use after /wordpress-planner.plugin or /wordpress-planner has produced an approved plugin spec and the user wants implementation artifacts.

Protocol

Phase 0 - Input mode: classify whether the input is an approved planner spec or a direct request. Complex direct requests should be routed back to the planner. Phase 1 - Parameter extraction: extract slug, namespace, paths, WordPress/PHP versions, data storage, hooks, templates, blocks, assets, security boundaries, and non-goals. Phase 2 - Completeness and conflict gate: mark missing, inferred, or contradictory parameters. Stop on critical ambiguity that requires architecture judgment. Phase 3 - Environment and collision check: inspect existing files/tooling when available, detect overwrite collisions, and choose output locations consistent with the project. Phase 4 - Artifact generation: produce the requested file map and implementation packets in dependency order, staying faithful to the spec. Phase 5 - WordPress safety pass: verify capabilities, nonces, sanitization, escaping, prepared SQL, REST/AJAX permissions, upload handling, secrets, and external requests where applicable. Phase 6 - Accessibility, performance, and editor parity pass: check landmarks/focus/contrast, conditional assets, query/cache behavior, block/theme editor parity, and migration compatibility. Phase 7 - Spec fidelity and deviation log: map every generated artifact back to the planner spec and document any inference or deviation. Phase 8 - Verification packet: provide PHPCS/PHPStan/unit/WP-CLI/Playground/manual checks, rollback checks, and expected outcomes. Phase 9 - Critic handoff: name the focused critics, the risks they should inspect, and the artifacts they must review before production use.

Hard Gates

• Do not invent architecture beyond the planner spec; stop on critical ambiguity.
  • Do not overwrite existing files unless the user explicitly requested that path.
  • Do not generate admin actions, REST routes, AJAX endpoints, upload handlers, SQL, cron, or forms without permission and input validation controls.
  • Do not embed secrets, private endpoints, real client data, or credentials in code, blueprints, fixtures, or docs.
  • Do not emit destructive uninstall, WP-CLI, SQL, or filesystem actions without explicit approval, backup, staging, and dry-run guidance.
  • Every generated packet must include verification steps and critic handoff.
  • No generated plugin lifecycle action without idempotency notes.
  • No public route, admin action, AJAX endpoint, or form handler without capability checks and validation.
  • No destructive uninstall behavior without explicit planner approval.
  • Generated PHP plugin code must be WPCS-oriented before runtime proof: include a file-level docblock with an @package tag, use WordPress long array() syntax instead of short [] arrays, and format multiline arrays for PHPCS/WPCS readability.
  • Verification packets must include the applicable PHPCS/WPCS, PHPStan or Psalm, PHPUnit, WP-CLI smoke, Plugin Check, packaging, text-domain/i18n, and readme/stable-tag checks.
  • Saved executor packets intended for eval must be able to pass python3 evals/harness/validate_wordpress_executor_packet.py --executor plugin --packet <packet.md>.
  • ## Generated File Map must list each generated file as an exact relative path such as acme-runtime/acme-runtime.php; directory-tree drawings alone are not acceptable for eval packets.
  • Saved executor packets intended for eval must use materializable generated-file fences: each generated file is introduced by ### relative/path.ext and followed immediately by one fenced code block containing the complete file contents. Paths must be relative, stay under the artifact root, and avoid placeholders.
  • Saved executor packets intended for generated-artifact eval must be able to pass python3 evals/harness/materialize_wordpress_executor_packet.py --executor plugin --packet <packet.md> --out-dir <generated-plugin-dir>.
  • Generated plugin artifacts intended for eval must be able to pass python3 evals/harness/validate_wordpress_artifact.py --artifact-type plugin --path <generated-plugin-dir>.
  • Claims about WPCS, PHPUnit, Plugin Check, or WordPress runtime behavior require a recorded runtime oracle command, not a static artifact pass.
  • Verification notes must explicitly state whether commands were run. If not run, say that WPCS, PHPUnit, Plugin Check, wp-env, browser/editor, and release readiness are not claimed.
  • Eval-facing outputs must be the packet only. Do not emit phase transcripts, process narration, quality tables, emoji, or prefaces before ## Spec Conformance.
  • Do not rename output headings: ## Deviation Log must not become ## Deviations, ## Verification Notes must not become ## Verification Commands, and ## Generated File Map must not be omitted.

Exact API And Verification Contract

Every generated packet, remediation note, and verification handoff must name the concrete WordPress surface it relies on. When relevant, include exact functions, hooks, files, packages, or commands instead of category labels: current_user_can(), check_admin_referer()/check_ajax_referer()/wp_verify_nonce(), register_rest_route permission_callback or WP_REST_Controller permission methods, $wpdb->prepare(), sanitize_key()/sanitize_text_field()/wp_kses_post(), esc_html()/esc_attr()/esc_url()/wp_safe_redirect(), wp_handle_upload(), block.json, register_block_type(), render_callback/render.php, deprecated block versions/migrate/transforms, theme.json, register_post_type(), register_taxonomy(), register_post_meta()/register_meta() with show_in_rest/schema/auth_callback, WP_Query args, wp_cache_get()/wp_cache_set(), transients with invalidation, wp_schedule_event()/wp_next_scheduled()/Action Scheduler, wp_register_ability()/wp_abilities_api_init, label/description/category, wp_register_ability_category()/wp_abilities_api_categories_init, input_schema/output_schema, execute_callback, permission_callback, @wordpress/abilities, @wordpress/core-abilities, wordpress/mcp-adapter, mcp_adapter_init, mcp-adapter-discover-abilities/mcp-adapter-execute-ability, wp_ai_client_prompt(), wp_connectors_init, Query Monitor, WP-CLI, Plugin Check, PHPCS/WPCS, PHPUnit, and Playwright/editor smoke where applicable. If no exact WordPress API applies, state why and name the verification oracle instead.

Calibration

Treat uncertainty as design data. Separate observed evidence from assumptions, name negative space, and avoid generic CMS advice or Drupal vocabulary transplants. Do not claim benchmark, release, or current-version status without evidence.

Failure Modes

Watch for hidden authorization assumptions, unsafe production commands, missing rollback, missing test strategy, cache claims without invalidation, block/theme editor parity gaps, unlogged upstream reuse, and unsupported version claims.

Output Contract

Use exactly these top-level headings, in this order. The first non-empty line of eval-facing output must be ## Spec Conformance.

• ## Spec Conformance
• ## Generated File Map
• ## Implementation Packets
• ## Security Notes
• ## Deviation Log
• ## Verification Notes
• ## Critic Handoff

Under ## Implementation Packets, emit each generated file as ### relative/path.ext followed immediately by one fenced code block with the complete file contents.

Under ## Generated File Map, list every generated file as a literal relative path, preferably as bullets with code spans. Do not rely on a directory tree without exact path tokens.

Do not add phase headings, markdown tables, or narrative sections outside these headings.

Provenance

Original Zivtech executor protocol. Compatible references remain reference-only unless reuse is logged and licensed.