// Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements.
Create, edit, build, and review a custom WordPress Gutenberg block plugin inside a Studio-backed site.
Create or update a custom WordPress plugin for site functionality that should not live in a theme or a block. Use when the user needs reusable behavior, admin/settings UI, hooks, REST endpoints, scheduled tasks, integrations, or server-side logic for a Studio-backed site.
Create a WordPress site from a rough idea using Studio and shared WordPress skills.
Use WordPress Studio for local WordPress development, preferring MCP and falling back to the Studio CLI when needed.
Create a modern WordPress block theme.
Route WordPress build and audit requests to the right implementation path for a Studio-backed site. Use when the user wants WordPress work and it is not yet clear whether the task should be handled as site creation, theme work, a custom block, a plugin, or an audit.
| name | auditing |
| description | Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements. |
Use this skill when the user wants to review, optimize, or verify an existing WordPress site rather than primarily build new functionality.
This skill owns:
Use studio for site resolution, screenshots, and MCP tool usage details.
Start with the smallest audit that answers the user's request.
Do not invent automated checks that the available tools do not provide. When a conclusion comes from visual inspection or code reading rather than a dedicated tool, say so.
Use studio to:
If the user did not specify a page, default to /.
Choose one or more of:
Tell the user which scope you are using when it is not obvious from the request.
Once you begin the actual audit workflow, call record_workflow_event with workflow: "auditing" and stage: "started".
Use audit_performance for the requested path.
Interpret at least:
Use these baseline thresholds:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| TTFB | < 800 ms | 800-1800 ms | > 1800 ms |
| FCP | < 1800 ms | 1800-3000 ms | > 3000 ms |
| LCP | < 2500 ms | 2500-4000 ms | > 4000 ms |
| CLS | < 0.1 | 0.1-0.25 | > 0.25 |
Use these page-composition warning signs:
Translate findings into WordPress-specific actions where possible, such as:
Use screenshots plus theme or plugin code inspection as needed.
Focus on issues this repo can realistically help with:
prefers-reduced-motionWhen the issue is visual, prefer screenshot-backed observations.
When the issue appears structural, inspect the relevant theme or plugin files before recommending a fix.
When the user wants a broader quality pass, use screenshots to check:
Keep this section focused on visible problems that materially affect the site.
Summarize:
Prefer a short prioritized report over a long exhaustive list.
If fixes are made during the same task, re-run the relevant audit steps and compare before versus after.
Call out what improved, what did not, and any remaining tradeoffs.
When the audit workflow is complete, call record_workflow_event with workflow: "auditing" and stage: "completed".
audit_performance results are synthetic measurements from a local Studio environment. Use them primarily for diagnosis and before-versus-after comparison, not as production truth.