--- name: launchgrade-setup description: Phase 2 of the Launchgrade workflow — takes the approved single-HTML draft (index.html from launchgrade-design) and brings it into production shape. Stack choice happens here (plain HTML default, or migration to Astro/Next/SvelteKit/Nuxt with visual parity check), plus required files (robots.txt with AI-crawler defaults, sitemap.xml, llms.txt, security.txt, manifest, 404/500), complete head metas, CSP/security headers per deploy target, JSON-LD, favicons. Never changes content or look (design fidelity). Triggers on "setup", "bring into shape", "go live", "deploy", "stack", "migrate", "required files", "CSP", "robots.txt", "manifest", "security.txt", "favicon", "JSON-LD", "hreflang", "in Form bringen", "produktiv machen", "Pflicht-Files", "Setup". --- # Launchgrade Web Setup Skill Zweite Phase im Launchgrade-Workflow: **In Form bringen**. Nimmt den freigegebenen Single-HTML-Draft aus `/launchgrade-design` und macht ihn produktionsreif — Pflicht-Files, ``-Metas, CSP/Headers, optional Stack-Migration. Diese Phase ist optional: nur nötig, wenn die Seite live gehen soll. ## Grundregel: Design-Treue **Setup verändert weder Inhalt noch Optik.** Der Draft ist die Ground-Truth — Setup ergänzt ausschließlich Technik (Metas, Files, Header, Struktur). Wer am Design oder an Texten drehen will → zurück zu `/launchgrade-design`. ## Wann triggern - Draft ist freigegeben und soll produktiv werden („in Form bringen", „live") - Konkrete Setup-Fragen: CSP, robots.txt für AI-Bots, Manifest, Favicons, security.txt, hreflang, JSON-LD, Stack-Migration - Migration eines Bestandsprojekts auf Launchgrade-Standards (technischer Teil) Nicht triggern bei: Design-/Copy-Änderungen (→ `launchgrade-design`), Audit/Pre-Launch-Check (→ `launchgrade-audit`), Backend-/Admin-Tasks. ## Wo die Wahrheit liegt Standards liegen in `./web-standards/AGENTS.md` und `./web-standards/checklist.md` im Repo-Root. Snapshot der Launchgrade Web Standards 2026, mit jedem Release versioniert. Relevante Kapitel für Setup: - §1 HTML & Document Baseline - §5 Security - §7 Browser-Support, Responsive & i18n - §8 PWA & Manifest - §10 Pflicht-Dateien im Repo-Root **Pflicht-Schritt:** Vor jeder Generierung das relevante Kapitel mit Read laden. Nicht aus dem Gedächtnis arbeiten — Standards können sich ändern. ## Vorgehen 1. **Voraussetzungs-Check (Bash):** ```bash if [ -f index.html ] && [ -f project.config.json ]; then echo "DRAFT_PRESENT" elif [ -f public/index.html ] && [ -f project.config.json ]; then echo "ALREADY_SHAPED" else echo "DRAFT_MISSING"; fi ``` Bei `ALREADY_SHAPED`: Setup lief bereits (Plain-HTML-Pfad) — nur fehlende Teile ergänzen (Header-Config, Favicons, offene Platzhalter), nichts erneut verschieben. Bei `DRAFT_MISSING`: abbrechen mit Hinweis *„erst `/launchgrade-design` ausführen"* — kein Blind-Scaffold auf leerem Repo. Ausnahme Bestandsprojekt: existiert bereits eine produktive Site ohne Draft, das explizit machen und nur den Pflicht-File-/Header-Teil fahren. 2. **Technische Erfassung** (nur was fehlt — Brand-Daten stehen in `project.config.json`, nichts doppelt fragen): - **Domain** — Final-URL (z.B. `example.com`) - **hreflang** bei Mehrsprachigkeit (z.B. `de,en`) - **BFSG-Relevanz** — B2C-Shop / Banking / Buchung → im Output markieren, `accessibility-statement.md` mitgenerieren (Pflicht seit Juni 2025) - **Deploy-Ziel** — Vercel / Cloudflare Pages / nginx / Apache (bestimmt das Format der Header-Config). Default-Annahme Vercel, sonst nachfragen. 3. **Stack-Wahl per `AskUserQuestion`** — der Draft existiert bereits als HTML, deshalb ist Plain HTML der Default: - Question: *„Wie soll die Seite produktiv werden?"* - Options: *Plain HTML (Default)* · *Astro* · *Next.js* · *SvelteKit / Nuxt* | Stack | Wann nehmen | |---|---| | **Plain HTML** (Default) | Draft IST die Website. One-Pager / Landing Page ohne App-Logik. Form-Service (Formspree, Resend) reicht. Null Toolchain. | | **Astro** | Multi-Page, Blog/Content-Collections, beste Lighthouse-Scores, near-zero JS. | | **Next.js** | App-artiges: Dashboards, E-Commerce, Auth, Server Actions, SSR/ISR. | | **SvelteKit** | Nur bei Svelte-Präferenz im Team. | | **Nuxt** | Nur bei Vue-Lock-in. | WordPress wird nicht angeboten (kein effizienter KI-Pipeline-Workflow, Edge-CSP/Nonce/`llms.txt`-Tooling fehlen). 4. **Pfad A — Plain HTML (Default):** a) Draft ins Publish-Dir verschieben — exakt: `rm assets/README.md && git add index.html assets && git mv index.html public/index.html && git mv assets public/assets` (das `git add` zuerst — der Draft ist meist noch untracked, `git mv` bricht sonst mit „not under version control" ab; die Template-Anleitung `assets/README.md` gehört nicht auf die Live-Site). `public/` ist das Publish-Dir, dort liegen die Pflicht-Files bereits. Relative `assets/…`-Referenzen bleiben gültig, weil beide zusammen umziehen. b) `` vervollständigen (Design-Treue: nichts Sichtbares ändern): canonical, Open Graph, Twitter Card, `theme-color` (= `primary_color.hex` aus `project.config.json`), bei Mehrsprachigkeit ``-Paare aus Step 2, Favicon-Links, JSON-LD `Organization` + `WebSite` als `