msrbuilds 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:
- Automated Analysis — Install and run PHPCS (with WPCS rules), PHPStan, and PHPUnit
- 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
- Check
/mnt/user-data/uploads/for uploaded plugin files (zip or folder) - If a zip file is found, extract it to
/home/claude/plugin-under-review/ - If a folder is found, copy it to
/home/claude/plugin-under-review/ - 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:
- Input Sanitization — Every
$_GET,$_POST,$_REQUEST,$_SERVER,$_FILESmust be sanitized - Output Escaping — Every
echo/printof dynamic data must use appropriateesc_*()functions - SQL Injection — All database queries must use
$wpdb->prepare() - Nonce Verification — All form submissions and AJAX handlers must verify nonces
- Capability Checks — All privileged actions must check
current_user_can() - File Operations — File uploads must validate type/size and use WP filesystem API
- CSRF Protection — State-changing requests must have nonce + referer checks
- Data Validation — All data must be validated before processing
- Direct File Access — All PHP files must prevent direct access (
defined('ABSPATH') || exit) - Secure API Calls — External HTTP requests must use
wp_remote_get/post()
B. WordPress Coding Standards
- Naming Conventions — Functions, classes, hooks follow WP naming patterns
- File Organization — Proper directory structure and file naming
- Hook Usage — Correct use of actions and filters
- Enqueue Scripts/Styles — Must use
wp_enqueue_script/style()with proper deps - Internationalization — All user-facing strings must use translation functions
- PHP Compatibility — Must work with PHP 7.4+
- WordPress API Usage — Use WP functions instead of raw PHP where available
- No Bundled Core Libraries — Must not include jQuery, PHPMailer, etc.
C. Repository Guidelines
Consult references/repo-guidelines-checklist.md for full details. Key areas:
- readme.txt — Proper format, required headers, changelog, FAQ
- Plugin Headers — All required headers present and accurate
- License — GPL-2.0-or-later compatible
- No Tracking/Phoning Home — No unauthorized external calls
- No Obfuscated Code — All code must be human-readable
- Stable Tag — Must match the latest tagged version
- Tested Up To — Must reference a current WordPress version
D. Unit Test Coverage
- Test Existence — Does a
tests/directory exist? - Test Quality — Do tests assert meaningful behavior?
- Coverage Areas — Are critical functions tested?
- WP Test Framework — Uses WP_UnitTestCase or equivalent?
- CI/CD Ready — Is there a phpunit.xml or phpunit.xml.dist?
E. Accessibility
- ARIA Attributes — Admin UI elements have proper ARIA labels
- Keyboard Navigation — Interactive elements are keyboard accessible
- Color Contrast — UI meets WCAG 2.1 AA standards
- Screen Reader Support — Dynamic content announces changes
- Form Labels — All inputs have associated labels
- Focus Management — Focus is managed in modals/dialogs
- 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