AlexMaghen/wp-dev

wp-dev: ライブWordPressサイトをローカルで開発する

wpsyncは ${CLAUDE_PLUGIN_ROOT}/bin/wpsync として実行します（以下 wpsync と表記）。開発者は通常このスキルを構築した人物ではないため、各ステップを平易な言葉で説明し、開発者の操作が必要な場合はその都度伝えてください。

最初に ${CLAUDE_PLUGIN_ROOT}/skills/wp-dev/guiding.md を読んでください。 このファイルには、進捗表示（フェーズの各ステップをチェックリストで表示）、質問方法（判断や待機が必要な場合は質問ダイアログを使用）、およびアプリがそれらを提供しない場合の対応方法が記載されています。以下の Ask 行は使用するダイアログを示しています。

原則: 何かを変更する前に必ず確認し、問題はすべて一度に報告し、修正方法も合わせて提示すること。すべてのステップは再実行しても安全であるため、中断後は開発者が「continue my wp-dev project」と言えば中断したところから再開できます。

最初に: wpsyncは実行可能か？

wpsyncは Bun 上で動作するため、BunがまだインストールされていないMacでは、すべてのwpsyncコマンド（status、init、doctorを含む）が「wpsync needs Bun」（終了コード127）で失敗します。最初にこれを確認してください。

1. ${CLAUDE_PLUGIN_ROOT}/bin/wpsync --version を実行します。バージョンが表示された場合は「現在の状況は？」に進みます。
2. 「wpsync needs Bun」と表示された場合、Homebrewを探します: command -v brew || ls /opt/homebrew/bin/brew /usr/local/bin/brew
   • Homebrewが見つかった場合 → brew install oven-sh/bun/bun（brew がPATHにない場合はフルパスを使用）を実行し、再度 wpsync --version を実行します。
   • Homebrewがない場合 → 開発者の操作が必要です（Macのパスワードを求められます）。wpsyncとその他のツールはHomebrewでインストールされることを説明し、https://brew.sh のインストーラーコマンドを用意したターミナルタブを開き（guiding.md を参照）、「Done, check it」ダイアログで待機します。その後、Homebrewを使用可能にし（ステップ2の「Homebrewをインストール直後」を参照）、上記の手順でBunをインストールします。

wpsyncが実行できた場合は、そのことについては何も言わずに次に進みます。Bunをインストールした場合のみ、これが最初の前提条件であったこと、および wpsync doctor --local で残りの環境をチェックすることを1行で伝えてください。

現在の状況は？

カレントフォルダで wpsync status --json を実行し、出力の phase に応じて次のように進めます:

phase	実行内容
no-project	フェーズ1のステップ1（スタートゲート）から
start-gate（以前のセッションでフォルダ作成済み）	フェーズ1のステップ2から
connect、pull	フェーズ1のステップ2から（完了済みのステップはスキップ）
work	フェーズ2: 変更には wp-work スキル、リフレッシュには wp-pull、公開には wp-publish
publish-pending	最後の公開が確定またはロールバックを待っている状態: wp-publish を参照

どのフェーズでも、status に wordfence フィールドがある場合、このサイトのWordfenceはwpsyncが処理中はオフにし、処理後にオンに戻す必要があります。${CLAUDE_PLUGIN_ROOT}/skills/wp-dev/wordfence.md に従ってください。

フェーズ1では、guiding.md の「セットアップチェックリスト」を開始（または再開時に再表示）し、完了したステップにチェックを入れ、「セットアップ」の章を開始してください。

フェーズ1: ローカルコピーをセットアップする

1. スタートゲート: 正しいフォルダ、次にアドレス

セッションのフォルダは開始時に固定されるため、開発者は ローカルコピーを配置するフォルダでセッションを開始 します。その後、すべての処理はこの1つのセッション内で行われます。

このセッションは使用可能なフォルダ内ですか？ カレントフォルダを確認します（ls -A）:

• 空（または .DS_Store や .claude のみ）: サイトの新しいフォルダです。以下の続きに進みます。

• その他（デスクトップ、ホームフォルダ、別のプロジェクト）: ここでセットアップしないでください。次のメッセージを送信し、停止します:

  サイトをセットアップするには、ローカルコピーを配置する新しい空のフォルダ（例: ~/wp-sites/example.com）で新しいClaude Codeセッションを開始してください。

  新しいセッションを開始し、そのフォルダを選択（または作成）し、各ステップの承認を避けたい場合は権限モードを Bypass permissions に設定してください。（ライブサイトへの公開は常に、ダイアログにドメインを入力するまで待機します。）その後、そのフォルダで 「new wp-dev project」 と伝えてください。

新しいフォルダ内で、 1つだけ質問します。ライブサイトのアドレスを1行で:

ライブサイトのアドレスは何ですか？例: https://example.com

フォルダ名にドメインが含まれている場合（例: example.com-local）、代わりに次のように提案します:「ライブサイトのアドレスは何ですか？フォルダ名から https://example.com と推測しますが。」

次に、ここでプロジェクトを作成します: wpsync init <site-url> --dir .。このコマンドはフォルダ内に CLAUDE.md、.claude/settings.json（ddev、git、brew および読み取り専用のwpsyncコマンドを事前承認; 公開は引き続き確認が必要）、および .wpsync.json（保留中）を作成します。外部には接触しません。そのままステップ2に進みます。これらの設定は、このフォルダ内での次のセッションから有効になります。Bypass permissions モードでない場合、このセッションではその間、少し頻繁に確認が求められる可能性があります。権限モードを検出することはできませんし、その必要もありません。

2. このMacを確認する

wpsync doctor --local ですべてを一度にリスト表示します。guiding.md の結果テーブルとして表示します。不足しているものを以下の順序でインストールします:

• あなたが実行可能: brew install ddev/ddev/ddev、brew install oven-sh/bun/bun、およびDocker。Dockerアプリがどちらもインストールされていない場合、「このMacにどのDockerアプリをインストールしますか？」 と質問します: OrbStack（推奨: Macで軽量かつ高速、個人利用は無料）または Docker Desktop（標準的なもの、個人利用および小規模企業は無料）。その後、brew install --cask orbstack または brew install --cask docker を実行します。 Dockerはインストール済みだが「実行中でない」場合: 自分で起動します（open -a OrbStack または open -a Docker）し、docker info が成功するまで最大1分待機します。初回起動時のみ（利用規約、パスワード）開発者の操作が必要です。1分経過しても docker info が失敗する場合、初回起動ダイアログが開発者の入力を待っています。
• 開発者の操作が必要（パスワードやクリックが必要であり、あなたは代わりに行いません）: Xcodeコマンドラインツール（xcode-select --install）、Homebrew（https://brew.sh から）、OrbStackまたはDocker Desktopの初回起動、および mkcert -install。コマンドを準備したターミナルタブを開き（guiding.md を参照）、「Done, check it」ダイアログで待機します。複数が不足している場合、1つのメッセージにすべてをリストし、1回だけ待機します（項目ごとに待機する必要はありません）。

mkcertは必須です（doctorはセットアップされるまでFIXと報告します）。ローカルコピーのアドレスは https://…ddev.site です。mkcert -install がないと、Chromeはそのアドレスを拒否し、プレーンなhttpではページのスタイルや画像が読み込まれません（WordPressはそれらをhttpsでリンクします）。これはステップ7でコピーが壊れているように見える原因になります。そのため、最初のプルの前に、ここで実行します: Macのパスワードが必要になることを伝え、ターミナルタブで mkcert -install を実行し、待機します。DDEV起動後にのみインストールされた場合（古いセットアップを再開する場合）、DDEVはまだ信頼されていない証明書を使用しています: サイトフォルダで ddev poweroff && ddev start を実行し、開発者にページをリロードするよう依頼します。

wpsync doctor --local を、FIXがなくなるまで再度実行します。Notesは待機できますが、その意味を説明してください。

Homebrewをインストール直後: Apple Silicon MacではHomebrewは /opt/homebrew にインストールされますが、インストーラーの「Next steps」の行が実行されるまでPATHに含まれません。doctorはこれを「installed at /opt/homebrew/bin/brew, but not on the PATH yet」と報告し、~/.zprofile に追加する行を表示します。決して再インストールを促さないでください。あなたのシェルは ~/.zprofile を読み込まないため、このセッションではコマンドの前に eval "$(/opt/homebrew/bin/brew shellenv)" && を付けて実行します。

3. サイトを確認する

wpsync doctor <site-url>（読み取り専用）。接続前に、サイトがWordPressでありREST APIが利用可能で、アプリケーションパスワードが有効であることを確認します（ホストがAuthorizationヘッダーを通過させるかどうかは実際のキーでのみテストできるため、wpsyncが接続した時点で確認されます）。結果テーブルを表示します。各FIXを次のステップに進む前に修正または説明します。ほとんどはホスティングやセキュリティプラグインの設定であり、開発者が誰かに問い合わせる必要があります: guiding.md の「チェックに誰か他の人が必要な場合」ダイアログを使用します。

Wordfence: アプリケーションパスワードが「Wordfenceによってオフにされている可能性が高い」と報告された場合、${CLAUDE_PLUGIN_ROOT}/skills/wp-dev/wordfence.md（「Before」）に従います: 開発者がwp-adminで1つの設定をオフにし、doctorが確認するまで「Done, check it」ダイアログで待機します。ステップ8でオンに戻すことを忘れずに伝えます。

4. 接続

wp-connect スキル。その後、再度 wpsync doctor <site-url> を実行します: 今度はAuthorizationヘッダー、マルチサイト、ファイル権限、バージョン、およびこのMacとサーバーのディスク容量もチェックします。

（wpsync new <site-url> はステップ2から7を1回で実行し、開発者の操作が必要な最初の項目で停止します。再開時に便利です。ここでのようにステップバイステップで進めると、より詳細に説明できます。）

5. プル

wp-pull スキル（初回プル: wpsync pull <site-url> --dir .）。https://<project>.ddev.site にDDEVプロジェクトを作成します。hostsファイルの変更は不要です。大規模なサイトは時間がかかります: 長時間ジョブとして実行します（guiding.md）。

6. コピーを安全に実行できるようにする

コピーにはライブのデータベースが含まれています: 実際の顧客のメールアドレス、ライブの支払いやAPIキー、スケジュールされたジョブなどです。DDEVはすべての送信メールをキャッチし（ddev mailpit で確認可）、wpsyncは WP_ENVIRONMENT_TYPE=local を設定します。CLAUDE.md で有効なプラグインを確認します。支払い、配送、CRM、ニュースレター、またはWebhookプラグインがある場合、それらをリストし、「<ドメイン>のローカルコピー上のこれらのプラグインは、実際のサービスと通信する可能性があります。どうしますか？」 と質問します: テストモードを案内する（推奨: 各プラグインのテストモードまたはサンドボックス設定をローカルのwp-adminで案内します）、または このままにする（ローカルコピーがそれらのサービスにアクセスできることを承諾します）。

そのようなプラグインが1つもアクティブでない場合、質問はせず、1行でそのことを伝え（DDEVがキャッチするメールのみ送信するプラグインがあればそれを記載）、次に進みます。

7. 確認

wpsync verify は、ページ、wp-admin、パーマリンク、残存するライブアドレス、画像、およびプラグインとテーマがライブと一致することをチェックします。結果テーブルを表示します。

失敗したページチェックを調査する前に、 自分で対象ページを1度確認します: curl -s -o /dev/null -w '%{http_code}' <localUrl>/。200が返ってきた場合、おそらくDDEVの起動中にチェックが実行された可能性があります（ddev start の直後は502を返します）。ログを調べる前に、wpsync verify を再度実行してください。

次に、自分で確認します: ライブとローカルコピーを Chrome（Claude内のChrome）で並べて開き、トップページといくつかの内部ページを比較します。アプリ内蔵のブラウザペインではコピーを評価しないでください。*.ddev.site ページのスタイル、スクリプト、画像がブロックされるため（ERR_BLOCKED_BY_CLIENT）、完全なコピーでも壊れて見えます。Chromeが利用できない場合、curl でページを確認し、開発者に見てもらうよう依頼します。説明できない相違がある場合、それを説明し、「今すぐ修正する」（推奨） または 「問題ない、次に進む」 と質問します。

ローカルログイン: コピーにはライブのユーザーが含まれているため、開発者は自分のライブパスワードでローカルのwp-adminにログインします。

8. 引き渡し

サイトの CLAUDE.md を今すぐ読み、そのルールが今後適用されるようにします。

最初に、このサイトがWordfenceを使用している場合（wpsync status --json に "wordfence": "switched-off" と表示されている場合）: セットアップはもうライブサイトを必要としないため、${CLAUDE_PLUGIN_ROOT}/skills/wp-dev/wordfence.md（「wpsyncが完了したとき」）に従い、開発者にWordfenceの保護を再度オンにしてもらい、待機し、wpsync status で確認します。これを引き渡しのメッセージの前に行い、開発者の最後のステップが別の作業ではなく作業の開始になるようにします。

次に、ローカルサイトをChromeで開き、チェックリストを完了します。セットアップは、以下のメッセージを太字で、独立した行に、メッセージの最後の要素として配置して終了します（その後には何も書かないでください。ログインなどの他の注意事項はその前に記述します）:

サイトのローカルコピーが https://{ローカルサイトドメイン} で準備できました。確認して、変更を開始したい内容を教えてください。

https://{ローカルサイトドメイン} は .wpsync.json の localUrl に置き換えます。その直前の1行でログインについて説明します: ローカルのwp-adminにはライブのユーザー名とパスワードでログインできます。