القائمة
Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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, management, and audit requests to the right target and implementation path. Use when the user wants WordPress work and it is not yet clear whether the task should use a local WordPress Studio site, a live WordPress.com site, site creation, theme work, a custom block, a plugin, or an audit.
استنادا إلى تصنيف SOC المهني
| 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, MCP setup guidance, and CLI fallback behavior.
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.
Use need_for_speed 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 take_screenshot 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 take_screenshot-backed observations. Use inspect_design when the rendered DOM or computed styles would identify the root cause faster than code inspection.
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 take_screenshot 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.
need_for_speed results are synthetic measurements from a local Studio environment. Use them primarily for diagnosis and before-versus-after comparison, not as production truth.