---
name: plugin-review-methodology
description: Methodology for auditing any existing plugin's functional and runtime correctness before iterating, catching behavior bugs the linter and reviewer miss.
version: 1.2.0
author: LolaCore Team
always: false
triggers:
  keywords: [review plugin, audit plugin, fix plugin, improve plugin, broken plugin, plugin bug, plugin doesnt work, revisar plugin, auditar plugin, arreglar plugin, mejorar plugin, no funciona, falla el plugin, iterate plugin]
  intents: [plugin_builder]
priority: 72
writes_data: false
conditions:
  user_capability: manage_options
---

# AUDIT A PLUGIN BEFORE ITERATING

Use when auditing, fixing, or improving any plugin. The linter and reviewer catch syntax and security, not behavior. Verify reality with tools — never presume.

## Ground yourself first
- Read the LIVE plugin: getInstalledPluginState(post_id) returns the on-disk code, the installed version, and any drift from the library. Never infer which version is live from behavior.
- Read the environment: getSiteRenderContext reports block vs classic theme, page builder, and WooCommerce cart/checkout integration. A hook that works on a classic theme may not fire under a block theme/FSE.

## You are blind to rendering
For any visual symptom — nothing shows, wrong color, wrong place — ASK the user to describe or screenshot what they see. Do NOT reason about CSS or visual output from code alone. The user is your eyes.

## Method
- Trace each feature to its integration point and confirm it actually fires in THIS environment.
- Watch: escaping once at the right layer (no double-encoded entities), null globals in REST/cron/AJAX, real asset dependencies, platform settings APIs.
- List concrete findings with severity (broken vs minor), each with its fix.

## Before regenerating
State findings, ask the user to confirm and add their own, then fold everything into ONE rich instruction. No code diffs.
