Add an initial set of simple, doc-driven WordPress development scenarios
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Domain
- testing-qa
Research direction
Read the existing scenarios under eval/scenarios/ and wp-interactivity-api-best-practices.md to learn the Skillsmith format and conventions. Research developer.wordpress.org and its sublinks, then add a sensible initial set of simple WordPress development scenarios and only genuinely shared rubrics; done means the scenarios fit the existing format and skills/wordpress-development/ is unchanged.
Written by the indexing model from the issue text.
Description
Goal
The wordpress-development eval suite covers more than the Interactivity API. It includes an initial set of simple scenarios drawn from the official WordPress developer documentation (developer.wordpress.org and its sublinks), so the skill can be evaluated across a broader range of WordPress development tasks. Cross-cutting best practices that are shared across scenarios are captured in simple, general rubrics rather than repeated in each scenario's own success criteria.
Constraints
- Scope this first batch to simple scenarios only; more complex scenarios are deliberately left for later, separate work.
- Scenario prompts must stay simple and read like a real user's request — phrased by outcome/intent, not by implementation. They must not name the specific tool, API, or technology to use (e.g. not "build a block with the Interactivity API"); choosing the right approach is the skill's job. This mirrors how the existing scenario prompts are written.
- Do not change the skill itself (
skills/wordpress-development/) in this work. Only scenarios and rubrics are added/changed here; skill updates happen afterward, once the scenarios exist. - Scenarios must be grounded in the official WordPress developer documentation at developer.wordpress.org and its sublinks.
- Any shared rubrics added must stay simple and contain only general, cross-cutting checks. A scenario's success criteria must not restate anything its rubrics already cover, and rubrics must not absorb scenario-specific criteria.
Context
- Today every scenario under
eval/scenarios/targets the Interactivity API, and the only rubric iswp-interactivity-api-best-practices.md. This work begins broadening the suite to the wider WordPress development domain. - Scenarios are authored for and tested with Skillsmith (https://github.com/Automattic/skillsmith); new scenarios and rubrics must fit its scenario format and conventions.
- This issue intentionally stops at scenarios (and shared rubrics). Expanding the skill to document these new topics is planned as follow-up work once the scenarios exist — the scenarios lead, the skill catches up later.
- Primary source: https://developer.wordpress.org/ and its sublinks (e.g. Block Editor Handbook, Themes Handbook, Plugin Handbook, REST API Handbook, Common APIs, Coding Standards).
Assumptions / directions to explore
(open — later research may confirm or revise these)
- Organizing scenarios into per-topic folders (e.g. grouping by area such as plugins, themes, blocks, REST API) is worth exploring — the exact structure is open.
- The existing Interactivity API scenarios may be reorganized into that topic structure (e.g. under an
interactivity-api/folder) if it aids consistency; whether to actually move them is left to the pipeline to decide. - Topic selection for the first batch is intentionally left open: a sensible spread of simple, documentation-driven scenarios should be chosen during research rather than fixed here.
- Plausible cross-cutting rubric themes, only where genuinely shared across scenarios: WordPress coding standards, security (escaping/sanitization/nonces), and internationalization (i18n). Which rubrics, if any, are warranted is open.
- Dominant language
- JavaScript
- Stars
- 1
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Automattic/wordpress-skill-experiments
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
All issues in Automattic/wordpress-skill-experiments
Similar issues
-
enhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
anoopcodehack/DevBoard#609 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
openai/codex-plugin-cc#813 ·
-
area: ops type: test
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
accensa/x402-facilitator-stellar#559 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bilawalsidhu/gods-eye-view#1060 ·
Maintainers usually reply within 1 day
-
Progress difficulty filter lists Hard before MediumPossibly taken @Pandamachi claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
sysprog21/codetrial#281 · 1 comment ·
Maintainers usually reply within 1 day