nextora-gutenberg-blocks

Nextoraテーマまたは子テーマでGutenbergブロックを構築・変更する — block.jsonの登録、型付き属性、RichTextやメディアを用いたネイティブなビジュアル編集、InspectorControls設定パネル、モーダル編集付きリピータリストエディター、render.php出力、ビュースクリプト、ブロックスタイルバリエーション、esbuildブロックパイプライン。

nextora-gutenberg-blocks とは？

このスキルは、WordPress GutenbergブロックをNextoraテーマ（親テーマまたは子テーマ）内で構築・変更するための完璧なコード契約を提供します。ブロックのメタデータ（block.json）、登録ロジック、エディターUI（edit.tsx）、動的レンダリング（render.php）、フロントエンド動作（view.ts）、およびビルド出力の消費を一元管理します。外観ルールは`nextora-design-system`が、テンプレートとパターンは`nextora-site-composition`が、子テーマのスキャフォールディングは`nextora-child-themes`が担当するため、ブロックがこれらの領域に触れる場合は関連スキルも併せて読み込む必要があります。このスキルは、ブロック、block.json、edit.tsx、index.tsx、render.php、ServerSideRender、InnerBlocks、リピータエディター、モーダルアイテムフォーム、インスペクターパネル、ブロックカテゴリー、または「セクションブロックの追加/スタイル変更」といったリクエストに応じて使用します。ワークフローは、対象テーマの特定から始まり、既存ブロックの再利用判断、メタデータの先行記述、save戦略の決定、エディターUIの構築、render.phpの作成、ビュースクリプトの追加、ビルドと品質ゲート検証までを順に実行します。ハードリミットとして、Reactランタイムの重複防止、esbuildパイプラインの一貫性維持、14パッケージの依存リスト制限、属性スキーマの不適切な変更禁止、RESTルートの追加禁止などが定められています。

対応~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/miketropi/nextora-skills/tree/main/skills/nextora-gutenberg-blocks

ドキュメント

Nextora ブロック

ブロックのコード契約を所有します：メタデータ、登録、エディターUI、動的レンダリング、ビュースクリプト、ビルド出力の消費。外観ルールは nextora-design-system が、テンプレートとパターンは nextora-site-composition が、子テーマのスキャフォールディングは nextora-child-themes が所有します。ブロックの見た目に関するリクエストがある場合はデザインシステムスキルを読み込み、ブロックがプリセットやビジタースイッチャーに従う必要がある場合は両方を読み込んでください。

最初にこれらの参照を読み込む

タスクに必要なものだけを、このファイルからの相対パスで読み取ってください：

ファイル	読む目的
`references/block-contract.md`	フォルダレイアウト、`block.json` キー、レジストラの動作、カテゴリーの強制、ジェネレーター、esbuild/`window.wp` シャムとその14ハンドル依存関係リスト、`save` セマンティクス、レンダーとビューの契約。
`references/editor-and-repeaters.md`	2つの実際のリストエディター（`team-section` と子の `repeater.tsx`）、その正確な commit/cancel セマンティクス、リッチテキストとメディアヘルパー。
`../nextora-ecosystem/references/source-map.md`	各ルールの出典と再確認方法、ルート解決の語彙。
`../nextora-ecosystem/references/quality-gates.md`	データ、パリティ、アセット、セキュリティ、i18n、アクセシビリティゲート、および共有の下流受け入れレシピ（§8）。

参照に引用されている値を現在のものとして扱わないでください。編集前にターゲットテーマ自身のファイルを再読してください。

順序付きワークフロー

1. ターゲットとブロックのホストテーマを特定する

ライブインストールまたは提供されたリポジトリから、親テーマのルートとアクティブな（子）テーマのルートを特定します — get_template_directory() と get_stylesheet_directory()、または style.css ヘッダー。子ブロックは子テーマが登録した場合にのみ存在します。親レジストラはテンプレートディレクトリのみを読み取ります。実際の Nextora ソースがない状態で Nextora 互換性を主張しないでください。

2. ターゲット自身の証拠を読む

この順序で、ここに書かれているものよりライブ値を優先します：

blocks/blocks.php — レジストラ、そのグロブ、読み取り可能性のチェック、カテゴリーフィルター、および取り込むブロックごとのPHPファイル。
blocks/*/block.json — 既存の名前、カテゴリー、supports、アセットポインター。
最も近い既存ブロックの edit.tsx、render.php、オプションの view.ts、save.tsx、register-styles.php/register-editor.php。
scripts/build-blocks.mjs — 正確なエントリグロブとシャム。
package.json + .nvmrc — 実際に存在するコマンドとNodeバージョン。
theme.json — ブロックが参照すべきパレット、フォント、グラデーション、フォントサイズ、スペーシングのスラッグ。

3. 作成前に再利用を判断する

リクエストされた編集構造がすでに存在する場合（別の見出しフィールド、別のリスト、別のトグル）、既存のブロックを拡張します。リクエストされた動作または編集構造が既存のブロック、コアブロック、パターン、またはブロックスタイルバリエーションで表現できない場合にのみ、ブロックを作成します。再利用した既存ブロック、またはなぜ何も適合しなかったかを成果物に明記してください — 会話だけでなく、ブロックのエディターエントリーの docblock とテーマの README に行（拒否した最も近い候補とそれぞれに欠けているものを記載）を追加します。リポジトリのみを読む記録者がその判断を見つけられるようにしなければなりません。

4. 最初にメタデータを書く

apiVersion: 3、名前空間/テキストドメイン/カテゴリー（親では nextora + nextora、子では <child-slug>）、デフォルト値を持つ型付き属性、ラッパー外観のための supports、およびビルド済みファイルを指すアセットポインターを含む block.json：`editorScript:

nextora-gutenberg-blocks