Back up WordPress before an update, with an AI agent

By Andrew Ivanov · Last updated

What does this skill do?

The pre-update backup skill is a SKILL.md file that makes an AI agent take a verified database checkpoint before it updates anything, then update one item at a time and confirm the site still works after each. It is the routine to reach for when the risk is a specific update — a major plugin version, a theme, or WordPress core — rather than a general health pass.

The skill exists because "back up before you update" is easy to say and easy to skip. Packaging it as a skill means the agent always checkpoints first, always verifies the checkpoint actually landed before it touches a single plugin, and always re-checks the site afterward. If you have searched for a "wordpress backup before update ai agent" workflow, this is that workflow written down as steps the model follows in order.

It is also deliberately honest about scope. A checkpoint is a snapshot of the database, and the skill tells the owner so up front: it does not back up your uploads, images, or the plugin and theme code files on disk. That matters, because an update that corrupts a file is not something a database restore can fix — so the skill draws the line clearly instead of implying a checkpoint is a full-site backup.

Which Cowboy MCP tools does it use?

The skill uses one write tool to create the safety net, a read-only pair to check the site before and after, and the update tools themselves — plus two rollback tools for when an update goes wrong. Every name below is a real Cowboy MCP tool exposed over MCP.

Tool What it does
wp_site_info Confirms safe mode is on and reads the current versions
wp_create_checkpoint Takes the pre-update database snapshot
wp_list_checkpoints Verifies the checkpoint exists, with a non-zero size, before updating
wp_site_health Baselines the site's health, then re-checks after each update
wp_get_php_error_log Compares the error log before and after the update
wp_update_plugin · wp_update_theme Update a single item; each takes its own file backup and auto-restores if the site breaks
wp_cli Updates WordPress core with core update
wp_undo_change Rolls back a single update from the undo journal
wp_restore_checkpoint Restores the whole database to the checkpoint

Every one of these actions is written to the audit log, so there is a complete record of what was backed up, what was updated, and in what order.

How do I run it?

Ask for a backup in plain language and name what you want updated. The agent takes and verifies the checkpoint first, then works through your list one item at a time — never all at once — checking health between each so a bad update is caught before the next one starts. Three prompts that work:

The third prompt is worth using the first time you run the skill: it makes the agent state the database-only scope out loud, so you know whether you also need a separate file backup from your host. A dry run resolves each update's target version and download source before it is applied, and if an update does break the site, Cowboy MCP's own auto-restore usually catches it — with wp_undo_change and wp_restore_checkpoint as the manual fallbacks.

How do I install the skill?

A skill is a folder containing a single SKILL.md file, so installing one is really just saving that file into your agent's skills directory — there is nothing to build, compile, or configure first. Where you place the folder decides how widely the skill is available, so pick project-level for a single repository or global for every session on your machine:

Keep the folder name (wordpress-pre-update-backup) matching the name field in the file's frontmatter. Start a new session, ask the agent to back up before an update, and it will match the skill by its description. The complete file is below, and the download link above serves this exact text.

---
name: wordpress-pre-update-backup
description: Use when asked to back up a WordPress site connected via Cowboy MCP before updating a plugin, theme, or core — takes a database checkpoint, verifies it exists, updates one item at a time, re-checks health after each, and states honestly what a checkpoint does not cover.
---

# Back up a WordPress site before an update

Take a verified database checkpoint before any update, then update one item at a time and confirm the site still works after each. Be honest about the checkpoint's scope: it captures the database, not files.

## Before you start

1. Confirm safe mode is on: call `wp_site_info`.
2. Tell the owner what a checkpoint does and does not cover: it is a snapshot of the database tables. It does **not** back up uploads, images, or plugin/theme code files. If they need those protected, they must take a separate file backup (host snapshot or a backup plugin) before continuing.

## Steps

1. **Create the checkpoint.** Call `wp_create_checkpoint` with a descriptive label (for example, the plugin and version you are about to update).
2. **Verify it exists.** Call `wp_list_checkpoints` and confirm the new checkpoint's id, label, and non-zero size appear in the list. Do not proceed until you have seen it.
3. **Baseline health.** Call `wp_site_health` and `wp_get_php_error_log` (both read-only) and record the result so you can compare afterward.
4. **Update ONE item.** Call `wp_update_plugin` (or `wp_update_theme`) with `dry_run: true` for a single slug to see the resolved plan, then call it again to apply. Cowboy MCP takes its own file backup and checkpoint before the update, runs a post-update health check, and auto-restores the previous version if the site breaks. For a core update, use `wp_cli` with `core update`.
5. **Re-check after each update.** Call `wp_site_health` and `wp_get_php_error_log` again and compare to the baseline. If something broke and the auto-restore did not catch it, undo the single change with `wp_undo_change`, or restore the whole database with `wp_restore_checkpoint`.
6. **Repeat.** Move to the next item and update it the same way — one at a time, never in bulk.

## Notes

- Cowboy MCP already auto-checkpoints before plugin and theme updates (and before mutating WP-CLI) when that setting is on. Taking your own labelled checkpoint first still helps: it gives a clean, named restore point for the whole session.
- `wp_restore_checkpoint` restores database tables only. It cannot bring back deleted uploads or reverted code files — that is why the file-backup caveat above matters.

## Report format

Summarize back to the site owner:
- The checkpoint id and label, and the reminder that it covers the database only, not files.
- Each item updated, with before and after versions and the health comparison.
- Anything that was auto-restored, and any errors that appeared in the log.
- How to roll back: `wp_undo_change` for a single update, `wp_restore_checkpoint` for everything since the checkpoint (which also discards non-MCP changes made after it, such as new orders or comments).