Menu
Comprehensive WordPress plugin audit by experienced developer
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Create a new Gutenberg block with scaffolding
Use when working with the WordPress Abilities API (wp_register_ability, wp_register_ability_category, /wp-json/wp-abilities/v1/*, @wordpress/abilities) including defining abilities, categories, meta, REST exposure, and permissions checks for clients.
Prepare plugin for WordPress.org deployment
Use when generating responses containing factual claims, API details, configuration specifics, version compatibility, or recalled knowledge that could be hallucinated - especially when not working directly from source code or command output
Use when executing implementation plans with independent tasks in the current session
Create a block extension to enhance core WordPress blocks
| name | plugin-review |
| description | Comprehensive WordPress plugin audit by experienced developer |
| context | fork |
| agent | Explore |
| allowed-tools | Read, Glob, Grep, Bash(npm run *), Bash(find *), Bash(grep *), Bash(ls *) |
Act as a senior WordPress plugin developer with 10+ years of experience building production-ready plugins. Review the DesignSetGo WordPress plugin comprehensively, evaluating code quality, architecture, WordPress best practices, and production readiness.
This is a COMPREHENSIVE PLUGIN AUDIT covering all aspects of plugin development. Focus on practical, actionable feedback that improves code quality, maintainability, and user experience.
Structure Assessment:
Code Quality:
Check these files:
designsetgo.php - Main plugin fileincludes/class-plugin.php - Core plugin classincludes/blocks/class-loader.php - Block registrationindex.js files for registration patternsBlock Registration:
block.json (no JavaScript-only registration)apiVersion set (should be 3 for modern blocks)supports configuration for FSE compatibilityexample property for pattern previewstextdomain on all blocks__() or _x())Block Implementation:
useBlockProps() in edit functionsuseInnerBlocksProps() instead of plain <InnerBlocks />useBlockProps.save() in save functionsuseEffect for styles)Check these files:
src/blocks/*/block.json filessrc/blocks/*/index.js filessrc/blocks/*/edit.js filessrc/blocks/*/save.js filesReference Documents:
docs/BLOCK-DEVELOPMENT-BEST-PRACTICES-COMPREHENSIVE.mddocs/BEST-PRACTICES-SUMMARY.mddocs/EDITOR-STYLING-GUIDE.mdBlock.json Configuration:
supports (color, spacing, typography, layout)__experimentalBorder support where appropriateinteractivity API support (if using block bindings)providesContext and usesContext for parent-child blocksTheme.json Integration:
Testing:
Reference: docs/FSE-COMPATIBILITY-GUIDE.md
Semantic HTML:
<ul>/<ol> appropriately<button> not <div onclick><a href> with proper URLsKeyboard Navigation:
tabindex > 0)Screen Reader Support:
alt textaria-label or aria-hidden="true"visually-hidden class for screen-reader-only textColor & Contrast:
Check all interactive blocks:
Translation Functions:
__(), _e(), _n(), _x()wp.i18n.__() or @wordpress/i18nImplementation:
load_plugin_textdomain() called correctly.pot file generation workingCheck:
# Search for hardcoded English strings
grep -r "console.log\|alert\|'[A-Z][a-z]" src/ --include="*.js" | grep -v "__("
# Verify text domains
grep -r "__(" includes/ src/ | grep -v "designsetgo"
Asset Loading:
build/ not src/Bundle Sizes:
Frontend Performance:
loading="lazy"React Performance:
useEffect for simple calculationsuseMemo, useCallback)Database:
Check:
# Bundle sizes
ls -lh build/ | grep -E "\.js$|\.css$"
# Frontend JavaScript
grep -r "view\.js\|frontend\.js" src/
Block Inspector (Sidebar) Controls:
Block Toolbar:
Block Variations:
Responsive Design:
Error Handling:
Code Documentation:
User Documentation:
Developer Documentation:
Check:
README.mddocs/ folderincludes/Input Validation:
javascript:, data:)Output Escaping:
esc_html(), esc_attr(), esc_url() used correctlywp_kses() for allowed HTMLinnerHTML with unsanitized datawp_json_encode()WordPress Security:
eval() or create_function()Refer to: /security-audit command for deep security review
Unit Tests:
E2E Tests:
Manual Testing Checklist:
Check:
tests/ folderphpunit.xml configurationpackage.json test scriptsBuild Configuration:
Scripts:
npm run build - Production buildnpm run start - Development watchnpm run lint:js - JavaScript lintingnpm run lint:css - CSS lintingnpm run lint:php - PHP lintingCode Quality Tools:
Check:
webpack.config.js.eslintrc.js.stylelintrc.jsonphpcs.xmlpackage.json scriptsPHP Standards:
if ( 'value' === $var ))array() or [] consistentlyJavaScript Standards:
var (use const/let)CSS/SCSS Standards:
!important (except accessibility overrides)Run checks:
npm run lint:js
npm run lint:css
npm run lint:php
Requirements:
readme.txt:
Assets:
Custom Hooks:
Examples:
// Good extensibility
$output = apply_filters( 'designsetgo_block_output', $output, $attributes, $block );
do_action( 'designsetgo_before_block_render', $block_name, $attributes );
JavaScript Extensibility:
window.DesignSetGoVersion Management:
Deprecation Strategy:
Generate a comprehensive PLUGIN-REVIEW.md file with the following structure:
# DesignSetGo WordPress Plugin - Comprehensive Developer Audit
**Review Date:** YYYY-MM-DD
**Plugin Version:** X.X.X
**WordPress Version Tested:** X.X
**Reviewer Role:** Senior WordPress Plugin Developer
## Executive Summary
### Overall Assessment
[Letter grade: A+, A, B+, B, C+, C, D, F]
### Production Readiness
[Ready for Production | Needs Minor Fixes | Needs Major Fixes | Not Ready]
### Key Strengths (Top 3)
1. [What you're doing exceptionally well]
2. [What you're doing exceptionally well]
3. [What you're doing exceptionally well]
### Critical Issues (Must Fix Before Production)
[Number and brief description]
### Statistics
- Total Files Reviewed: XX
- Critical Issues: XX
- High Priority: XX
- Medium Priority: XX
- Low Priority: XX
- Suggestions: XX
## 🔴 CRITICAL ISSUES (Must Fix Before Production)
### 1. [Issue Title]
**File:** `path/to/file.php:123`
**Issue:**
[Clear description of the problem]
**Why This Matters:**
[Impact on users, security, stability]
**Current Code:**
```php
// Problematic code
Fixed Code:
// Corrected code with explanation
Effort: [15 minutes | 1 hour | 4 hours | 1 day]
[Same format as critical issues]
[Grouped by category: Performance, UX, Documentation, etc.]
[Code quality, refactoring suggestions, future enhancements]
Files over 300 lines (should refactor):
- src/blocks/example/index.js (450 lines)
Block Name | JS Size | CSS Size | Total
--------------------|---------|----------|-------
flex | 8.2 KB | 2.1 KB | 10.3 KB ✅
grid | 12.5 KB | 3.2 KB | 15.7 KB ⚠️
PHP: XX% coverage
JavaScript: XX% coverage
Before deploying to production, ensure:
/security-audit)Immediate Actions:
Schedule Review:
Continuous Improvement:
End of Review
## Execution Strategy
### 1. **Initial Assessment (10 minutes)**
- Read main plugin file
- Review folder structure
- Check build process
- Identify plugin scope
### 2. **Code Review (60-90 minutes)**
- Review all PHP files in `includes/`
- Review all block `index.js`, `edit.js`, `save.js` files
- Review extensions
- Check build configuration
### 3. **Security Review (30-45 minutes)**
- **Run `/security-audit` command** for comprehensive security scan
- Review security audit findings
- Prioritize critical security issues
- Note high-priority vulnerabilities for immediate attention
### 4. **Standards Compliance (30 minutes)**
- Run linting tools
- Check coding standards
- Review accessibility
- Verify i18n
### 5. **Best Practices Check (30 minutes)**
- Compare against internal docs
- Check FSE compatibility
- Review block.json files
- Test responsive design
### 6. **Documentation Review (15 minutes)**
- README quality
- Code comments
- User documentation
- Developer guides
### 7. **Generate Report (30 minutes)**
- Compile findings (including security audit results)
- Prioritize issues (security first, then critical, high, medium, low)
- Write fixes
- Create action plan
## Analysis Commands
```bash
# Find all blocks
find src/blocks -name "block.json"
# Check for hardcoded strings
grep -r "__(" src/ includes/ | grep -v "designsetgo"
# Find large files
find src/ includes/ -name "*.js" -o -name "*.php" | xargs wc -l | sort -rn | head -20
# Bundle sizes
ls -lh build/ | grep -E "\.js$|\.css$"
# Test coverage
npm run test:coverage
# Linting
npm run lint:js
npm run lint:css
npm run lint:php
# Accessibility check
npm run test:a11y
A successful review should:
DELIVER VALUE: The review should make the developer better, not just point out problems.