launch-audit
Durchsuche eine Staging- oder Live-Site, sammle Beweise und übergebe einer Person einen Bericht, den sie umsetzen kann.
Die goldene Regel
Nur lesen, nur berichten. Nichts in diesem Skill bearbeitet eine Site, sendet ein Formular ab, ändert eine Einstellung, schreibt in eine Provider-API oder klickt auf ein zerstörerisches Steuerelement. Jede Feststellung ist eine Empfehlung mit Nachweis für einen Menschen, der handeln soll.
Vier weitere, die daraus folgen und die du wiederholst, wenn du den Bericht präsentierst:
- Keine stillschweigenden Einschränkungen. Jede Grenze der Abdeckung – maximale Seiten, Tiefe, Stichproben, nicht überprüfbare externe Links – wird namentlich im Abschnitt Nicht abgedeckt aufgeführt.
- Nachweis für jede Feststellung. Eine URL, ein Statuscode, ein Header-Wert, ein Screenshot-Pfad.
Nicht abgedecktist niemals ein Bestehen. Du wiederholst diesen Abschnitt der Person wörtlich.- Eine Auslassung ist kein Bestehen. Jede übersprungene Prüfung enthält einen Grund.
1. Eingaben sammeln
Frage nach dem, was du noch nicht weißt. Rate bei keinem dieser Punkte.
- Die zu auditierende URL. Erforderlich.
- Ist es Staging oder Live? Ein Staging-Ziel wird voraussichtlich als
noindexmarkiert sein; übergib--staging, damit eine siteweitenoindex-Markierung von einem Blocker zu einer Information herabgestuft wird. Bei einem Live-Ziel ist es der Blocker. - Ersetzt dies eine bestehende Site? Wenn ja, erhalte die URL der alten Site und übergib
--old-url. Dies muss durchgeführt werden, solange beide Sites noch erreichbar sind – normalerweise bevor DNS umgestellt wird. Dies ist der einzige Zeitpunkt, zu dem eine Redirect-Karte automatisch erstellt werden kann. - Alle Entwicklungs- oder Staging-Hostnamen, die in den Build gelangt sein könnten. Übergib jeden mit
--dev-host. Ein durchgesickerter Hostname ist ein Blocker und das Audit kann nur nach den Hostnamen suchen, die es kennt. - Ist Playwright installiert? Wenn ja, läuft die Browser-Ebene: Screenshots, axe-Barrierefreiheit, Lighthouse und ob die Analytik tatsächlich ausgelöst wird. Wenn nicht, sage dies – etwa ein Drittel des Berichts findet nicht statt, und der Bericht sagt, welches Drittel.
2. Das Skript ausführen
Führe es aus; lies niemals seinen Quellcode und implementiere niemals neu, was es tut. Alles, was es tut, ist schreibgeschützt: Es ruft Seiten ab, rendert eine Stichprobe von ihnen und schreibt ein Bündel auf die Festplatte.
node scripts/launch-audit.mjs --url <url> [--old-url <url>] [--dev-host <host>] [--staging] [--browser auto|on|off] [--out <verzeichnis>]
Der Pfad ist relativ zum eigenen Verzeichnis dieses Skills – führe den Befehl von dort aus und schreibe das Bündel mit --out dorthin, wo die Arbeit liegt.
Andere Flags: --max-pages (Standard 200), --max-depth (Standard 4), --ignore-robots, --baseline <pfad zu einer vorherigen baseline.json>, --json, --config <pfad>, --help.
Die Browser-Ebene standardmäßig auf auto: Sie läuft, wenn Playwright vorhanden ist, und wird mit einem Grund übersprungen, wenn es nicht vorhanden ist. Verwende --browser on, um sein Fehlen zu einem Fehler zu machen, off, um es bewusst zu überspringen.
Das Skript beendet sich mit 0, egal wie viele Feststellungen es gibt – es berichtet, es blockiert nicht. Exit-Code 2 bedeutet einen Anwendungsfehler. Wenn es vorschlägt, Playwright zu installieren, gib den Vorschlag weiter; installiere nichts, ohne darum gebeten zu werden.
3. Das Bündel lesen
Das Skript gibt den Bündelpfad aus und schreibt:
report.md Feststellungen nach Dimension, dann Betriebs- & Zugriffsbereitschaft, dann Nicht abgedeckt
findings.json dieselben Feststellungen, maschinenlesbar
crawl.json jede erreichte URL, ihr Status, Tiefe und wie sie gefunden wurde
baseline.json ein Schnappschuss für den Post-Launch-Vergleich
manifest.json genau welche Dateien dieser Lauf geschrieben hat
redirects.csv eine Zeile pro alter URL (nur mit --old-url)
screenshots/ Desktop, Tablet und Mobil pro gerenderter Seite (nur Browser-Ebene)
lighthouse/ die von Lighthouse gemessenen Werte und Metriken, pro Seite und Formfaktor (nur Browser-Ebene)
Lies zuerst report.md: Blocker, dann Nicht abgedeckt, dann alles andere. Zu wissen, was nicht überprüft wurde, ändert, wie du einen sauberen Abschnitt liest. references/reading-the-report.md enthält die Schweregrad-Tabelle und wie man mit dem Bündel arbeitet.
4. Führe die drei Beurteilungsdurchgänge selbst durch
Das Skript sammelt Beweise für drei Überprüfungen, die kein Prüfprogramm durchführen kann. Führe alle drei durch, bevor du etwas präsentierst. Jede hat eine Referenzdatei; lies sie vor dem Durchgang, nicht danach.
Screenshots – gemäß references/reading-the-report.md. Öffne die mobilen und Desktop-Aufnahmen jeder gerenderten Seite nebeneinander und suche nach Layout-Brüchen, horizontalem Überlauf, fehlenden Bildern, abgeschnittenem oder abgeschnittenem Text, Navigation, die bei Telefonbreite nicht zusammenklappt, und Platzhalterbildern, die bis zum Launch überlebt haben. Wenn kein Browser gelaufen ist, gibt es keine Screenshots, und diese Überprüfung hat nicht stattgefunden – sage dies, anstatt dass das Fehlen als Bestehen gelesen wird.
Formulare – gemäß references/forms.md. Klassifiziere jedes Formular im Inventar als First-Party, Third-Party oder tot, unter Verwendung der Beweise im Bericht. Sage dann dem Menschen, welche Formulare eine Testeinreichung benötigen und was genau zu bestätigen ist: die Erfolgsmeldung, die Benachrichtigung, die in einem überwachten Posteingang ankommt, und der Datensatz, der dort erscheint, wo er soll. Du selbst reichst niemals ein Formular ein.
Kontaktdaten – gemäß references/content.md. Sammle alle Telefonnummern, E-Mail-Adressen und Postadressen, die der Bericht gefunden hat, in einer Liste, überprüfe, ob die tel:-Links die daneben angezeigten Nummern wählen, und frage den Site-Eigentümer, welche aktuell sind. Eine zweite Telefonnummer, die auf einer Seite vergessen wurde, schickt die Hälfte der Anrufe ins Leere, und von außen kann niemand sagen, welche richtig ist.
5. Den Bericht präsentieren
Strukturiere deine Zusammenfassung so, wie der Bericht strukturiert ist, und führe mit der Entscheidung, nicht mit einer Anzahl. Vierzig niedrige Feststellungen aus einer Vorlage sind eine Korrektur; ein Blocker ist ein Launch.
- Was den Launch blockiert. Ein einfacher Satz pro Blocker. Wenn es keine gibt, sage dies direkt.
- Feststellungen gruppiert nach Dimension, innerhalb jeder Dimension der schwerwiegendste zuerst. Gib die Form an, nicht nur die Anzahl: „Vierzehn Seiten haben eine Beschreibung – es ist eine Vorlage, also ist es eine Korrektur". Nenne die Korrektur anstelle des Fehlers und sage, was es in einfachen Worten kostet.
- Betriebs- & Zugriffsbereitschaft. Dies sind die Aufgaben des Site-Eigentümers, und sie sind diejenigen, die Launch-Tage ruinieren. Lies die
[human]-Punkte laut vor und erhalte für jeden eine Antwort. - Nicht abgedeckt, wörtlich. Jede Zeile, unverändert, ehrlich eingeleitet: „Hier ist, was dies nicht überprüft hat". Fasse es niemals zusammen, nenne es niemals nebensächlich, lasse es niemals weg, weil die Liste lang ist.
Die beiden Prüfungen, die niemals laufen
Jeder Bericht endet mit diesen, und sie sind da, weil sie die beiden Fehler sind, die am meisten wehtun und die kein Crawler jemals erreichen kann:
- Text vs. Quellendokumente. Nichts hier vergleicht die Wörter auf der Site mit dem freigegebenen Text. Jemand muss sich mit beiden hinsetzen und lesen.
- Seiten vs. vereinbarten Umfang. Nichts hier weiß, welche Seiten existieren sollten. Eine Seite, die nie gebaut wurde, ist für einen Crawler unsichtbar.
Sage beide laut, wenn du den Bericht präsentierst. Eine Site kann jede Prüfung in diesem Skill bestehen und trotzdem die Hälfte dessen vermissen lassen, was vereinbart wurde.
Referenzen
Lies die Datei für eine Dimension, bevor du ihre Feststellungen erklärst. Jede behandelt, was die Feststellung bedeutet, warum sie beim Launch wichtig ist, wie man sie auf üblichen Stacks behebt und was die Prüfung dir nicht sagen kann.
| Datei | Behandelt |
|---|---|
references/reading-the-report.md | Schweregrade, die Screenshot-Checkliste, Nicht abgedeckt, Präsentation vor einem Kunden |
references/indexability.md | Crawl und Inventur, noindex, robots.txt, Sitemaps, Kanonische URLs, hreflang |
references/host.md | HTTPS, Zertifikate, www vs. Apex, Weiterleitungen, Sicherheitsheader, die 404-Seite |
references/head.md | Titel, Beschreibungen, Überschriften, Symbole, Social Cards, strukturierte Daten |
references/links.md | Kaputte und nicht überprüfbare Links, Linktext, mailto: und tel: |
references/images.md | Alt-Text, Abmessungen, Ladestrategie, Gewicht, Formate, Video |
references/forms.md | Das Inventar, Endpunkte, Klassifizierung und die Testeinreichung |
references/accessibility.md | Der HTML-Boden, axe-Verstöße und der 15-minütige manuelle Durchgang |
references/performance.md | Hinweise vs. Messungen, Lighthouse und die Anordnung der Arbeit |
references/analytics.md | Tag-Erkennung, Auslösung, Einwilligung und der Verifizierungsdurchgang |
references/content.md | Platzhalter, veraltete Daten, Varianten von Kontaktdaten |
references/redirects.md | Die Umzugskarte, redirects.csv und das Schreiben der Regeln |
references/ops.md | E-Mail-Authentifizierung, rechtliche Seiten und die Bereitschafts-Checkliste |
Wo dies sitzt
pre-launch ist das Tor, das gegen das Repository vor dem Deployment läuft. launch-audit ist dieses hier: es berichtet und blockiert niemals. post-launch läuft, sobald DNS umgestellt wird, und vergleicht die Produktion mit der Basislinie, die dieses Audit geschrieben hat. Führe sie in dieser Reihenfolge aus.