AbhiDas-lab/Website-Builder-Skill

Websites überprüfen und erstellen, die richtig bleiben

Eine Website bleibt nicht einfach dadurch korrekt, dass sie einmal jemand überprüft hat. Sie bleibt korrekt, wenn jede Regel eine Prüfung ist, jede Prüfung an einem Ort läuft, der einen fehlerhaften Deploy stoppen kann, und jede Prüfung bereits fehlgeschlagen ist. Alles unten Dienende dient diesem Ziel.

Dies ist eine Methode, kein Markenleitfaden. Die eigenen Regeln einer Website (ihre Locale, Interpunktion, wie sie ihren Namen schreibt, Partner-Marken, was vertraulich ist, wie Kontaktdaten angezeigt werden) gehören in ein Hausprofil für dieses Projekt, normalerweise die CLAUDE.md. Lies das Hausprofil des Projekts, bevor du Texte überprüfst. Wenn es keines gibt, biete an, eines zu erstellen (Vorlage in references/templates.md).

Ein Hausprofil gehört zu einer einzigen Website. Übertrage nicht die Regeln, die Rechtsordnung, die Zeitzone oder die Marke eines anderen Projekts in dieses, nur weil sie zufällig in deinem Kontext sind. Frage nach der Locale, der Rechtsordnung (welches Datenschutzrecht gilt), der Zeitzone, in der Zeitpläne ausgeführt werden, und der Zielgruppe, oder lege dar, was du annimmst.

Zwei Modi teilen sich einen Kreislauf:

• Überprüfung: Auditiere eine Live-Website, einen Branch, eine Seite oder einen externen Auditbericht, den jemand geschickt hat.
• Erstellung: Starte eine neue Website oder füge einer bestehenden eine Seite, Funktion, CMS-Sammlung oder einen wiederkehrenden Inhaltstyp hinzu.

Der Kreislauf, für jede Änderung

1. Messe zuerst, an der erstellten Ausgabe, überall. Erstelle die Website und lies dist/ (oder die Live-Website), jede Seite, bei mehreren Breiten. Ein Bericht, der nur eine URL geprüft hat, übersieht die Seite, auf der das eigentliche Problem liegt. Behandle jeden externen Audit als eine Reihe von Hypothesen: In dem Projekt, aus dem diese Methode stammt, haben drei von vier „Muss“-Punkten eines Berichts die Messung nicht bestanden (er hat alt="" als fehlend gezählt, hat Karten-Markup für Anker aus zwei Navigationen verantwortlich gemacht und vorhandene strukturierte Daten als nicht vorhanden bezeichnet).

2. Klassifiziere, was du gefunden hast. Ein Fehler wird behoben. Eine redaktionelle Entscheidung (Text, Layout-Kompromisse, eine einzelne Karte in der letzten Zeile eines Rasters, welche Titelformulierung verwendet werden soll) geht mit gemessenen Optionen an den Eigentümer, nicht mit deiner Präferenz. Eine bewusste Nicht-Änderung wird mit ihrem Grund dokumentiert, damit der nächste Prüfer sie nicht wieder aufmacht. Lies den Code-Kommentar in der Nähe von etwas, das falsch aussieht, bevor du es änderst; der Grund steht oft dort.

3. Behebe an der Quelle der Wahrheit. Korrigiere niemals von Hand generierte Dateien. Korrekturen, die eine Neugenerierung überleben müssen, kommen in eine Regelschicht, die der Generator anwendet, und diese Schicht sollte einen Fehler werfen, wenn der Text, an dem sie verankert ist, verschwindet.

4. Füge eine Prüfung hinzu, die es gefangen hätte, im richtigen Gate (nächster Abschnitt), die die erstellte Ausgabe liest, nicht ein Test-Fixture. Füge dann eine Kontrolle hinzu: einen nahegelegenen Fall, der nicht auslösen darf.

5. Teste die Prüfung durch Bruch. Zerstöre das echte Ding (im Quellcode oder durch Mutation von dist/), führe die Prüfung aus, beobachte, wie sie mit einer nützlichen Nachricht fehlschlägt, stelle es wieder her, beobachte, wie sie besteht. Eine Prüfung, die nicht fehlschlagen kann, sieht genau so aus wie eine, die besteht. Wenn die Mutation sie nicht auslöst, bestätige zuerst, dass die Mutation tatsächlich das getroffen hat, was die Prüfung liest, und korrigiere dann die Prüfung. scripts/break-test.mjs erledigt den Mutieren-Ausführen-Wiederherstellen-Zyklus sicher.

6. Generiere abgeleitete Daten neu und lies das Diff. Bilddimensionstabellen, Sitemap-Daten, Suchindizes und Typdateien werden still und leise veraltet. Abweichungen, die du nicht verursacht hast, sind echte Abweichungen, kein Rauschen.

7. Liefere aus und beobachte, wie es landet. Finde heraus, was ein Push deployed, bevor du dich darauf verlässt (bei vielen Hosts ist ein Push auf einen beliebigen Branch die Produktion). Branche, merge, push, beobachte dann CI bis zum Ende und bestätige, dass die Live-Website die Änderung ausliefert. Melde keinen Erfolg von einem lokalen Build.

8. Dokumentiere es. Eine nummerierte Tabellenzeile: was geändert wurde, warum, welche Dateien, welche Prüfung hält es fest. Dokumentiere auch zurückgezogene Ergebnisse und deine eigenen Fehler. Format in references/templates.md.

Gates: Wo jede Prüfung lebt

Die meisten Teams nehmen an, dass CI einen fehlerhaften Deploy blockiert. Oft tut es das nicht: Der Host baut und deployed bei Push, während CI parallel läuft, und ein CMS-Speichern löst einen Deploy ohne CI aus. Entscheide für jede Regel, welches Gate sie benötigt, und schreibe das neben die Prüfung.

Gate	Blockiert den Deploy?	Hier einfügen
Build/Postbuild (läuft im Build des Hosts)	Ja	Alles, was niemals Besucher erreichen darf: durchgesickerte Geheimnisse oder personenbezogene Daten, verbotene Zeichensetzung oder Rechtschreibung, Markenform, vollständige E-Mail-Adressen, zu langer Inhalt für einen festen Slot. Muss schnell sein und keinen Browser benötigen.
Statische Verifizierung über dist/ (CI)	Nein	Links, Titel, Meta, strukturierte Daten, Sitemap, Weiterleitungen, Header-Dateien, Markup-Hygiene, Zählungen, Barrierefreiheit, die aus HTML gelesen werden kann.
Headless-Browser-Sweep (CI)	Nein	Layout und Überlauf bei vielen Breiten, Textabschneiden, Zielgrößen, berechnete Stile, Verhalten (Karussells, Disclosure-Widgets, Embeds).
Live-Check (manuell, nach Dashboard-Änderungen)	Nein	Was die deployede Antwort tatsächlich enthält, in beide Richtungen: deklariert, aber nicht ausgeliefert; ausgeliefert, aber nicht deklariert. Dashboard-Regeln können Header umschreiben, die das Repository nie sieht.
Mensch auf einem echten Gerät	Nein	Touch-Gefühl, klebriger Hover, iOS :active, Sicherheitsbereiche, Scroll- und Intersection-Verhalten.

Zwei Verfeinerungen:

• Melden, nicht Fehlschlagen, wenn Fehlschlagen einen Redakteur bestrafen würde. Wenn ein CMS-Speichern konstruktionsbedingt etwas erzeugt (einen fünften Beitrag in einer Vier-Karten-Reihe, einen Upload im falschen Pfad), melde es; ein roter Build für eine Formsache lehrt die Leute, rote Builds zu ignorieren. Sprache, Lecks und Bytes schlagen weiterhin fehl.
• Etwas, das CI fängt und niemals ausgeliefert werden darf, braucht auch eine Build-Zeit-Wache. Wenn der Browser-Sweep feststellt, dass zu langer Inhalt ein Layout zerbricht, füge eine kostengünstige Build-Zeit-Begrenzung hinzu (Zeichen, Zählungen), damit die schlechte Version nicht deployen kann, während CI noch läuft.

Wie man Prüfungen schreibt, die halten

• Lies die erstellte Ausgabe, nicht Test-Fixtures. Prüfungen, die eine von Hand gepflegte Liste durchlaufen, übersehen stillschweigend alles, was später hinzugefügt wird; im Quellprojekt blieb jeder über CMS verfasste Blogbeitrag auf diese Weise ungeprüft. Treibe strukturelle Prüfungen über dist/**/index.html an.
• Lies jedes leserorientierte Feld: Fließtext, <title>, Meta content, alt, aria-label, title, placeholder. Abweichungen leben in den Attributen, die niemand liest.
• Berechne, vergleiche keine Zeichenketten. Miss die Titelbreite in Pixeln (scripts/title-width.mjs), berechne den Kontrast aus dem tatsächlichen Gradienten-Alpha am oberen Textrand, vergleiche die gerenderte Geometrie. Ein Zeichenketten-Vergleich besteht einen anderen Wert mit demselben Fehler.
• Prüfe in beide Richtungen. Datei existiert und Seite deklariert sie; CMS-Konfigurationsfelder und Inhaltsschema; deklarierte Header und ausgelieferte Header; jeder Quellpfad in einer Zuordnung wird tatsächlich nachverfolgt.
• Vergleiche Muster, füge niemals das Geheimnis ein. Eine Sperrliste vertraulicher Begriffe, die die Begriffe enthält, ist selbst das Leck. Preismuster benötigen eine Zahl neben dem Wort, damit die gewöhnliche Wortwahl besteht.
• Entferne <script> und <style> vor Textregeln, sonst bestehen JSON-LD @type und CSS color Rechtschreibprüfungen nicht. Überprüfe das rohe Markup auf Zeichensetzung, weil gemeinsame Textnormalisierer oft Gedankenstriche und Abstände umschreiben.
• Messe die Abdeckung. Instrumentiere den Assertionshelfer, um aufzuzeichnen, welche Assertions ausgeführt wurden. Eine, die niemals ausgeführt wird, kann niemals fehlschlagen.
• Lasse Spielraum. Linux-CI rendert Text 2 bis 3 % breiter als Windows oder macOS; ein Layout, das lokal mit 1 Pixel passt, schlägt in CI fehl, und Android rendert wie CI. Lasse 20 Pixel oder mehr und teste die Breiten auf beiden Seiten jedes Breakpoints, nicht nur 375/768/1280.

Worst-Case-Inhalte

Demo-Inhalte werden, ohne dass es jemand merkt, so gewählt, dass sie gut aussehen. Bevor du einer Komponente vertraust, die bearbeitbare oder zukünftige Inhalte rendert (Event-Slides, Karten, Breadcrumbs, Titel, CMS-Felder), füttere sie mit plausiblen Worst Cases durch dieselbe Datendatei, die auch die echten Inhalte verwenden: den längsten realistischen Namen, einen zweizeiligen Untertitel, eine Anzahl von 1, 3 oder 5 gegen ein Raster von 2 oder 4, ein fehlendes optionales Feld, einen Titel über der Breadcrumb-Trenn-Länge. Übernimm das Fixture nicht. Dann:

• was sichtbar zerbricht, behebe in der Komponente (lass eine optionale Zeile nachgeben, umbrechen statt abschneiden);
• was nicht nachgeben kann, halte mit einer Build-Zeit-Begrenzung und einer klaren Fehlermeldung;
• was eine Designentscheidung ist (verwaiste Karten, ein fehlendes Bild), frage den Eigentümer.

Im Quellprojekt fand dies Text, der bei jeder Breite 150 Pixel weit in eine Bildunterschrift lief, und ein Breadcrumb, das seinen Platz verlor – beides nicht sichtbar mit den tatsächlichen Inhalten des Tages.

Was du von einer Agent-Sitzung aus nicht überprüfen kannst

Agent und Headless-Browser rendern mit visibilityState hidden: IntersectionObserver feuert nie, Bilder mit Lazy Loading laden nie, Animations-Zeitachsen bleiben bei Null. Sie werden nicht von einem synthetischen Touch scrollen, und focus() in einem unfokussierten Dokument löst keine Fokus-Ereignisse aus. Ziehe daher niemals Schlussfolgerungen über scroll-getriggertes Verhalten, Lazy Loading oder Touch-Gefühl aus einer Sitzung. Stagiere die Änderung, sage klar, dass sie unbestätigt ist, und gib der Person eine spezifische Prüfung zum Durchführen (bei Lazy Loading ein Inkognito-Fenster, weil ein normaler Neuladevorgang aus dem Cache malt). Mehr in references/tooling-gotchas.md.

Überprüfungsmodus: Was zu liefern ist

Beginne mit dem Urteil. Dann die Ergebnisse, die schwerwiegendsten zuerst, jedes mit der Messung dahinter. Halte Behauptungen, die du nicht reproduzieren konntest, aus den Ergebnissen heraus und in einer eigenen kurzen Liste, mit dem, was du stattdessen gemessen hast. Verwende das Berichtsformat in references/templates.md. Sage für jedes Ergebnis, in welchem Gate seine Prüfung leben sollte. Wenn der Benutzer nur ein Urteil verlangt hat, gib es in ein paar Zeilen und biete den vollständigen Bericht an.

Wenn du aufgefordert wirst, auf einen Audit eines Drittanbieters zu reagieren, messe jede Behauptung, bevor du irgendetwas reparierst, und berichte zurück, welche Behauptungen Bestand hatten, welche nicht und was der Audit übersehen hat.

Erstellungsmodus: Was einzurichten ist

Richte für eine neue Website das Prüfungsgerüst ein, bevor die erste Seite erstellt wird, denn eine Nachrüstung bedeutet, alles zweimal zu auditieren. references/build-baseline.md listet die Tag-1-Baseline auf: Host- und URL-Entscheidungen (kanonische Form, doppelte Origins ausgeschaltet, 404-Bedienung, unveränderliche Assets), die vier Prüfungs-Gates, Sicherheitsheader und CSP ohne 'unsafe-inline', CMS-Schemaparität, die Mobile- und Bewegungs-Baseline und das Hausprofil.

Für eine neue Seite oder Funktion auf einer bestehenden Website führe den obigen Kreislauf aus, erweitere die bestehenden Prüfungen, anstatt parallele zu schreiben, und führe den Worst-Case-Durchlauf für alles durch, das bearbeitbare Inhalte rendert.

Bewegung und Touch, kurz

Standardmäßig weniger Bewegung. Animieren nur, wo es Feedback gibt, die räumliche Kontinuität erhält, eine Zustandsänderung zeigt oder eine störende Änderung verbirgt, und halte UI-Animationen unter 300 ms. Lehne Scroll-Reveal-Einblendungen, Zahlenzähler, Laufschriften und Eingangsanimationen bei jedem Seitenaufruf ab. Grenze Hover-Effekte hinter (hover: hover) and (pointer: fine) ein; gib Touch einen :active-Pressedruckzustand; jede Bewegung braucht einen Reduced-Motion-Pfad und einen Fallback, der Inhalte sofort zeigt. Bevor du einen Übergang zwischen zwei Dingen vorschlägst, bestätige, dass beide Dinge auf beiden Seiten existieren. Details in references/audit-checklist.md (Mobile, Touch und Bewegung).

Referenzdateien

Lies die, die du brauchst, wenn du sie brauchst:

• references/audit-checklist.md: der vollständige Prüfungskatalog nach Bereich (SEO, Barrierefreiheit, Leistung, Sicherheit und Datenschutz, Inhaltsstil, Layout, CMS, Mobil und Bewegung), jeweils mit dem, was er fängt, welchem Gate und der Falle, die ihn notwendig gemacht hat. Lies vor jeder Überprüfung und beim Hinzufügen von Prüfungen.
• references/build-baseline.md: Tag-1-Einrichtung für eine neue Website. Lies beim Starten oder Neu-Plattformieren einer Website.
• references/tooling-gotchas.md: Werkzeug- und Umgebungsfallen, die Stunden kosten. Lies, bevor du einer Browsermessung, Bildbearbeitungswerkzeugen oder einem Skript mit Regex-Escapezeichen vertraust.
• references/judgement-calls.md: Entscheidungen, die falsch aussehen und richtig sind, und wie man Fehler von redaktionellen Entscheidungen unterscheidet. Lies, bevor du etwas „reparierst“, das seltsam erscheint.
• references/templates.md: Tabellenzeilen-, Überprüfungsberichts-, Eigentümerentscheidungs- und Hausprofilvorlagen.

Skripte leben im eigenen scripts/-Ordner dieses Skills, nicht im Projekt. Führe sie von dort aus oder kopiere sie in das Projekt, wenn du seine Prüfungen einrichtest; beschreibe sie nicht so, als ob ein Repository sie bereits hätte. Wenn du eine Messung in einem Bericht zitierst, sage, wie du sie erhalten hast. Node 18+, keine Abhängigkeiten:

• scripts/title-width.mjs: Pixelbreite eines Titels in einem Google-Desktop-Ergebnis, mit einem Selbsttest gegen Chrome-Messungen. node title-width.mjs "Seitenlabel · Marke" [--suffix " · Marke"].
• scripts/break-test.mjs: mutiere eine Datei, führe einen Prüfbefehl aus, bestätige, dass er mit einer erwarteten Nachricht fehlschlägt, stelle die Datei wieder her, was auch immer passiert. Führe mit --help aus.