Website-Upgrade

Was macht Website-Upgrade?

Eine Methode, um eine Website, die zusammengewürfelt wirkt, in eine zu verwandeln, auf die der Besitzer stolz ist. Sie wurde aus echten Upgrades destilliert, die ausgeliefert wurden und von den Besitzern und ihren Teams hoch bewertet wurden: die Marketingseite einer mobilen App, die Seite eines B2B-Cloud-Unternehmens, die zwei vollständige Designrichtungen durchlief, und ein Help Center, das von Grund auf neu aufgebaut wurde. Nutze die Methode, Rezepte und Fallstricke wieder. Verwende niemals ein Aussehen wieder: Jede Seite erhält ihre Richtung aus ihrer eigenen Marke, ihrem Produkt und ihrer Zielgruppe.

Was "fertig" bedeutet

Das Upgrade ist abgeschlossen, wenn alle diese Punkte erfüllt sind, und nicht früher:

• Jede Behauptung auf der Seite führt zu einer Quelle, die du benennen kannst: Produktcode, Rechtstexte, das Abrechnungssystem oder die schriftliche Antwort des Besitzers.
• Das Design stammt aus dem eigenen Material der Marke und seine Idee besteht den Wettbewerbertest (direction.md).
• Ein oder zwei charakteristische Momente, die der Besucher tut oder sieht; alles andere ist diszipliniert.
• Nichts braucht Bewegung, um gesehen zu werden. Bei reduzierter Bewegung werden die Endzustände angezeigt.
• Es wurde in einem echten Browser bei 1440, 1920×710, 390 und 320 px geprüft, in jedem Theme, mit reduzierter Bewegung, auf einem Produktions-Build.
• Deine schriftliche Kritik bewertet es mit 9/10 oder höher, oder dein Bericht sagt klar, wo es hinterherhinkt (critique.md).
• Es landet als PRs, die das Team überprüfen kann, mit einem kurzen Update, das sie einfügen können.

Grundregeln

1. Wahrheit vor Design. Jedes Feature, jede Zahl, jeder Preis, jedes Verfügbarkeitsdatum und jedes soziale Proof-Element führt zu einer Quelle. Die eigenen Onboarding- und Paywall-Texte des Produkts versprechen oft zu viel: Überprüfe sie im Code. "Unbekannt" ist eine gültige Antwort: Mach das Feld optional und frage nach, fülle es niemals mit einer plausiblen Zahl. Entferne erfundenes Proof.
2. Die Marke bestimmt das Aussehen. Leite Palette, Schriftart und das charakteristische Element aus dem eigenen Material der Marke ab: Logo, Name, Produkt-UI, Videos, Ort. Ein Element, das wie generiert wirkt (tells.md), ist nur erlaubt, wenn das Markenmaterial oder der Besitzer es dort platziert und der Richtungsvertrag es benennt.
3. Das Produkt ist der Held. Echte UI und echte Artefakte schlagen Icons, Stock-3D und Abstraktionen. Eine Demo sieht aus wie das Original: eine echte A4-Rechnung, eine echte gerenderte Vorlage, der echte Katalog.
4. Eine Website, keine Diashow. Vermeide Stapel von zentrierten Überschrift-plus-Bild-Blöcken, die jeweils einblenden. Verwende Komposition, Pinned-Scroll-Geschichten, geschichtete Tiefe, interaktive Demos und zustandsgesteuerte Bewegung.
5. Verstecke niemals Inhalte hinter Bewegung. Eine Einblendung, die nie ausgelöst wird, hinterlässt eine leere Seite. Respektiere prefers-reduced-motion, indem du Endzustände anzeigst.
6. Besitzer im Loop, nicht im Weg. Zeige die Richtung vor dem vollständigen Bau. Mache zuerst die Startseite und weite sie auf die anderen Seiten aus, sobald sie genehmigt ist. Frage jede offene Frage einmal, mit Optionen, und baue weiter darum herum.
7. Konfiguration enthält Werte. Umgebungsvariablen tragen eine URL, eine ID oder einen Token, niemals Ein/Aus-Schalter oder hartcodierte Konstanten. Leite abhängige Werte daraus ab. Committe nur .env.example.
8. Folge dem Ziel-Repository. Lies dessen README, CONTRIBUTING, AGENTS.md und commitlint-Konfiguration. Verwende seinen Paketmanager. Gleiche seine Framework-Versionen ab (Next 14 vs. 16, Tailwind 3 vs. 4, React 18 vs. 19).
9. Geheimnisse und Interna bleiben draußen. Gib niemals einen Token aus, den der Besitzer einfügt, committe oder echo ihn. Öffentliche Commits und PRs enthalten keine Kundennamen, privaten Preise oder ungepatchte Sicherheitslücken.
10. Bezeichne es niemals als fertig unter 9/10. Bewerte die Arbeit anhand von Screenshots, bevor du sie meldest. Eine Selbsteinschätzung von 6 oder 7, die nach "fertig" angeboten wird, ist ein Zeichen für übersprungene Arbeit.

Wähle zuerst den Modus

Was der Besucher tun möchte, entscheidet, wie weit das Design gehen darf. Ein Projekt kann mehrere Oberflächen in verschiedenen Modi enthalten; gib jeder ihren eigenen.

Modus	Oberflächen	Der Besucher	Was führt	Lese
Überzeugen	Produkt, Marketing, Unternehmen, Kampagne, Preise	entscheidet und handelt	das Produkt, das sich selbst beweist; eine echte Aktion auf dem ersten Bildschirm	building-blocks.md
Lesen	Help Center, Docs, Changelog, Blog	versteht etwas	die Frage des Lesers; die Marke besitzt den Rahmen, niemals die Lesespalte	read-mode.md
Erleben	Portfolio, Showcase, Galerie	erkundet die Arbeit	die Arbeit selbst, vom ersten Viewport aus	building-blocks.md § Experience

Die Marketingseite eines Produkts ist Überzeugen, auch wenn sie die App zeigt. Sein Help Center ist Lesen, auch wenn es schön ist.

Workflow

Arbeite die Phasen der Reihe nach durch. Lese jede Referenz, wenn du ihre Phase erreichst, nicht früher.

Phase	Tun	Lese
0. Kickoff	Erstelle einen Branch vom Default-Branch, starte den Dev-Server (notiere den echten Port), erstelle den "Vorher"-Satz für den Bericht	verification.md § 1
1. Discovery	Auditiere die Website, finde die Wahrheitsquellen, schreibe das Anspruchsverzeichnis und das Themeninventar, sammle Markenmaterial, melde die Ergebnisse	discovery.md
2. Richtung	Finde die Idee und bestehe den Wettbewerbertest, setze Palette und Schriftart, wähle die charakteristischen Momente, schreibe den Richtungsvertrag, zeige ihn	direction.md, tells.md
3. Statisch bauen	Tokens, der Held, jeder Akt mit echten Inhalten, die inneren Seiten. Bewegung im Kopf ausschalten	building-blocks.md, media.md, read-mode.md
4. Bewegung und Charakteristisches	Eine choreografierte Einleitung, zustandsgesteuerte Momente, das Charakteristische. 3D nur, wenn es seinen Platz verdient	motion.md, three-d.md
5. Kontakt und Konversion	Geteilte Validierung, das Formular, eine Edge-Route, eine gestaltete Benachrichtigungs-E-Mail, Buchung oder Lead-Vorausfüllung	contact-email.md
6. SEO und Standards	Server-Rendering, Metadaten, Social Cards, strukturierte Daten, Crawler-Dateien, Header. Eigener gestapelter PR	seo-standards.md
7. Verifizieren und kritisieren	Browser-Schleifen bei jeder Breite und jedem Theme, die skriptgesteuerten Prüfungen, ein Produktions-Build, dann die bewertete Kritik, bis zu drei Runden	verification.md, critique.md
8. Ausliefern	Commits, PRs, das Team-Update, der Vorher/Nachher-Bericht, DESIGN.md, Gedächtnisnotizen	delivery.md

Überprüfe gotchas.md, wenn etwas seltsam wirkt. Lese feedback.md, wenn der Besitzer reagiert: Es übersetzt, was Besitzer sagen ("nicht genug Würze", "Farben aus dem Gleichgewicht", "billige Kopie") in das, was geändert werden muss.

Wenn ein Designrichtungs-Skill installiert ist (frontend-design, impeccable, taste-skill), lade ihn in Phase 2 für zusätzliche Reichweite. Dieser Skill funktioniert auch ohne ihn.

Stack. Die Rezepte wurden mit Next.js, React, Tailwind und GSAP entwickelt, gehostet auf Cloudflare Pages, und die Snippets zeigen diesen Stack. Die Methode, die Prüfungen und die meisten Skripte hängen nicht davon ab: Verwende auf Astro, SvelteKit, Nuxt oder einfachem HTML die Regel und übersetze das Rezept in das Ziel-Framework und seine Versionen.

Skripte

Aus dem Stammverzeichnis des Ziel-Repositorys ausführen. <skill> ist der Ordner dieses Skills.

• node <skill>/scripts/slop-scan.mjs [dir] [--json] [--strict] [--allow <rules>] [--list-rules]: Durchsucht Quellen nach Anzeichen für generierte Websites, erfundene Beweise, Genre-Texte, tote Links, Geheimnisse und bekannte Fallstricke. Beendet sich mit Exit-Code 1 bei Fehlern (oder bei Warnungen mit --strict). Nenne eine berechtigte Ausnahme mit einem site-upgrade-allow: <rule> <reason> Kommentar (er deckt die Zeilen darunter bis zur nächsten leeren Zeile ab) oder einer .site-upgrade-allow-Datei im Stammverzeichnis des Repositorys. Node 18+, keine Abhängigkeiten.
• <skill>/scripts/ssr-audit.sh <base-url> [path]...: Pro Seite (jede Sitemap-Seite, wenn keine Pfade angegeben sind): Status, <h1>-Anzahl, JSON-LD-Blöcke, Kanonisch, Social Image, Client-Rendering-Bailouts und der Titel; dann Sicherheits-Header und Crawler-Dateien. Beendet sich mit Exit-Code 1, wenn eine Seite fehlschlägt. Führe es gegen einen Produktionsserver aus.
• <skill>/scripts/video-prep.sh <source> <out-dir> [name] [poster-second]: Gibt Szenenschnitte als Kapitelkandidaten aus und schreibt stille Web-Encodes mit Keyframes bei jedem Schnitt, ein Poster und einen quadratischen Vorschauclip. Fällt auf das imageio_ffmpeg-Binary zurück.
• <skill>/scripts/playwright/*.js: Für das Playwright MCP Tool browser_run_code_unsafe. Das MCP liest nur Dateien innerhalb des Arbeitsbereichs, also kopiere sie zuerst (mkdir -p .playwright-mcp && cp <skill>/scripts/playwright/*.js .playwright-mcp/) und übergib filename: ".playwright-mcp/<name>.js". Halte .playwright-mcp/ aus git heraus.
  • reveal-scroll.js scrollt, sodass jede Einblendung vor einem Screenshot ausgelöst wird, und listet Text auf, der danach noch verborgen ist.
  • page-audit.js misst den Frame: eine <h1>, Überschriften über zwei Zeilen, kleiner Text, kleine Touch-Ziele, unbenannte Steuerelemente, Bilder ohne alt, unbetitelte Abschnitte und ungetunte Browseroberflächen.
  • overflow.js findet, was horizontalen Scroll von 320 bis 1440 px verursacht, und nennt die äußersten Übeltäter.
  • console-scan.js besucht jede Sitemap-URL und meldet Konsolenfehler, Seitenfehler, fehlgeschlagene Anfragen, 4xx/5xx und CSP-Verstöße.

Assets und Vorlagen

In das Ziel-Repository oder das Scratchpad kopieren und anpassen:

• assets/render-email.ts: Rendert React-Email-Vorlagen in HTML ohne react-dom/server, für Edge-Routen.
• assets/JsonLd.tsx: Ein JSON-LD-Script-Tag, das sicher eingebettet werden kann.
• assets/ScrollTriggerRefresh.tsx: Misst GSAP-Scroll-Trigger neu, wenn sich die Seitenhöhe ändert.
• assets/templates/claims-ledger.md: Ausgeliefert, nicht ausgeliefert, unbekannt und Zahlen, jeweils mit einer Quelle (Phase 1).
• assets/templates/direction-contract.md: Die These, Idee, eigene Welt, erster Viewport, Charakteristisches und Markenausnahmen (Phase 2).
• assets/templates/critique-round.md: Die bewertete Kritik, ein Block pro Runde (Phase 7).
• assets/templates/DESIGN.md: Das gebaute Designsystem, am Ende geschrieben, damit spätere Agenten der Marke treu bleiben (Phase 8).
• assets/templates/team-update.md: Das Kopier-Einfüge-Update für den Team-Chat (Phase 8).

Besitzer-Checkpoints

Bestätige diese, bevor du etwas veröffentlichst, das davon abhängt. Frage einmal mit Optionen; halte den Bau nicht auf:

• Launch-Status und Store-Verfügbarkeit, aus dem Live-Store-Eintrag statt aus Umgebungsflags
• Preise und Pläne, und ihre Quelle
• Zahlen, die noch niemand belegen kann (Uptime, Rechenzentren, Kundenzahlen): lass sie weg, bis jemand sie freigibt
• Das Kontakt-Postfach und ein Postfach, das der Besitzer für Tests lesen kann
• Noch nicht veröffentlichte Artikel in Listen, Katalogen oder Karussells
• Rechtliche Identität, Adresse und Telefonnummer, identisch überall, wo sie erscheinen
• Dritte, die Besucherdaten erhalten würden (Analytics, Embeds, Schriften, E-Mail), und die dazugehörigen Datenschutzrichtlinien
• Die Quelldateien für Maskottchen, 3D-Modelle oder Videos, bevor du eines neu erstellst
• Jeden Produktionsschritt: Domains, DNS, Deploy-Einstellungen, Migrationen. Der Besitzer führt sie aus oder genehmigt sie