Developer Tool Workflows

Use when interacting with a WordPress admin panel via Chrome DevTools MCP — logging in, creating users, navigating menus, submitting forms, or performing any data operations (create/update/delete) through the browser. Also use when needing a temporary admin user for testing instead of the main admin account. Not for: headless automated testing without a real browser — use wp-plugin-testing; PHP code changes or plugin logic that don't require browser interaction.

Use when implementing background jobs, queued tasks, or long-running processes in a WordPress plugin — Action Scheduler (WooCommerce queue), WPBackgroundProcess (Delicious Brains pattern), WP Cron, batch processing with progress tracking, or retry/error handling for async jobs.

Use when setting up or debugging the JavaScript/CSS build pipeline for a WordPress plugin — @wordpress/scripts, webpack, Vite, block editor assets, asset enqueuing with .asset.php files, compiling Sass/PostCSS, or reusing a JS/CSS library bundled by a dependency plugin (e.g. EDD/WooCommerce) instead of vendoring your own. Not for block registration logic — use the official wp-block-development skill.

Use when a PR has QA-reported failures, a "Testing Failed" label, or QA comments saying features are broken. Covers reading QA feedback, tracing root causes, applying scoped commits, updating PR labels, and posting a QA re-test comment. Not for: writing new features or routine code review — use wp-github-flow for standard contribution flow.

Use when setting up PHPCS with WordPress Coding Standards (WPCS), configuring phpcs.xml.dist, running or fixing sniff violations, adding PHPCS to CI, or auditing a plugin's code style against WP.org requirements. Not for PHPStan type analysis — use wp-phpstan-stubs for that.

Use when creating custom database tables with dbDelta, writing schema migrations and upgrade routines, querying with $wpdb prepared statements, optimising slow queries, handling custom table data with CRUD patterns, migrating data between plugin versions, or seeding sample/preview data into custom tables for local development.

Use when adding or refactoring transactional emails in a WordPress plugin — extract inline email strings into reusable HTML templates that share one branded base wrapper, sent as HTML via wpmail(). Not for: REST API webhooks, push notifications, or transactional email in themes (not plugins).

Use when integrating the Freemius SDK into a WordPress plugin for monetisation — free/pro feature gating, license management, trials, SaaS pricing plans, SDK bootstrap setup, update mechanism, opt-in analytics, or affiliate program integration.

Use when shipping a contribution through GitHub — either (a) debugging a GitHub issue by URL/number (fetch, root-cause, fix), or (b) shipping uncommitted working-tree changes when the user says "commit my changes", "commit scope by scope", "create a branch and PR", "open a PR for these changes", or similar. Covers grouping changes into scoped conventional commits, creating a branch, pushing, and opening a PR with assignee + labels. Use this whenever the end goal is a commit/branch/PR, even if no issue is mentioned. Not for: plugin version releases or WP.org SVN deploy — use wp-plugin-release and wp-org-submission for those.

Use when implementing a guided tour system in a WordPress admin plugin using Driver.js — setting up the IIFE bundle, defining PHP backend tour configs, writing JS scope detection from URL + hash, tracking completion correctly, testing selectors against live DOM, and regenerating the POT file. Not for: front-end-only SPAs or non-WordPress apps; guided tours in themes.

Use when managing the full translation workflow for a WordPress plugin — generating POT files with wp i18n make-pot, compiling .po to .mo and .json, setting up JavaScript translations with wpsetscripttranslations, submitting to translate.wordpress.org, or debugging missing translations.

Use when building or adapting a WordPress plugin for multisite/network — network activation, network admin pages, per-site vs network options, switchtoblog() patterns, super admin capabilities, table prefix handling, getsites() loops, or site-aware hook registration.

Use when submitting a plugin to the WordPress.org plugin directory for the first time, deploying a new version via SVN, fixing a reviewer rejection, or setting up WP.org assets (banner, icon, screenshots). Covers the pre-submission checklist, 17 recurring rejection patterns with exact reviewer quotes, readme.txt requirements, the git→SVN deploy flow, and how the Stable tag controls what users receive. For pure WP.org guideline compliance review (18 official guidelines, GPL, naming, trialware rules), use the official wp-plugin-directory-guidelines skill instead.

Use when asked to create a new PHPStan stubs package (phrases like "create stubs for X", "new stubs package", "scaffold phpstan stubs", "add stubs for plugin/composer package"). Scaffolds the full standard structure matching the my-org freemius pattern. Not for: configuring phpstan.neon or generating baselines — use the official wp-phpstan skill for that.

Use when asked to audit a WordPress plugin for inconsistencies, run a consistency/quality sweep, or "find inconsistencies" across code and docs. Fans out parallel checks across dimensions and verifies every finding before reporting. Not for: PHPStan type analysis — use wp-phpstan (official); WP.org pre-submission review — use wp-org-submission.

Use when bumping or releasing a WordPress plugin version, syncing version numbers, or updating readme.txt / changelog. Keeps every version source coherent so Stable tag, header, and constant never drift. Not for: WP.org SVN deploy or submitting a new plugin — use wp-org-submission for that.

Use when setting up or writing tests for a WordPress plugin — PHPUnit integration tests with WP test suite, unit tests with WPMock or Brain\Monkey, acceptance tests with wp-browser/Codeception, factory-based fixtures, HTTP request mocking, or multisite test scaffolding.

Use when building, extending, or debugging a WooCommerce plugin — custom product types, payment gateways, shipping methods, REST API extensions, WC hooks, CRUD with WCProduct/WCOrder/WCCustomer, admin columns/tabs, cart/checkout blocks, or WooCommerce subscription logic.