vicunav/vicunav-transform-claude-to-gutenberg

Claude Code プロトタイプを Gutenberg FSE テーマに変換する

目的

承認された Claude Code プロジェクトを、ネイティブかつメンテナブルな WordPress サイトに変換します。合意されたデザイン、コンテンツ、動作は維持しつつ、WordPress がブロックで編集可能なソリューションを既に提供している場合に、フロントエンドプロトタイプのアーキテクチャを持ち越さないようにします。

ソースプロジェクトは、ビジュアルおよび機能の仕様として扱います。承認された LocalWP 環境でのみ作業します。明示的な承認なしに、本番環境の変更、コンテンツの削除、Site Editor のカスタマイズ、またはローカルデータの削除は行いません。

最小限のコンテキストを収集する

編集を開始する前に、以下の情報を確認または取得します。

• Claude Code でエクスポートまたはリファインされたプロジェクトのパス
• LocalWP サイトと対象テーマのパス
• 承認されたデザインを構成する正確なコミット、ビルド、または状態
• 含まれるページ、ブレークポイント、状態、インタラクション
• ローカルサイトの実際の WordPress と PHP のバージョン
• 目標が 1:1 パリティ、承認済みの最適化、またはリデザインのいずれか
• WordPress から編集可能にする必要があるコンテンツと統合
• プラグイン、カスタムブロック、フォント、アセットライセンスの制約

コンテンツ、アーキテクチャ、機能、デザインを変更するような決定事項が不足している場合は、一旦停止してその決定を求めます。ファイルシステム、フロントエンド、またはローカルサイトから復元可能なデータが不足している場合は、それを検査し、その前提を記録します。

再利用可能なベースをロードする

フェーズに応じて、インストールされている公式スキルを適用します。

• wp-project-triage: WordPress プロジェクトとそのツールチェーンを分類します。
• wp-block-themes: theme.json、テンプレート、パーツ、パターン、FSE スタイルを実装します。
• wp-block-development: インタラクションがカスタムブロックを必要とする場合のみ使用します。
• wp-wpcli-and-ops: WP-CLI を使用してコンテンツやオプションを検査または変更します。
• unlazy（インストールされている場合）: 大規模な移行（複数ページ、または常時監視なしで完了報告される作業）に対するクロージャの規律を提供します。詳細は後述の「各ユニットをゲートの規律で終了する」を参照してください。

最初にターゲットバージョンを確認します。公式スキルが LocalWP のバージョンよりも新しい WordPress バージョンを対象としている場合は、互換性のある API のみを使用し、公式ドキュメントを参照して差異を解決します。

必要に応じて、自身のリソースを読み込みます。

• source-contract.md: ベースラインを凍結し、移行契約を定義する前に。
• migration-manifest.md: ベースラインをキャプチャする前、または視覚的影響を与える変更を実装する前に。
• translation-map.md: Gutenberg アーキテクチャを決定する前、および各コンポーネントの変換中に。
• localwp.md: サイトやデータベースに触れる前に。
• qa-checklist.md: 最初の可視セクションの前、および作業完了を宣言する前に再度。
• upstream.md: 再利用されたベースを更新、監査、または再配布する際に。
• templates/gates-fse-migration.md: $unlazy をページまたはセクションに対してオープンする際に、初期台帳としてコピーして記入し、ゲートをゼロから記述しないようにします。

フローを実行する

1. 両方のプロジェクトに直接関連するローカルの手順、Git の状態、ドキュメントを読みます。
2. scripts/audit_source.mjs <ソースパス> を実行し、その結果を手動でレビューします。ヒューリスティックなレポートをアーキテクチャ上の決定として扱わないでください。
3. 移行マニフェストを作成し、期待されるすべての組み合わせをインデックスし、scripts/validate_migration_manifest.mjs <マニフェストパス> を実行します。
4. クリーンな環境でソースフロントエンドを起動し、デスクトップ、タブレット、モバイルのベースラインをキャプチャします。関連するインタラクティブな状態も含めます。
5. 移行契約を作成します: ページ、セクション、コピー、アセット、トークン、インタラクション、データソース、統合、受け入れ基準。
6. 再利用可能なトークンをローカルジオメトリから分離します。前者を theme.json にマッピングし、後者をブロック、レイアウト、および最小限のセマンティッククラスで保持します。
7. FSE アーキテクチャを設計します: テンプレート、テンプレートパーツ、パターン、ページコンテンツ。必要な場合のみカスタムブロックやプラグインを使用します。
8. まず代表的なセクションを実装します。パターンをサイトの残りの部分にスケーリングする前に、フロントエンドと Site Editor を比較します。
9. ページごと、セクションごとに移行します。実装中は常にソースプロジェクトを可視リファレンスとして維持します。$unlazy が利用可能な場合、templates/gates-fse-migration.md をそのページまたはセクション独自の GATES.md にコピーしてからユニットをオープンします（実装後ではありません）。
10. プロジェクトのドキュメント化されたフローに従って、LocalWP にテーマをインストールまたはアクティブ化します。コンテンツは冪等的に作成または更新し、既存のものを保持します。
11. scripts/validate_fse_theme.mjs <テーマパス> を実行し、すべてのエラーを修正します。該当する警告をレビューします。
12. フロントエンドと Site Editor で、ビジュアル、構造、編集、レスポンシブ、アクセシビリティ、パフォーマンスの QA を完了します。
13. capture_visual_evidence.mjs、compare_visual_evidence.mjs、verify_visual_evidence.mjs を使用してキャプチャ、比較、ゲートチェックを実行します。サイドバイサイドとオーバーレイを手動でレビューします。ページにフルブリードセクションが少なくとも 1 つある場合は、scripts/verify_editor_frontend_parity.mjs も実行します（scripts/wp_auth_cookies.php で生成された実際のセッション Cookie が必要です。translation-map.md を参照）。PARIDAD_EDITOR_FRONTEND_OK を要求します。人間による視覚比較だけでは、このプロジェクトですでに 2 回文書化されたこの種のバグには十分ではありません。ユニットに GATES.md がある場合は、node <unlazyスキルディレクトリ>/scripts/gate-check.mjs --reverify GATES.md を実行し、続行する前に ALL MET を要求します。
14. 証拠、制限事項、ロールバック、および次の作業ユニットを提供します。$unlazy を使用した場合は、達成されたゲート、未達成のゲート、放棄されたゲートの修飾 ID を含めます。保留中または放棄されたゲートがあるユニットを完了として記述しないでください。

各ユニットをゲートの規律で終了する（$unlazy）

unlazy がインストールされている場合、このスキルのクロージャの規律レイヤーとして扱います。このスキルの代替ではありません。このスキルは FSE 移行で何を検証するかを決定し、unlazy はそれらの基準を作業前に実行可能なコマンドとして宣言し、実際の証拠で再検証してから完了を報告することを強制します。「見た目が良い」という視覚的な読み取りに頼るのではありません。

• ページまたはセクションには unlazy の単独モードを使用します（ユニットごとに 1 つの GATES.md、templates/gates-fse-migration.md からコピー）。オーケストレーションモードは、多くの独立したページを持つサイト全体に対してのみ使用します。各ページは Depth Tree のリーフであり、独自の OWNS:（独自のテンプレート/パターンファイル）と、ページ間のクロスナビゲーション、共有ヘッダー/フッター、リグレッションの欠如を検証する統合ブランチを持ちます。
• 些細な修正をすべてゲートの台帳に変換しないでください。規律は、ページ、サイト全体の移行、または黙って不完全なまま放置された場合のコストがそれを正当化するユニット（実際の例: テンプレートにハードコードされたコンテンツにより、サイト所有者が手動で検出するまで、いくつかの作業ユニットにわたってページが空で編集不能のままになっていた）に予約します。
• 実際のコンテンツゲート（空でない post_content）をプロジェクトの実際の WP-CLI 呼び出しに適合させます。LocalWP では、ほとんどの場合、グローバルな wp バイナリではありません（localwp.md を参照）。
• 手動ゲートは、どのコマンドもうまく測定できないもの（知覚的な視覚的忠実度、コピーの編集レビュー）に対して引き続き有効です。手動ゲートを避けるためだけに自動メトリクスを強制しないでください。このスキルの契約は、知覚的メトリクスをパリティの自動承認に変換することをすでに禁止しています。
• unlazy のオプションの Stop フックは、ユーザーに明示的に要求せずにインストールしないでください。スキル自体がそれを要求しています。
• 作業は、unlazy のオーケストレーションモードとこのスキルのページごとの移行の両方で、適切なモデルレベルにルーティングします。機械的で適切に範囲が限定されたリーフ（別のページですでに解決されたコンポーネントの直接変換、クラス調整、診断済みの特定の修正）は軽量モデルに送ります。アーキテクチャの判断（ブロック vs パターン vs CPT の決定）や視覚的検証を必要とするリーフは、セッションのモデルが保持します。小さな編集ごとに完全なエージェントを分散させるのではなく、それらを 1 回のパスにグループ化することで、より少ない調整で同じ結果が得られます。

交渉不可の契約を維持する

• コアブロック、テーマのパターン、WordPress の公開 API を優先します。
• core/html をプロトタイプの HTML を保持するためのショートカットとして使用しないでください。
• theme.json を共有トークンの真実のソースとして使用します。
• テンプレートとパーツをグローバル構造に使用し、ページコンテンツまたはパターンを編集上の構成に使用します。
• 実証され承認された要件がない限り、WordPress フロントエンドに React、Tailwind、またはプロトタイプのランタイムを導入しないでください。
• コアブロックが保守可能な方法で表現できない動作や編集のためにのみカスタムブロックを作成します。
• ビジネスロジック、予約、注文、データモデルは、テーマではなくプラグインに配置します。
• フォントと画像はローカルで提供し、ライセンス、出所、代替テキストを保持します。
• フロントエンドと Site Editor を必須のサーフェスとして維持します。
• 有効なマニフェストと完全なマトリックスなしに視覚的な移行を実装しないでください。
• 知覚的メトリクスをパリティの自動承認に変換しないでください。
• データベースに保存された偶発的なグローバルスタイルに依存しないでください。
• prefers-reduced-motion、キーボード、フォーカスの可視性、WCAG 2.1 AA を尊重します。
• デザインのギャップを埋めるためにコンテンツ、パス、機能を発明しないでください。

レストランデモの基準を適用する

• 小さく純粋に編集可能なメニューをブロックとパターンでモデル化します。
• メニューに構造化編集、フィルター、再利用、または実際の成長が必要な場合にのみ、vicu_menu_item などの CPT を提案します。プラグインに登録し、その動作をテストします。
• 予約、注文、支払い、動的な時間、可用性は、個別の機能統合として扱います。静的なフォームで黙ってシミュレートしないでください。
• ヘッダー、フッター、予約の呼び出し、連絡先モジュールは、承認されたアーキテクチャと同期したパーツまたはパターンを使用して再利用します。

検証可能なユニットで作業する

以下の条件が満たされた場合にのみ、ページまたはセクションを閉じます。

• コンテンツ、リンク、アセットが契約と一致している。
• マークアップが有効で、ブロックが編集可能なままである。
• フロントエンドとエディタがスタイルを正しくレンダリングしている。
• デスクトップ、タブレット、モバイルがベースラインと比較されている。
• 該当するホバー、フォーカス、アクティブ、ローディング、エラー状態がテストされている。
• コンソールエラー、予期しないリモートリソース、または Claude Code 開発サーバーへの依存関係がない。
• 証拠がテストされた正確な状態に対応している。
• その組み合わせがマニフェストに一意の行を持ち、pending の状態ではない。

検証可能な状態を提供する

以下の情報を報告します。

• 完了したページとセクション
• 影響を受けたアーキテクチャとファイル
• コアブロック、パターン、カスタムブロック、プラグインに関する決定
• 実行されたコマンドとチェック、およびその結果
• 比較に使用された URL とビューポート
• 受け入れられた差異、残存リスク、ロールバック
• 検証されたマニフェストのパスと、その証拠マトリックスの概要

サイトがレンダリングされている、または HTML に同じコピーが含まれているという理由だけで、視覚的パリティを主張しないでください。パリティには、視覚的な比較と編集可能性の検証が必要です。

呼び出し例

$transform-claude-to-gutenberg を使ってこの Claude Code プロジェクトを監査し、指定された LocalWP サイトへのホームページの移行契約を作成してください。

$transform-claude-to-gutenberg を使って、レストランデモをコアブロックとローカルアセットを使用した 1:1 の FSE ブロックテーマに変換してください。

$transform-claude-to-gutenberg を使って、移行されたテーマをレビューし、承認されたプロトタイプと編集可能かつ視覚的に同等であると見なすことを妨げているものを列挙してください。