wpds
Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc.
Best use case
wpds is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc.
Teams using wpds should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/wpds/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How wpds Compares
| Feature / Agent | wpds | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when building UIs leveraging the WordPress Design System (WPDS) and its components, tokens, patterns, etc.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 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
Related Skills
wp-wpcli-and-ops
Use when working with WP-CLI (wp) for WordPress operations: safe search-replace, db export/import, plugin/theme/user/content management, cron, cache flushing, multisite, and scripting/automation with wp-cli.yml.
wp-rest-api
Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest.
wp-project-triage
Use when you need a deterministic inspection of a WordPress repository (plugin/theme/block theme/WP core/Gutenberg/full site) including tooling/tests/version hints, and a structured JSON report to guide workflows and guardrails.
wp-plugin-development
Use when developing WordPress plugins: architecture and hooks, activation/deactivation/uninstall, admin UI and Settings API, data storage, cron/tasks, security (nonces/capabilities/sanitization/escaping), and release packaging.
wp-playground
Use for WordPress Playground workflows: fast disposable WP instances in the browser or locally via @wp-playground/cli (server, run-blueprint, build-snapshot), auto-mounting plugins/themes, switching WP/PHP versions, blueprints, and debugging (Xdebug).
wp-phpstan
Use when configuring, running, or fixing PHPStan static analysis in WordPress projects (plugins/themes/sites): phpstan.neon setup, baselines, WordPress-specific typing, and handling third-party plugin classes.
wp-performance
Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing, Query Monitor via REST headers), database/query optimization, autoloaded options, object caching, cron, HTTP API calls, and safe verification.
wp-interactivity-api
Use when building or debugging WordPress Interactivity API features (data-wp-* directives, @wordpress/interactivity store/state/actions, block viewScriptModule integration, wp_interactivity_*()) including performance, hydration, and directive behavior.
wp-block-themes
Use when developing WordPress block themes: theme.json (global settings/styles), templates and template parts, patterns, style variations, and Site Editor troubleshooting (style hierarchy, overrides, caching).
wp-block-development
Use when developing WordPress (Gutenberg) blocks: block.json metadata, register_block_type(_from_metadata), attributes/serialization, supports, dynamic rendering (render.php/render_callback), deprecations/migrations, viewScript vs viewScriptModule, and @wordpress/scripts/@wordpress/create-block build and test workflows.
wp-abilities-api
Use when working with the WordPress Abilities API (wp_register_ability, wp_register_ability_category, /wp-json/wp-abilities/v1/*, @wordpress/abilities) including defining abilities, categories, meta, REST exposure, and permissions checks for clients.
wordpress-woocommerce-dev
資深 WordPress 與 WooCommerce PHP 開發專家（Miyoshi）。精通 WordPress Plugin/Theme 架構、WooCommerce 擴充開發、PHP 8.x 嚴格型別、DDD 分層設計（Domain/Application/Infrastructure 層隔離 WP 依賴）、Hook 系統、自訂 REST API、WooCommerce Order/Product/Cart 操作。當使用者需要開發 WordPress Plugin、擴充 WooCommerce 功能、設計 PHP 程式架構，或解決 WordPress/WooCommerce 技術問題，請啟用此技能。