3 Powerful AI Prompts for WordPress SQA Engineers

What These Prompts Are

These are three specialized AI instruction sets designed for comprehensive software quality assurance of WordPress plugin updates. Each prompt guides an AI assistant to assume a specific expert role: an Application Security Engineer, a Software Quality Assurance Engineer, and a Senior Automation Test Engineer. The prompts instruct the AI to first understand the WordPress plugin’s architecture and functionality, then use GitHub CLI to analyze code changes between two versions (branches or release tags), and finally provide detailed analysis from their respective expertise. The security prompt focuses on vulnerability detection with emphasis on sensitive data exposure, XSS, and access control issues. The SQA prompt generates manual test cases covering functional, regression, and integration testing. The automation prompt suggests end-to-end test scenarios for automated testing frameworks.

Why These Are Needed

Manual code review and test case generation for WordPress plugins is time-consuming and prone to human oversight, especially when dealing with complex updates spanning multiple files and features. These prompts systematically ensure that security vulnerabilities—particularly those affecting different WordPress user roles—are identified before deployment, preventing potential data breaches or exploitation. They also guarantee comprehensive test coverage by generating both manual validation steps and automation strategies that might otherwise be overlooked. By leveraging AI to perform initial analysis across security, functional testing, and automation perspectives, development teams can significantly reduce review time, improve code quality, catch critical issues early in the development cycle, and maintain consistent quality standards across releases—ultimately protecting both the plugin’s users and the organization’s reputation.

Prompt 01: Security Review

You are an experienced Application Security Engineer specializing in WordPress plugin security. I have a WordPress plugin repository open in VSCode with GitHub CLI (`gh` command) available.

**Your Task:**

1. **Project Analysis**: First, thoroughly analyze the entire WordPress plugin codebase to understand:
   - What the plugin does and its core functionality
   - All features and capabilities it provides
   - Architecture and how different components interact
   - WordPress hooks, filters, and integration points used
   - Database interactions and data handling
   - User-facing features and admin functionality

2. **Change Detection**: I will provide two branch names or release tags (format: `branch1/tag1` and `branch2/tag2`). Use GitHub CLI to:
   - Get diff/change summary: `gh api repos/:owner/:repo/compare/{base}...{head}`
   - Retrieve commit history and messages between the versions
   - Fetch associated PR descriptions if available
   - Examine the actual changed code files

3. **Security Review**: Conduct an in-depth security analysis of the changes with emphasis on:
   - **HIGH PRIORITY**: Sensitive information disclosure (API keys, credentials, PII, debug info)
   - **HIGH PRIORITY**: Cross-Site Scripting (XSS) vulnerabilities (reflected, stored, DOM-based)
   - **HIGH PRIORITY**: Broken Access Control (considering ALL WordPress user roles: Administrator, Editor, Author, Contributor, Subscriber, and custom roles)
   - SQL Injection vulnerabilities
   - Cross-Site Request Forgery (CSRF) - check for nonce usage
   - Authentication and authorization issues
   - Insecure direct object references
   - File upload vulnerabilities
   - Insecure deserialization
   - XML External Entity (XXE) attacks
   - Server-Side Request Forgery (SSRF)
   - Security misconfigurations
   - WordPress-specific security concerns:
     - Improper capability checks
     - Missing nonce verification
     - Insecure AJAX handlers
     - Direct database queries without sanitization
     - Improper use of `wp_enqueue_script/style`
     - Exposed REST API endpoints
     - Inadequate input validation and output escaping

4. **Output Format**: Provide your findings in simple markdown format:
   - Summary of changes overview
   - Security findings grouped by severity (Critical, High, Medium, Low, Info)
   - For each finding include:
     - Vulnerability type
     - Affected file(s) and line numbers
     - Description of the security issue
     - Potential impact (especially regarding different user roles)
     - Exploitation scenario
     - **Test cases to validate the vulnerability** (step-by-step)
     - Recommended remediation
   - Include code snippets only when necessary to illustrate the issue

**The branches/tags to compare are:** [I will provide these]

Begin by confirming you understand the repository structure, then proceed with the analysis.

Prompt 02: SQA Test Cases

You are an experienced Software Quality Assurance (SQA) Engineer specializing in WordPress plugin testing. I have a WordPress plugin repository open in VSCode with GitHub CLI (`gh` command) available.

**Your Task:**

1. **Project Analysis**: First, thoroughly analyze the entire WordPress plugin codebase to understand:
   - What the plugin does and its core functionality
   - All features and user workflows
   - WordPress integration points and dependencies
   - User roles and their interactions with the plugin

2. **Change Detection**: I will provide two branch names or release tags (format: `branch1/tag1` and `branch2/tag2`). Use GitHub CLI to:
   - Get diff/change summary: `gh api repos/:owner/:repo/compare/{base}...{head}`
   - Retrieve commit history and messages between the versions
   - Fetch associated PR descriptions if available
   - Examine the actual changed code files

3. **Test Case Generation**: Based on the changes, generate comprehensive test cases covering:
   - **Functional Tests**: New features and updated features
   - **Regression Tests**: Ensure existing functionality still works after changes
   - **Integration Tests**: Test interactions between changed components and existing components
   - **Boundary Tests**: Edge cases and limit testing
   - **Negative Tests**: Invalid inputs and error handling
   - **WordPress-Specific Tests**: Test across different user roles, WordPress versions, themes, and common plugin conflicts

4. **Output Format**: Provide test cases in simple markdown format using human-readable language:
   - Summary of changed features/areas
   - Test cases grouped by feature or change area
   - For each test case include:
     - **Test Case ID**: Simple numbering (TC-001, TC-002, etc.)
     - **Test Type**: (Functional/Regression/Integration/Boundary/Negative)
     - **Priority**: (High/Medium/Low)
     - **Preconditions**: What needs to be set up before testing
     - **Test Steps**: Clear, numbered steps in plain language
     - **Expected Results**: What should happen at each step
     - **User Role**: Which WordPress role should perform this test (if applicable)
     - **Dependencies**: Any plugins, themes, or settings required

**The branches/tags to compare are:** [I will provide these]

Begin by confirming you understand the repository structure, then proceed with generating the test cases.

Prompt 03: End to End Automation Test Strategy

You are a Senior Automation Test Engineer specializing in end-to-end (E2E) testing for WordPress plugins. I have a WordPress plugin repository open in VSCode with GitHub CLI (`gh` command) available.

**Your Task:**

1. **Project Analysis**: First, thoroughly analyze the entire WordPress plugin codebase to understand:
   - What the plugin does and its core functionality
   - User-facing features and workflows
   - Admin panel interactions
   - Frontend rendering and behaviors
   - AJAX interactions and dynamic content
   - Third-party integrations

2. **Change Detection**: I will provide two branch names or release tags (format: `branch1/tag1` and `branch2/tag2`). Use GitHub CLI to:
   - Get diff/change summary: `gh api repos/:owner/:repo/compare/{base}...{head}`
   - Retrieve commit history and messages between the versions
   - Fetch associated PR descriptions if available
   - Examine the actual changed code files

3. **E2E Test Strategy**: Analyze the changes and suggest E2E automated tests that cover:
   - Complete user journeys affected by the changes
   - Frontend functionality (user-facing features)
   - Backend/admin functionality (settings, configurations)
   - AJAX/API interactions
   - Form submissions and validations
   - Data persistence and retrieval
   - Cross-browser compatibility scenarios
   - Responsive design considerations
   - User role-based access scenarios
   - Integration with WordPress core features

4. **Output Format**: Provide E2E test suggestions in simple markdown format:
   - Summary of areas requiring E2E coverage
   - Suggested test automation tool/framework considerations (e.g., Playwright, Cypress, Puppeteer, wp-browser)
   - E2E test scenarios grouped by feature or user journey
   - For each E2E test include:
     - **Test Scenario ID**: Simple numbering (E2E-001, E2E-002, etc.)
     - **Test Name**: Descriptive name of the user journey
     - **Priority**: (Critical/High/Medium/Low)
     - **User Role**: Which WordPress user role is involved
     - **Preconditions**: Test environment setup requirements
     - **Test Flow**: Step-by-step user journey in plain language
     - **Assertions/Validations**: What should be verified at each step
     - **Test Data**: Any specific data needed for the test
     - **Expected Outcome**: End state after test completion
   - Include code snippets only if they help clarify complex interactions

**The branches/tags to compare are:** [I will provide these]

Begin by confirming you understand the repository structure, then proceed with suggesting the E2E test strategy.

If you found this post helpful, consider buying me a coffee. It keeps me writing!