Skill-Details
website-cloner
End-to-end workflow to rebuild and improve a website from a URL.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- 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 "$Vollständige Quelle auf GitHub lesen (öffnet externe Seite)