Detalle del Skill

website-cloner

End-to-end workflow to rebuild and improve a website from a URL.

CoincidenciaDirectaRevisado para creación de sitios web
Fuenteluongnv89/skillsFuente externa
Instalaciones reportadas40Solo señal de popularidad

Revisar antes de usar

La revisión automática comprueba relevancia, no seguridad ni respaldo. Lee las instrucciones de la fuente antes de usar este Skill.

Vista previa guardada

SKILL.md

Este extracto es una copia guardada durante la revisión. La fuente externa contiene la versión completa y actual.

---
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 "$
Leer la fuente completa en GitHub (abre una página externa)
Contexto

Trabajo relacionado