Weekly WordPress maintenance with an AI agent
What does this skill do?
The weekly maintenance skill is a SKILL.md file that teaches an AI agent a fixed, safe routine for keeping a Cowboy MCP–connected WordPress site healthy — check for updates, read the error log, review the audit trail, and apply updates one at a time behind a database checkpoint. You install it once, then ask your agent to run it whenever you want a maintenance pass.
The point of packaging the routine as a skill is repeatability. Instead of remembering the right order of operations every week — checkpoint first, read before you write, update one plugin at a time, re-check health afterward — you hand the agent a written procedure it follows the same way every time. That turns "automate WordPress maintenance with AI" from a vague instruction into a checklist the model cannot skip steps in, because the steps are spelled out in the MCP tool calls themselves.
It also keeps the work honest. Every read step changes nothing, every write step is previewed, and the whole session sits behind a checkpoint you can restore in one call. The agent does the tedious part — comparing versions, scanning the log, applying updates — while the guardrails Cowboy MCP already enforces keep a wrong move from becoming a broken site.
Which Cowboy MCP tools does it use?
The skill leans almost entirely on read-only tools, then reaches for a small set of write tools once it has a checkpoint. Every tool below is a real Cowboy MCP tool the agent sees over MCP; the read-only ones change nothing, so most of a maintenance run is pure inspection before a single update is applied.
| Tool | What it does |
|---|---|
wp_site_info |
Confirms the connection and reads the WordPress, PHP, and plugin versions |
wp_site_health |
Runs WordPress Site Health for a good / recommended / critical summary |
wp_get_php_error_log |
Reads recent PHP error-log entries, with secrets redacted |
wp_db_health_report |
Read-only database checks: revisions, spam, transient count, autoload size |
cowboy_mcp_get_audit_log |
Reviews every tool call, error, and auth event agents made this week |
wp_list_changes |
Queries the undo journal of past mutating changes |
wp_list_plugins · wp_list_themes |
List installed plugins and themes with any pending updates |
wp_create_checkpoint |
Snapshots the database before any change |
wp_list_checkpoints |
Confirms the checkpoint was written before the agent proceeds |
wp_update_plugin · wp_update_theme |
Update one item; each takes a file backup, health-checks after, and auto-restores if the site breaks |
wp_cli |
Runs a core update (core update) when one is pending |
wp_get_transients |
Clears expired transients if the database report flags a backlog |
How do I run it?
Once the skill is installed, you run it in plain English — the agent picks up the SKILL.md and follows its steps. Because the routine names its own tools, you do not have to spell out the procedure yourself; a short request is enough, and you can scope it from a full pass down to a report-only dry run. Three prompts that work:
- "Run the weekly maintenance skill on my site — take a checkpoint first, apply any updates one at a time, and tell me if anything broke."
- "Do the weekly maintenance pass but only report: show me what updates are pending and any new errors in the log. Don't change anything yet."
- "Run weekly maintenance, and when you're done give me the checkpoint id so I can roll everything back if I need to."
The first prompt runs the whole routine. The second stops after the read-only steps, which is a good way to see what a run would do before you let it write. The third is the same full run with an explicit reminder to surface the database checkpoint id in the report. In every case, safe mode still applies underneath, and a dry run resolves each update's real plan before it is applied.
How do I install the skill?
A skill is just a folder with a SKILL.md file inside it. Download this skill's file and drop it into your agent's skills directory — no build step, no dependencies. Where it goes depends on whether you want it available in one project or everywhere:
- Download SKILL.md — the exact file embedded below.
- Project-level: save it as
.claude/skills/wordpress-weekly-maintenance/SKILL.mdinside the project you work in, so the skill travels with that repository. - Global: save it under
~/.claude/skills/wordpress-weekly-maintenance/SKILL.mdto make it available in every session on your machine.
Keep the folder name (wordpress-weekly-maintenance) matching the name field in the file's frontmatter. After the file is in place, start a new session and ask your agent to run weekly maintenance — it will find the skill by its description. The full file is below for reference; the download link above serves this exact text.
---
name: wordpress-weekly-maintenance
description: Use when asked to run weekly maintenance on a WordPress site connected via Cowboy MCP — checks for updates, verifies site health, reviews error logs and the audit trail, and applies updates safely with a database checkpoint first.
---
# WordPress weekly maintenance
Run a safe, repeatable weekly pass over a WordPress site through Cowboy MCP. Read the site's state first, take a checkpoint, apply updates one at a time, then confirm nothing broke. Never skip the checkpoint, and never batch every plugin into one update call.
## Before you start
1. Confirm safe mode is on and the connection is healthy: call `wp_site_info` and, if anything looks off, `wp_connection_doctor`.
2. Create a database checkpoint with `wp_create_checkpoint` (label it "weekly-maintenance").
3. Verify it exists: call `wp_list_checkpoints` and confirm the new checkpoint id and label are listed before making any change.
## Steps
1. **Health baseline.** Call `wp_site_health` (read-only) and record the summary counts (good / recommended / critical).
2. **Error log.** Call `wp_get_php_error_log` (read-only). Note any recurring fatal errors or warnings.
3. **Database health.** Call `wp_db_health_report` (read-only): post revisions, spam/trashed comments, transient count, and autoloaded-options size.
4. **Audit trail.** Call `cowboy_mcp_get_audit_log` to review what agents did since the last run, and `wp_list_changes` to see the undo journal.
5. **Find updates.** Call `wp_list_plugins` and `wp_list_themes` (read-only) and list every item with a pending update.
6. **Apply updates one at a time.** For each plugin, call `wp_update_plugin` with `dry_run: true` first to resolve the real plan (target version and download source), then call it again for that single slug to apply. Do the same with `wp_update_theme`. Each update takes a file backup and checkpoint, runs a post-update health check, and auto-restores the old version if the site breaks. Update core last via `wp_cli` (`core update`) if one is pending.
7. **Optional cleanup.** If `wp_db_health_report` flagged a large transient backlog, clear expired transients with `wp_get_transients` using `dry_run: true` first, then apply.
8. **Re-verify.** Call `wp_site_health` and `wp_get_php_error_log` again and compare against the baseline from steps 1–2.
## Notes
- `dry_run` applies to write tools only. Read-only tools (`wp_site_health`, `wp_list_plugins`, `wp_get_php_error_log`, the audit and journal tools) reject `dry_run` — call them directly.
- On large sites, update a few plugins per call at most to stay within PHP time limits; never fire one update call for everything.
- If an update leaves the site up but misbehaving, roll back that single change with `wp_undo_change` before moving to the next item, so you never stack two unverified updates.
## Report format
Summarize back to the site owner:
- Health before vs. after (the summary counts).
- Each plugin, theme, or core update applied, with target versions — and anything auto-restored.
- Errors found in the log and whether they are new or recurring.
- The checkpoint id, so a full rollback is one `wp_restore_checkpoint` away. Individual updates roll back with `wp_undo_change`.
- Anything you skipped and why, and anything that needs the owner's decision.