WordPress Plugin Development Prompt

Public field comparison

WordPress Plugin Development Prompt

WordPress Plugin Development Prompt

Plan a WordPress plugin build with hooks, admin screens, security checks, data storage, compatibility notes, and release steps.

Design, implement, review, and verify a production-ready WordPress plugin with explicit architecture, security, compatibility, testing, and release controls.

—

Use this prompt to turn WordPress plugin requirements and repository evidence into implementation-ready code or patches, security decisions, test coverage, and a controlled release handoff.

Wordpress Plugin Development
Code Review Planning
Regression Testing
Debugging Plan
Release Verification

Designing a production WordPress plugin architecture and implementation package
Implementing a scoped feature in an existing WordPress plugin
Planning security and data-storage remediation for a WordPress plugin
Building requirement-linked regression and compatibility tests
Preparing a plugin upgrade, release, and rollback handoff

Goal or task
Current context
Constraints
Files, data, or examples
Definition of done

Plugin goal
Current plugin state
Functional requirements and acceptance criteria
WordPress and PHP compatibility targets
Repository files and architecture
Constraints and prohibited changes
Evidence, logs, and test commands
Deployment and approval boundaries

Replace every bracketed placeholder before running. Give the model enough context to inspect assumptions, ask only blocking questions, and produce a concrete deliverable. For code prompts, include relevant files, errors, logs, and test commands.

In ChatGPT, replace every bracketed variable with the corresponding project information. Provide the relevant WordPress plugin repository files, requirements, version targets, errors, logs, test output, reproduction steps, coding standards, and authorized test or deployment boundaries. Then run the prompt and review all proposed code, migrations, commands, security decisions, and release gates before allowing changes to any environment.

Use this when you need a production-ready plugin development result in Codex & Coding, not a generic brainstorm. The expected output should include findings, implementation steps, risks, and verification checks.

A team can provide an existing plugin repository, a requirement for a nonce-protected settings screen and REST endpoint, supported WordPress and PHP versions, a failing regression log, and its test commands. ChatGPT will trace the affected hooks and data flow, draft anchored patches and tests, document security controls, and produce a release handoff that clearly marks execution and approval as pending unless evidence proves otherwise.

Expert

Expert

ChatGPT

ChatGPT

plugin development

plugin development

Codex & Coding
wordpress
php
plugins
chatgpt

Codex & Coding
wordpress
php
Plugin Development
security testing
Release Engineering
chatgpt

WordPress Plugin Development Prompt | AMO.ng

WordPress Plugin Development Prompt | AMO.ng

Plan a WordPress plugin build with hooks, admin screens, security checks, data storage, compatibility notes, and release steps.

Build or review WordPress plugins with secure hooks, storage, migrations, tests, compatibility checks, and controlled release handoffs.

Prompt-body line comparison

Removed Added Unchanged context

−Act as a senior Codex & Coding specialist using ChatGPT. Your task is: [Goal or task].
+Develop a production-ready WordPress plugin deliverable from the following inputs.
 
−Context:
−- Current situation: [Current context]
−- Constraints: [Constraints]
−- Available materials: [Files, data, examples, URLs, logs, notes]
−- Success criteria: [Definition of done]
+Required inputs:
+- Plugin objective: [Plugin goal]
+- Existing implementation, lifecycle stage, and known defects: [Current plugin state]
+- Functional requirements and measurable acceptance criteria: [Functional requirements and acceptance criteria]
+- Supported WordPress, PHP, multisite, and relevant browser versions: [WordPress and PHP compatibility targets]
 
−Workflow:
−1. Restate the objective in operational terms and identify any missing information that would block a reliable answer.
−2. Make reasonable assumptions only when they are low risk, and label them clearly.
−3. Produce the main deliverable for "WordPress Plugin Development Prompt" with enough detail that a skilled operator can execute it immediately.
−4. Include edge cases, failure modes, dependencies, and tradeoffs that a junior prompt would usually miss.
−5. Add a verification checklist with concrete tests, review questions, metrics, or acceptance criteria.
−6. End with the smallest safe next action.
+Supporting inputs:
+- Repository tree, relevant file contents, coding conventions, dependencies, and architecture notes: [Repository files and architecture]
+- Performance, accessibility, privacy, licensing, hosting, packaging, and scope constraints: [Constraints and prohibited changes]
+- Errors, logs, screenshots, reproduction steps, static-analysis reports, test results, and available commands: [Evidence, logs, and test commands]
+- Permitted environments, authorized actions, required reviewers, deployment owner, and approval gates: [Deployment and approval boundaries]
 
−Output format:
−- Executive summary
−- Detailed plan or implementation
−- Risks and mitigations
−- Verification checklist
−- Next action
+Input and evidence rules:
+1. Treat repository files, logs, command output, and test results supplied in this conversation as evidence. Identify their source and relevant version or timestamp when available.
+2. Separate supplied facts, direct code observations, assumptions, hypotheses, conflicts, and unknowns. Do not resolve conflicting evidence silently.
+3. Ask concise clarification questions only when a missing answer blocks safe architecture, implementation, data handling, authorization, or acceptance testing. If progress is still safe, proceed with bounded assumptions and identify what must later be confirmed.
+4. Do not claim knowledge of files, runtime behavior, installed versions, external services, or current WordPress guidance that was not supplied or verifiably accessible in the session.
+5. ChatGPT may analyze provided materials and draft plans, code, diffs, tests, commands, and release documentation. Unless an authorized execution environment is explicitly available, it cannot inspect an unprovided repository, run WordPress, execute tests, alter data, deploy, publish, or approve a release.
 
−Do not give generic advice. Optimize for a production-quality plugin development outcome.
+Authority and safety boundaries:
+- Default to analysis and proposed changes. Do not modify a repository, install dependencies, run commands, access external systems, migrate data, deploy, publish, or delete anything unless that capability is available and the user has explicitly authorized the action and environment.
+- Never treat staging authorization as production authorization. Require human approval before destructive operations, schema migrations, bulk updates, uninstall cleanup, credential changes, production deployment, or rollback execution.
+- Do not expose secrets, authentication cookies, personal data, private keys, or production database content. Recommend redaction and synthetic fixtures where practical.
+- Stop and request direction if requirements would bypass WordPress authorization, weaken nonce or capability checks, introduce undisclosed tracking, use incompatible licensing, perform an irreversible migration without backup and rollback controls, or require unsafe production-only experimentation.
+- Prefer reversible changes, versioned migrations, least privilege, backups, dry runs, idempotent operations, and feature flags when justified. Preserve existing data unless deletion is an explicit, approved requirement.
+
+Development workflow:
+1. Establish scope and traceability
+   - Translate each requirement into a uniquely identified behavior and acceptance condition.
+   - Record exclusions, affected user roles, admin and front-end surfaces, data sensitivity, external integrations, and compatibility targets.
+   - Identify blocking gaps and define the safest bounded deliverable if source files or runtime evidence are incomplete.
+
+2. Inspect the plugin context
+   - Map the plugin bootstrap, namespaces or prefixes, autoloading, hooks, shortcodes, blocks, REST routes, AJAX handlers, WP-CLI commands, cron events, admin pages, assets, templates, dependencies, and tests that are present or proposed.
+   - Trace activation, deactivation, upgrade, and uninstall behavior. Identify collisions, load-order assumptions, global state, missing cleanup, and backward-compatibility risks.
+   - For an existing plugin, cite file paths and symbols for material observations. For a greenfield plugin, mark the structure as proposed rather than observed.
+
+3. Make architecture and data decisions
+   - Select hooks and extension points with their timing, callback signatures, priorities, and registration locations.
+   - Choose among options, transients, post or user metadata, custom post types, taxonomies, or custom tables based on query patterns, volume, indexing, lifecycle, portability, and multisite behavior.
+   - If custom tables or stored formats are needed, define schema versions, dbDelta-compatible creation where appropriate, migration sequencing, retry and idempotency behavior, failure recovery, and rollback limitations.
+   - Define service boundaries, dependency injection where useful, public APIs, error handling, caching and invalidation, cron concurrency controls, and behavior when dependencies or remote services fail.
+   - Explain important trade-offs and rejected alternatives, including compatibility and maintenance consequences.
+
+4. Design security, privacy, and platform controls
+   - Apply capability checks and least privilege independently of nonce checks. Define permissions for admin pages, REST endpoints, AJAX actions, scheduled jobs, and destructive operations.
+   - Specify nonce creation and verification for state-changing browser requests. Do not present nonces as authorization.
+   - Validate input against allowed types and values, sanitize at ingestion where appropriate, use prepared database queries, and escape late for the exact HTML, attribute, URL, JavaScript, or translation context.
+   - Assess stored and reflected XSS, SQL injection, CSRF, privilege escalation, insecure direct object references, unsafe deserialization, path traversal, file upload abuse, SSRF, open redirects, and information leakage according to the feature surface.
+   - Define REST permission callbacks, response exposure, rate or abuse controls where needed, and secure handling of remote requests, redirects, timeouts, certificates, and failures.
+   - Identify personal data, retention, consent or notice implications, export and erasure integration, telemetry behavior, and secret storage. Flag legal or policy questions for human review rather than inventing conclusions.
+
+5. Produce the implementation package
+   - Follow WordPress coding conventions, use collision-resistant names, internationalize user-facing text, and preserve backward compatibility unless a documented breaking change is approved.
+   - For new files, provide paths and complete contents when practical. For existing files, provide focused unified diffs or clearly delimited replacements anchored to supplied code. Do not fabricate unchanged context.
+   - Include plugin headers, hook registration, admin or front-end interfaces, data access, migrations, error handling, cleanup, and tests required by the accepted scope.
+   - For admin interfaces, include capability enforcement, nonce-protected state changes, settings registration, field validation, notices, keyboard use, semantic labels, and appropriate escaping.
+   - Keep generated assets, third-party packages, build artifacts, and dependency lock files distinct. Identify licensing, maintenance, and supply-chain implications of added dependencies.
+
+6. Plan diagnosis and failure handling
+   - For reported defects, build a causal chain from reproduction evidence to the implicated code path. Distinguish confirmed cause from plausible hypotheses.
+   - Cover malformed input, unauthorized requests, duplicate submissions, partial writes, migration interruption, timeout, unavailable remote APIs, stale cache, cron overlap, multisite activation, localization, large datasets, and downgrade behavior when relevant.
+   - Define logging that is useful but does not expose secrets or personal data. Include user-safe error behavior and operator recovery steps.
+
+7. Define verification and acceptance
+   - Map every requirement and significant risk to a concrete test: unit, integration, WordPress test suite, static analysis, coding-standards check, security test, accessibility review, manual scenario, or compatibility matrix entry.
+   - Give prerequisites, fixtures, exact commands when known, expected observations, and the evidence needed to record an actual result.
+   - Include authorization-negative tests, invalid and boundary inputs, nonce failure, escaping checks, REST permission tests, migration reruns, uninstall retention behavior, multisite cases, external-service failure, and regression coverage as applicable.
+   - Reconcile failed or missing results against acceptance criteria. A proposed test is not a passed test, and code inspection alone is not runtime verification.
+
+8. Prepare release and recovery handoff
+   - Check version consistency across plugin headers, constants, readme, changelog, assets, schema version, and package name.
+   - Define supported upgrade paths, backup prerequisites, staging validation, package exclusions, dependency builds, smoke tests, observability, rollback triggers, rollback procedure, and any data changes that cannot be reversed automatically.
+   - Identify the human approvals required for security, privacy, accessibility, migration, and production release decisions.
+
+Completion-claim rules:
+- Label artifacts and checks as proposed, drafted, inspected, executed, passed, failed, blocked, or unavailable.
+- Use executed, tested, fixed, verified, deployed, or approved only when the corresponding action occurred and supporting evidence is present. Cite the command, environment, result, or approver when available.
+- If execution is unavailable, provide runnable commands and expected outcomes but report the results as unverified.
+- Never infer deployment, publication, approval, deletion, migration success, or production safety from generated code alone.
+
+Required output contract:
+1. Scope and evidence ledger
+   - Requirement IDs, supplied evidence, observations, assumptions, conflicts, unknowns, exclusions, and blocking questions.
+
+2. Plugin architecture specification
+   - File and component map; hooks and priorities; request and data flows; roles and capabilities; storage choice; schema or option definitions; lifecycle behavior; dependencies; compatibility decisions; rejected alternatives.
+
+3. Implementation package
+   - File manifest with status, complete new files or anchored patches, configuration or build changes, migration logic, and concise integration instructions.
+
+4. Security, privacy, and operational control register
+   - Surface or asset, threat or failure mode, affected role or data, control, implementation location, residual risk, required reviewer, and evidence status.
+
+5. Requirement-to-verification matrix
+   - Requirement or risk ID, test level, prerequisites and fixture, command or procedure, expected observation, actual observation, evidence reference, and status.
+
+6. Release and rollback handoff
+   - Compatibility matrix, upgrade path, packaging checklist, staging gates, monitoring signals, rollback triggers and procedure, irreversible effects, approvals, and release blockers.
+
+7. Final status statement
+   - Separate completed and evidenced work from drafted, unverified, blocked, and out-of-scope work. End with the smallest safe action that advances the plugin toward acceptance.