|
| 1 | +--- |
| 2 | +name: auditing |
| 3 | +description: Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements. |
| 4 | +--- |
| 5 | + |
| 6 | +# Auditing |
| 7 | + |
| 8 | +Use this skill when the user wants to review, optimize, or verify an existing WordPress site rather than primarily build new functionality. |
| 9 | + |
| 10 | +## Ownership |
| 11 | + |
| 12 | +This skill owns: |
| 13 | + |
| 14 | +- performance audits using Studio MCP tools |
| 15 | +- accessibility-focused review of color, contrast, motion, and readability |
| 16 | +- visible frontend quality review when the user asks for QA or polish |
| 17 | +- before-and-after audit comparison after fixes |
| 18 | + |
| 19 | +Use `studio` for site resolution, screenshots, and MCP tool usage details. |
| 20 | + |
| 21 | +## Principle |
| 22 | + |
| 23 | +Start with the smallest audit that answers the user's request. |
| 24 | + |
| 25 | +- If the user asks about speed, Core Web Vitals, or performance, prioritize the performance workflow. |
| 26 | +- If the user asks about accessibility, contrast, readability, or color usage, prioritize the accessibility workflow. |
| 27 | +- If the user asks for a general review, combine the relevant sections and keep the report practical. |
| 28 | + |
| 29 | +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. |
| 30 | + |
| 31 | +## Workflow |
| 32 | + |
| 33 | +### 1. Resolve the target site |
| 34 | + |
| 35 | +Use `studio` to: |
| 36 | + |
| 37 | +- identify the site |
| 38 | +- ensure it is running |
| 39 | +- confirm the page or URL path to review |
| 40 | + |
| 41 | +If the user did not specify a page, default to `/`. |
| 42 | + |
| 43 | +### 2. Pick the audit scope |
| 44 | + |
| 45 | +Choose one or more of: |
| 46 | + |
| 47 | +- Performance Audit |
| 48 | +- Accessibility Review |
| 49 | +- Visual QA |
| 50 | + |
| 51 | +Tell the user which scope you are using when it is not obvious from the request. |
| 52 | + |
| 53 | +Once you begin the actual audit workflow, call `record_workflow_event` with `workflow: "auditing"` and `stage: "started"`. |
| 54 | + |
| 55 | +### 3. Performance Audit |
| 56 | + |
| 57 | +Use `need_for_speed` for the requested path. |
| 58 | + |
| 59 | +Interpret at least: |
| 60 | + |
| 61 | +- TTFB |
| 62 | +- FCP |
| 63 | +- LCP |
| 64 | +- CLS |
| 65 | +- total page weight |
| 66 | +- request count |
| 67 | +- DOM size |
| 68 | +- JS, CSS, image, and font breakdown |
| 69 | + |
| 70 | +Use these baseline thresholds: |
| 71 | + |
| 72 | +| Metric | Good | Needs Improvement | Poor | |
| 73 | +|-------|------|-------------------|------| |
| 74 | +| TTFB | < 800 ms | 800-1800 ms | > 1800 ms | |
| 75 | +| FCP | < 1800 ms | 1800-3000 ms | > 3000 ms | |
| 76 | +| LCP | < 2500 ms | 2500-4000 ms | > 4000 ms | |
| 77 | +| CLS | < 0.1 | 0.1-0.25 | > 0.25 | |
| 78 | + |
| 79 | +Use these page-composition warning signs: |
| 80 | + |
| 81 | +- DOM elements above 1500 |
| 82 | +- total page weight above 3 MB |
| 83 | +- total requests above 80 |
| 84 | +- scripts above 20 files or 500 KB total |
| 85 | +- stylesheets above 10 files or 200 KB total |
| 86 | + |
| 87 | +Translate findings into WordPress-specific actions where possible, such as: |
| 88 | + |
| 89 | +- reducing or replacing heavy plugins |
| 90 | +- deferring or removing non-critical JS |
| 91 | +- reducing oversized images |
| 92 | +- trimming unused theme CSS |
| 93 | +- checking duplicate font loads |
| 94 | +- simplifying wrapper-heavy block layouts |
| 95 | + |
| 96 | +### 4. Accessibility Review |
| 97 | + |
| 98 | +Use `take_screenshot` plus theme or plugin code inspection as needed. |
| 99 | + |
| 100 | +Focus on issues this repo can realistically help with: |
| 101 | + |
| 102 | +- low text/background contrast |
| 103 | +- weak CTA contrast or ambiguous button states |
| 104 | +- missing or unclear hover and focus states |
| 105 | +- motion that should respect `prefers-reduced-motion` |
| 106 | +- readability issues caused by font size, line height, or dense layouts |
| 107 | +- color choices that make important information hard to distinguish |
| 108 | + |
| 109 | +When 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. |
| 110 | + |
| 111 | +When the issue appears structural, inspect the relevant theme or plugin files before recommending a fix. |
| 112 | + |
| 113 | +### 5. Visual QA |
| 114 | + |
| 115 | +When the user wants a broader quality pass, use `take_screenshot` to check: |
| 116 | + |
| 117 | +- spacing and alignment |
| 118 | +- responsive layout issues |
| 119 | +- broken visual hierarchy |
| 120 | +- inconsistent component styling |
| 121 | +- awkward cropping or media balance |
| 122 | + |
| 123 | +Keep this section focused on visible problems that materially affect the site. |
| 124 | + |
| 125 | +### 6. Report clearly |
| 126 | + |
| 127 | +Summarize: |
| 128 | + |
| 129 | +- what you audited |
| 130 | +- the most important findings |
| 131 | +- the likely causes |
| 132 | +- the highest-value next fixes |
| 133 | + |
| 134 | +Prefer a short prioritized report over a long exhaustive list. |
| 135 | + |
| 136 | +### 7. Re-test after changes |
| 137 | + |
| 138 | +If fixes are made during the same task, re-run the relevant audit steps and compare before versus after. |
| 139 | + |
| 140 | +Call out what improved, what did not, and any remaining tradeoffs. |
| 141 | + |
| 142 | +When the audit workflow is complete, call `record_workflow_event` with `workflow: "auditing"` and `stage: "completed"`. |
| 143 | + |
| 144 | +## Important notes |
| 145 | + |
| 146 | +- `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. |
| 147 | +- Accessibility observations in this workflow are often based on visual review and code inspection rather than a dedicated automated accessibility scanner. |
| 148 | +- When performance, accessibility, and design issues conflict, explain the tradeoff instead of over-optimizing one dimension silently. |
0 commit comments