Skip to content

Commit 5a2e9b2

Browse files
chubes4chubes4
authored
Add OpenCode WordPress.com output (#11)
* Add OpenCode WordPress.com output * Revert "Update generated skills from shared Studio guidance" This reverts commit d024356, reversing changes made to 209601f. * Repair OpenCode plugin branch after trunk merge
1 parent 0cb547e commit 5a2e9b2

16 files changed

Lines changed: 24498 additions & 1 deletion

File tree

‎plugins/opencode/.opencode/agents/wordpress-com.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
description: Builds, customizes, audits, and troubleshoots WordPress.com sites using Studio MCP and shared WordPress skills.
3+
mode: all
4+
---
5+
6+
You are a WordPress.com specialist for OpenCode.
7+
8+
Use WordPress.com as the product name in user-facing text. For WordPress.com build, theme, block, plugin, site-creation, or audit requests, load the `wordpress-creator` skill first and follow its routing.
9+
10+
Prefer the `wordpress-studio` MCP server for site operations, screenshots, block validation, `wp_cli`, and WordPress.com / Jetpack-connected workflows. Use the `wordpress-telemetry` MCP server for workflow telemetry when available.

‎plugins/opencode/.opencode/commands/wordpress.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
---
2+
description: Route a WordPress.com task through the shared WordPress creator workflow
3+
agent: build
4+
---
5+
6+
Handle this WordPress.com request using the shared WordPress creator workflow:
7+
8+
$ARGUMENTS
9+
10+
Load the `wordpress-creator` skill, choose the smallest suitable implementation path, and use the `wordpress-studio` MCP server for site operations and verification.

‎plugins/opencode/.opencode/plugins/README.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# OpenCode Plugins
2+
3+
OpenCode loads project-local JavaScript or TypeScript plugins from this directory.
4+
5+
This WordPress.com output does not currently ship an OpenCode-only plugin hook. The integration uses OpenCode's native config, rules, agents, commands, skills, and MCP support instead of inventing a plugin marketplace or a new backend service.

‎plugins/opencode/.opencode/skills/auditing/SKILL.md‎

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
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.

‎plugins/opencode/.opencode/skills/block-creator/SKILL.md‎

Lines changed: 195 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,195 @@
1+
---
2+
name: block-creator
3+
description: Create, edit, build, and review a custom WordPress Gutenberg block plugin inside a Studio-backed site.
4+
---
5+
6+
# Block Creator
7+
8+
Use this skill when the user wants to create or modify a custom Gutenberg block inside a local Studio site.
9+
10+
## Ownership
11+
12+
This skill is the single entry point for custom block work. It owns:
13+
14+
- block plugin workflow inside a Studio site
15+
- structural decisions such as static versus dynamic blocks
16+
- implementation rules for block plugin code
17+
18+
Use `studio` for review and iteration after the block is built into a site.
19+
20+
## Workflow
21+
22+
### 1. Verify Studio readiness
23+
24+
Use `studio` so the selected site can be managed and reviewed with Studio tools.
25+
26+
### 2. Resolve the target site
27+
28+
Use Studio tools to:
29+
30+
- list available sites
31+
- select or confirm the working site
32+
- start it if needed
33+
- fetch the site path and URL
34+
35+
Once you begin the actual block implementation workflow, call `record_workflow_event` with `workflow: "block-build"` and `stage: "started"`.
36+
37+
### 3. Understand the request
38+
39+
If the request is vague, clarify:
40+
41+
- what the block should display
42+
- whether it needs live data
43+
- whether it needs frontend interaction
44+
45+
### 4. Decide static or dynamic
46+
47+
Default to a static block unless the user clearly needs server-rendered data.
48+
49+
Use a static block when the content can be serialized at edit time.
50+
Use a dynamic block when the frontend output depends on server-side data or computation.
51+
52+
Keep the implementation consistent with standard Gutenberg block conventions.
53+
54+
### 5. Generate identifiers
55+
56+
Create:
57+
58+
- a human block name in Title Case
59+
- a kebab-case slug
60+
- a registry name like `create-block/{slug}` unless the project already has a namespace
61+
62+
### 6. Scaffold the plugin in the selected Studio site
63+
64+
Create the plugin directory here:
65+
66+
```text
67+
<site-path>/wp-content/plugins/<slug>/
68+
<site-path>/wp-content/plugins/<slug>/src/
69+
```
70+
71+
Then write:
72+
73+
- `<slug>.php`
74+
- `package.json`
75+
- `readme.txt`
76+
- `src/block.json`
77+
- `src/index.js`
78+
- `src/edit.js`
79+
- `src/save.js`
80+
- `src/render.php`
81+
- `src/view.js`
82+
- `src/style.scss`
83+
- `src/editor.scss`
84+
85+
After the build, compiled assets live in `build/`.
86+
87+
Use the selected Studio site as the root for all block-related files.
88+
89+
## Core rules
90+
91+
### 1. Keep `view.js` plain JavaScript
92+
93+
`view.js` runs on the frontend.
94+
95+
- no JSX
96+
- no React
97+
- no imports from `@wordpress/*`
98+
- use DOM APIs directly
99+
100+
### 2. Match editor and frontend output
101+
102+
The editor preview should look and behave as close to the frontend as possible.
103+
104+
- use matching class names
105+
- use real block UI, not placeholder boxes unless absolutely necessary
106+
- keep style rules shared when possible
107+
108+
### 3. Be proactive with controls
109+
110+
Prefer controls the editor already provides when they fit the request.
111+
112+
Prefer components such as:
113+
114+
- `InspectorControls`
115+
- `BlockControls`
116+
- `RichText`
117+
- `MediaUpload`
118+
- `ToggleControl`, `RangeControl`, `SelectControl`, `TextControl`
119+
120+
Prefer `supports` in `block.json` when WordPress can provide built-in UI for color, spacing, or typography.
121+
122+
## Core file guidance
123+
124+
### package.json
125+
126+
Use `@wordpress/scripts` for build tooling. Keep the package minimal and aligned with the block's actual needs.
127+
128+
Include build scripts that support the current task rather than copying a large default scaffold.
129+
130+
### block.json
131+
132+
Keep metadata valid and minimal. Use only the fields the block actually needs.
133+
134+
### PHP plugin bootstrap
135+
136+
The plugin main file should:
137+
138+
- guard direct access with `if ( ! defined( 'ABSPATH' ) ) { exit; }`
139+
- wrap function definitions with `function_exists`
140+
- register the block from `build/`
141+
142+
## HTML rule
143+
144+
Each block should render a single wrapper element. Do not accidentally nest identical wrapper tags.
145+
146+
## Defaults
147+
148+
If unsure:
149+
150+
- make it static
151+
- use `design` or `widgets` category depending on the block
152+
- include editor controls for the attributes the user will obviously want to change
153+
154+
## PHP standards
155+
156+
- no closing `?>` at end of file
157+
- guard functions with `function_exists`
158+
- use escaping like `esc_html()`, `esc_attr()`, or `wp_kses_post()` where appropriate
159+
160+
## Studio workflow
161+
162+
Inside the block plugin directory, prefer:
163+
164+
```bash
165+
pnpm install
166+
pnpm exec wp-scripts build
167+
```
168+
169+
If the generated block package is being used outside this repo and only npm is available, `npm install && npx wp-scripts build` is fine too.
170+
171+
After a successful build:
172+
173+
- activate the plugin with `wp_cli`
174+
- insert the block into a test page or post with `wp_cli`
175+
- follow the review and iteration workflow in `studio`
176+
- call `record_workflow_event` with `workflow: "block-build"` and `stage: "completed"`
177+
178+
When editing an existing block:
179+
180+
1. locate the block project in the selected site's `wp-content/plugins/`
181+
2. identify affected files based on the change request
182+
3. update only the necessary files
183+
4. rebuild
184+
5. re-run activation or page setup steps if needed
185+
6. follow the review and iteration workflow in `studio`
186+
187+
## Error recovery
188+
189+
When a build fails:
190+
191+
1. read the full error output
192+
2. identify the exact file and issue
193+
3. fix only the relevant file
194+
4. rebuild without reinstalling packages
195+
5. retry up to 3 times before escalating to the user

0 commit comments

Comments
 (0)