Wpds
Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc
What Is This?
Overview
The WordPress Design System (WPDS) is a structured collection of UI components, design tokens, and interaction patterns maintained by the WordPress project. It provides a unified visual and functional language for building interfaces that align with the WordPress ecosystem, ensuring consistency across themes, plugins, and block-based editors. WPDS defines everything from color palettes and typography scales to button variants and form controls, all expressed through reusable tokens and documented components.
When working with WPDS in a development environment, the system integrates with the WPDS MCP (Model Context Protocol) server, which exposes design system documentation, token lists, and component references directly to your tooling. This allows developers to query available tokens, look up component usage patterns, and apply design system conventions without switching between documentation tabs and code editors. The skill targets WordPress 6.9 and later, running on PHP 7.2.24 or higher.
WPDS is not simply a component library. It is a living specification that governs how WordPress interfaces should look and behave. Adopting it means your UI work stays aligned with platform updates, accessibility standards, and the broader WordPress contributor community.
Who Should Use This
- Block developers building custom Gutenberg blocks who need consistent spacing, color, and typography tokens
- Plugin authors creating admin interfaces that should match the WordPress dashboard visual language
- Theme developers working within Full Site Editing (FSE) contexts where design token alignment is critical
- Frontend engineers contributing to WordPress core or Gutenberg who must follow established component patterns
Why Use WPDS?
Problems It Solves
- Visual inconsistency across plugins and themes: Without a shared token system, each plugin invents its own spacing and color values, leading to fragmented admin experiences.
- Redundant component work: Developers rebuild buttons, modals, and form inputs repeatedly instead of consuming tested, accessible components from a central source.
- Accessibility gaps: Custom-built components often miss ARIA attributes, focus management, or contrast requirements that WPDS components handle by default.
- Token drift during WordPress updates: Hard-coded color or size values break when WordPress updates its design language, while token-based implementations update automatically.
Core Highlights
- Access to the full WPDS token vocabulary including color, spacing, typography, and elevation
- Pre-built, accessible UI components aligned with WordPress core design standards
- MCP server integration for real-time documentation and token queries inside your editor
- Compatibility with WordPress 6.9 and the block editor architecture
- Consistent naming conventions that map directly to CSS custom properties
- Pattern library covering common UI layouts and interaction flows
- Support for both light and dark mode through semantic token usage
How to Use WPDS?
Basic Usage
After configuring the WPDS MCP server, you can query available tokens and components directly. A typical workflow starts with identifying the correct token for a design property.
/* Using a WPDS spacing token */
.my-block-wrapper {
padding: var(--wp--custom--spacing--medium);
color: var(--wp--preset--color--primary);
}// Using a WPDS Button component in a block
import { Button } from '@wordpress/components';
const MyBlockControls = () => (
<Button variant="primary" onClick={handleSave}>
Save Settings
</Button>
);Specific Scenarios
Scenario 1: Building a custom admin settings page. Use WPDS form components and spacing tokens to match the native WordPress admin UI. Query the MCP server for the current input and card component specifications before writing markup.
Scenario 2: Creating a Gutenberg sidebar panel. Reference WPDS panel and typography tokens to ensure your inspector controls align visually with core block controls.
Real-World Examples
- A plugin settings screen using
PanelBody,TextControl, and WPDS color tokens to match the core editor appearance - A custom block toolbar built with
ToolbarGroupandToolbarButtoncomponents sourced from WPDS specifications
When to Use WPDS?
Use Cases
- Building any UI that will appear inside the WordPress admin or block editor
- Contributing components or patterns back to WordPress core
- Auditing an existing plugin for design system compliance
- Migrating a legacy plugin UI to match modern WordPress visual standards
- Creating documentation or Storybook stories for WordPress-adjacent component libraries
- Prototyping new block editor features that need to match platform conventions
- Enforcing design token usage in a team codebase through linting or code review
Important Notes
Requirements
- WPDS MCP server must be installed and running before using this skill
- WordPress 6.9 or later is required for full token and component compatibility
- PHP 7.2.24 or higher on the server environment
- Node.js environment for consuming
@wordpress/componentsin JavaScript-based UIs
More Skills You Might Like
Explore similar skills to enhance your workflow
Async Python Patterns
- Building async web APIs (FastAPI, aiohttp, Sanic)
Error Handling Patterns
Build resilient applications with robust error handling strategies that gracefully handle failures and provide excellent debugging experiences
Service Mesh Observability
Complete guide to observability patterns for Istio, Linkerd, and service mesh deployments
Python Packaging
Comprehensive guide to creating, structuring, and distributing Python packages using modern packaging tools, pyproject.toml, and publishing to PyPI
Nx Workspace Patterns
| Type | Purpose | Example |
Debian Linux Triage
Comprehensive Debian Linux system triage and stability management for creative and design workflows