website-cloner

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: website-cloner
description: "Build an improved website clone from a URL via 6-phase gated workflow (Vite/React/shadcn/Tailwind + GitHub Pages). Use for end-to-end site rebuilds. Don't use for single-phase work."
license: MIT
effort: high
metadata:
  version: 1.2.1
  author: "Luong NGUYEN <[email protected]>"
---

# Website Cloner

6-phase orchestrator that clones any website and produces an improved version — better performance, UI/UX, SEO, and security — built with Vite + React + shadcn/ui + Tailwind CSS, deployable to GitHub Pages.

## When to Use

Trigger when the user asks to:
- Clone, rebuild, or recreate a website ("clone this site", "make a better version of <url>")
- Improve a website's performance, UI/UX, or SEO by analyzing and rebuilding it
- Start a full website improvement workflow from a URL

Do **not** use for single-phase work (use the specific sibling skill directly).

## Prerequisites

- A target URL (publicly reachable preferred).
- Write access to create a local project dir (defaults under `~/workspace/clones` or `$CLONE_DIR`).
- The sibling phase skills installed (website-analyzer, website-clone-report, etc.).
- Optional: GitHub token if you want Pages deploy automation in Phase 5.
- User approval at gates (explicit confirmation before Phases 3, 4, 5 advance).

If a prerequisite is missing, stop and report it — do not guess paths or credentials.

## Workflow

```
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
```

Approval gates after Phase 2, 3, and 4: the orchestrator **must not advance** without explicit user approval.

**Artifacts** (each written once, then referenced by name in the phases below): `analysis.json` — Phase 1's structured findings; `report.md` — Phase 2's plain-language summary; `prd.md` — Phase 3's improvement proposal; `tasks.md` — Phase 4's phased implementation plan, including the approved GitHub Actions artifact-deployment task; `builder-metadata.json` — Phase 5's build metadata, workflow-produced Pages URL, and structured post-deployment performance/SEO/security snapshot consumed by Phase 6; `after-analysis.json` — the comparable Phase 5 re-audit source. Phase 5 also produces base-aware Vite configuration and `.github/workflows/deploy-pages.yml`, which builds and deploys `dist/` rather than publishing the repository root.

## Layout

This umbrella and its phase skills live together in a single suite folder:

```
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
```

Why nested: the phases are tightly coupled to this umbrella's data flow (analysis JSON → report → PRD → tasks → built site → final report). Keeping them in one folder makes the suite easy to browse, audit, and ship together. Each phase skill stays independently installable — the installers (`install.sh`, `remote-install.sh`) discover both top-level and nested skills.

When invoking phase skills below, refer to them by name (`/website-analyzer`, `/website-clone-report`, …); the runtime resolves names regardless of filesystem path.

See the individual phase skill docs for their full references/ and scripts/. This orchestrator stays short to fit the agent's context budget.

## Repo Sync Before Edits (mandatory)

Before modifying files in a repository:

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