Style-Guide-Meta-Analyse 2026: Was 33 Guides verraten

Kurz gesagt: 15 Regeln bilden den Branchenkonsens, angeführt von der direkten Leser-Ansprache in 85 Prozent der Guides. Der Dissens verläuft entlang einer einzigen Achse (formal-technisch vs. konversational-markengetrieben). Sechs Themenfelder (AI-Content, Dark Mode, RTL-Layout, Voice-Interfaces, Sustainability, Collaboration-Sprache) werden in keinem der 33 Guides systematisch geregelt. Der synthetisierte Style Guide 2026 steht als AsciiDoc-Download kostenlos bereit.

Ihr Style Guide ist das meistignorierte Dokument in Ihrer Content- und Produkt-Organisation. Wir haben 33 davon gelesen: öffentlich zugängliche Content- und Writing-Style-Guides großer Technologie-Unternehmen, Design-Systeme, Redaktionshäuser und Accessibility-Organisationen. Von Apple und Google bis WCAG, von Mailchimp bis zur BBC. 1.636 extrahierte Regeln. 321 wörtliche Zitate. 13 Themenachsen.

Drei Befunde liegen vor. Erstens: Es gibt einen verblüffend stabilen Branchenkonsens aus 15 Kernregeln, auf die sich Apple, Google, Mailchimp und die US-Regierung im Wortlaut einigen. Zweitens: Der Dissens verläuft entlang einer einzigen Achse (formal-technisch versus konversational-markengetrieben) und erzeugt dort, wo er verläuft, gegensätzliche Regeln für Kontraktionen, Emoji, Anführungszeichen und Ausrufezeichen. Drittens: Ganze Themenfelder der Gegenwart (AI-Content, Voice-Interfaces, RTL-Layout, Dark Mode) tauchen im Korpus praktisch nicht auf.

Wer 2026 einen Style Guide schreibt, kann die ersten 80 Prozent aus dem Konsens übernehmen. Die restlichen 20 sind es, die zählen. (Einen Überblick zur übergreifenden Disziplin gibt unser Technical Writing Guide.)

Wie wir die Studie gebaut haben

Ausgewertet wurden 33 öffentlich zugängliche Style Guides. Der Korpus deckt das funktionale Spektrum ab:

• Tech-Doku-Guides (Google, Microsoft, GitLab, GitHub, MongoDB, Splunk, Red Hat, Rackspace, Aiven, DigitalOcean)
• Marken- und Voice-Guides (Mailchimp, Monzo, Buffer, The Writer)
• Design-System-Content-Guides (Atlassian, Shopify Polaris)
• Accessibility-Spezifikationen (WCAG 2.1, MDN)
• Journalistisch-redaktionelle Manuals (BBC)
• Akademisches Lehrbuch-PDF (Michigan State University)
• Reine Wortlisten (Apple Style Guide, Container Terminology, Coda Human Words)
• Meta-Verzeichnisse (Conscious Style Guide, Styleguides.io, Write The Docs)

Jeder Guide wurde in eine JSON-Struktur überführt, die Regeln pro Kategorie zählt, wörtliche Zitate erhält und thematische Cluster aggregiert. 13 Kategorien strukturieren die Analyse: Voice & Tone, Inclusive Language, Grammar, Punctuation, Formatting, Structure, Code Conventions, Accessibility, Linking, Numbers/Dates/Measures, UI Content, Global/Localization, Naming & Terminology. Als Konsens gilt, was mindestens 50 Prozent der Guides explizit vorgeben, nicht bloßer Keyword-Treffer, sondern inhaltlich gemünzte Regel. Als Dissens gilt, wenn mindestens drei Guides eine Richtung vorgeben und mindestens drei die Gegenrichtung. Einzelregeln aus genau einem Guide sind Nischen-Praxis.

Der Konsens: 15 Regeln, um die sich die Branche versammelt

Aus der Matrix lassen sich 15 Regeln ableiten, die 2024/25 den Stand der Praxis bilden. „Konsens” hat dabei zwei Ebenen: Drei Regeln überschreiten die 50-Prozent-Schwelle der expliziten Nennung im Wortlaut. Die übrigen elf sind gelebte Praxis, werden aber unterschiedlich stark verschriftlicht. Das Chart unten macht diese Trennung sichtbar.

Tonalität und Adressierung

„Be direct (‘add apps’ not ‘you can add apps’).” (Shopify Polaris)

Direkte Leser-Ansprache in zweiter Person. 28 von 33 Guides (85 Prozent) sprechen Sie direkt als „you” an, von Apple und Google über Microsoft und Splunk bis Plain Language und Mailchimp. „The user” und die dritte Person werden aktiv abgelehnt. Shopify Polaris formuliert die Haltung direkt: „Be direct (‘add apps’ not ‘you can add apps’)”. Google verlangt in seinem Developer-Documentation-Style-Guide explizit: „Use ‘you’, instead of ‘the user’ or ‘they’”.

Active Voice als Default, Passiv als begründete Ausnahme. 16 Guides schreiben Active Voice explizit vor; nur GitHub (Audit-Logs) und MSU (Executive Summaries) formulieren legitime Ausnahmen. Der US-Federal-Plain-Language-Guide kanonisiert den Default in einem Merksatz: „Not ‘It must be done,’ but ‘You must do it.’” GitLab begründet pragmatisch: „text is easier to understand and to translate if you use active voice instead of passive.”

Formelle Jubel-Wörter („successfully”, „Success!”) streichen. Atlassian, Shopify und Mailchimp empfehlen, UI-Meldungen auf die Handlung zu reduzieren, nicht auf die Feier. Atlassians Merksatz ist einzigartig im Korpus: „These are low commitment experiences, we want to give flowers not puppies.”

Klarheit und Lesbarkeit

„Be friendly and conversational. No. Robot. Words.” (Microsoft Writing Style Guide)

Plain Language, einfaches Vokabular, keine Buzzwords. 18 Guides argumentieren gegen Jargon, Idiome und aufgeblasene Wörter. Microsoft fasst die Schule in drei Punkten zusammen: „Be friendly and conversational. No. Robot. Words.” Google präzisiert am Beispiel: „use ‘start’ not ‘commence’, ‘use’ not ‘utilize’”. Der Federal Plain Language Guide liefert die prinzipielle Begründung: „Complexity is the greatest enemy of clear communication.”

Idiome, Metaphern und lateinische Abkürzungen vermeiden. Mindestens acht Guides explizit, deutlich mehr implizit. Atlassian verbannt „piece of cake” sowie „e.g.”, „i.e.”, „etc.”, „&” als nicht lokalisierungsfreundlich. GitHub schreibt: „Avoid regional idioms, slang, stacked nouns”. Google geht so weit, sogar branchenübliche Fachbegriffe zu hinterfragen: „Don’t use casing-style names like ‘camel case’ or ‘snake case’ in docs — they don’t translate well.”

Zahlen 0–9 ausgeschrieben, ab 10 als Ziffern. Der klassische Microsoft-AP-Default ist die gesetzte Regel bei Atlassian, Datagrok, GitLab und MSU. Splunk nutzt Ziffern konsequent für alle Mess- und Versionsangaben; Apple hält Dezimal- und Telefonnummern als Sonderfall.

Inklusion

„Don’t use terms like ‘sanity check’, which associates mental health with being functional.” (Apple Style Guide)

Geschlechtergerechte Sprache, Singular „they” als Default. 20 Guides (61 Prozent) fordern gender-neutrale Sprache; mindestens acht (Apple, Atlassian, Buffer, Datagrok, MongoDB, Splunk, The Writer, Conscious Style) nennen Singular „they” ausdrücklich. Apple: „it’s OK to use they, their, or them as a singular, gender-neutral pronoun.”

Keine mentalen, rassisierten oder gewaltnormativen Metaphern. Fünf Tech-Guides (Apple, GitLab, Google, Monzo, Splunk) ersetzen Begriffe wie sanity check, blacklist/whitelist oder kill systematisch. Apple: „don’t use terms like ‘sanity check’, which associates mental health with being functional.” Monzo ergänzt: „We use ‘blocklist’ and ‘allowlist’ instead”. Es ist der stärkste neu etablierte Konsens-Punkt der letzten fünf Jahre.

Person-first oder Identity-first, nach Kontext. Sechs Guides thematisieren die Debatte, alle landen beim gleichen Kompromiss: Community fragen. Apple und Conscious Style halten die Wahl explizit offen. Splunk setzt Identity-first als Default, wenn die Community es bevorzugt („autistic person”, „Deaf community”). Buffer fasst die gemeinsame Haltung zusammen: „Labels are for boxes, not people.”

Accessibility

„No ARIA is better than bad ARIA.” (MDN Web Docs)

Beschreibende Link-Texte, niemals „click here” oder „learn more”. 16 Guides dokumentieren diese Regel: MDN, Accessible Social, Aiven, Mailchimp, Plain Language, Shopify, Splunk und andere. Aiven: „Never use ‘here’ as link text”. Die Begründung ist durchgängig: Screen-Reader-Nutzer navigieren häufig über eine Link-Liste; kontextlose Links sind unbrauchbar.

Alt-Text für informative Bilder. 15 Guides normieren Alt-Text; Shopify, Splunk und MDN präzisieren die Abgrenzung gegen dekorative Bilder. Accessible Social ist unmissverständlich: „Auto-generated alt text created by an artificial intelligence program should never be used in place of a custom image description written by a human.”

Lückenlose Heading-Hierarchie, Kontrast 4.5 : 1, Keyboard-Operabilität. MDN: „Headings must not break hierarchical structure”. GitLab: „H1 comes from page metadata; do not add an H1 in Markdown and do not skip heading levels.” Die Kontrastgrenze 4.5:1 (Normaltext) bzw. 3:1 (Large Text) wird von MDN, Atlassian, Google und WCAG deckungsgleich genannt.

Typografie und Formatierung

„When in doubt, don’t capitalize.” (Microsoft Writing Style Guide)

Oxford-/Serial-Komma ist Standard. Alle sieben Guides, die das Thema ausdrücklich aufgreifen (Apple, Mailchimp, MSU, Microsoft, MongoDB, Shopify, The Writer), sind dafür. Kein einziger Guide im Korpus verbietet das Oxford-Komma. The Writer nennt es bemerkenswerterweise eine „grey area”, nutzt es aber. (Typografische Details für Dokumente vertiefen wir im Typography Guide.)

Non-breaking Space zwischen Zahl und Einheit. Atlassian, Google, GitLab, MSU und Splunk formulieren deckungsgleich, Splunk wörtlich: „Add a nonbreaking space between the numeral and the rate measurement.” GitLab zeigt Beispiel: „128 GB”.

Sentence Case in Überschriften und UI-Labels. Acht Guides legen Sentence Case als Default fest. Microsofts Merkregel ist so kompakt wie universell: „When in doubt, don’t capitalize.” Das ist ein enger Konsens gegen das US-amerikanische Title-Case-Erbe.

Ausrufezeichen: sparsam, wenn überhaupt. Jeder Guide, der Position bezieht, zeigt in dieselbe Richtung. Drei verbieten sie komplett (Developer Style Guide, Splunk, The Writer), vier begrenzen auf maximal eines pro Seite (Atlassian, Shopify, Google, Aiven). Kein einziger Guide im Korpus empfiehlt den emphatischen Einsatz. Developer Style Guide bringt das Register auf den Punkt: „technical documentation is not a gossip magazine.” Google ergänzt das Accessibility-Argument: manche Screen-Reader lesen Satzzeichen nicht vor.

Und eine Bonus-Regel, die quer durch alle Cluster läuft: Vier Guides (Apple, GitLab, Google, Splunk) fordern explizit, Produktnamen nie als Verb und nie als Possessive zu verwenden. Google: „Don’t use product names or feature names as verbs.” Splunk: „Don’t use ‘Splunk’ in the possessive form, which can dilute the trademark.”

Der Dissens: eine Achse, vier Symptome

Der Dissens im Korpus ist nicht zufällig verteilt, sondern folgt einer klaren Bruchlinie: formal-technisch (akademisch, traditionell, risiko-avers) gegen konversational-markengetrieben (Consumer-Product, Voice-led). Fast alle Einzelkonflikte sind Projektionen dieser Grundspannung.

Kontraktionen: erlaubt oder tabu

„Use contractions, where possible, as they convey a conversational, friendly tone.” (Atlassian Design System)

Das Lager „erlaubt” umfasst neun Guides (Apple, Atlassian, Datagrok, GitLab, Microsoft, Shopify, Splunk, Mailchimp, The Writer). Atlassians Begründung steht für die Gruppe: „Use contractions, where possible, as they convey a conversational, friendly tone.” Splunk präzisiert: nur im Präsens und Futur, nicht im Past Tense. Das Lager „verboten” umfasst MSU, die Red Hat Documentation Guidelines und Teile von DigitalOcean. MSU ist am schärfsten: „Contractions are not to be used in technical writing.” Die Lagerlinie verläuft exakt zwischen Produkt- und Marketing-Doku einerseits und akademisch-wissenschaftlichem Report andererseits.

Anführungszeichen: gerade oder typografisch

„Don’t use curly quotes. Use straight quotes instead.” (Datagrok Writing Style)

Das Lager „curly/smart” umfasst Apple und Atlassian für Prosa und UI. Apple: „Use curly opening and closing quotation marks except in code font.” Das Lager „straight” umfasst GitLab, Google, Splunk und Datagrok. Datagrok: „Don’t use curly quotes. Use straight quotes instead.” Der Graben ist funktional: Developer-Docs wollen keine Brüche im Terminal-Output, Brand-Copy will typografische Sauberkeit.

Title Case versus Sentence Case

„Use sentence case for document titles and headings.” (Google Developer Documentation Style Guide)

Acht Guides verlangen Sentence Case (Atlassian, Datagrok, Developer Style Guide, Google, Mailchimp Sub-Nav, Microsoft, Shopify, Accessible Social). Vier halten an Title Case fest (Linode, Mailchimp Haupt-Nav, Container Terminology, GitLab für Produktnamen). Mailchimp praktiziert intern einen dritten Weg: Title Case nur für Haupt-Navigation und Form-Titles, Sentence Case für Sub-Navigation, Checkboxes und Radio Buttons. Microsoft bleibt dogmatisch: „When in doubt, don’t capitalize.”

Emoji: bewusst nutzen oder vermeiden

„With intention — to highlight, not to decorate.” (CLI Guidelines)

Fünf Guides verbieten Emoji (DigitalOcean, GitLab, GitHub, Developer Style Guide, Splunk im Chatbot-Kontext), sechs erlauben sie bewusst (Mailchimp, Buffer, Aiven, CLI Guidelines, Accessible Social, Monzo). CLI Guidelines formuliert die vielleicht schönste Richtlinie im gesamten Korpus: Emojis „with intention — to highlight, not to decorate.” Accessible Social setzt pragmatische Grenzen: maximal drei Emoji pro Post, keine reinen Emoji-Kolonnen, nicht am Anfang einer Zeile, weil Screen-Reader sie dort oft überspringen.

Die Trennung folgt dem klassischen Register-Muster: Doku nein, Marketing und Community ja. Wer genau hinsieht, erkennt: Wer Emoji erlaubt, erlaubt meist auch Kontraktionen und Sentence Case. Wer Curly Quotes verbietet, verbietet meist auch Emoji. Der Dissens ist in Wahrheit ein Register-Cluster.

Welche Themen gepflegt sind, und welche vernachlässigt

Nicht jede Kategorie wird gleich dicht dokumentiert. Produkt- und Markennamen sind mit Abstand die dichteste Achse (92 Prozent aller Guides treffen mindestens eine Aussage dazu). Global/Localization liegt am unteren Ende (49 Prozent): paradox für einen Korpus, in dem Übersetzung regelmäßig als Grund für andere Regeln zitiert wird.

Was die Tabelle erzählt: Die Basics sind dicht dokumentiert. Voice, Struktur, Formatierung, Grammatik sind die Felder, in denen fast jeder Guide eine Haltung hat. Die Ränder werden dünn: Code-Konventionen (54 Prozent), Zahlen und Datumsformate (51 Prozent), Lokalisierung (49 Prozent). Gerade die Kategorie, die in einer globalisierten Content-Welt zentral sein müsste, wird am seltensten systematisch behandelt.

Die Hauptbotschaft: Was jeder Guide regelt, ist Tonalität und Terminologie. Was zu wenige regeln, sind Übersetzbarkeit und technische Notation.

Was 2026 in keinem Guide steht

Der Korpus hat blinde Flecken, die 2026 auffällig sind.

AI- und LLM-Content. Keiner der 33 Guides formuliert Regeln zum Umgang mit LLM-generierten Inhalten, zu Prompt-Schreibweisen oder zur Zitation halluzinierter Passagen. Accessible Social streift das Thema negativ („Never rely on auto-generated alt text”), Splunk hat eine Chatbot-Tonalitäts-Sektion. Das war’s. In einem Jahr, in dem jede größere Content-Organisation mit Copilot- und Perplexity-Output arbeitet, ist das eine auffällige Leerstelle.

Voice-Interfaces. Außerhalb von Splunks Chatbot-Kapitel tauchen Voice-UIs nirgends auf. Keine Regel zu Prosodie, zu Pausen-Zeichensetzung, zu Screen-Reader-first-Formulierung in UI-Text.

Dark Mode, Farb-Tokens, semantische Farben. Null systematische Regeln. Design-Systems sprechen über Farben, aber nicht über Farbtoken-Sprache („color.status.error”) oder über Dark-Mode-Kontrast-Strategien.

RTL-Layout und CJK-Line-Breaking. Null native Treffer. RTL (right-to-left) bezieht sich auf Schriften wie Arabisch und Hebräisch; CJK steht für Chinesisch, Japanisch und Koreanisch, Sprachen, bei denen Typografie, Zeilenumbrüche und Satzzeichen fundamental anders funktionieren als in der lateinischen Schrift. Google und Splunk empfehlen, keine direktionalen Hinweise („rechts daneben”) zu verwenden; das ist der einzige RTL-Einschlag. Arabisch, Hebräisch, CJK-Satzregeln: Fehlanzeige.

Sustainability und Content-Weight. Null Guides. Keine Regel zu Bild-Budgets, keine zu Text-Kompressibilität, keine zur CO₂-Bilanz medialer Inhalte.

Collaboration-Sprache. Keine Guides zu PR-Titeln, Commit-Messages, Review-Ton. Ein Feld, in dem täglich Millionen von Wörtern entstehen, ohne Style Guide.

Die Botschaft: Wenn Sie 2026 einen Style Guide schreiben, haben Sie hier freie Fläche und keinen Grund, sie leer zu lassen.

Acht Typen, ein Korpus

Die 33 Guides sind keine homogene Gruppe. Sie lassen sich in acht klar unterscheidbare Typen clustern, und jeder Typ hat andere Stärken und Blindspots.

Die Tech-Doku-Fraktion (zehn Guides) ist dicht bei Code-Konventionen, Terminologie und Lokalisierung. Sie schreibt präzise, sie ist disziplinierter als der Rest. Aber sie schweigt zu Brand-Voice, Humor und Emoji-Register. Mailchimps „Wink statt Schrei” findet hier nicht statt. Die Brand- und Voice-Fraktion (vier Guides) regelt Tonalitäts-Spektren, UI-Mikrocopy und inklusive Markenführung mit einer Wärme, die Tech-Doku nicht kennt. Sie schreibt selten einen präzisen Platzhalter-Style auf.

Die Design-Systems (Atlassian, Shopify Polaris) sind der seltene Fall, in dem beides zusammenkommt: UI-Content mit klarer Brand-Stimme, Error-Messages mit Accessibility-Disziplin. Die Accessibility-Specs (WCAG, MDN, Accessible Social) definieren die technischen Regeln des Web, beschreiben aber nicht, wie eine Marke klingt.

Editorial-Guides (BBC, MSU, Plain Language, Datagrok) sind alt, erprobt und konservativ; sie schweigen zu UI-Content und Code. Wortlisten (Apple Style Guide, Human Words, Container Terminology) sind Nachschlagewerke, keine Philosophien. Meta-Verzeichnisse (Conscious Style, Styleguides.io, Write the Docs) treffen keine eigenen Entscheidungen, sie verweisen. CLI- und Developer-Guides (CLI Guidelines, Linode, Developer Style Guide) haben einen eigenen Ton: imperativ, knapp, unironisch.

Wer einen Style Guide baut, wählt zuerst seinen Typ. Ein Produkt-Guide ist kein Editorial-Manual, und auch kein Accessibility-Spec. Die Konsens-Regeln sind überall dieselben, aber die Gewichtung, die Beispiele und der Ton folgen dem Typ.

Sieben Bausteine für 2026

Aus der Matrix lassen sich sieben Handlungsempfehlungen ableiten, die jeder moderne Guide adressieren sollte.

1. Direkte Leseransprache in 2. Person, Active Voice, Sentence Case als Baseline. Keine Diskussion. 85 Prozent der Branche haben entschieden (auf Deutsch ist die Form, Sie oder Du, eine separate Register-Entscheidung).
2. Inklusive Terminologie mit konkreter Ersatzliste. Kein „sanity check”, keine „blacklist”, keine „master/slave”, jeweils mit dem Ersatzwort daneben. Ohne Ersatzliste bleibt der Guide vage.
3. Accessibility als Grammatik, nicht als Anhang. Link-Texte, Alt-Text, Heading-Hierarchie und Kontrast in denselben Review wie Tippfehler.
4. Explizite Register-Entscheidung. Kontraktionen ja oder nein? Emoji ja oder nein? Curly oder straight quotes? Ausrufezeichen? Diese vier Entscheidungen trennen Ihr Produkt-Register von jedem anderen. Dokumentieren Sie sie.
5. AI-Content-Policy. Halluzinations-Review, Kennzeichnung, manuelle Alt-Text-Pflicht, Prompt-als-Code-Regel. Kein Guide der Branche hat das. Sie können die Ersten sein. Den redaktionellen Rahmen skizzieren wir in wie KI Technical Writer unterstützt.
6. Lokalisierbar formulieren. Keine Idiome, keine direktionalen Hinweise, keine gestackten Substantive, Raum für 30 % Expansion in UI-Strings. Die dünnste Achse im Korpus hat die meisten Konsequenzen.
7. Pre-Publish-Checkliste. Zehn Fragen, nicht fünfzig. Michigan State macht das vor, Mailchimp macht das vor, Atlassian macht das vor. Wer keine Checkliste im Guide hat, hat keinen anwendbaren Guide.

Häufige Fragen

Wie viele Style Guides empfehlen die direkte Leser-Ansprache in zweiter Person?
28 von 33 Guides (85 Prozent) sprechen den Leser als „you” an, von Apple und Google über Microsoft, Splunk und Plain Language bis Mailchimp. „The user” und die dritte Person werden im gesamten Korpus aktiv abgelehnt.

Welche Style Guides regeln AI- und LLM-Content?
Keiner der 33 analysierten Guides formuliert systematische Regeln zum Umgang mit LLM-generierten Inhalten, zu Prompt-Schreibweisen oder zur Zitation halluzinierter Passagen. Accessible Social streift das Thema negativ („Never rely on auto-generated alt text”) und Splunk hat eine Chatbot-Tonalitäts-Sektion. Das ist alles.

Ist das Oxford-Komma der Branchenstandard?
Ja. Alle sieben Guides, die das Thema ausdrücklich aufgreifen (Apple, Mailchimp, MSU, Microsoft, MongoDB, Shopify, The Writer), sind dafür. Kein einziger Guide im 33er-Korpus verbietet das Oxford-Komma.

Sentence Case oder Title Case für Überschriften?
Acht Guides verlangen Sentence Case (Atlassian, Google, Microsoft, Shopify und andere). Vier halten an Title Case fest (Linode, Mailchimp Haupt-Navigation, Container Terminology, GitLab für Produktnamen). Der Trend 2026 zeigt klar in Richtung Sentence Case.

Welche Themen decken die 33 Style Guides gar nicht ab?
Sechs Themenfelder sind im Korpus systematisch ungeregelt: AI- und LLM-Content, Dark Mode und Farb-Tokens, RTL-Layout und CJK-Typografie, Sustainability und Content-Weight, Collaboration-Sprache (Commit-Messages, PR-Titel, Review-Ton) sowie generative UI-Texte. Voice-Interfaces, Video-Captions und Neurodiversität tauchen in genau einem Guide auf.

Wir haben die Befunde in einen anwendbaren Internal Style Guide destilliert: 17 Paragraphen, von Voice & Tone bis AI-Content, mit expliziten Unsere Regel-Entscheidungen dort, wo die Branche sich uneinig ist. Acht Pro-Tipps aus einzelnen Guides, die sonst im Rauschen untergehen (Atlassians „Flowers not puppies” für Success-Messages, DigitalOceans sammy als Default-Beispielname, Linodes „Lazy Numbering” in Markdown-Listen).

Die Datei ist in AsciiDoc geschrieben und kann in adoc Studio direkt geöffnet, angepasst und als PDF oder HTML exportiert werden. Tabellen, Admonitions (NOTE/TIP/IMPORTANT/WARNING), Quote-Blöcke und ein automatisches Inhaltsverzeichnis sind im Doc-Header bereits konfiguriert. Teams, die ihren Style Guide auf mehrere Dateien aufteilen, profitieren vom modularen Dokumentations-Ansatz mit AsciiDoc-Includes.

Die langweilige Wahrheit: Ihr Guide wird wahrscheinlich zu 80 Prozent aus Konsens-Regeln bestehen, die alle anderen auch haben. Der Wert liegt in den restlichen 20, also in expliziten Entscheidungen zu Register, Terminologie, AI-Content und Accessibility. Schreiben Sie sie auf, begründen Sie sie, und lassen Sie sich von Mailchimp den Ton setzen: „We prefer winking to shouting.”