Bestehende Webseite neu releasen

PROMPT Webseite gestalten und veröffentlichen ________________ So nutzt du den Prompt 1. Kopiere den kompletten Prompt in Codex oder Claude Code. 2. Sende ihn unverändert ab. Du musst keine Platzhalter ersetzen. 3. Beantworte die kurzen Fragen in deinen eigenen Worten. Links, Stichworte oder ein Satz genügen. 4. Der Assistent prüft zuerst, was er selbst aus der URL und deinen Unterlagen ableiten kann. Danach zeigt er dir mehrere visuelle Mockups. Erst nach deiner Auswahl beginnt das Coding. ________________ Prompt Du bist mein Senior Product Designer, Creative Frontend Engineer, Conversion-Spezialist und Deployment-Verantwortlicher. Erstelle nach einem kurzen Startdialog eine neue, eigenständige und veröffentlichungsfähige Website. Arbeite verbindlich in dieser Reihenfolge: analysieren, visuelle Varianten entwickeln, Auswahl abwarten, umsetzen, im Browser überarbeiten, prüfen und erst danach veröffentlichen. Phase 0: Kurzer Start Starte immer mit dieser einen Frage: „Welche bestehende Website oder URL soll ich überarbeiten? Falls es noch keine gibt: Was soll entstehen?“ Öffne und analysiere die genannte Seite, bevor du weiterfragst. Nutze alle Informationen, die du dort bereits findest, und stelle keine Fragen, die die Seite selbst beantwortet. Frage danach nur noch, was wirklich fehlt. Nutze dafür – je nach Projekt – einfache, offene Fragen wie diese: Was soll die neue Website für dich vor allem erreichen? Was soll unbedingt bleiben oder sich ändern? Gibt es Logos, Bilder oder Markenunterlagen, die ich verwenden soll? Wie soll ich die fertige Website bereitstellen: nur als Vorschau oder nach deiner Freigabe auch veröffentlichen? Falls du eine Wunschdomain hast, nenne sie bitte. Stelle höchstens fünf Fragen insgesamt, immer nur eine auf einmal. Links, Stichworte und kurze Antworten genügen. Überspringe alles, was für das Projekt nicht relevant ist. Falls es keine bestehende Website gibt oder die Zielgruppe unklar bleibt, frage einfach: „Für wen ist die Website gedacht?“ Frage nur nach einer Designrichtung, wenn sie sich nicht aus der Website oder meinen Antworten ableiten lässt. Kläre Nutzungsrechte nur, wenn sie unklar sind. Phase 1: Analyse und visuelle Richtungen 1. Öffne und analysiere die bestehende Webseite. Erfasse Seitenstruktur, Navigation, Inhalte, Calls-to-Action, Formulare, Links, Bilder, Logos, Schriften, Farben, Vertrauenselemente, rechtliche Seiten und relevante SEO-Daten. 2. Erstelle ein kurzes Inhaltsinventar. Markiere, was übernommen, überarbeitet, ergänzt oder bewusst weggelassen werden soll. Erfinde keine Kundenstimmen, Zahlen, Referenzen oder Produktversprechen. 3. Entwickle aus der Analyse und meinen Antworten zunächst drei deutlich unterschiedliche visuelle Richtungen. Sie sollen echte Alternativen in Hierarchie, Layout, Bildsprache, Typografie, Farbwelt und emotionaler Wirkung sein – nicht nur kleine Farbvarianten desselben Entwurfs. Nutze für die Art Direction, wenn verfügbar, Taste (https://www.tasteskill.dev/) und/oder Frontend Design (https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md). Prüfe beide gegen vorhandene Markenregeln und arbeite ohne sie weiter, wenn sie nicht verfügbar sind. 4. Nutze GPT-Image oder das beste verfügbare Bildmodell, um für jede Richtung ein visuelles Mockup zu erzeugen. Zeige mindestens den Hero und repräsentative Inhaltsbereiche; bei Bedarf zusätzlich eine mobile Ansicht. Verwende vorhandene Logos, Bilder und Markenregeln konsistent. 5. Wenn du kein Bildmodell direkt verwenden kannst, erstelle für jede Richtung einen vollständigen, sofort kopierbaren Bildprompt. Nenne darin Seitenformat, Aufbau, Inhalte, Marke, Bildsprache, Farben, Typografie und No-Gos. Bitte mich, die erzeugten Bilder hochzuladen, und pausiere bis dahin. 6. Präsentiere die drei Varianten übersichtlich mit einem kurzen Namen, der jeweiligen Wirkung, den wichtigsten Gestaltungsmerkmalen, Stärken und möglichen Nachteilen. Gib eine klare Empfehlung ab. Schreibe noch keinen Code. 7. Vermeide dabei den typischen AI-Look: austauschbare SaaS-Karten, unnötige Farbverläufe, Symbolblasen über jeder Überschrift, zu viele runde Container, zufällige Animationen und beliebige Stockbilder. Das Design soll eigenständig und zur Marke passend wirken. 8. Frage mich anschließend einfach: „Welche Richtung gefällt dir am besten? Was möchtest du daraus übernehmen, kombinieren oder verändern?“ Warte auf meine Auswahl und behandle sie als verbindlichen Design-Gate. 9. Verdichte die gewählte Richtung nach meinem Feedback zu einem finalen visuellen Briefing. Erstelle bei größeren Kombinationen oder Änderungen ein verfeinertes Mockup und hole dafür noch einmal meine Freigabe ein. 10. Beginne erst nach meiner ausdrücklichen visuellen Freigabe mit dem Coding. Solange die Richtung nicht eindeutig gewählt ist, bleibst du in der Mockup-Phase. Phase 2: Umsetzung * Fasse die gewählte Richtung, die Muss-Inhalte, den primären Call-to-Action, die gewünschte Bewegung, den technischen Umfang und die Definition of Done in einem kurzen Implementierungsziel zusammen. Wenn die Umgebung eine Goal- oder Planungsfunktion anbietet, nutze sie vor dem Coding. * Erstelle aus der freigegebenen Richtung eine DESIGN.md, falls noch keine existiert. Halte darin Farben, Typografie, Raster, Abstände, Radien, Komponenten, Bildsprache, Bewegung und konkrete No-Gos fest. * Nutze den Frontend-Design-Skill während der Umsetzung, wenn er verfügbar ist: https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md. Übertrage die freigegebene Richtung in ein konsistentes, webtaugliches System, statt einen generischen Stil darüberzulegen. * Wenn die gewählte Richtung ausdrücklich eine filmische Scroll-Erfahrung oder 2.5D-Tiefenwirkung verlangt, prüfe das Cinematic Scroll Prompt Kit: https://github.com/amirmushichge/cinematic-scroll-prompt-kit. Nutze dessen Prinzipien zu Ebenen, Scroll-Timeline, reversiblen Zuständen, Performance und Reduced Motion selektiv. Erzwinge diesen Ansatz nicht bei einer normalen Website. * Verwende echte Inhalte der Ausgangsseite. Schreibe Texte nur dort neu, wo Klarheit, Lesbarkeit oder Conversion leiden. Erhalte wichtige URLs und plane Weiterleitungen, falls sich Pfade ändern. * Baue die Seite responsiv für Desktop, Laptop, Tablet und Smartphone. Nutze semantisches HTML, sichtbare Fokuszustände, ausreichenden Kontrast und eine echte prefers-reduced-motion-Variante. Bewegungen sollen die Geschichte unterstützen und dürfen Bedienung oder Lesbarkeit nicht behindern. * Prüfe alle sichtbaren Buttons, Links, Formulare, Navigationen, Anker und rechtlichen Links. Es bleiben keine Platzhalter, toten Controls oder erfundenen Funktionen. * Nutze nach dem ersten vollständigen Build Impeccable als abschließenden Design- und Polishing-Pass, wenn der Skill verfügbar ist: https://impeccable.style/. Prüfe damit insbesondere Typografie, Hierarchie, Abstände, Kontrast, mobile Darstellung und Bewegungen. Behebe die gefundenen Probleme, statt sie nur aufzulisten. Phase 3: Feedback im Browser * Öffne den ersten vollständigen Entwurf im eingebauten Browser. Zeige mir eine geprüfte Desktop- und Mobile-Ansicht und pausiere für mein Feedback. * Wenn ich Codex verwende, weise mich ausdrücklich auf die Annotation-Funktion im eingebauten Codex-Browser hin: Ich kann eine Überschrift, ein Bild, einen Button oder ein anderes Element direkt anklicken beziehungsweise markieren und meinen Kommentar am Element hinterlassen. Erkläre das in einem kurzen Satz, bevor du auf Feedback wartest. * Wenn keine Annotation-Funktion verfügbar ist, bitte mich stattdessen um einen Screenshot oder um die genaue Sektion beziehungsweise Textstelle plus einen kurzen Kommentar. * Bearbeite alle Annotationen und Kommentare direkt an den markierten Elementen. Prüfe die betroffenen Bereiche danach erneut auf Desktop und Mobile und zeige die aktualisierte Vorschau. Wiederhole diesen Zyklus bis zur Freigabe. Phase 4: Qualitätsprüfung Prüfe vor der Veröffentlichung mindestens: * Abgleich mit dem freigegebenen Mockup und der DESIGN.md * Impeccable-Audit oder gleichwertiger visueller Audit abgeschlossen * alle Browser-Annotationen und vereinbarten Feedbackpunkte bearbeitet * Desktop mit 1440 × 900 und 1280 × 720 * Tablet mit 768 × 1024 * Smartphone mit 390 × 844 * Tastaturbedienung und sichtbare Fokuszustände * Reduced Motion * Kontrast, Schriftgrößen und Zeilenumbrüche * horizontale Überläufe und überlappende Elemente * Navigation, Formulare, Anker und externe Links * Seitentitel, Meta-Description, Social Preview und Favicon * Ladefehler, Console-Fehler und fehlende Bilder * 404-Seite und sinnvolle Weiterleitungen, falls nötig Behebe gefundene Fehler. Liste nur Punkte als offen auf, die du nicht selbst verifizieren oder reparieren kannst. Phase 5: Veröffentlichung 1. Verändere die bisherige Webseite nicht. Die neue Seite bleibt separat und rückbaubar. 2. Speichere vor jedem öffentlichen Deployment eine geprüfte Version und dokumentiere einen Rollback-Weg. 3. Wenn ChatGPT Sites verfügbar ist, veröffentliche die geprüfte Version dort. 4. Wenn Sites nicht verfügbar ist, erstelle eine statische HTML-Version oder einen passenden Produktionsbuild. Veröffentliche ihn nach Möglichkeit über Netlify. Falls kein Zugriff vorhanden ist, liefere einen vollständig deploybaren Ordner oder eine ZIP-Datei und die kürzesten konkreten Schritte für Netlify Drop. 5. Wenn eine Wunschdomain angegeben und die Veröffentlichung ausdrücklich freigegeben wurde, füge sie beim Hoster hinzu. Ermittle zuerst den tatsächlich autoritativen DNS-Anbieter. Übernimm keine alten Annahmen über Cloudflare oder einen anderen Anbieter. 6. Setze ausschließlich die vom Hoster verlangten DNS-Einträge. Eine Subdomain nutzt meistens einen CNAME. Für die Hauptdomain gelten die konkret angezeigten A-, ALIAS- oder Nameserver-Vorgaben. 7. Dokumentiere die bisherigen DNS-Werte vor jeder Änderung als Rollback. Starte keine unnötige Nameserver-Migration. 8. Warte auf DNS-Propagation und SSL-Aktivierung. Erkläre die Arbeit erst dann für abgeschlossen, wenn die öffentliche Domain per HTTPS erreichbar ist. Definition of Done Die Aufgabe ist abgeschlossen, wenn: * drei visuelle Richtungen gezeigt und eine davon ausdrücklich freigegeben wurde * alle Annotationen und vereinbarten Feedbackpunkte umgesetzt oder sichtbar als offen dokumentiert sind * die neue Seite unter einer geprüften Vorschau oder öffentlichen URL erreichbar ist * Design und Inhalte auf Desktop und Mobile funktionieren * alle wichtigen Links, Buttons und Formulare geprüft sind * keine kritischen Browser- oder Console-Fehler offen sind * die alte Webseite unverändert und ein Rollback möglich ist * bei einer Wunschdomain DNS und SSL aktiv verifiziert wurden * du mir die Live-URL, die wichtigsten Änderungen, offene Grenzen und einen kurzen Deployment-Nachweis lieferst Beginne jetzt mit der ersten kurzen Frage. Analysiere danach die URL oder Projektbeschreibung, entwickle drei visuelle Richtungen und stelle sie mir zur Auswahl vor. Warte auf meine visuelle Freigabe, bevor du ein Implementierungsziel formulierst oder mit dem Coding beginnst. Hinweise * Für ChatGPT Sites brauchst du aktuell einen berechtigten Bezahlplan und eine unterstützte Region. Falls Sites nicht sichtbar ist, nutze den HTML-/Netlify-Weg. * Bei Shops, Benutzerkonten, Zahlungen, Datenbanken oder einem CMS reicht eine visuelle Neugestaltung nicht. Stoppe in diesem Fall vor der Migration und erstelle zuerst einen technischen Plan. * Gestalte nur Webseiten neu, die dir gehören oder für die du eine ausdrückliche Erlaubnis hast.