Plugin development

When to use it

Build, debug or review WordPress plugin lifecycle, hooks, upgrade routines, storage, scheduled jobs and packaging. Use for activation/upgrade/uninstall failures, hook order or removal bugs, multisite setup and directory readiness; not REST routes, admin screens or WP-CLI.

Boundaries and hand-offs

Hand off instead of absorbing: REST routes, schemas and permissions go to wp-devkit-rest-api-development; settings pages, list tables and admin assets go to wp-devkit-admin-ui-development; WP-CLI commands, search-replace and runbooks go to wp-devkit-wpcli-and-ops. Exploitable-input analysis beyond the lifecycle questions here belongs to wp-devkit-security-review. This skill owns the plugin skeleton those features hang on.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:plugin-review <target-path>

The short form /wp-devkit:plugin requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-plugin-development
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• hooks-and-callbacks.md : read for hook order, priorities, removal, recursion, custom hooks, request-context detection, early-translation notices.
• lifecycle-and-upgrades.md : read for headers, activation/deactivation/uninstall, versioned upgrades, dbDelta, dependencies, multisite provisioning.
• packaging-and-compatibility.md : read for directory rules, Plugin Check, readme, Composer and prefixing, PHP-version gates, release ZIP checks.
• plugin-development-workbook.md : Plugin lifecycle and integration workbook
• storage-jobs-and-multisite.md : read for options and autoload, transients and object cache, custom tables, $wpdb->prepare , WP-Cron, Action Scheduler, privacy hooks, switch_to_blog cost.

How a review runs

1. Identify the real entry file and loading mode. Trace bootstrap, dependency loading and hook registration to the first point where observed behavior departs from the expected lifecycle.
2. Classify each concern into one lifecycle stage: install/activation, versioned upgrade, runtime, deactivation, uninstall. Updates never rerun activation; must-use plugins and drop-ins have no activation hooks.
3. For each hook, confirm timing, priority, accepted-args count and (for filters) the return value on every branch. Confirm removal uses the registered callback identity.
4. For storage and jobs, check ownership of the schema or option, autoload and size, idempotence of repeat runs, multisite scope and uninstall policy.
5. For packaging, compare the declared headers, text domain, shipped files and dependencies against the real runtime. Do not build, install or activate during review.
6. Classify per the contract. Pattern hits stay candidates until the reachable path is traced; use insufficient evidence when the target version, loading mode or runtime cannot be established. Read references/plugin-development-workbook.md for symptom triage, worked decisions, benign look-alikes and acceptance checks. Load topic references only when in scope: - references/lifecycle-and-upgrades.md : read for headers, activation/deactivation/uninstall, versioned upgrades, dbDelta, dependencies, multisite provisioning. - references/hooks-and-callbacks.md : read for hook order, priorities, removal, recursion, custom hooks, request-context detection, early-translation notices. - references/storage-jobs-and-multisite.md : read for options and autoload, transients and object cache, custom tables, $wpdb->prepare , WP-Cron, Action Scheduler, privacy hooks, switch_to_blog cost. - references/packaging-and-compatibility.md : read for directory rules, Plugin Check, readme, Composer and prefixing, PHP-version gates, release ZIP checks.

What you get back

Review: result and reviewed scope first. Each confirmed finding: file:line, actor, trigger, reachable path, impact, confidence, severity (per contract), minimal fix, regression check. List candidates and missing evidence separately. Implementation: changed boundaries, design decision, commands run with exit status, unexecuted checks, rollback note and residual risk.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.