What this prompt does
This prompt makes the model a WordPress DevOps engineer producing a suite of WP-CLI automation scripts for a [site_type] site. It covers six scripts: deployment, database management, content migration, scheduled maintenance, health monitoring, and a custom WP-CLI command plugin.
The deployment script pulls from [git_branch], runs Composer and core/plugin/theme updates (with [update_strategy] and [excluded_plugins] left to Composer), flushes caches, and backs up the database first. The database toolkit handles timestamped exports to [backup_directory] with [retention_count] retention, URL search-replace between [production_url] and [staging_url], and PII anonymization when copying to [staging_environment]. Maintenance runs [maintenance_frequency], logging to [log_file] and alerting [notification_channel].
What makes the suite trustworthy is that every script is built to run unattended. The health monitor verifies core and plugin checksums, audits administrator accounts, checks scheduled events, and confirms [critical_pages] return HTTP 200, emitting JSON and a non-zero exit code when anything fails. The custom command plugin registers wp [command_namespace] subcommands for setup, sync, seed, cleanup, and reporting, all following WP-CLI conventions like success and error helpers, progress bars, and --dry-run. Treating WordPress operations as versioned code is what makes them repeatable across environments rather than a series of manual clicks.
When to use it
- You manage a WordPress site and want deploys scripted, not clicked through.
- You need safe production-to-staging database sync with PII stripped.
- You migrate
[content_type]content between environments repeatedly. - You want unattended maintenance with logging and
[notification_channel]alerts. - You need health checks that fail loudly when something drifts.
- You want project-specific commands under a
wp [command_namespace]namespace.
Example output
Expect a set of shell and PHP scripts: a deploy.sh with pre-flight checks and a pre-update backup, database export/import scripts writing to [backup_directory] with [retention_count] retention and search-replace from [production_url] to [staging_url], a migration script using WXR export/import, a cron-ready maintenance script logging to [log_file], a health script emitting JSON and a non-zero exit on failure, and a command plugin registering wp [command_namespace] subcommands with --dry-run support.
Pro tips
- Always create the pre-update backup before touching core or plugins; the deploy script should refuse to continue without it.
- Keep
[excluded_plugins]aligned with whatever Composer manages so auto-updates do not fight your dependency lock. - Anonymize PII on every copy to
[staging_environment], not just production-to-prod moves. - Build
--dry-runinto the customwp [command_namespace]commands so destructive ones can be previewed. - Set
[retention_count]against your disk space; timestamped backups in[backup_directory]add up fast. - Route failures to
[notification_channel]and write everything to[log_file]so unattended runs are auditable. - Pin
[git_branch]and[update_strategy]to match your release process, since a deploy script that pulls the wrong branch is worse than no automation. - Run the health-check script in CI as well as cron, so checksum drift on
[critical_pages]is caught before it reaches production.
