playbooks

home / skills / automattic / agent-skills / wpds

wpds skill

/skills/wpds

This skill helps you build WordPress UI components aligned with WPDS tokens and patterns, leveraging the MCP server for authoritative docs.

npx playbooks add skill automattic/agent-skills --skill wpds

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
name: wpds
description: "Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc."
compatibility: "Requires WPDS MCP server configured and running. Targets WordPress 6.9+ (PHP 7.2.24+)."
---

# 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

Overview

This skill helps designers and developers build UIs using the WordPress Design System (WPDS), its components, tokens, and patterns. It guides component selection, token usage, and layout decisions assuming a TypeScript + React + CSS stack. Use it to ensure conformity with WPDS best practices and to produce working component code snippets.

How this skill works

The skill inspects the UI requirements and maps them to WPDS reference documentation available on the WPDS MCP server (components, pages, and design-tokens). It recommends the appropriate @wordpress components, design tokens, and accessibility patterns, then provides example TypeScript/React code that follows WPDS conventions. At the end it summarizes what was implemented and why, and explicitly notes UI-only boundaries and omitted non-UI concerns.

When to use it

  • When building or reviewing WordPress-related UIs (Gutenberg, WooCommerce, Jetpack, WordPress.com).
  • When you need to select WPDS components, tokens, or patterns for a UI element.
  • When converting visual specs to WPDS-compliant React + TypeScript code.
  • When validating spacing, color, and typography against WPDS token sets.
  • When you need accessible component patterns consistent with WPDS.

Best practices

  • Always consult the WPDS MCP reference pages and token lists before proposing components.
  • Prefer official @wordpress/components packages and WPDS tokens over custom styles.
  • Keep UI logic separate from data fetching and localization; focus on presentation.
  • Use TypeScript + React and follow existing lint scripts in the local project.
  • Verify accessibility attributes and keyboard interactions for interactive components.

Example use cases

  • Create a WPDS Button using @wordpress/components with token-based colors: import { Button } from '@wordpress/components'; /* use wpds token variables for color and spacing */
  • Build a form row using WPDS spacing and typography tokens in a TSX component: const FormRow: React.FC = () => (<div style={{ gap: 'var(--wpds-space-3)' }} />);
  • Review a header layout and replace custom primitives with WPDS layout patterns and container tokens for consistent breakpoints.
  • Convert a design token (color/spacing/typography) into CSS custom properties and import them into a component stylesheet.
  • Compose a modal using WPDS modal patterns and ensure focus trap and accessible labels are included.

FAQ

Do you search the web for WPDS docs?

No. I use the WPDS MCP server as the canonical source and will ask you to enable it if needed.

Will you handle data fetching or localization?

No. I focus on UI construction and explicitly skip non-UI concerns like stores, APIs, or i18n unless asked separately.

What stack do you assume?

TypeScript, React, and CSS are assumed unless you give different constraints.