website-cloner

网站克隆器

6 阶段编排器，可克隆任意网站并生成改进版本——提升性能、UI/UX、SEO 和安全性。基于 Vite + React + shadcn/ui + Tailwind CSS 构建，可部署到 GitHub Pages。

使用场景

在用户要求以下操作时触发：

• 克隆、重建或复刻网站（“克隆这个网站”“为 制作一个更好的版本”）
• 通过分析并重建网站，提升其性能、UI/UX 或 SEO
• 从 URL 开始完整的网站改进工作流

不要用于单阶段工作（直接使用对应的同级技能）。

前置条件

• 目标 URL（优先使用可公开访问的 URL）。
• 写入权限，以便创建本地项目目录（默认位于 ~/workspace/clones 或 $CLONE_DIR 下）。
• 已安装同级阶段技能（website-analyzer、website-clone-report 等）。
• 可选：如果希望在 Phase 5 自动部署到 Pages，需要 GitHub token。
• 各阶段关卡均需用户批准（进入 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 — Phase 4 的分阶段实施计划，其中包含已批准的 GitHub Actions 产物部署任务；builder-metadata.json — Phase 5 的构建元数据、工作流生成的 Pages URL，以及供 Phase 6 使用的结构化部署后性能/SEO/安全快照；after-analysis.json — 用于对比的 Phase 5 重新审计结果来源。Phase 5 还会生成适配 base 路径的 Vite 配置和 .github/workflows/deploy-pages.yml，该工作流会构建并部署 dist/，而不是发布仓库根目录。

目录结构

这个总入口及其各阶段技能位于同一个套件目录中：

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 → 任务 → 构建后的网站 → 最终报告）。将它们放在同一目录中，便于浏览、审计和一并发布。每个阶段技能仍可独立安装——安装程序（install.sh、remote-install.sh）会查找顶层和嵌套技能。

调用以下阶段技能时，请使用其名称（/website-analyzer、/website-clone-report 等）；无论文件系统路径如何，运行时都会解析名称。

完整参考资料和脚本请参阅各阶段技能文档中的 references/ 和 scripts/。此编排器保持简短，以适应 Agent 的上下文预算。

编辑前同步仓库（必需）

修改仓库中的文件之前：

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. 确定工作目录——用于构建克隆网站的目录。如果设置了 $CLONE_DIR，则使用它。否则询问用户一次，并保存到 ~/.config/website-cloner-dir.txt。默认值：~/workspace/clones。
1. 在解析后的根目录下创建项目文件夹：YYYY_MM_DD_<slug_from_url>/
2. 将创建的文件夹路径设置为 $PROJECT_DIR。
3. 如果 $ARGUMENTS 中没有提供 URL，请向用户询问。

Phase 1：了解网站

使用 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 阶段：面向最终用户的报告（门控）

使用分析输出调用 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 阶段：改进提案（门控）

使用已批准的报告和分析调用 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 阶段：实施计划（门控）

使用 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），并通过 .github/workflows/deploy-pages.yml 部署经过验证的 dist/ 构建产物。对于用户或组织的 Pages 仓库，工作流会将 Vite 基础路径设为 /；对于项目 Pages，则设为 /<repo>/；禁止从仓库根目录和分支文件夹发布。随后，它会针对工作流生成的响应式 Pages URL 重新运行 website-analyzer，并在元数据中输出结构化的改造后快照，供第 6 阶段使用。如果部署或重新审计未完成，第 5 阶段必须返回 PARTIAL，并保留空值或错误，不得编造指标。

步骤完成报告：

◆ 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。
• 没有可抓取内容的 JS 密集型 SPA：在第 1 阶段说明此限制，并尽力继续分析。构建阶段可能需要用户提供素材来弥补。
• 用户在任一门控环节拒绝批准：停止整个流程。不得自动继续。用户可以重新运行此技能以恢复流程。
• 缺少同级技能：如果某个同级技能不可用，则跳过该阶段并在报告中说明。尽可能继续，但总体结果不能高于 PARTIAL。
• 第 1 阶段结果不完整：如果分析器返回的数据不完整（例如没有 SEO 评分），请附注并继续进入第 2 阶段；如果必需的基准对比不可用，则第 6 阶段和整个工作流仍为 PARTIAL。
• 第 5 阶段重新审计不完整：继续进入第 6 阶段以记录缺失项，但除非报告创建本身失败，否则第 6 阶段和整个工作流都必须返回 PARTIAL。