website-cloner

Web サイトクローン

6 フェーズのオーケストレーターです。あらゆる Web サイトを複製し、パフォーマンス、UI/UX、SEO、セキュリティを改善したバージョンを作成します。Vite + React + shadcn/ui + Tailwind CSS で構築されており、GitHub Pages にデプロイできます。

使用する場合

ユーザーから次の依頼があった場合に使用します。

• Web サイトの複製、再構築、または再現（「このサイトを複製して」「 の改善版を作って」など）
• Web サイトを分析して再構築することで、パフォーマンス、UI/UX、または SEO を改善する
• URL を起点に、Web サイト全体の改善ワークフローを開始する

単一フェーズの作業には使用しないでください（該当する個別のスキルを直接使用してください）。

前提条件

• 対象 URL（一般公開され、アクセス可能な URL が望ましい）。
• ローカルのプロジェクトディレクトリを作成するための書き込み権限（デフォルトでは ~/workspace/clones または $CLONE_DIR 配下）。
• 兄弟フェーズのスキルがインストールされていること（website-analyzer、website-clone-report など）。
• 任意：Phase 5 で Pages のデプロイを自動化する場合は GitHub トークン。
• 各ゲートでのユーザー承認（Phase 3、4、5 に進む前に明示的な確認が必要です）。

前提条件が不足している場合は、処理を停止して報告してください。パスや認証情報を推測してはいけません。

ワークフロー

Phase 1 — Analyze        → website-analyzer
Phase 2 — Report (gate)  → website-clone-report
Phase 3 — Propose (gate) → website-improvement-prd  (outputs prd.md)
Phase 4 — Plan  (gate)   → website-implementation-plan  (outputs tasks.md)
Phase 5 — Build          → website-builder
Phase 6 — Final Report   → website-clone-final-report

Phase 2、3、4 の後には承認ゲートがあります。オーケストレーターは、ユーザーの明示的な承認なしに先へ進んではいけません。

成果物（それぞれ一度だけ作成し、以下の各フェーズでは名前で参照します）：analysis.json — Phase 1 の構造化された調査結果、report.md — Phase 2 の平易な言葉による要約、prd.md — Phase 3 の改善提案、tasks.md — 承認済みの GitHub Actions アーティファクトデプロイタスクを含む、Phase 4 の段階的な実装計画、builder-metadata.json — Phase 5 のビルドメタデータ、ワークフローが生成した Pages URL、および Phase 6 で使用する、デプロイ後のパフォーマンス／SEO／セキュリティの構造化スナップショット、after-analysis.json — 比較可能な Phase 5 の再監査データ。Phase 5 では、ベースパスに対応した Vite 設定と .github/workflows/deploy-pages.yml も生成します。このワークフローは、リポジトリのルートではなく dist/ をビルドしてデプロイします。

ディレクトリ構成

この包括スキルと各フェーズのスキルは、1 つのスイートフォルダーにまとめられています。

skills/website-cloner/                    ← this umbrella
├── SKILL.md                              ← orchestrator (you are here)
├── website-analyzer/                     ← Phase 1
├── website-clone-report/                 ← Phase 2
├── website-improvement-prd/              ← Phase 3
├── website-implementation-plan/          ← Phase 4
├── website-builder/                      ← Phase 5
└── website-clone-final-report/           ← Phase 6

ネストされている理由：各フェーズは、この包括スキルのデータフロー（分析 JSON → レポート → PRD → タスク → 構築済みサイト → 最終レポート）と密接に連携しています。1 つのフォルダーにまとめることで、スイートを簡単に閲覧、監査し、一緒に配布できます。各フェーズのスキルは個別にインストール可能なままです。インストーラー（install.sh、remote-install.sh）は、最上位とネストされた両方のスキルを検出します。

以下のフェーズのスキルを呼び出す際は、名前（/website-analyzer、/website-clone-report など）で参照してください。実行環境は、ファイルシステム上のパスに関係なく名前を解決します。

完全な references/ と scripts/ の説明については、各フェーズのスキルのドキュメントを参照してください。このオーケストレーターは、エージェントのコンテキスト予算に収まるよう短くしています。

編集前のリポジトリ同期（必須）

リポジトリ内のファイルを変更する前に、次を実行してください。

branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

変更がある場合は、先にスタッシュしてください。

git stash push -u -m "website-cloner: pre-sync"
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin && git pull --rebase origin "$branch"
git stash pop

origin が存在しない場合、またはリベースで競合が発生した場合は、停止してユーザーに確認してください。

セットアップ

0. 作業ディレクトリを解決する — クローンした Web サイトを構築するディレクトリです。$CLONE_DIR が設定されている場合は、それを使用します。設定されていない場合は、ユーザーに一度だけ尋ね、~/.config/website-cloner-dir.txt に保存します。デフォルト：~/workspace/clones。
1. 解決したルートの下にプロジェクトフォルダーを作成します：YYYY_MM_DD_<slug_from_url>/
2. 作成したフォルダーのパスを $PROJECT_DIR に設定します。
3. $ARGUMENTS に URL が指定されていない場合は、ユーザーに尋ねます。

Phase 1：Web サイトを把握する

URL を指定して website-analyzer を呼び出します。

/website-analyzer <url> --output "$PROJECT_DIR/analysis.json"

アナライザーは、UI/UX、カテゴリ、スタイル、パフォーマンス（lcp_estimate_seconds、単位のない cls_estimate、ttfb_estimate_seconds、KB 単位のページサイズ、リクエスト数）、表層的なセキュリティ、SEO（全体スコアと次元ごとの内訳）を網羅する構造化分析を生成します。

確認： 分析ファイルが存在し、6 つの次元すべてを網羅していること。次元が不足している場合はその旨を記録しますが、処理は続行してください。Phase 2 では部分的な結果でも問題ありません。

ステップ完了レポート：

◆ Analyze (step 1 of 6 — <site name>)
······································································
  UI/UX profile:        √ pass | × partial — <gap>
  Category detected:    √ pass (<category>)
  Style analysis:       √ pass | × partial — <gap>
  Performance metrics:  √ pass (LCP=<val> CLS=<val>)
  Security surface:     √ pass | × partial — <gap>
  SEO score:            √ pass (<score>/100)
  ____________________________
  Result:               PASS | PARTIAL

フェーズ 2：エンドユーザー向けレポート（GATE）

分析結果を使って website-clone-report を呼び出します。

/website-clone-report "$PROJECT_DIR/analysis.json" --output "$PROJECT_DIR/report.md"

このスキルは、技術者以外にも分かりやすいレポートを作成し、保存する前に承認を求めます。オーケストレーターはここでユーザーの承認を待ちます。

確認： report.md が存在し、ユーザーの承認を得ていること。

ステップ完了レポート：

◆ Report (step 2 of 6 — <site name>)
······································································
  Report written:       √ pass (report.md)
  User approved:        √ pass | × pending
  ____________________________
  Result:               PASS | BLOCKED

承認されなかった場合は、先に進まず、レポートを確認して承認するか、変更を依頼するようユーザーに求めます。

フェーズ 3：改善提案（GATE）

承認済みのレポートと分析結果を使って website-improvement-prd を呼び出します。

/website-improvement-prd "$PROJECT_DIR/report.md" "$PROJECT_DIR/analysis.json" --output "$PROJECT_DIR/prd.md"

このスキルは、各変更の内容・理由・価値を含む包括的な改善提案を作成し、ユーザーの承認後に prd.md を書き込みます。

確認： prd.md が存在し、承認されていること。

ステップ完了レポート：

◆ Proposal (step 3 of 6 — <site name>)
······································································
  prd.md written:       √ pass
  User approved:        √ pass | × pending
  Changes catalogued:   √ pass (<N> proposed changes)
  ____________________________
  Result:               PASS | BLOCKED

フェーズ 4：実装計画（GATE）

prd.md を使って website-implementation-plan を呼び出します。

/website-implementation-plan "$PROJECT_DIR/prd.md" --output "$PROJECT_DIR/tasks.md"

このスキルは、ランディングページを最初に作成する段階的な実装計画を作成します。この計画には、アセットの収集と作成の区別、個別タスク、ベースパスを考慮した Vite の dist/ 出力から GitHub Actions Pages に確実にアーティファクトをデプロイする方法が含まれます。ユーザーの承認後に tasks.md に書き込まれます。

確認： tasks.md が存在し、承認されていること。

ステップ完了レポート：

◆ Plan (step 4 of 6 — <site name>)
······································································
  tasks.md written:     √ pass
  User approved:        √ pass | × pending
  Phases defined:       √ pass (≥ 2 phases)
  Landing page first:   √ pass
  Pages artifact task:  √ pass (base-aware dist/)
  ____________________________
  Result:               PASS | BLOCKED

フェーズ 5：ビルド

tasks.md と prd.md を使って website-builder を呼び出します。

/website-builder "$PROJECT_DIR/tasks.md" "$PROJECT_DIR/prd.md" --output "$PROJECT_DIR/"

このスキルは計画を実行してサイトを構築し（Vite + React + shadcn/ui + Tailwind）、検証済みの dist/ アーティファクトを .github/workflows/deploy-pages.yml 経由でデプロイします。このワークフローは、ユーザー／組織の Pages リポジトリでは Vite のベースパスを / に、プロジェクトの Pages では /<repo>/ に設定します。リポジトリルートおよびブランチフォルダーへの公開は禁止されています。その後、ワークフローで生成された Pages のレスポンシブ URL に対して website-analyzer を再実行し、フェーズ 6 用の構造化されたビルド後スナップショットをメタデータとして出力します。デプロイまたは再監査が未完了の場合、フェーズ 5 は PARTIAL を返し、メトリクスを捏造せず、null／エラーをそのまま保持する必要があります。

ステップ完了レポート：

◆ Build (step 5 of 6 — <site name>)
······································································
  Landing page built:   √ pass
  Assets collected:     √ pass (<N> assets)
  Assets created:       √ pass (<N> assets)
  Pages dist artifact:  √ pass | × unavailable
  GitHub Pages URL:     √ pass (<url>) | × unavailable
  After metrics:        √ complete | × partial ([performance/SEO/security gaps])
  ____________________________
  Result:               PASS | PARTIAL | FAIL

フェーズ 6：最終比較レポート

分析のベースラインとビルダーのメタデータを使って website-clone-final-report を呼び出します。

/website-clone-final-report "$PROJECT_DIR/analysis.json" "$PROJECT_DIR/builder-metadata.json" --output "$PROJECT_DIR/final-report.md"

このスキルは、ベースラインとデプロイ後の構造化スナップショットを検証し、パフォーマンス、SEO、セキュリティ、UI/UX の変更、差異、GitHub Pages の URL を含むビフォー／アフター比較を作成します。必須のパフォーマンス、SEO、またはセキュリティの比較が利用できない場合は、PARTIAL を引き継ぐ必要があります。

ステップ完了レポート：

◆ Final Report (step 6 of 6 — <site name>)
······································································
  final-report.md:      √ pass
  Performance delta:    √ pass (before→after) | × partial ([missing])
  SEO delta:            √ pass (before→after) | × partial ([missing])
  Security comparison:  √ pass (before→after) | × partial ([missing])
  Deviations listed:    √ pass | × none
  ____________________________
  Result:               PASS | PARTIAL | FAIL

期待される出力

◆ Website Cloner — <site name>
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
  Phase 1  Analyze      √ pass
  Phase 2  Report       √ approved
  Phase 3  Proposal     √ approved (prd.md)
  Phase 4  Plan         √ approved (tasks.md)
  Phase 5  Build        √ pass | × partial
  Phase 6  Final Report √ pass | × partial | × fail
  Overall Result:       PASS | PARTIAL | FAIL

  GitHub Pages: https://<user>.github.io/<repo>/
  Project:      <project_dir>

全体の結果は、フェーズ 1～6 のうち最も低い結果になります。フェーズ 5 のビルド後スナップショット、またはフェーズ 6 の必須比較のいずれかが一部のみ、利用不可、または失敗の場合、全体の結果として PASS を報告してはいけません。

エッジケース

• URL に到達できない場合：フェーズ 1 を停止し、エラーを報告して続行しません。別の URL をユーザーに求めます。
• クロール可能なコンテンツがない、JavaScript を多用する SPA：フェーズ 1 で制約を記載し、可能な範囲で分析を続けます。補完のため、ビルドフェーズでユーザー提供のアセットが必要になる場合があります。
• いずれかのゲートでユーザーが承認しない場合：パイプラインを停止します。自動的に続行してはいけません。ユーザーはスキルを再実行して再開できます。
• 関連スキルが見つからない場合：関連スキルを利用できない場合は、そのフェーズをスキップし、レポートに記載します。可能な範囲で続行しますが、全体の結果は PARTIAL を超えられません。
• フェーズ 1 の結果が一部のみの場合：アナライザーが一部のデータ（例：SEO スコアなし）しか返さない場合は、その旨を記載してフェーズ 2 に進みます。必須のベースライン比較が利用できない場合、フェーズ 6 とワークフロー全体の結果は PARTIAL のままとなります。
• フェーズ 5 の再監査が一部のみの場合：不足箇所を記録できるようフェーズ 6 に進みます。ただし、レポート作成自体が失敗しない限り、フェーズ 6 とワークフロー全体の結果は PARTIAL を返す必要があります。