You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+48-1Lines changed: 48 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
Shared source for WordPress-focused agent skills and plugin packaging.
4
4
5
-
This repo currently packages shared skills and setup files for Codex, Claude Code, Cursor, Continue, Factory Droid, GitHub Copilot, Gemini, Roo Code, Windsurf/Cascade, Aider, and Zed as separate outputs:
5
+
This repo currently packages shared skills and setup files for Codex, Claude Code, Cursor, Continue, Devin CLI, Factory Droid, GitHub Copilot, Gemini, Roo Code, Windsurf/Cascade, Aider, and Zed as separate outputs:
6
6
7
7
- prefers the WordPress Studio MCP server for site management, screenshots, and block validation
8
8
- falls back to the Studio CLI through a shared Studio skill when MCP is unavailable
@@ -16,6 +16,7 @@ This repo currently packages shared skills and setup files for Codex, Claude Cod
16
16
- includes an Aider config and conventions pack for terminal pair-programming
17
17
- keeps skills shared so other surfaces can reuse them later
18
18
- includes Continue-native setup files for WordPress.com rules, prompts, and MCP configuration
19
+
- includes Devin CLI project config, rules, and skills under Devin's documented `.devin/` surfaces
19
20
- adds Roo Code workspace rules and project MCP config without introducing a Roo-specific backend service
20
21
- adds Zed project instructions, project-local skills, and project settings for MCP without introducing a Zed-specific backend service
21
22
- adds Windsurf/Cascade workspace rules and MCP config without introducing a Windsurf-specific backend service
The generated Devin config launches both `studio mcp` and the bundled `wordpress-telemetry` MCP server through Devin's documented project config surface. Devin's official docs support project rules in `AGENTS.md`, project skills in `.devin/skills/<name>/SKILL.md`, and project MCP servers in `.devin/config.json`.
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