Wpds
Build or review WordPress-related UIs (Gutenberg, WooCommerce, Jetpack) using canonical WPDS components and design tokens instead of ad-hoc styles.
Overview
wpds is an agent skill for the Build phase that guides WordPress-related UI implementation and review through the WordPress Design System (WPDS) via the WPDS MCP server.
Install
npx skills add https://github.com/wordpress/agent-skills --skill wpdsWhat is this skill?
- Requires the WPDS MCP server for authoritative docs (wpds://pages, wpds://components, wpds://design-tokens)
- Treats WordPress/WP and Design System/DS as synonyms with WPDS as the canonical name
- Targets WordPress 6.9+ (PHP 7.2.24+) across Gutenberg, WooCommerce, WordPress.com, and Jetpack contexts
- Explicit rule: do not web-search for canonical WPDS documentation—use MCP URIs including wpds://components/:name
- Triggers on @wordpress/components, @wordpress/ui, spacing scales, and color primitives
- WPDS MCP resource URIs: wpds://pages, wpds://components, wpds://design-tokens
Adoption & trust: 1.4k installs on skills.sh; 1.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are building WordPress UI but lack authoritative, in-context access to WPDS components and tokens, so the agent might guess styles or pull stale web docs.
Who is it for?
Solo builders on WordPress 6.9+ who already run the WPDS MCP server and want MCP-sourced DS truth while coding or reviewing UI.
Skip if: Non-WordPress stacks, headless frontends with no WPDS requirement, or teams unwilling to configure and maintain the WPDS MCP server.
When should I use this skill?
User mentions building or reviewing UI in a WordPress-related context, WPDS, design tokens, @wordpress/components, or @wordpress/ui.
What do I get? / Deliverables
The agent uses WPDS MCP URIs to apply the correct components and design tokens while building or reviewing Gutenberg, WooCommerce, and related UIs.
- UI implementations aligned to WPDS components and tokens
- UI review feedback grounded in MCP-sourced WPDS documentation
Recommended Skills
Journey fit
WPDS governs how product UI is composed in the Build phase when you are implementing screens, blocks, and admin surfaces. Frontend is the canonical shelf because the skill centers on components, tokens, typography presets, and @wordpress/ui packages—not backend or ops.
How it compares
Use this design-system skill with the WPDS MCP server—not generic web search or unofficial component snippets—for canonical WordPress UI guidance.
Common Questions / FAQ
Who is wpds for?
Solo and indie builders working on WordPress, Gutenberg, WooCommerce, or adjacent products who need WPDS-aligned components and tokens during implementation or review.
When should I use wpds?
Use it in Build (frontend) when mentioning WPDS, design tokens, @wordpress/components, or WordPress UI review; optionally in Ship (review) when auditing UI consistency before release.
Is wpds safe to install?
Review the Security Audits panel on this Prism page for install risk and file-hash signals; the skill expects an MCP server and does not substitute for your own dependency and hosting review.
SKILL.md
READMESKILL.md - Wpds
# WordPress Design System (WPDS) ## Prerequisites This skill works best with the **WPDS MCP server** installed. The MCP provides access to WordPress Design System documentation and resources, such as components and DS token lists. The following terms should be treated as synonyms: - "WordPress" and "WP"; - "Design System" and "DS"; - "WordPress Design System" and "WPDS". ## When to use Use this skill when the user mentions: - building and/or reviewing any UI in a WordPress-related context (for example, Gutenberg, WooCommerce, WordPress.com, Jetpack, etc etc); - WordPress Design System, WPDS, Design System; - UI components, Design tokens, color primitives, spacing scales, typography variables and presets; - Specific component packages such as @wordpress/components or @wordpress/ui; ## Rules ### Use the WPDS MCP server to access WPDS-related documentation - Use the WPDS MCP server to retrieve the canonical, authoritative documentation: - reference site (`wpds://pages`) - list of available components (`wpds://components`) and specific component information (`wpds://components/:name`) - list of available tokens (`wpds://design-tokens`) - DO NOT search the web for canonical documentation about the WordPress Design System. If asked by the user, push back and ask for confirmation, warning them that the MCP server is the best place to provide information ### Required documentation Before working on any WPDS-related tasks, make sure you read relevant documentation on the reference site. This documentation should take the absolute precedence when evaluating the best course of action for any given tasks. ### Boundaries - Skip non-UI related aspects of an answer (for example, fetching data from stores, or localizing strings of text). - Focus on building UI that adheres as much as possible to the WPDS best practices, uses the most fitting WPDS components/tokens/patterns. ### Tech stack - Unless you are told otherwise (or gathered specific information from the local context of the request), assume the following tech stack: TypeScript, React, CSS. ### Validation - If the local context in which a task is running provide lint scripts, use them to validate the proposed code output when possible. ## Output - As a recap at the end of your response, provide a clear and concise explanation of what the solution does, and add context to why each decision was made. - Be explicit about the boundaries, ie. what was explicitly left out of the task because not relevant (eg non-ui related). - Provide working code snippets