wp-block-development
作成者 WordPresswp-block-development は、WordPress の Gutenberg ブロックをより少ない試行錯誤で作成・更新・デバッグできるようにするスキルです。`block.json` のメタデータ、`register_block_type(_from_metadata)`、attributes と serialization、supports、dynamic rendering、deprecations、build tooling に使えます。特に、エディターとフロントエンドの一致に影響する Frontend Development タスクで効果を発揮します。
このスキルは 84/100 で、Agent Skills Finder の候補として十分有力です。WordPress のブロック開発ワークフローを明確に呼び出せるうえ、一般的なプロンプトよりも手探りを減らせるだけの実務情報があります。一方で、やや専門特化で、テスト用ラベルの色合いがあり、広く洗練された完成版というよりは実用寄りです。
- 呼び出しやすさが高いです。frontmatter と「使用タイミング」セクションで、`block.json` の編集、dynamic rendering、deprecations、build ワークフローなどのブロック開発タスクが明確に対象化されています。
- 運用面の説明がわかりやすいです。具体的な手順、必要入力、決定的に動くブロックスキャン用スクリプトがあり、エージェントが最初から正しく着手しやすくなっています。
- 参考資料が実用的です。10 個の参照ファイルが、無効なコンテンツ、attributes が保存されない問題、apiVersion 3 への移行、inner blocks など、よくある失敗パターンをカバーしています。
- experimental / test の संकेतがあるため、利用時は実務向けではあるものの、まだ完成度が最高水準ではないと見込むのがよいです。
- `SKILL.md` にはインストールコマンドがないため、導入時はリポジトリ構成からセットアップを推測する必要があるかもしれません。
wp-block-development の概要
wp-block-development でできること
wp-block-development は、WordPress Gutenberg ブロックの作成と修正に役立つ実践的な skill です。特に、問題が block.json、ブロック登録、保存済みマークアップ、またはビルドツールにあるときに力を発揮します。wp-block-development skill は、API の表面を理解するだけでなく、安全にブロックをリリースしたい読者に最適です。
最適なユースケース
新しいブロックを作るとき、既存のブロックを更新するとき、invalid block を調査するとき、あるいはブロックを dynamic rendering に寄せていくときに、この wp-block-development ガイドを使ってください。viewScript、viewScriptModule、supports、wrapper output、フロントエンドとエディターの整合性に関わる Frontend Development にも役立ちます。
何が違うのか
この skill は判断支援に重点があります。適切なブロックパターンを選び、壊れる変更を事前に見つけ、脆い attribute source や deprecation path の不足といった WordPress のありがちな落とし穴を避ける手助けをします。wp-block-development skill の主な価値は、registration、serialization、compatibility 周りの迷いを減らすことにあります。
wp-block-development skill の使い方
正しくインストールして、対象範囲を絞る
npx skills add WordPress/agent-skills --skill wp-block-development で wp-block-development skill をインストールしてください。そのうえで、プロンプトを投げる前に対象を明確にします。repo root、block namespace、分かるなら block path、そして対応すべき WordPress のバージョン範囲を指定してください。apiVersion、modules、server rendering support によって wp-block-development の挙動が変わるため、この前提情報は重要です。
まず見るべきファイルから始める
最初に SKILL.md を読み、そのあとでタスクに関連する参照ファイルを確認してください。references/block-json.md、references/attributes-and-serialization.md、references/creating-new-blocks.md、references/dynamic-rendering.md、references/deprecations.md、references/debugging.md が主な対象です。ブロックを素早く見つけたい場合は、推測で探すのではなく scripts/list_blocks.mjs を使って block.json の root を特定してください。
実行できる形でプロンプトを書く
優れた wp-block-development のプロンプトは、目的、現在の不具合、制約をはっきり書いています。たとえば、「my-plugin/blocks/cta を更新して、保存後もボタンアイコンが保持されるようにし、既存投稿の妥当性を維持しつつ、WordPress 6.9+ に対応する」といった具合です。「ブロックを直して」よりも、こちらのほうが良いのは、markup を変えるべきか、deprecated を追加すべきか、registration を調整すべきかを skill が判断しやすくなるからです。
ブロック種別に合ったワークフローを使う
静的ブロックなら、attribute source、serialized markup、save() を重視してください。dynamic block なら、render.php、render_callback、wrapper attributes を中心に確認します。container block の場合は、テンプレートルールを変える前に InnerBlocks の構造を見直してください。この wp-block-development の導入パターンは、まずブロック root を読み、次に小さな変更経路で試してから大きくリファクタリングする流れで使うと最も効果的です。
wp-block-development skill の FAQ
wp-block-development は Gutenberg ブロック作成専用ですか?
いいえ。wp-block-development skill は、invalid content、editor styles の欠落、registration failure、deprecations、frontend output のずれといったトラブルシューティングや保守にも向いています。block metadata や serialization に触れるなら、この skill は十分に関連があります。
すでに WordPress に詳しくても、この skill は必要ですか?
WordPress に詳しくても、ブロック実装のミスを減らしたいなら、必要です。通常のプロンプトでは、ブロック開発に潜む compatibility の見えにくい作業が抜け落ちがちですが、wp-block-development は保存済みコンテンツやエディターの挙動に影響するファイルと判断ポイントへ導いてくれます。
どんなときに wp-block-development を使わないほうがいいですか?
一般的な PHP plugin architecture、theme styling、関係のない JavaScript アプリ作業には使わないでください。最も向いているのは、ブロック登録、ブロックマークアップ、dynamic rendering、WordPress エディターの挙動が問題の中心にあるケースです。
wp-block-development は初心者向けですか?
タスクの範囲が明確なら、はい。どのファイルが重要かを具体的に示し、static block、dynamic block、nested block の違いを切り分けてくれるので、初心者にも役立ちます。ただし、block root を特定できない場合や、ブロックが markup を保存するのか server-side で描画するのか分からない場合は、効果が下がります。
wp-block-development skill をもっと良く使うには
ブロックの前提情報を最初に渡す
wp-block-development で良い結果を得るには、block 名、フォルダ、static か dynamic か、そして対応必須の WordPress バージョンを最初から含めることが大切です。現在の block.json、edit/save の構造、あるいは失敗している markup を貼れるなら、skill は推測ではなく compatibility を踏まえて判断できます。
機能ではなく、壊れ方を説明する
「更新後に attributes がリセットされる」「editor に invalid block と出る」「frontend の CSS が iframe で効かない」「新しい markup で古い投稿を壊したくない」といったように、何が壊れるのかを伝えてください。そうした情報があれば、wp-block-development は migration、registration fix、wrapper 変更、build 変更のどれを勧めるべきか判断できます。
既存コンテンツを守る
最も重要なのは、古い投稿を壊さないことです。保存済み HTML が変わるなら、deprecated の経路と migration plan を求めてください。attribute source が脆い selector に依存しているなら、現在の HTML と期待する出力を渡すと、wp-block-development ガイドがより安全な source を提案しやすくなります。
狭いテストループで反復する
最初の回答のあと、1 ブロック、1 投稿、1 つの WordPress バージョンずつ試してください。それでも結果が違う場合は、console warning、invalid-content メッセージ、レンダリングされた HTML の diff をそのまま返してください。そうすると次の wp-block-development の反復はより正確になり、不要なリファクタリングも避けやすくなります。
