robbertvanempel/wordpresstowebsite-community

WordPress zu Website-Community

Verwandle eine bestehende WordPress-Seite in eine wartbare, individuelle Website, ohne die Neugestaltung als leere Leinwand zu betrachten. Bewahre zuerst die Quelle, übersetze die gewünschte Gestaltungsrichtung in ein eigenes visuelles System, baue und beweise die Migrationsparität.

Passe dich der Sprache des Benutzers an. Wiederhole keine Fragen, die bereits in der Anfrage oder im verfügbaren Projektkontext beantwortet wurden.

Beginne mit der Aufnahme

Bevor du die Quelle durchsuchst, Dateien erstellst, ein Framework auswählst oder ein visuelles Design vorschlägst, lies references/intake.md und stelle eine kompakte Runde mit nur den unbeantworteten wesentlichen Fragen.

Die erste Runde muss mindestens Folgendes klären:

• die aktuelle WordPress-URL;
• den Migrationsumfang und eventuelle nicht-öffentliche Inhalte;
• den gewünschten Stil, direkt beschrieben und/oder durch Beispiel-URLs;
• das beabsichtigte Ergebnis und Ziel;
• erforderliche Funktionalität, Sprachen, Branding und Startbeschränkungen;
• Bestätigung, dass der Benutzer die bereitgestellten Inhalte und Assets migrieren darf.

Akzeptiere „entscheide du“ für Design- und Implementierungsentscheidungen. Eine Quell-URL, ein umsetzbarer Umfang und die Erlaubnis zur Nutzung des Quellmaterials können nicht erfunden werden. Bitte den Benutzer niemals, Passwörter, API-Schlüssel, Cookies, Datenbankanmeldedaten oder Wiederherstellungscodes in den Chat einzufügen. Fordere eine Exportdatei oder eine genehmigte sichere Zugriffsmethode nur an, wenn die öffentliche Erkennung nicht ausreicht.

Nachdem der Benutzer geantwortet hat, fasse das vereinbarte Briefing, die expliziten Standards, unbekannte Unbekannte und Ausschlüsse zusammen. Stelle eine Folgefrage nur, wenn eine Antwort die Erhaltung, Architektur, Kosten oder Bereitstellung wesentlich verändern würde.

Trenne Erkundung, Bau und Start

Behandle diese als separate Autorisierungsgrenzen:

1. Erkundung: Überprüfe öffentliche Seiten, APIs, Sitemaps, Feeds und bereitgestellte Exporte, ohne die Quellseite zu verändern.
2. Bau: Erstelle oder ändere das Zielprojekt, während die Quellseite verfügbar bleibt.
3. Start: Stelle bereit, ändere DNS, ersetze Hosting, füge Weiterleitungen hinzu oder stelle WordPress nur außer Betrieb, wenn der Benutzer diese Aktion ausdrücklich autorisiert.

Betrachte die Erlaubnis zur Analyse oder zum Bau nicht als Erlaubnis zur Veröffentlichung. Bevorzuge eine Staging- oder Vorschau-URL zur Überprüfung. Lösche oder deaktiviere die WordPress-Seite niemals, bis die neue Seite akzeptiert wurde und eine wiederherstellbare Sicherung existiert.

Bewahre die Quelle, bevor du sie transformierst

Lies references/preservation.md, bevor du Inhalte oder Medien sammelst.

Erstelle ein Quellinventar vor der Implementierung. Verwende die stärksten verfügbaren Quellen: einen WordPress-Export oder eine authentifizierte API, falls bereitgestellt, dann die öffentliche REST-API, WordPress-Sitemaps, normale Sitemaps oder Feeds und schließlich einen begrenzten HTML-Crawl. Kombiniere Quellen, wenn eine unvollständig ist.

Zeichne jedes im Umfang enthaltene Element und seinen Migrationsstatus auf. Erfasse Seiten, Beiträge, benutzerdefinierte Beitragstypen, Taxonomien, Autorenschaft, Daten, Slugs, interne Links, SEO-Felder, strukturierte Daten, Anhänge, vorgestellte Bilder, Inline-Medien, Alt-Text, Bildunterschriften, herunterladbare Dateien und erforderliche interaktive Funktionen.

Bewahre die ursprünglichen Medien-Bytes, wenn sie zugänglich und autorisiert sind. Zeichne die ursprüngliche URL, den Zielpfad, den MIME-Typ, Abmessungen (wo zutreffend), Byte-Größe, SHA-256-Hash, Referenzen, Alt-Text, Bildunterschrift und Ergebnis auf. Behaute niemals, dass ein öffentlicher Crawl Entwürfe, private Beiträge, unveröffentlichte Überarbeitungen, Formularübermittlungen, Benutzerkonten, Plugin-Einstellungen oder originale Mediendateien umfasst, die nicht öffentlich erreichbar waren.

Halte rohe Exporte, Datenbank-Dumps, Anmeldedaten und private Medien standardmäßig aus der Versionskontrolle heraus. Speichere Benutzerinhalte, Marken-Assets oder Anmeldedaten nicht in diesem installierten Skill-Ordner.

Übersetze Stil anstatt Identität zu klonen

Lies references/design-direction.md, wenn der Benutzer eine Beispiel-URL, Screenshots, Markenmaterial oder eine offene Stilanfrage bereitstellt.

Analysiere Referenzen in wiederverwendbare Eigenschaften wie Hierarchie, Abstände, Typografie-Rollen, Palettenverhalten, Bildbehandlung, Formen, Dichte, Bewegung und Navigationsmuster. Frage, was dem Benutzer gefällt oder nicht gefällt, wenn dies unklar ist. Erstelle eine kurze Zusammenfassung der Gestaltungsrichtung, bevor du kostenintensive visuelle Arbeiten durchführst.

Erstelle ein originelles Design. Kopiere nicht den Quellcode, Text, Logos, Illustrationen, proprietäre Assets oder das charakteristische Erscheinungsbild einer anderen Website ohne Erlaubnis. Eine Referenz-URL autorisiert die Analyse, nicht die Vervielfältigung. Bewahre bereitgestellte Logos und Marken-Assets genau so auf, es sei denn, der Benutzer autorisiert Änderungen.

Wähle die Architektur basierend auf den Anforderungen

Erzwinge keinen modischen Stack für das Projekt. Wähle basierend auf Bearbeitungsbedarf, Inhaltsvolumen, Interaktivität, Integrationen, Hosting, Wartbarkeit und dem technischen Komfort des Benutzers.

• Bevorzuge statische Generierung oder Server-Rendering für inhaltsreiche öffentliche Websites, bei denen SEO und Leistung wichtig sind.
• Füge ein CMS nur hinzu, wenn nicht-technische Bearbeitung erforderlich ist; erkläre, wer nach dem Start was bearbeiten wird.
• Bewahre nach Möglichkeit bestehende öffentliche Pfade. Erstelle andernfalls explizite permanente Weiterleitungen für jede geänderte URL im Umfang.
• Modelliere wiederholbare Inhalte als strukturierte Daten, anstatt sie in Seitenkomponenten einzufügen.
• Halte die Herkunft importierter Inhalte und Medien zum Quellinventar nachvollziehbar.
• Bewahre erforderliche Analysen, Zustimmung, Formulare, Suche, E-Commerce, Mitgliedschaften, Einbettungen und Integrationen nur, wenn sie im Umfang und testbar sind.

Übernimm nicht stillschweigend anfällige Plugins, Tracking-Skripte, veraltete Shortcodes oder WordPress-spezifisches Markup. Konvertiere nützliche Bedeutung und Verhalten und melde alles, was einen Ersatz oder eine manuelle Überprüfung erfordert.

Baue in Migrationsabschnitten

Implementiere zuerst einen repräsentativen Inhaltstyp oder eine Route, wenn das Projekt groß ist. Validiere das Inhaltsmodell, die Medienbehandlung, das Stilsystem und das responsive Verhalten, bevor du die Migration skalierst.

Halte eine Routenkarte und Inhalts-/Medienmanifeste aktuell, während die Arbeit voranschreitet. Zeichne für jedes übersprungene Element einen Grund auf, wie außerhalb-des-Umfangs, Duplikat, privat-nicht-verfügbar, defekt-an-Quelle oder erfordert-Benutzerentscheidung. Lass fehlende Elemente niemals aus dem Prüfpfad verschwinden.

Respektiere das bestehende Ziel-Repository, Framework, Konventionen und nicht zusammenhängende Benutzerarbeit. Überschreibe kein nicht leeres Projekt oder ersetze keine bestehende Implementierung ohne explizite Anweisung.

Überprüfe Parität und Qualität

Lies references/verification.md, bevor du die Migration als abgeschlossen bezeichnest.

Überprüfe die gebaute oder bereitgestellte Website anhand der Manifeste, nicht aus dem Gedächtnis. Beweise mindestens:

• jede im Umfang enthaltene Quell-URL wird durch eine Zielseite oder eine absichtliche Weiterleitung repräsentiert;
• Titel, sinnvoller Haupttext, Daten, Autoren, Taxonomie und SEO-Metadaten sind erhalten, wo erforderlich;
• jedes referenzierte lokale Asset wird als der erwartete Medientyp aufgelöst, nicht als HTML-Fallback mit Status 200;
• Bildabmessungen, Alt-Text, Bildunterschriften, Downloads, interne Links, kanonische URLs, Sitemap-Einträge und strukturierte Daten sind korrekt, wo zutreffend;
• bereichsbezogene Formulare, Suche, Analysen, Zustimmung, E-Commerce, Authentifizierung, Einbettungen und Integrationen funktionieren durchgängig;
• repräsentative mobile und Desktop-Seiten haben keine offensichtlichen Zugänglichkeits-, Überlauf-, Konsolen- oder Leistungsfehler.

Verwende Byte-Hashes, wenn die Anforderung darin besteht, Originaldateien zu erhalten. Verwende visuelle Überprüfung für Zuschnitte, responsives Art Direction, Layout und Transformationen, bei denen Byte-Gleichheit absichtlich unmöglich ist.

Melde nicht „nichts wurde verloren“, es sei denn, alle Inventarzeilen im Umfang haben ein verifiziertes Ziel oder eine akzeptierte Ausnahme. Unterscheide zwischen lokalen Bauprüfungen, Vorschau-Verifizierung, Produktions-Verifizierung und Elementen, auf die nicht zugegriffen werden konnte.

Liefere einen Migrationsbericht

Passe Dateinamen an das Zielprojekt an, stelle jedoch das Äquivalent von Folgendem bereit:

• migration-brief.md: Umfang, Gestaltungsrichtung, Architektur, Annahmen und Ausschlüsse;
• source-inventory.csv oder .json: Quellinhalts- und Routeninventar;
• media-manifest.csv oder .json: Quell-/Zielmedienzuordnung und Hashes;
• redirect-map.csv: alte URL, neue URL, Weiterleitungsstatus und Verifizierungsergebnis;
• der Quellcode und Inhalt der neuen Website;
• verification-report.md: Nachweise zu Parität, Browser, Funktionalität, SEO und Zugänglichkeit;
• handover.md: Bearbeitung, Bereitstellung, Rollback, Backups und verbleibende manuelle Arbeit.

Halte sensible Exporte außerhalb eines öffentlichen Repositories und verweise auf deren gesicherten Ort, ohne Geheimnisse preiszugeben.

Stopp-Bedingungen

Pausiere und erkläre die genaue Lücke, wenn:

• die Quell-URL oder der autorisierte Umfang unbekannt ist;
• Robots, Authentifizierung, Ratenbegrenzungen oder Hosting-Kontrollen eine sichere Erkundung verhindern;
• wesentliche private Inhalte in einem bereitgestellten Export nicht vorhanden sind;
• das angeforderte Design vom Kopieren von Assets oder einer Identität abhängt, die der Benutzer möglicherweise nicht verwenden darf;
• der Start Anmeldedaten, DNS-Änderungen, Käufe, destruktiven Ersatz oder andere nicht erteilte Befugnisse erfordert;
• Parität nicht aus der verfügbaren Quelle nachgewiesen werden kann.

Biete den kleinsten sicheren nächsten Schritt an. Tarnen einen unvollständigen Crawl, eine funktionierende Startseite oder einen erfolgreichen Bau nicht als abgeschlossene Migration.