WordPress Plugin Development Prompt

Develop a production-ready WordPress plugin deliverable from the following inputs.

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]

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]

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.

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.