An AI agent for git-deployed WordPress

Plugin updates, done by an agent. The hard ones, handed to you.

WPWatchtower learns how your site is built, takes the safe plugin updates through develop or staging on its own, and opens a pull request with the evidence in the body. Anything with a breaking change arrives as an issue with the research already done.

For developers who own plugin updates on git-deployed WordPress with a pull-request process.

A clean run is a pull request. Anything else is an issue. Both carry the work already done.

Open

[DEVELOP] Update Example Plugin to 4.2.1

develop from update/example-plugin-4.2.1

Summary

Example Plugin 4.2.0 to 4.2.1. Minor release. The changelog lists two bug fixes; the code diff touches 3 files and no hooks this site uses.

Checks on develop

Fatals: none
Rendered pages: 12 of 12
Plugin screens: settings, logs
Test suite: passed

Issue

[PLUGIN] Example Forms (example-forms) 2.8.3 to 3.0.0: removes the legacy submission hook this site's theme calls

Nothing was merged. The research is below; the call is yours.

Names and versions illustrative. The shape is exact.

On its own, and handed to you

On its own

Scans every vendor plugin for pending versions.
Reads the changelog and the real code diff before touching anything.
Branches, updates, merges to develop or staging, waits for the deploy.
Runs the checks: fatals, rendered pages, the plugin's own screens, your test suite.
Opens the pull request with the evidence in the body.
Updates its blueprint for that plugin after every cycle.

Handed to you

Major versions.
Any release with a breaking change, a removed hook or function, a database migration, or a raised PHP or WordPress floor.
Security fixes, flagged so you move fast.
Plugins you mark as never-auto, such as your forms or payment path.
A plugin someone patched in place.
Any check that failed or could not run.
The merge and the promotion to production.

A cycle, in four steps

scan
1. Scan and classify

Every vendor plugin, every pending version. Each one is sorted by the tier you set for that plugin and by what the release says: the changelog and the real code diff, read before anything moves.
update + test
2. Update and test on develop or staging

One branch per plugin. Merged, deployed, then checked: fatals, rendered pages, the plugin's own screens, your test suite. No test environment? The agent never merges anywhere and opens the pull request labeled untested, with the baseline recorded.
pr | issue
3. Pull request or issue

A clean run becomes a pull request with the evidence in the body. Anything else becomes an issue with the research already done.
learn
4. Learn

The plugin's blueprint is updated with what this cycle found. A lesson about the whole site is proposed as a pull request for you to review, so the agent never rewrites its own rules unsupervised.

Image prompt: Blueprint-style technical diagram of a four-stage pipeline on a near-black background: thin green lines, small square nodes, the third node splitting into two outputs drawn as simple shapes. No text, no people, no logos.

What it never does

never merges to preprod or production. Those are your promotion steps.
never hides one update behind another. One plugin per branch, per pull request.
never reverts on its own. A failed check holds the state and alerts a person.
never edits vendor plugin code. A compatibility problem is an issue with a proposed fix.
never counts a check that could not run as passed. BLOCKED is not evidence.

What it needs from your site

A git repository that deploys WordPress, with a pull-request process.
A develop or staging environment, if you have one. Without it, the agent never merges and labels the pull request untested.
A way for the agent to read your plugins and the deploy state. Setup is covered during onboarding.

Early access

We are onboarding a small number of design-partner sites. Leave your email and, if you like, a line about your site or hosting setup. Someone on the team replies.