Admin interfaces

When to use it

Build, debug or review WordPress admin settings pages, list tables, custom save handlers and editor-side tools. Use for save-says-success-but-unchanged, role/capability gaps, scoped assets, notices, and accessible loading/error states; not REST route design.

Boundaries and hand-offs

REST route design and auth go to wp-devkit-rest-api-development; plugin bootstrap and storage to wp-devkit-plugin-development; block editor blocks to wp-devkit-block-development; formal WCAG evidence to wp-devkit-wcag-review; code-level accessibility defects to wp-devkit-accessibility-review; visual design direction to wp-devkit-ui-design. This skill owns the admin screen, its save boundary and its interaction states.

Ask Claude

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

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

The short form /wp-devkit:admin 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-admin-ui-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:

• admin-accessibility-and-verification.md : read for labels, status announcements, focus, WCAG 2.2 criteria that apply, and the Playwright/axe/role-matrix verification method.
• admin-ui-development-workbook.md : Administrative screens and save behavior workbook
• screens-assets-and-lists.md : read for menus and access, hook-suffix scoping, enqueue arguments, translations, React/components, WP_List_Table , notices, 7.0 admin changes.
• settings-and-save-flows.md : read for the Settings API lifecycle, sanitize vs validate, options.php capability, admin-post /AJAX handlers, REST-backed settings, secrets.

How a review runs

1. Follow screen registration and each write handler separately. Menu visibility and direct-URL access control are not enforcement at admin-post , AJAX or REST write boundaries.
2. Trace the save path: option group, registered setting, posted field names, sanitizer, validation, nonce mechanism, capability. Confirm previous valid data survives a failed submission.
3. Trace assets to the exact screen (hook suffix) and their dependencies. Prefer installed WordPress components; do not add a parallel UI framework for a small change.
4. Assess labels, errors, pending/success/empty states, focus management and announcements. Gather keyboard evidence; describe duplicate-submit verification without making live writes.
5. Report the screen/save boundary, confirmed behavior and the scoped correction with permission and interaction checks. Leave options, metadata and assets unchanged during review.
6. Classify per the contract; pattern hits remain candidates; use insufficient evidence when the save path, role set or version is unknown. Read references/admin-ui-development-workbook.md for symptom triage, worked decisions, benign look-alikes and verification. Load topic references only when in scope: - references/settings-and-save-flows.md : read for the Settings API lifecycle, sanitize vs validate, options.php capability, admin-post /AJAX handlers, REST-backed settings, secrets. - references/screens-assets-and-lists.md : read for menus and access, hook-suffix scoping, enqueue arguments, translations, React/components, WP_List_Table , notices, 7.0 admin changes. - references/admin-accessibility-and-verification.md : read for labels, status announcements, focus, WCAG 2.2 criteria that apply, and the Playwright/axe/role-matrix verification method.

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. Candidates and missing evidence separate. Implementation: changed boundaries, role/interaction checks with results and exit status, unexecuted checks, residual risk.

Where to go next

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