원클릭으로
wordpress-blueprint-executor
Generate WordPress Playground Blueprint JSON and reproducible demo/test environment packets from approved specs.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Generate WordPress Playground Blueprint JSON and reproducible demo/test environment packets from approved specs.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Review WordPress performance risks in queries, object cache, autoloaded options, cron, HTTP calls, REST, block rendering, assets, and measurement plans.
Review WordPress security boundaries: capabilities, nonces, sanitization, escaping, SQL, REST permissions, files, secrets, and supply chain.
Review WordPress themes for theme.json correctness, templates, patterns, accessibility, performance, and editor/frontend parity.
Review WordPress performance risks in queries, object cache, autoloaded options, cron, HTTP calls, REST, block rendering, assets, and measurement plans.
Review WordPress security boundaries: capabilities, nonces, sanitization, escaping, SQL, REST permissions, files, secrets, and supply chain.
Review WordPress themes for theme.json correctness, templates, patterns, accessibility, performance, and editor/frontend parity.
| name | wordpress-blueprint-executor |
| type | executor |
| model | Codex-sonnet-4-6 |
| description | Generate WordPress Playground Blueprint JSON and reproducible demo/test environment packets from approved specs. |
Use when an approved plan needs a WordPress Playground Blueprint for demos, smoke tests, plugin/theme reproduction, snapshots, or disposable QA environments.
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.
python3 evals/harness/validate_wordpress_executor_packet.py --executor blueprint --packet <packet.md>.## Generated Blueprint that can be materialized to blueprint.json by python3 evals/harness/materialize_wordpress_executor_packet.py --executor blueprint --packet <packet.md> --out-dir <generated-blueprint-dir>.python3 evals/harness/validate_wordpress_artifact.py --artifact-type blueprint --path <blueprint.json>.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.
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.
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.
Use these headings:
## Input Summary## Generated Blueprint## Provenance Notes## Safety And Determinism Notes## Deviation Log## Verification Notes## Critic HandoffUnder ## Generated Blueprint, emit one fenced JSON object. Explanatory prose belongs outside the fence.
Original Zivtech executor protocol. Compatible references remain reference-only unless reuse is logged and licensed.