What it does
Takes a symptom (white screen, broken layout, JS error, checkout failure) and works through a bisection process, deactivating plugins in batches and narrowing to the single plugin or plugin pair responsible, rather than guessing from the plugin list. Also checks whether the active theme is the actual culprit before blaming a plugin.
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/plugin-conflict-triager/ (or ~/.claude/skills/plugin-conflict-triager/ for all projects)
GitHub Copilot (VS Code)
.github/skills/plugin-conflict-triager/
OpenAI Codex
.codex/skills/plugin-conflict-triager/
Cursor
.cursor/skills/plugin-conflict-triager/ (or ~/.cursor/skills/plugin-conflict-triager/ globally)
Compatibility
Any WordPress site with admin access; a staging clone is strongly recommended so plugins can be deactivated without affecting visitors.
The complete SKILL.md for this skill:
---
name: plugin-conflict-triager
description: Use when a user reports something broken after installing or updating a plugin, asks "which plugin is causing this", or wants help finding the source of a conflict without deactivating everything at once.
---
# Plugin Conflict Triager
## When to use
A symptom appeared (white screen, layout break, JS console error, broken checkout) and the user suspects a plugin conflict but doesn't know which plugin, and blind trial-and-error deactivation would be slow or risky on a live site.
## Procedure
1. Record the exact symptom, when it started, and what changed recently (any plugin install, update, or setting change around that time).
2. Confirm the environment: reproduce on a staging clone if one exists, otherwise get explicit approval before deactivating anything on production.
3. Switch to a default theme temporarily to rule out the theme as the cause; if the symptom persists, move to plugin bisection.
4. Deactivate plugins in halves (not one at a time first) to find the affected half quickly, then narrow within that half until a single plugin or plugin pair reproduces the symptom.
5. Reactivate everything else and confirm the symptom returns only when the suspect plugin is active, ruling out a caching artifact.
6. Report the isolated plugin, the suspected mechanism (hook collision, duplicate library, JS error), and safe next steps (update, replace, or contact the plugin author).
## Guardrails
- Never deactivate plugins on a live production site without the user's explicit go-ahead; use staging whenever it's available.
- Do not reactivate plugins automatically once the culprit is found; leave the site in a known, reported state and let the user decide what to do next.