WordPress Plugin Review Skill

Review WordPress plugins for security, coding standards, repository guidelines, unit tests, and accessibility. Produces a comprehensive Markdown report with findings, severity levels, and fix recommendations.

Overview

This skill performs a two-phase review:

1. Automated Analysis — Install and run PHPCS (with WPCS rules), PHPStan, and PHPUnit
2. Manual Code Review — Deep inspection of security patterns, repo compliance, accessibility, and architecture

The final output is a structured Markdown report saved to /mnt/user-data/outputs/.

---

Workflow

Phase 0: Setup Environment

Run the setup script to install required tools:

bash scripts/setup_tools.sh

This installs PHPCS, WordPress Coding Standards, PHPStan, and PHPUnit if not already present.

Phase 1: Locate the Plugin

1. Check /mnt/user-data/uploads/ for uploaded plugin files (zip or folder)
2. If a zip file is found, extract it to /home/claude/plugin-under-review/
3. If a folder is found, copy it to /home/claude/plugin-under-review/
4. Identify the main plugin file (the one with the Plugin Name: header)

Phase 2: Automated Analysis

Run the following tools and capture output:

PHPCS with WordPress Coding Standards

phpcs --standard=WordPress --extensions=php --report=json \
  /home/claude/plugin-under-review/ > /home/claude/phpcs-report.json 2>&1

Also run with security-focused sniffs:

phpcs --standard=WordPress-Extra --extensions=php \
  /home/claude/plugin-under-review/ 2>&1 | head -200

PHPStan (Static Analysis)

phpstan analyse --level=5 --no-progress \
  /home/claude/plugin-under-review/ 2>&1 | head -200

PHPUnit (if tests exist)

Check for tests/ directory or phpunit.xml. If found:

cd /home/claude/plugin-under-review && phpunit 2>&1 | head -100

If no tests exist, note this as a finding in the report.

Phase 3: Manual Code Review

Read references/security-checklist.md and references/repo-guidelines-checklist.md BEFORE starting the manual review.

For each PHP file in the plugin, review against ALL categories:

A. Security Review

Consult references/security-checklist.md for the full checklist. Key areas:

1. Input Sanitization — Every $_GET, $_POST, $_REQUEST, $_SERVER, $_FILES must be sanitized
2. Output Escaping — Every echo/print of dynamic data must use appropriate esc_*() functions
3. SQL Injection — All database queries must use $wpdb->prepare()
4. Nonce Verification — All form submissions and AJAX handlers must verify nonces
5. Capability Checks — All privileged actions must check current_user_can()
6. File Operations — File uploads must validate type/size and use WP filesystem API
7. CSRF Protection — State-changing requests must have nonce + referer checks
8. Data Validation — All data must be validated before processing
9. Direct File Access — All PHP files must prevent direct access (defined('ABSPATH') || exit)
10. Secure API Calls — External HTTP requests must use wp_remote_get/post()

B. WordPress Coding Standards

1. Naming Conventions — Functions, classes, hooks follow WP naming patterns
2. File Organization — Proper directory structure and file naming
3. Hook Usage — Correct use of actions and filters
4. Enqueue Scripts/Styles — Must use wp_enqueue_script/style() with proper deps
5. Internationalization — All user-facing strings must use translation functions
6. PHP Compatibility — Must work with PHP 7.4+
7. WordPress API Usage — Use WP functions instead of raw PHP where available
8. No Bundled Core Libraries — Must not include jQuery, PHPMailer, etc.

C. Repository Guidelines

Consult references/repo-guidelines-checklist.md for full details. Key areas:

1. readme.txt — Proper format, required headers, changelog, FAQ
2. Plugin Headers — All required headers present and accurate
3. License — GPL-2.0-or-later compatible
4. No Tracking/Phoning Home — No unauthorized external calls
5. No Obfuscated Code — All code must be human-readable
6. Stable Tag — Must match the latest tagged version
7. Tested Up To — Must reference a current WordPress version

D. Unit Test Coverage

1. Test Existence — Does a tests/ directory exist?
2. Test Quality — Do tests assert meaningful behavior?
3. Coverage Areas — Are critical functions tested?
4. WP Test Framework — Uses WP_UnitTestCase or equivalent?
5. CI/CD Ready — Is there a phpunit.xml or phpunit.xml.dist?

E. Accessibility

1. ARIA Attributes — Admin UI elements have proper ARIA labels
2. Keyboard Navigation — Interactive elements are keyboard accessible
3. Color Contrast — UI meets WCAG 2.1 AA standards
4. Screen Reader Support — Dynamic content announces changes
5. Form Labels — All inputs have associated labels
6. Focus Management — Focus is managed in modals/dialogs
7. Semantic HTML — Proper use of headings, landmarks, roles

Phase 4: Generate Report

Use severity levels:

Severity	Meaning
🔴 CRITICAL	Security vulnerability or blocking issue — must fix
🟠 HIGH	Significant issue — may cause repository rejection
🟡 MEDIUM	Best practice violation — recommended fix
🟢 LOW	Minor improvement — nice to have
✅ PASS	Area passes review

Use the report template in references/report-template.md for structure.

Save the final report to: /mnt/user-data/outputs/[plugin-name]-review-report.md

---

Important Notes

• Always read BOTH reference checklist files before starting manual review
• Provide actual code fixes with before/after snippets, not just descriptions
• Reference specific file names and line numbers for every finding
• If the plugin has no unit tests, provide a sample test file as a bonus deliverable
• Be thorough but fair — acknowledge good practices alongside issues
• The report should be fully actionable: a developer should fix all issues from reading it
• Score each category and provide an overall score out of 100