wpds

wpds skill の概要

wpds の用途

wpds skill は、WordPress Design System を使って WordPress の UI を構築・レビューするための skill です。勘に頼るのではなく、正規の WPDS MCP server を使って確認しながら進められます。WordPress、Gutenberg、WooCommerce、WordPress.com、Jetpack、またはその周辺の管理画面で、正しいコンポーネント名、token 値、あるいは design-system に沿ったパターンが必要なときに特に役立ちます。

どんな人に向いているか

wpds skill は、WPDS の慣例に合わせた UI を作るときや、実装前にコンポーネント、token、パターンが実際にサポートされているか確認したいときに使います。デザインからコードへの作業、レビュー、リファクタリングの過程で、信頼できる wpds ガイドが必要な agent に特に適しています。

何が違うのか

最大の違いは、wpds が install 前提で documentation-driven だという点です。公開ウェブや記憶から推測するのではなく、MCP 経由で WPDS のリソースを直接問い合わせることを前提にしています。そのため、コンポーネント API や token の使い方のズレが起きにくくなります。これは、出力品質が design-system の正確な判断に強く左右される場面ほど重要です。

wpds skill の使い方

まず正しい環境をインストールして接続する

npx skills add WordPress/agent-skills --skill wpds を使って wpds の install 手順を実行し、そのあと実装相談を始める前に WPDS MCP server が設定済みで稼働していることを確認してください。server がなければ、skill は正規ドキュメントを根拠に安定して答えられません。つまり、セットアップは任意の追加作業ではなく、workflow の一部です。

具体的な UI 目標から始める

あいまいな依頼ではなく、具体的な task を与えてください。良い入力の例は、「この settings panel を、承認済みの components と tokens で WPDS 化し、keyboard accessibility を維持し、custom colors は使わない」です。一方で、「もっと modern にして」のような弱い入力だと、agent は component の適合、spacing、hierarchy を推測するしかなくなります。

先に読むべき files を見極める

まず SKILL.md を読み、その後、この skill の価値の中心である documented decision path に沿うために、運用ルールを定義している repo files を確認してください。wpds の使い方では、前提条件、使うべきタイミング、rules を説明している section を優先し、そのうえで wpds://pages、wpds://components、wpds://design-tokens の MCP sources を使って詳細を確認してから、code や提案を書き始めます。

手戻りを減らす workflow で進める

良い wpds workflow は、画面を定義し、component を特定し、token の制約を確認し、そのあとで UI か review note を下書きする流れです。もし対象 package がすでに分かっているなら、@wordpress/components や @wordpress/ui のように最初に明示してください。そうすれば、skill は実際の implementation surface に合わせたまま進められ、一般論に広がりすぎません。

wpds skill の FAQ

wpds は WordPress core 専用ですか？

いいえ。wpds skill は core より広く、WordPress の design language が重要なあらゆる場所で役立ちます。WordPress エコシステムらしさを感じさせたい product surface でも有効です。ただし、一般的な UI style guide ではなく WPDS に基づいた出力が欲しいときに最も価値を発揮します。

wpds を使うには MCP server が必要ですか？

はい、それがこの skill の実質的な境界です。WPDS MCP server がなければ、wpds を信頼できるものにしている component と token の authoritative な参照が失われます。そのため、オフライン前提の prompting にはあまり向いていません。

wpds は通常の prompt より優れていますか？

WPDS の正確な事実が成果物の品質を左右する task では、たいてい yes です。通常の prompt でも大まかな UI アイデアには使えますが、component の有無、命名、design-token 値についての hallucination を減らしたいなら、wpds のほうが適しています。

wpds は初心者向けですか？

はい、作りたい screen を説明できるなら使えます。wpds guide を効果的に使うのに深い WPDS 知識は必須ではありませんが、skill が関連する components を選び、制約を確認できるだけの context は必要です。

wpds skill を改善するには

機能ではなく、設計判断を渡す

wpds で最も良い結果が出るのは、対象ユーザー、画面種別、変えてはいけない点まで含めて入力したときです。たとえば、「この plugin sidebar を初回管理者向けにリファクタリングし、既存の form fields は維持しつつ、spacing と color は WPDS tokens のみに限定する」といった指示です。これは「WPDS を適用して」よりもずっと実行可能です。

component 選択に効く制約を明示する

accessibility 要件、platform 制約、コンテンツ密度の条件は、案を作る前に伝えてください。よくある失敗は、UI が informational なのか、editable なのか、destructive なのかを示さずに wpds の使い方を求めることです。その場合、component family や interaction pattern を誤ることがあります。

component と token の確認で反復する

最初の回答のあとで、component 選定、token 使用、未対応の custom styling がないかを検証する second pass を依頼してください。wpds における最も有効な改善ループは、下書きを wpds://components と wpds://design-tokens と照合し、ずれている部分に合わせて prompt を絞り込むことです。依頼を広げるのではなく、差分を詰めるのがコツです。