Staging Diff Reporter

What it does

Compares plugin and theme versions, active plugin lists, core version, and modified files between the two environments, then separates the diff into intentional changes (what staging was built to test) versus drift, changes that crept into production but were never applied to staging, or vice versa.

Install

This skill isn't packaged in an installable registry. It's a plain SKILL.md file you can copy directly. Copy it from the SKILL.md tab and save it at the path for your assistant:

Use it in your AI assistant

Claude Code

.claude/skills/staging-diff-reporter/ (or ~/.claude/skills/staging-diff-reporter/ for all projects)

GitHub Copilot (VS Code)

.github/skills/staging-diff-reporter/

OpenAI Codex

.codex/skills/staging-diff-reporter/

Cursor

.cursor/skills/staging-diff-reporter/ (or ~/.cursor/skills/staging-diff-reporter/ globally)

Compatibility

Any WordPress site with a staging environment; needs read access (WP-CLI or file/database access) to both environments.

The complete SKILL.md for this skill:

---
name: staging-diff-reporter
description: Use when a user is about to push staging to production and wants to know exactly what will change, or suspects staging and production have drifted apart unintentionally.
---

# Staging Diff Reporter

## When to use
Before a staging-to-production push, or when the user suspects the two environments have drifted, and needs a clear list of what's actually different rather than pushing blind.

## Procedure
1. Compare WordPress core version, active theme version, and the full active plugin list (including versions) between staging and production.
2. Diff any modified theme or plugin files if custom code changes were made directly rather than through updates.
3. Compare key configuration (permalink structure, active menus, site options relevant to the change) if the update touches settings, not just code.
4. Separate results into "intentional" (matches what staging was set up to test) and "drift" (unexpected differences not related to the planned change).
5. Flag anything in the drift category loudly, since it usually means a hotfix was applied to production and never backported to staging, or vice versa.
6. Summarize what the push will actually change on production, in plain terms, before the user proceeds.

## Guardrails
- Never perform the actual staging-to-production push as part of this skill, only report the diff so the user (or their deploy process) makes the final call.
- If drift is found, call it out explicitly rather than folding it silently into the "expected changes" list, since unnoticed drift is what causes production incidents.