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
+73-1Lines changed: 73 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 Amp, Codex, Claude Code, Cursor, Continue, Devin CLI, Factory Droid, GitHub Copilot, Gemini, Junie, Qodo, Roo Code, Windsurf/Cascade, Aider, and Zed as separate outputs:
5
+
This repo currently packages shared skills and setup files for Amp, Cline, Codex, Claude Code, Cursor, Continue, Devin CLI, Factory Droid, GitHub Copilot, Gemini, Junie, Pi, Qodo, 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
@@ -17,6 +17,8 @@ This repo currently packages shared skills and setup files for Amp, Codex, Claud
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
19
- includes Devin CLI project config, rules, and skills under Devin's documented `.devin/` surfaces
20
+
- adds Cline workspace rules, skills, MCP settings, and Cline plugin-surface documentation from official Cline docs
21
+
- adds a Pi skills package using Pi's official package manifest and Agent Skills support
20
22
- adds Roo Code workspace rules and project MCP config without introducing a Roo-specific backend service
21
23
- adds a Qodo `AGENTS.md` workspace package and documents Qodo's manual MCP setup path from official Qodo docs
22
24
- adds Zed project instructions, project-local skills, and project settings for MCP without introducing a Zed-specific backend service
@@ -84,6 +86,24 @@ claude --plugin-dir ./plugins/claude-code
84
86
- creating a custom plugin
85
87
- running an audit request
86
88
89
+
### Test in Cline
90
+
91
+
1. Install Cline using the official instructions at https://docs.cline.bot/getting-started/installing-cline.md.
92
+
2. Open `./plugins/cline` as the project root, or copy its generated files into a target workspace root.
93
+
3. Confirm the generated Cline files exist:
94
+
-`plugins/cline/.clinerules/wordpress-com.md`
95
+
-`plugins/cline/.cline/skills/`
96
+
-`plugins/cline/.cline/plugins/README.md`
97
+
-`plugins/cline/mcp.json`
98
+
4. Merge the server entries from `plugins/cline/mcp.json` into Cline's MCP settings.
99
+
5. Confirm the `wordpress-studio` and `wordpress-telemetry` MCP tools are available in Cline.
100
+
6. Try the same representative tasks:
101
+
- creating a new site
102
+
- building or editing a theme
103
+
- creating a custom block
104
+
- creating a custom plugin
105
+
- running an audit request
106
+
87
107
### Test in Amp
88
108
89
109
1. Install Amp using the official instructions at https://ampcode.com/manual.
1. Review the generated Pi output in `./plugins/pi`.
271
+
2. Confirm the generated Pi package manifest exists at `plugins/pi/package.json`.
272
+
3. Confirm the manifest includes the `pi-package` keyword and `pi.skills` path.
273
+
4. Install the local package with Pi:
274
+
275
+
```bash
276
+
pi install ./plugins/pi
277
+
```
278
+
279
+
5. For a project-local install, use `pi install -l ./plugins/pi`.
280
+
6. Use the skills as Pi-readable WordPress workflows. Pi's official docs state that Pi has no built-in MCP support, so direct Studio MCP tool access requires a future Pi TypeScript extension.
@@ -317,6 +356,8 @@ It also generates plugin-specific MCP configs or setup guidance for each surface
317
356
318
357
Aider does not use a normal marketplace plugin or MCP package surface, so the Aider output uses `.aider.conf.yml` to read conventions and shared guidance files.
319
358
359
+
Pi is intentionally not listed here. The official Pi documentation says Pi has no built-in MCP support; the supported compatibility path is a future Pi TypeScript extension that registers equivalent tools or bridges MCP.
360
+
320
361
The telemetry server source lives in `scripts/wordpress-telemetry-mcp.mjs` and is bundled to:
321
362
322
363
-`dist/wordpress-telemetry-mcp.mjs`
@@ -509,6 +550,20 @@ That folder currently contains:
509
550
510
551
The generated Zed MCP config launches both `studio mcp` and the bundled `wordpress-telemetry` MCP server through Zed's `context_servers` settings shape. Zed's official docs support project `AGENTS.md` instructions and project-local `.agents/skills/`, so this output does not generate a Zed extension package.
511
552
553
+
The Pi package is generated to:
554
+
555
+
```text
556
+
plugins/pi/
557
+
```
558
+
559
+
That folder currently contains:
560
+
561
+
-`package.json`
562
+
-`skills/`
563
+
-`README.md`
564
+
565
+
The generated Pi package uses Pi's official package format: `package.json` contains the `pi-package` keyword and a `pi.skills` entry pointing at `./skills`. It does not generate MCP configuration or bundle the telemetry MCP server because Pi's official documentation does not expose built-in MCP configuration.
566
+
512
567
The Roo Code workspace output is generated to:
513
568
514
569
```text
@@ -527,6 +582,23 @@ That folder currently contains:
527
582
528
583
The generated Roo Code project MCP config launches both `studio mcp` and the bundled `wordpress-telemetry` MCP server. The `.roo/rules/` files are Roo-specific; the WordPress.com MCP and skill behavior is shared with the other outputs.
529
584
585
+
The Cline workspace output is generated to:
586
+
587
+
```text
588
+
plugins/cline/
589
+
```
590
+
591
+
That folder currently contains:
592
+
593
+
-`.clinerules/wordpress-com.md`
594
+
-`.cline/skills/`
595
+
-`.cline/plugins/README.md`
596
+
-`mcp.json`
597
+
-`scripts/wordpress-telemetry-mcp.mjs`
598
+
-`README.md`
599
+
600
+
The generated Cline MCP config launches both `studio mcp` and the bundled `wordpress-telemetry` MCP server. The Cline output uses Cline-native workspace rules, skills, and MCP configuration instead of claiming extension marketplace packaging because official Cline plugin docs currently scope plugins to the Cline SDK, CLI, and Kanban.
This Pi package shares the Build with WordPress skills with the official Pi coding-agent surface.
4
+
5
+
## Official Pi surface
6
+
7
+
Pi's official coding-agent package is `@earendil-works/pi-coding-agent`, documented at https://pi.dev/docs/latest and implemented in https://github.com/earendil-works/pi/tree/main/packages/coding-agent.
8
+
9
+
The official Pi documentation describes these compatible extension points:
10
+
11
+
- repo instructions through `AGENTS.md` or `CLAUDE.md`
12
+
- Agent Skills loaded from `skills/` directories or package manifests
13
+
- TypeScript extensions for custom tools, commands, events, providers, and UI
14
+
- prompt templates and themes
15
+
- Pi packages installed from npm, git, or local paths
16
+
17
+
## Install
18
+
19
+
From this repository after `pnpm build`:
20
+
21
+
```bash
22
+
pi install ./plugins/pi
23
+
```
24
+
25
+
For a project-local install, use:
26
+
27
+
```bash
28
+
pi install -l ./plugins/pi
29
+
```
30
+
31
+
## Compatibility path
32
+
33
+
This output is intentionally a skills-only Pi package. Pi's official docs state that Pi has no built-in MCP support; MCP support should be built as a TypeScript extension if we want Pi to call the WordPress Studio MCP server directly.
34
+
35
+
Until that extension exists, use these skills as Pi-readable WordPress workflows and use the Studio CLI fallback paths documented in the shared `studio` skill when MCP tools are unavailable.
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