site-consistency — offer-aligned Copy-QA

Site Consistency — Offer-Aligned Text Audit

Ziel: Jeder Text auf der Website erzählt die gleiche Geschichte – das auf der Startseite genannte Angebot – dem gleichen Kunden, mit dem gleichen Versprechen, den gleichen Namen und den gleichen Begriffen. Zuerst prüfen; nur das korrigieren, was der Benutzer genehmigt.

Zwei harte Grenzen:

1. Prüfung vor Korrektur. Die Prüfung ist schreibgeschützt. Es wird keine Datei geändert, bis der Benutzer bestimmte Zeilen der Prüfungstabelle genehmigt.
2. Nur Text. Diese Fähigkeit ändert Wörter – niemals Layout, Stile, Komponenten, Bilder, Routen oder Seitenstruktur. Siehe „Text-Only Editing Rules".

Sprachen

• Sprechen Sie mit dem Benutzer in der Sprache, die er im Gespräch verwendet. Der Bericht, die Tabellenüberschriften, die Schweregradbezeichnungen und die Spalte „Warum" sind in dieser Sprache.
• Zitate des aktuellen Texts sind wörtlich, in ihrer Originalsprache.
• Vorgeschlagener Seitentext wird in der Sprache des Textes, den er ersetzt, nativ und idiomatisch (niemals eine wörtliche Übersetzung) verfasst, wobei die Anredeform der Website (z. B. deutsch „du"/„Sie") und der Tonfall beibehalten werden.
• Erkennen Sie die Seitensprache(n) anhand von <html lang>, i18n-Konfiguration, Locale-Dateien und dem sichtbaren Text. Bei mehrsprachigen Websites identifizieren Sie das primäre Gebietsschema; falls unklar ist, welche Gebietsschemata zu prüfen sind, fragen Sie nach.

Arbeitsablauf

Führen Sie die Schritte in der angegebenen Reihenfolge aus. Die Schritte 1–6 ändern niemals Dateien.

Schritt 1 — Aufklärung

Lesen Sie references/text-inventory.md. Stellen Sie Folgendes fest:

• den Stack und das Routing (wie URLs auf Dateien abgebildet werden),
• wo der Text lebt: Komponenten/Templates, i18n-Dateien, Markdown/MDX/Inhaltssammlungen, Metadaten, E-Mail-Vorlagen, externes CMS,
• Gebietsschemata und die primäre Seitensprache,
• vorhandene Angebotsdokumente: docs/offer/offer-brief.md (erstellt von der Fähigkeit grand-slam-offer) oder ein beliebiges Kurzbrief/Positionierungsdokument in docs/.

Wenn der meiste Text in einem externen CMS lebt und weder ein Export noch eine URL zum Lesen der gerenderten Website vorhanden ist, teilen Sie dem Benutzer mit, was geprüft werden kann und was nicht, bevor Sie fortfahren.

Schritt 2 — Extraktion des Angebots von der Startseite

Lesen Sie die Startseite so, wie es ein Erstbesucher tun würde: zuerst den Hero-Bereich, dann jeden Abschnitt in der Reihenfolge, plus <title>, Meta-Beschreibung, Kopfzeile und Fußzeile. Füllen Sie die Angebotsaussage aus:

Feld	Was es beantwortet
Was verkauft wird	Produkt/Dienstleistung und ihr Format
Für wen	der Kunde/Avatar, das Segment, der Markt
Kernversprechen	das Ergebnis, das der Kunde erhält (+ Zeitrahmen, falls angegeben)
Mechanismus / Unterscheidungsmerkmal	wie es geliefert wird, warum dies statt Alternativen
Namen	exakte Schreibweise des Angebots, Produkts, der Methode und der Paketnamen
Schlüsselbegriffe	Preis/Pakete, Garantie, Knappheit/Fristen, Lieferzeit – nur die genannten
Primäre Konversion	der wichtigste CTA und was nach dem Klicken passiert
Tonfall	Ton, Anredeform, Positionierung (Premium, Budget, Experte, freundlich…)

Notieren Sie für jedes Feld den Wert und die Quelle (Zitat + Ort). Wenn ein Feld nicht auf der Startseite steht, schreiben Sie „nicht angegeben". Falls eine Angebotskurzbeschreibung existiert, vergleichen Sie sie Feld für Feld mit der Startseite.

Bei einer Website mit mehreren unterschiedlichen Angeboten (z. B. separate Dienstleistungen für verschiedene Zielgruppen) notieren Sie das übergeordnete Angebot von der Startseite und listen Sie die Unterangebote auf; jede Unterseite wird sowohl gegen ihr eigenes Angebot als auch gegen das übergeordnete geprüft.

Schritt 3 — Angebotsklarheit-Prüfung

Das Angebot ist klar, wenn alle folgenden Punkte zutreffen:

1. „Was verkauft wird", „Für wen", „Kernversprechen" und „Primäre Konversion" können allein von der Startseite beantwortet werden.
2. Die Startseite präsentiert ein Hauptangebot (oder ein klares übergeordnetes Angebot mit Unterangeboten) – keine konkurrierenden Angebote.
3. Die Startseite widerspricht sich nicht selbst (zwei Preise, zwei Zielgruppen, zwei unterschiedliche Versprechen).
4. Die Startseite widerspricht nicht der Angebotskurzbeschreibung, falls eine vorhanden ist.

Klar → fortfahren. Die Angebotsaussage ist der Maßstab; sie steht oben im Bericht, damit der Benutzer sie korrigieren kann.

Nicht klar → anhalten und den Benutzer nach dem Angebot fragen, bevor etwas anderes geprüft wird. Niemals das Angebot erraten, um diese Hürde zu umgehen.

• Verwenden Sie das Tool AskUserQuestion, falls verfügbar (max. 4 Fragen pro Runde), mit Optionen, die aus den Kandidaten erstellt wurden, die Sie tatsächlich auf der Website gefunden haben, plus Platz für eine benutzerdefinierte Antwort. Andernfalls im Chat fragen.
• Fragen Sie nur nach Feldern, die fehlen oder widersprüchlich sind, z. B. „Die Startseite verkauft sowohl X als auch Y – welches ist das Hauptangebot?", „Ist der Hauptkunde A (Hero) oder B (Dienstleistungsbereich)?", „Die Kurzbeschreibung sagt eine 30-tägige Garantie, die Startseite 14 Tage – welche ist aktuell?". Bestätigen Sie bei mehreren Angeboten die Hierarchie (Hauptangebot vs. Unterangebote).
• Notieren Sie die Antworten in der Angebotsaussage mit der Quelle „vom Benutzer bestätigt". Der unklare oder widersprüchliche Text der Startseite wird dann zu Befunden – die Startseite wird wie jede andere Seite gegen das bestätigte Angebot geprüft.

Schritt 4 — Seiten- und Textinventar

Listen Sie alles auf, was ein Besucher lesen kann (Details in references/text-inventory.md):

• jede Route/Seite, einschließlich dynamischer Routen und Inhaltssammlungen,
• gemeinsam genutzter Text: Kopfzeile, Navigation, Fußzeile, Banner, Modals/Popups, Formulare (Beschriftungen, Platzhalter, Validierung, Erfolgs-/Fehlermeldungen), 404/500 und Leerzustände,
• Text, den Besucher indirekt sehen: <title>, Meta-Beschreibung, Open Graph/Twitter-Tags, JSON-LD-Textfelder, alt, aria-label, Web-Manifest-Name/-Beschreibung,
• Transaktions-E-Mails und Benachrichtigungen, falls ihre Vorlagen im Repository sind.

Weisen Sie jeder Seite ihre narrative Rolle zu (siehe references/consistency-checklist.md) – die Rolle bestimmt, was „konsistent" für diese Seite bedeutet.

Große Websites: Prüfen Sie jede Kernseite vollständig. Bei großen Sammlungen des gleichen Typs (z. B. mehr als 20 Blogbeiträge oder Produkte) prüfen Sie die gemeinsam genutzte Vorlage plus Titel, Beschreibung, Einleitung und CTA jedes Elements; sagen Sie im Bericht genau, was auf diese Weise abgedeckt wurde, und bieten Sie einen vollständigen Durchlauf an. Falls das Agent-Tool verfügbar ist, können Sie das Inventar auf Unteragenten aufteilen – geben Sie jedem die bestätigte Angebotsaussage, die Checkliste und seine Liste der Seiten und führen Sie dann ihre Ergebnisse in einer einzigen Tabelle zusammen.

Schritt 5 — Prüfung

Lesen Sie references/consistency-checklist.md. Überprüfen Sie jede Texteinheit anhand der Angebotsaussage in allen Dimensionen (D1–D10) im Kontext der Rolle ihrer Seite. Notieren Sie für jeden Befund: Ort, wörtliches Zitat, Dimension, Schweregrad, warum es ein Problem ist (bezogen auf ein bestimmtes Feld der Angebotsaussage), Korrekturtyp und den vorgeschlagenen Text.

• Erstellen Sie zuerst die Faktenmatrix (jede Erwähnung von Preis, Garantie, Fristen, Plätzen, Lieferzeit, Namen – nebeneinander), damit Widersprüche zwischen Seiten systematisch erfasst werden und nicht zufällig.
• Vorgeschlagener Text folgt den Text-Only Editing Rules und erfindet niemals Fakten. Ein fehlender Fakt wird zu einem Platzhalter in der Seitensprache (z. B. [ZUM AUSFÜLLEN: …], englisch [TO FILL IN: …]).
• Widersprüchliche Fakten, bei denen die Wahrheit nicht feststeht → Korrekturtyp Entscheidung: Optionen auflisten, keine auswählen.
• Probleme, die Text nicht lösen kann (Bild, das ein anderes Produkt zeigt, fehlender Abschnitt oder CTA-Button, eine Seite, die nicht existieren sollte, falsches Linkziel, URL-Slug) gehen zu „Außerhalb des Textumfangs" – gemeldet, niemals von dieser Fähigkeit behoben.

Schritt 6 — Prüfbericht, dann anhalten

Präsentieren Sie den Bericht genau wie im „Ausgabeformat". Der Bericht endet immer mit der Ergebnistabelle. Das einzige, was nach der Tabelle erlaubt ist, ist die Genehmigungsfrage. Dann anhalten und warten – keine Datei in dieser Runde ändern.

Genehmigungsfrage (verwenden Sie AskUserQuestion, falls verfügbar):

• Alle anwenden
• Nur kritische und schwere anwenden
• Ausgewählte Zeilen anwenden (der Benutzer listet die # auf und kann jeden Vorschlag bearbeiten)
• Nicht anwenden – nur Prüfung

Jede Entscheidungs-Zeile, die der Benutzer angewendet haben möchte, benötigt eine Antwort; fragen Sie in derselben Runde danach, wenn möglich.

Schritt 7 — Anwenden der genehmigten Korrekturen

• Wenden Sie nur die genehmigten Zeilen mit den Bearbeitungen des Benutzers gemäß den Text-Only Editing Rules an.
• Bevor Sie eine Zeichenfolge ändern, prüfen Sie, wo sie sonst noch gerendert wird (gemeinsamer i18n-Schlüssel, gemeinsame Komponente, wiederverwendeter Markdown-Teil). Wenn der neue Text nicht in einen dieser Kontexte passt, anhalten und nachfragen.
• Wenn sich herausstellt, dass eine genehmigte Korrektur eine nicht-textliche Änderung erfordert oder nicht wie genehmigt angewendet werden kann, überspringen Sie sie und melden Sie es. Keine andere Korrektur improvisieren.
• Text, der in einem externen CMS gespeichert ist: Versuchen Sie nicht, ihn zu bearbeiten; bereiten Sie eine Kopier-Einfüge-Liste vor (CMS-Eintrag/Feld | aktueller Text | neuer Text).

Schritt 8 — Überprüfen und Berichten

• Lesen Sie jede geänderte Passage mit dem umgebenden Text erneut – sie muss im Kontext natürlich klingen.
• Suchen Sie nach Überbleibseln der alten Varianten (alte Namen, alte Begriffe, altes Versprechen) innerhalb des genehmigten Umfangs.
• Validieren Sie geänderte Dateien: JSON/YAML-Parsing, Gebietsschema-Dateien behalten die gleichen Schlüssel, Interpolationsvariablen sind intakt. Führen Sie das Lint/Typecheck/Build des Projekts aus, wenn eines verfügbar und schnell ist.
• Mehrere Gebietsschemata: Listen Sie die anderen Gebietsschemata auf, deren Zeichenfolgen ebenfalls aktualisiert werden müssen, es sei denn, der Benutzer hat deren Aktualisierung genehmigt.
• Beenden Sie mit der Zusammenfassungstabelle: # | Wo | Status (Angewandt / Übersprungen – Grund / CMS-Update erforderlich) | Änderung (kurz). Nicht commiten, es sei denn, der Benutzer fordert es an.

Text-Only Editing Rules

Erlaubt:

• benutzersichtbarer Zeichenfolgeninhalt: Textknoten in JSX/Vorlagen, Zeichenfolgenliterale, die Benutzern gerendert werden, i18n-Werte, Markdown/MDX-Text, Frontmatter-Textfelder (Titel, Beschreibung), CMS/Inhaltsdateien im Repository,
• Textattribute und Metadaten: alt, title, aria-label, placeholder, <title>, Meta-Beschreibung, OG/Twitter-Text, JSON-LD-Textwerte, Manifest-Name/-Beschreibung,
• Formular-, System- und E-Mail-Vorlagen-Nachrichten,
• Umschreiben, Kürzen oder Löschen von Sätzen innerhalb eines vorhandenen Textelements.

Nicht erlaubt (stattdessen unter „Außerhalb des Textumfangs" melden):

• Hinzufügen, Entfernen, Neuanordnen oder Neustylen von Elementen, Abschnitten oder Komponenten; Ändern von Markup, Klassen, CSS oder nicht-textlichen Props,
• Leeren eines Elements – ein leeres Element ist eine Layoutänderung; stattdessen umschreiben,
• i18n-Schlüssel, Variablennamen, Dateinamen, Routen, URL-Slugs, Anker (Slugs sind Text, aber das Ändern unterbricht Links und SEO),
• Linkziele (href) – nur der Linktext kann sich ändern,
• Bilder, Symbole, Videos und andere Medien,
• Codlogik, Bedingungen, Datenabruf.

Beim Bearbeiten:

• Interpolation und Syntax beibehalten: {name}, {{count}}, %s, :attribute, ICU-Plural-/Select, HTML-Entitäten, Inline-Tags innerhalb von Zeichenfolgen (<strong>, <br>, <0>…</0>), Markdown-Formatierung und Maskierung (Anführungszeichen in JSX/JSON, Apostrophe in PHP-Zeichenfolgen).
• Halten Sie die Länge nahe am Original (etwa ±30 %), da sich das Layout nicht ändert. Wenn eine Korrektur viel mehr Text benötigt, sagen Sie dies im Vorschlag.
• Halten Sie sich an die typografischen Konventionen der Website (Anführungszeichen, Gedankenstriche, geschützte Leerzeichen).

Verbindliche Regeln

• R1. Schreibgeschützte Prüfung. Keine Bearbeitungen und keine Dateischreibvorgänge (einschließlich Berichtsdateien, es sei denn, der Benutzer fordert eine an) vor expliziter Genehmigung. Die Genehmigung gilt nur für die genehmigten Zeilen.
• R2. Nur Text. Alles außerhalb der Text-Only Editing Rules wird gemeldet, niemals geändert.
• R3. Maßstab zuerst. Niemals gegen ein erratenes Angebot prüfen: Die Angebotsaussage ist entweder von der Startseite klar oder vom Benutzer bestätigt.
• R4. Belege. Jeder Befund zitiert den aktuellen Text wörtlich und gibt einen genauen Ort an (datei:zeile oder i18n-Schlüssel).
• R5. Die Tabelle kommt immer zuletzt. Jeder Prüfbericht endet mit der Ergebnistabelle, auch wenn es keine Befunde gibt – dann endet er mit einer Abdeckungstabelle (Seite | Rolle | Urteil).
• R6. Keine erfundenen Fakten. Vorschläge fügen niemals Zahlen, Ergebnisse, Erfahrungsberichte, Garantien oder Bedingungen hinzu, die der Benutzer nicht bereitgestellt hat oder die die Website nicht bereits konsistent angibt. Konflikt → Entscheidung. Fehlend → Platzhalter.
• R7. Konsistenz, nicht Gleichförmigkeit. Nicht das Hero-Versprechen überall einfügen oder jede Seite zu einem Verkaufsgespräch zwingen. Kennzeichnen Sie nur Text, der dem Angebot widerspricht, es verwässert, davon abweicht oder davon ablenkt, unter Berücksichtigung der Rolle der Seite. Rechtliche Seiten werden niemals für die Erzählung umgeschrieben – nur ihre Faktenkonflikte mit Marketingtexten werden gemarkert, mit der Empfehlung, den rechtlichen Text überprüfen zu lassen.
• R8. Am Angebot ausrichten, es nicht neu entwerfen. Diese Fähigkeit richtet die Website am bestätigten Angebot aus. Wenn das Angebot selbst schwach ist (vages Versprechen, keine Beweise, preisgeführt), sagen Sie dies in einer Zeile der Zusammenfassung und schlagen Sie die Fähigkeit grand-slam-offer vor; bauen Sie das Angebot hier nicht neu auf.
• R9. Sprache. Kommunikation in der Gesprächssprache; vorgeschlagener Seitentext in der Sprache des Textes, den er ersetzt.

Ausgabeformat

Prüfbericht

Abschnitte in dieser Reihenfolge, verfasst in der Gesprächssprache:

1. Benchmark-Angebot – die Angebotsaussage (kompakte Tabelle) + ihre Quelle (Startseite / Angebotskurzbeschreibung / vom Benutzer bestätigt).
2. Umfang – geprüfte Seiten und Textquellen (Anzahl + Liste oder Gruppierung), Gebietsschemata, was durch Stichproben abgedeckt wurde, was sich außerhalb des Repositorys befindet und nicht geprüft wurde.
3. Zusammenfassung – Anzahl der Befunde nach Schweregrad; die 2–3 größten narrativen Probleme, jeweils ein Satz; optional eine Zeile über das Angebot selbst (R8).
4. Vollständige Umschreibungen (nur bei Bedarf) – Vorschläge länger als etwa 40 Wörter, vollständig, mit der Befundnummer gekennzeichnet.
5. Außerhalb des Textumfangs (nur falls vorhanden) – kurze Aufzählungspunkte; diese Fähigkeit wird sie nicht beheben.
6. Ergebnistabelle – das letzte Element des Berichts.

Ergebnistabelle – Kopfzeilen in die Gesprächssprache übersetzt:

#	Wo	Schweregrad	Heute	Warum es so nicht sein sollte	Vorgeschlagene Korrektur

• # – stabile ID, die für die Genehmigung verwendet wird.
• Wo – Seite · Abschnitt · datei:zeile oder i18n-Schlüssel.
• Schweregrad – Kritisch / Schwer / Gering (siehe Checkliste).
• Heute – wörtliches Zitat des relevanten Fragments; mit „…" kürzen, wenn mehr als etwa 25 Wörter.
• Warum es so nicht sein sollte – der konkrete Konflikt mit dem Benchmark, z. B. „Startseite: für Zahnarztpraxen; hier: für jedes Unternehmen".
• Vorgeschlagene Korrektur – der genaue neue Text in der Seitensprache, „siehe Vollständige Umschreibungen #N" oder ENTSCHEIDUNG: A) … / B) ….

Sortieren nach Schweregrad, dann nach der Seitenreihenfolge des Inventars.

Beispiel: In einem deutschen Gespräch werden die drei Kernüberschriften zu „Wie es heute ist", „Warum es anders sein sollte", „Wie ich es korrigiere".

Beispielzeilen (englische Website, englisches Gespräch):

#	Wo	Schweregrad	Heute	Warum es so nicht sein sollte	Vorgeschlagene Korrektur

…

[truncated for translation]