tereza-kohutova/website-builder-agent

/website-build – eine Website richtig erstellen

Destilliert aus der Erstellung, Übersetzung in fünf Sprachen und dem Launch einer echten Marketing-Site für ein Mobile-App-Unternehmen. Jede Regel in den Referenzen basiert auf etwas, das tatsächlich schiefgelaufen ist oder Zeit gekostet hat. Diese Datei ist die Route; die Referenzen enthalten die Details.

Dies öffnen	wenn Sie im Begriff sind, …
references/01-architecture-pipeline-deploy.md	Ordner und Build-Kette aufzusetzen, Bibliotheken auszuwählen, einen Build-Schritt hinzuzufügen, zu deployen, Hosting/CSP/Redirects zu konfigurieren, Backups einzurichten
references/02-design-typography-mockups.md	Tokens und Typografie zu definieren, Schriftarten und Zeilenumbrüche zu handhaben, Telefon-Mockups zu erstellen, Symbole/Logos zu platzieren, Komponenten und Motion zu bauen
references/03-i18n-seo-geo.md	zu übersetzen, einen Markt hinzuzufügen, Meta/JSON-LD zu schreiben, Sitemap/Robots/llms.txt zu erstellen, GEO umzusetzen, die Performance zu optimieren, Analytics einzurichten
references/04-qa-devices-modes.md	etwas zu testen: die Prüfumgebung, Geräte-/Breiten-/Modi-Matrix, In-App-Browser, A11y, Consent-Flows, adversarielle und Live-QA
references/05-process-content-legal-launch.md	das Projekt zu leiten: Rollen, Freigaben, Feedback-Loop, IA, Fakten, rechtliche Seiten, Consent, Go-Live
scripts/qa/	die QA-Prüfumgebung auszuführen (rohes CDP, nichts zu installieren) und die WebKit/In-App-Browser-Matrix (Playwright)
scripts/backup/snapshot.py	eine Datei vor einer Bearbeitung zu versionieren, Versionen aufzulisten, wiederherzustellen; oder als PreToolUse-Hook zu installieren

1. Phasen (in Reihenfolge)

1. Briefing (05): Ziel und CTA, Märkte/Sprachen, Seitenliste, Faktenblatt mit Quellen, Marken-Assets, juristische Person pro Markt, Tracking und Consent, Hosting und wer den Produktions-Merge durchführt.
2. Skelett (01): ein Quellordner, Meistersprache handschriftlich bearbeitet, gemeinsames Chrome durch idempotente markierte Blöcke injiziert, Builder für alles andere, _dist (optimiert) und _deploy (Hosting) als unidirektional generierte Kopien, ein Build-Lock, Git ab der ersten Datei.
3. Design-System (02): Tokens je Grundfläche, clamp() mit rem plus kleinem vw-Gefälle, echte width/height auf Bildern, absolutes srcset, selbst gehostete Subset-Schriftarten mit allen diakritischen Zeichen, ein Motion-System pro Element, Reduzierte-Bewegung-sicher und JS-aus-sicher.
4. Bildmaterial (02): echte Produktbildschirme, pro Markt aus dem Design-Tool exportiert (3x PNG -> WebP). Niemals Text auf Rasterbilder patchen. Logos in der Datei fixieren, nicht mit Überblendungsmodi.
5. Texte und Fakten (05): eine Faktenliste, ein Begriff pro Konzept, juristische Person pro Markt, formelle/informelle Anrede je Zielgruppe.
6. i18n (03): Wörterbuch plus exakt-Text-Übereinstimmungs-Builder, Laufzeit-Typografie, hreflang (+ x-default), pro-Markt-Datentabellen, Sprach-QA.
7. SEO (03): ein idempotenter Post-Processor zwischen Markierungen, ein JSON-LD @graph pro Seite, Sitemap mit echtem lastmod, Robots (KI-Crawler absichtlich erlaubt), eine echte 404.
8. GEO (03): llms.txt (+ vollständig), facts.json, konsistente Entitätsdaten auf und abseits der Site, Text, der ohne JS-Extraktion überlebt, dann das GEO-Testprotokoll, einschließlich Abfragen der echten KI-Engines.
9. Performance (03): Inline-Assets -> gehashte Dateien, WebP, lazy below the fold, selbst gehostete Bibliotheken, verzögerter Tag-Manager, Lighthouse auf mobil und Desktop.
10. Consent, Analytics, Rechtliches (03, 05): Consent-Leiste, Consent Mode v2 (entscheiden ob basic oder advanced bewusst), Tags nur nach Consent, jeder Tracker in der Datenschutzerklärung aufgelistet, erforderliche rechtliche Seiten, CSP zunächst in Report-Only.
11. QA (04): die vollständige Seite-x-Breite-Matrix, Modi, WebKit und soziale In-App-Browser, Tastatur/Fokus, Consent-Szenarien, Links/Anker/Sprachumschaltung, adversarielle Prüfung, dann echte Telefone.
12. Go-Live (05, 01): alte Site und DNS sichern, jede alte URL umleiten (Store-Listen-Pfade exakt beibehalten), Vorschau gegen Baseline testen, umschalten, Live-Checkliste ausführen.

2. Harte Regeln

1. Niemals generierte Dateien handschriftlich bearbeiten (Sprachversionen, _dist, _deploy). Quelle oder Builder bearbeiten, dann neu bauen.
2. Niemals  /<br> handschriftlich in Texte einfügen, die von Übersetzungs-Buildern per exaktem Textabgleich gefunden werden. Zeilenumbrüche werden zur Laufzeit gemacht.
3. Ein Session baut und publiziert. Der Build-Lock prüft seinen Besitzer; warten, wenn er gehalten wird, niemals löschen. Freien Speicher vor einem vollständigen Build prüfen.
4. Eine Seite, die rendert, beweist nichts: jedes Inline-Skript syntaxprüfen, auf Steuerzeichen scannen, die gesamte Matrix durchlaufen.
5. Jede Feedback-Runde wird zu einem idempotenten Durchlauf im Build, der fehlschlägt, wenn der Zieltext verschwindet.
6. Der Produktions-Merge wird vom Eigentümer durchgeführt. Hosting-, CSP-, Consent-, Tracking- und Rechtsänderungen gehen zuerst auf einem Seitenzweig an den technischen Prüfer.
7. Fakten leben in einer Liste. Eine Zahl, die zwischen zwei Seiten abweicht, ist ein Vertrauens- und ein GEO-Fehler.
8. Backups: git pro Site mit einem Commit in jeder Phase; scripts/backup/snapshot.py (oder sein Hook) für alles zwischen Commits; alte Site und DNS vor Go-Live gesichert.
9. Overlays, Sticky-Bars und Menü auf der gebauten, minifizierten Ausgabe erneut testen. Minifier können die Spezifität von Selektoren herabsetzen.
10. CSP und Consent in den In-App-Browsern testen, in denen Ihre Anzeigen landen, und auf Seiten, die Zustand enthalten (Tokens in URLs).

3. QA in einem Satz

Pfade sind relativ zu diesem Skill-Ordner. Zuerst node scripts/qa/jscheck.mjs site/_dist, dann node scripts/qa/audit.mjs <Ordner-oder-URL> mit QA_WIDTHS=1440x900,1280x800,1024x768,768x1024,430x932,390x844,360x780,320x700, dann anchors.mjs, modes.mjs, console-sweep.mjs, shots.mjs (Sehen Sie sich die Screenshots selbst an), und inapp.mjs für WebKit plus die Instagram/Facebook/TikTok-In-App-Browser. Jedes Skript folgt einem einheitlichen Exit-Code-Vertrag: 0 sauber, 1 Funde (einschließlich einer Seite, die nicht lädt), 2 falsche Verwendung, 3 konnte nicht ausgeführt werden (Chrome, axe-core oder Playwright fehlen). Checklisten: 04, Abschnitte „Vor Veröffentlichung“ und „Nach dem Deploy“.