# Schreibstil (gelernt)

Übertragbare Regeln für Bewerbungstexte. Wird am Ende jeder Bewerbungssession
aktualisiert. Nur **übertragbares** Wissen, keine projektspezifischen Einmaligkeiten.

> **Verbindlicher Grundstil:** `vorgaben/marketing.md` §5 (Tonalität und Markenstimme)
> sowie dessen Dos & Don'ts. Diese Datei ergänzt nur **bewerbungsspezifische**
> Erkenntnisse darüber hinaus und wiederholt die Grundregeln nicht.

## Wortwahl / verbotene Formulierungen (verbindlich)
- **„darstellbar"** nicht verwenden (wirkt gekünstelt). Stattdessen z. B. „machbar",
  „möglich", „leistbar".
- **Schreibweise „System Integration"** (zwei Wörter, englisch), nie „Systemintegration".
  Gilt für Bewerbungstexte.
- **Keine körperlichen Metaphern für Software-/KI-Agenten.** Wendungen wie „AI-Agenten etwas
  **an die Hand geben**" wirken primitiv, weil Agenten keine Hände haben. Sachlich formulieren,
  z. B. „AI-Agenten orchestriert, **sie mit Tools ausgestattet und an Datenquellen angebunden**".
  (Nutzer-Entscheidung Effection Network, AI / MCP Engineer.)

## Grundsätze (verbindlich)
- **Keine falschen Behauptungen.** Niemals etwas behaupten, das der Lebenslauf nicht
  hergibt (z. B. „arbeite täglich an X", „erste produktionsreife Plattform"). Falsche
  Aussagen sind in Bewerbungen absolut tabu.
- **Lücken nicht erwähnen.** Schwächen/fehlende Abdeckung nicht offenlegen. Entdeckt
  der Empfänger sie, lässt sich das im Interview souverän klären; von selbst darauf
  hinweisen schadet nur.
- **Nicht abgedeckten Buzzword als Vergleichsgegenstand nutzen.** Ein in der Ausschreibung
  geforderter, aber **nicht belegter** Begriff darf als Abgrenzung/Vergleich auftauchen, ohne
  eigene Erfahrung zu behaupten (Beispiel Computer-Vision-Projekt: „Informationen aus Dokumenten
  noch besser extrahieren als die konventionellen **OCR**-Methoden" — nennt OCR, ohne OCR-Praxis
  zu behaupten). So entsteht ein Buzzword-Treffer ohne Falschaussage.
- **Einleitung bei fachlich grenzwertiger Rolle entschärfen.** Trifft die Rolle das Profil nur
  teilweise, kann die Einleitung ehrlich „… da sie meine **Interessen** unmittelbar trifft"
  sagen statt eine Liste beanspruchter Schwerpunkte/Buzzwords. Die konkreten Belege folgen
  weiter unten. (Nutzer-Entscheidung Tenth Revolution Group, Fullstack AI Engineer Computer Vision.)
- **Knappes Zeitbudget ehrlich scopen (als Stärke).** Bei Kurz-/Stundenkontingent-Projekten
  realistisch benennen, was im Rahmen leistbar ist (z. B. Schulung/Befähigung sicher machbar, die
  eigentliche Umsetzung beispielhaft an ausgewählten Use-Cases als erweiterbare Grundlage). Wirkt
  kompetent und seriös, nicht als Einschränkung. (Nutzer-Entscheidung WorkGenius, 40-h-Make.com-Coaching.)
- **Triviale Aussagen weglassen.** Nichts schreiben, was für den Empfänger ohnehin
  offensichtlich ist. Insbesondere bei Portal-Bewerbungen **nicht** erwähnen, **wo** die
  Ausschreibung gefunden wurde (bei einer Hays-Bewerbung ist „auf der Hays-Projektbörse
  gesehen" trivial) und **seit wann** das Projekt online ist. Eine sachliche
  Aktualitäts-Nachfrage („Ist das Projekt noch aktuell?") bleibt erlaubt, aber ohne die
  triviale Begründung.

## Wortwiederholung vermeiden (verbindlich)
- **Jede spezielle/markante Formulierung nur einmal im gesamten Text.** Vor dem
  Speichern den ganzen Text gegen Wiederholungen prüfen, **auch über Absätze hinweg**,
  nicht nur innerhalb eines Satzes.
- Greift man **Schlüsselbegriffe der Ausschreibung** auf (Buzzword-Match für den
  Agentur-Empfänger), die markante Wendung **nur einmal** verwenden und eine zweite
  Erwähnung umformulieren (Beispiel: „umsetzungsnahe Spezifikationen" einmal lassen,
  an anderer Stelle „systematisch aufbereiten").
- Dieselbe **Verb-Wurzel** nicht zweimal dicht hintereinander, auch nicht im selben Satz
  (schlecht: „… remote zu **erbringende** Leistung **erbringe** ich …" → besser
  „Die **Remote-Leistungen** erbringe ich in …").
- Dieselbe **Wendung nicht in aufeinanderfolgenden Absätzen** wiederholen (schlecht:
  Absatz 6 „habe ich in **mehreren Positionen** bereits erbracht" und Absatz 7 „In
  **mehreren Positionen** habe ich …" → eine der beiden umformulieren, z. B. „bereits
  mehrfach erbracht").
- **Tätigkeitsbegriffe nicht doppelt listen:** Der „Was-mich-reizt"-Absatz und der
  „Tätigkeiten"-Absatz dürfen nicht dieselben Stichworte (z. B. Bring-up, Debugging,
  Fehleranalyse) aufzählen. Den Reiz-Absatz höher ansetzen (das Themenfeld), die
  konkreten Tätigkeiten genau einmal nennen.

## Tonalität an den Empfänger anpassen
- **Signalisiert der Empfänger ausdrücklich Lockerheit** (z. B. „Bitte unkompliziert und
  formlos", informeller Website-Ton, Du-/Hands-on-Kultur), den Grundton entsprechend
  lockern: Anrede „Hallo Herr/Frau <Nachname>," statt „Sehr geehrte/r", kürzere, direktere
  Sätze, optional ein **P.S.** mit persönlichem Bezug (z. B. ein passendes Zitat von der
  Firmenwebsite, dem man inhaltlich zustimmt). Die verbindlichen Don'ts aus `marketing.md`
  (keine Gedankenstriche, keine Emojis, kein Humor, keine Übertreibungen) gelten **auch im
  lockeren Register** weiter.
- **Anrede auf Vornamen-Basis, wenn der Kunde es vormacht.** Stellt sich die Ansprechperson
  in ihrer Anfrage selbst mit Vornamen vor („Ich bin Lazar") und signiert mit Vornamen
  („Viele Grüße, Lazar"), die Anrede passend unkonventionell spiegeln: „Hallo <Vorname>,".
  Wirkt persönlich und auf Augenhöhe, ohne anbiedernd zu sein. Grußformel bleibt dennoch die
  feste „Mit besten Grüßen". Die verbindlichen Don'ts gelten weiter. (Nutzer-Entscheidung
  Masterschool, GenAI-Instructor.)
- **Direktkunde/Endkunde mit KI-Affinität:** Hier sind konkrete Praxis-Belege mit echten
  Tool-/Methodennamen (Agentic AI, On-Premise-KI, Web Scraping, Supervised Fine-Tuning) ein
  Pluspunkt — anders als bei Agenturen, wo nur Ausschreibungs-Buzzwords zählen (siehe unten).
  Ein authentischer Beleg kann eine schwächere Anforderungs-Abdeckung (z. B. Web Scraping nur
  als ❔) überzeugend auffüllen, solange nichts Falsches behauptet wird.

## Anschreiben an Agenturen
Annahme: Der Agentur-Mitarbeiter hat fast keine Fachkenntnis und gleicht nur
Buzzwords und Zahlen mit der Ausschreibung ab.
- **Kurz und prägnant, Teaser-Charakter.** Nur klarstellen, welche wichtigen
  Anforderungen abgedeckt sind.
- **Keine Fachbegriffe, die nicht in der Ausschreibung vorkommen** (Produktnamen,
  Modellnamen, Protokolle wie Ollama, PyTorch, gpt-oss, Qwen, DDS, SOME/IP). Solche
  Begriffe sind für den Agentur-Mitarbeiter nur „Techno-Blabla". Nur die Buzzwords
  der Ausschreibung selbst aufgreifen.
- **Ausnahme bei Entwickler-/Spezialisten-Rollen** (Titel wie „Senior <Tool> Developer"):
  Hier zählt ein konkreter, verifizierter Praxis-Beleg zum geforderten Kern-Tool mehr als
  abstrakte Buzzword-Treffer. Dann sind kurze, konkrete Projektbeispiele mit echten
  Tool-/Komponenten-Namen vertretbar (z. B. n8n-Workflow mit Telegram-AI-Agent, RAG mit
  Embedding-Modell und Vektordatenbank), auch wenn diese Namen nicht in der Ausschreibung
  stehen. Möglichst an mindestens einem Begriff andocken, der **doch** genannt ist
  (Beispiel: „OpenAI" stand als Nice-to-have in der n8n-Ausschreibung). Vom Nutzer in der
  K2-/n8n-Bewerbung bewusst so entschieden.
  - **Einschränkung bei Agentur-Empfänger (Vorrang vor der Ausnahme):** Geht das Anschreiben an
    eine **Agentur** (nicht den Endkunden), bleibt es trotz Spezialisten-Rolle buzzword-orientiert.
    Konkrete Tool-Belege, die **nicht** in der Ausschreibung stehen, weglassen — für den
    Agentur-Mitarbeiter sind sie nur „Tech-Blabla". Die Details stehen im Lebenslauf, den der
    **Endkunde** bei einem Vorschlag erhält. (Nutzer-Entscheidung Computer Futures / SThree,
    Rolle „Senior Fullstack-Entwickler KI": eigener KI-Agent mit REST-API/MCP und RAG-Workflow
    mit Embeddings/Vektordatenbank bewusst aus dem Agentur-Anschreiben gestrichen.)
  - Gedankenstriche auch im **Entwurf-Header** (An:/Betreff:) vermeiden, nicht nur im Anschreiben.
  - **Kern-Tool der Ausschreibung belegt UND als Buzzword genannt (z. B. Vector CANoe):** dann
    den exakten Begriff der Ausschreibung **namentlich** nennen (nicht zu „Vector Tools" o. Ä.
    verallgemeinern), damit der Agentur-Mitarbeiter den Buzzword-Treffer sieht. Eine Mischform
    „Vector-Tools wie CANoe" nimmt den exakten Treffer mit und bleibt zugleich ehrlich breit.
    (Nutzer-Entscheidung Amoria Bond, Systemingenieur Automotive.)
  - **Bewusst etwas breitere Infrastruktur-Kompetenz durchscheinen lassen, wenn ein Ausschreibungs-Schlagwort es motiviert:** Steht ein Schlagwort wie **Backend** in der Ausschreibung, darf der Nutzer auch beim Agentur-Empfänger etwas Netzwerk-/Server-/Cloud-Kompetenz andeuten, obwohl die konkreten Begriffe nicht in der Ausschreibung stehen. Dann **allgemein verständliche** Begriffe wählen (z. B. „eigene Linux Root Server", „Private Cloud Services") statt zu spezieller, für den Agentur-MA nichtssagender Begriffe (z. B. „On-Premise KI-Server" wurde wieder gestrichen). Abwägung bleibt Nutzer-Entscheidung. (Nutzer-Entscheidung RecNow, Freelance Testautomatisierer Backend/Integration.)
  - **Persönliche Anfrage mit detailliertem Brief und benannten Kundensystemen (Ausnahme zur Buzzword-Beschränkung):**
    Schreibt der Agentur-Kontakt Thomas **persönlich** an und nennt im Projektangebot die **konkreten
    Systeme des Endkunden** (z. B. SharePoint, Jira, Confluence, Azure OpenAI, Intranet), darf das
    Anschreiben **beratend und systemspezifisch** auftreten: genau diese Systeme namentlich aufgreifen und
    einen darauf zugeschnittenen Lösungs-/Integrationsweg skizzieren. Die benannten Kundensysteme sind
    faktisch die Buzzwords der Ausschreibung, der Text bleibt also treffer-orientiert und wirkt zugleich
    kompetent statt generisch. Voraussetzung: nichts Falsches behaupten (Fähigkeits-/Umsetzbarkeitsaussagen
    statt Referenzprojekte, siehe `inhalte.md`). (Nutzer-Entscheidung Effection Network, AI / MCP Engineer.)
  - **Kern-Tool der Ausschreibung nicht belegt (z. B. UiPath):** Dann tragen die belegten gleichwertigen Tools die Substanz — sie konkret nennen und **jedes auf ein in der Ausschreibung genanntes System mappen** (Beispiel Amoria Bond / RPA: UI.Vision-Webshop-Automation ↔ webbasiertes Ticketsystem; Python-Oberflächenautomatisierung ↔ Oracle-Forms-Desktop-ERP; Power Automate Desktop als „RPA-Plattform evaluiert"). So entsteht ein glaubwürdiger Eignungsnachweis trotz fehlendem Kern-Tool, auch beim Agentur-Empfänger. (Nutzer-Entscheidung Amoria Bond, Process Automation & RPA UiPath.)

## „Eigene Einschätzung"-Absatz bei geforderter Eignungsbewertung
- Verlangt die Ausschreibung ausdrücklich eine **Einschätzung der Projekteignung** (und ggf. „Referenzprojekte wenn möglich"), einen kurzen Absatz „Eigene Einschätzung:" direkt nach der Einleitung setzen: knappe Passungs-Aussage plus **konkret benannte Referenzprojekte** (Arbeitgeber + Zeitraum). Das erfüllt Eignungs-Einschätzung und (optionale) Referenzprojekte in einem; ein separater Referenzen-Satz ist dann nicht nötig. (Nutzer-Entscheidung Amoria Bond.)

## Legacy-/Wissenslücke bei KI-affiner Rolle souverän rahmen
- Ergänzung zu „Lücken nicht erwähnen": Bei **ausdrücklich KI-affinen** Rollen darf eine kleine, klar benannte Wissenslücke (z. B. Oracle Forms) **als vernachlässigbar gerahmt** werden, statt sie ganz zu verschweigen, indem die KI-gestützte Arbeitsweise als Ausgleich gespielt wird („vielleicht fehlendes Detailwissen … fällt bei der effizienten Umsetzung kaum ins Gewicht, da State-of-the-Art KI-Werkzeuge die eigene Intelligenz ergänzen"). Nur bei KI-Rollen, wo das KI-gestützte Arbeiten selbst Teil des Nutzenversprechens ist. (Nutzer-Entscheidung Amoria Bond.)

## Coaching-/Schulungs-Rollen
- Hier sind konkrete eigene Praxis-/Tool-Belege auch beim **Agentur**-Empfänger erwünscht, wenn der
  Nutzer es will und sie die **Lehr-/Befähigungskompetenz** stützen (z. B. eigener CRM-API-/KI-Workflow
  als Nachweis für moderne AI-Workflows, REST-API und System Integration). Möglichst an
  Ausschreibungs-Buzzwords andocken (Make.com, OpenAI, APIs). Ausnahme zur sonst buzzword-orientierten
  Agentur-Regel; vom Nutzer für WorkGenius (Make.com-Coaching) so entschieden.

## Anrede bei unklarem Geschlecht
- Ist das Geschlecht der Ansprechperson aus dem Namen nicht eindeutig (z. B. nicht-deutsche
  Vornamen), in der **Signatur der Ausschreibung** nachsehen: Oft nennt sich die Person dort
  unter „Best regards," / „Mit freundlichen Grüßen" mit ihrem **bevorzugten (Kurz-)Namen**
  (Beispiel: Kontakt „Pisittha Kudtho", signiert aber als „Poppy" → Anrede „Dear Poppy,").
  Das löst die Geschlechtsfrage elegant und wirkt persönlicher als „Sehr geehrte Damen und Herren".
- Findet sich kein solcher Hinweis: neutral bleiben (DE „Sehr geehrte Damen und Herren,",
  EN „Hello <Vorname Nachname>,").

## Aufbau eines Anschreibens (Reihenfolge)
1. **Einleitung:** Begeisterung, sich sehr gern auf genau dieses Projekt zu bewerben.
   - **Dank nur, wenn Thomas angeschrieben wurde.** Hat Thomas die Projektbeschreibung
     selbst durch Suche gefunden (z. B. auf einem Portal), **nicht** für die Ausschreibung
     bedanken; direkt mit der Begeisterung einsteigen.
2. **Wichtigste Fakten** (jeweils als eigener Absatz mit Schlagwort am Anfang, da
   Bullet-Points im Mail-Editor oft nicht dargestellt werden). **Fett-Formatierung
   nur, wenn Rich-Text-Versand gesichert ist:** bei bekannter E-Mail-Adresse des Empfängers
   **oder** über ein Portal, das Rich-Text übernimmt (z. B. das **Hays-Portal**). Dann
   **sparsam** fetten, nämlich die Themen-Schlagworte mit Doppelpunkt am Absatzanfang sowie
   die interessantesten Informationen (meist Starttermin, Verfügbarkeit, Stundensatz).
   **Nur bei reinem Klartext-Kanal** (Portal-Nachricht ohne Rich-Text, E-Mail-Adresse
   unbekannt) **gar keine Textformatierungen verwenden** — Labels und Zahlen bleiben unformatiert.
   - **Verfügbarkeit:** ab wann, welcher Prozentsatz. **Interesse an langfristiger
     Zusammenarbeit nur erwähnen, wenn die Ausschreibung selbst eine Verlängerung nach der
     Erstbeauftragung in Aussicht stellt** (dann: „auch über die ersten <N> Monate hinaus
     interessiert"). Sagt die Ausschreibung nichts zu einer Verlängerung, **nichts** über
     eigenes Verlängerungs-Interesse schreiben.
   - **Stundensatz:** Keinen festen Satz nennen, sondern Verhandlungsbereitschaft
     signalisieren, indem der Satz als **Vorstellung** formuliert wird (in € netto, ggf.
     mit Randbedingungen). DE: „Meine All-in-Stundensatz-Vorstellung liegt bei 105 € netto."
     EN: „My all-in hourly rate expectation is 105 € net."
     - **Stundensatz mit Kalkulations-Annahmen begründen (löst zugleich offene Rahmenbedingungen):**
       Sind Rahmenbedingungen wie Remote-Anteil oder Auslastung unklar, lässt sich der Satz an
       **explizite Annahmen** koppeln und damit beides in einem Satz klären, z. B. „… liegt bei
       105 € netto, basierend auf den Annahmen 100 % Auslastung, Projektdauer mindestens 1 Monat,
       eine Woche Onboarding vor Ort und danach 100 % Remote". Wirkt transparent und kalkuliert die
       Vor-Ort-Phase sichtbar ein. (Nutzer-Entscheidung CONTRACTOR Consulting, KI Consultant Engineering.)
     - **Ausnahme — Festsatz der Ausschreibung plus Wunsch, erst Konditionen zu klären:**
       Nennt die Ausschreibung bereits einen festen Satz (z. B. 55 €/h Session-Zeit) und der
       Nutzer will zunächst nur Interesse signalisieren und offene Konditionen erfragen, **keinen
       eigenen Satz** ins Anschreiben setzen. Stattdessen gezielt die offenen Geld-/Rahmenfragen
       stellen (z. B. Session-Dauer, Vergütung der Kursvorbereitung). (Nutzer-Entscheidung
       Masterschool, GenAI-Instructor.)
   - **Vor-Ort-Termine** (falls Onsite gefordert): bis zu X Vor-Ort-Termine inkl.
     Reise-/Übernachtungskosten im All-in-Satz enthalten. **Bei stark onsite-lastigen
     Projekten im Großraum München** (Onsite-Ort lokal erreichbar) stattdessen als Stärke
     spielen: Präsenz „leicht und ohne Reise- oder Übernachtungskosten machbar".
   - **Remote-Anteil** (falls vorhanden): Leistung remote, dafür eigene Räume mit
     professionellem IT-Equipment im Ingenieurbüro in Unterhaching (Großraum München).
     Formulierung: Leistung „remote **in** meinem Ingenieurbüro", nie „aus meinem Ingenieurbüro".
3. **Kurzer Absatz:** was mich am Projekt am meisten reizt.
4. **Kurze Schilderung:** was ich einbringe und welche im Projekt geforderten
   Tätigkeiten ich bereits erbracht habe.
5. **Product-Lifecycle-Absatz (falls passend, vorvorletzter Absatz):** Hinweis, dass
   meine Kompetenz einen weiten Bereich abdeckt, von Requirements Engineering bis
   Validation/Deployment/Wissenstransfer. Verbunden mit dem Nutzen für den Kunden.
6. **Vorletzter/letzter Absatz:** Anhänge nennen („Gern sende ich Ihnen anbei meinen
   aktuellen Lebenslauf …"), Freude bei Interesse, Verfügbarkeit für Rückfragen/Gespräch.

## Job-Titel ungleich Ausschreibungstitel positiv rahmen
- Entsprechen die bisherigen Job-Titel des Lebenslaufs **nicht** dem Ausschreibungstitel
  (Beispiel: nie „Projektmanager", aber Projektmanagement geleistet), das offen ansprechen und
  positiv wenden: „Auch wenn meine bisherigen Positionen andere Titel trugen, war <X> in vielen
  von ihnen fester Bestandteil meiner Aufgaben …".
- **Immer mit konkretem Beleg erden**, nie als bloße Behauptung stehen lassen (Beispiel:
  „… etwa als Gruppenleiter mit bis zu zehn Mitarbeitern und Verantwortung für anspruchsvolle
  Zielvorgaben"). Eine ankerlose Behauptung wurde vom Nutzer zu Recht bemängelt (Zabel/Projektmanager).

## KI-Kompetenz als optionaler Zusatznutzen (fachfremde Rollen)
- Bei Rollen **ohne** KI-Bezug lässt sich die KI-Kompetenz als „bei Bedarf zusätzlich einsetzbar"
  anbieten, ohne von der Kernbewerbung abzulenken: ein eigener kurzer Absatz vor dem Anhänge-Absatz,
  z. B. „Bei Bedarf kann ich zusätzlich meine Kompetenz als TÜV-zertifizierter AI Consultant
  einsetzen, etwa um die <fachnahe> Arbeit mit generativer KI zu beschleunigen …".
- **Buzzword-Ebene halten**, keine Produkt-/Modellnamen (gilt besonders beim Agentur-Empfänger).
  Passender Anhang dazu: „Zertifikat AI Consultant".

## Erfüllung der Ausschreibungs-Wünsche
- Explizite Wünsche der Ausschreibung erfüllen: verlangt sie CV + Stundensatz per Mail,
  müssen **Stundensatz genannt** und **Anhang Lebenslauf erwähnt** werden.
- Fehlt die nötige Kontaktangabe (z. B. E-Mail des Ansprechpartners) → **anmerken**,
  dass sie noch fehlt, statt sie zu erfinden.

## Anhang-Format des Lebenslaufs/CV (verbindlich)
Format des Lebenslauf-/CV-Anhangs richtet sich nach dem **Empfänger-Typ**:
- **Agentur:** CV im **.doc**-Format anhängen (Agenturen passen den CV oft an).
- **Endkunde (Direktauftrag):** CV im **.pdf**-Format anhängen.
Gilt für deutschen Lebenslauf und englischen CV gleichermaßen.

## Header des Entwurfs
Immer angeben: Zielperson, Nachrichtenkanal + Zieladresse, Betreff, Anhänge.

**Ausnahme Freelancermap:** Bei Bewerbungen über das freelancermap-Portal **keine
Betreff-Zeile** in den Header aufnehmen — das Portal bietet beim Bewerben kein
Betreff-Feld. Zielperson, Kanal und Anhänge bleiben.

Beispiele:
```
An: Frau Candy Williams per E-Mail an C.Williams@brink.de
Betreff: …
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf, Zertifikat TÜV AI Consultant
```
Bei Versand über ein Portal statt E-Mail den Kanal entsprechend benennen (Zielperson
ggf. „Sehr geehrte Damen und Herren", falls keine namentliche Ansprechperson genannt):
```
An: Hays (Referenz 873996/1) über das Hays-Bewerberportal
Betreff: …
Anhänge: Lebenslauf_Dr-Ing_Thomas_Langer.pdf
```

## Grußformel (immer identisch)
Ohne Dr.-Titel, drei Leerzeichen vor dem Namen:
```
Mit besten Grüßen

   Thomas Langer
```

## Englische Bewerbungen
- **Englischer CV liegt vor:** Basisname `CV_Thomas_Langer_PhD` (Format empfängerabhängig,
  siehe Anhang-Format-Regel: Agentur `.doc`, Endkunde `.pdf`). Bei englischen Bewerbungen
  als Anhang nennen, nicht den deutschen Lebenslauf.
- **Anrede:** vollständiger Name, „Dear <Vorname Nachname>," (Nutzer-Präferenz, von der
  englischen Norm „Dear Ms <Nachname>" bewusst abweichend).
- **Grußformel (englisch):** „Best regards", danach drei Leerzeichen vor dem Namen:
  ```
  Best regards

     Thomas Langer
  ```
- **Anhänge-Absatz (englisch):** „Attached please find my current CV and my TÜV certificate
  as an AI Consultant."
- **Agentur-Buzzwords (englisch) nur aus der Ausschreibung übernehmen**, keine Produkt-/
  Modellnamen — gleiche Regel wie bei deutschen Agentur-Anschreiben.
