claude-regelwerk/AI/Regelwerk/schreibstil.md

type, status, title, summary, tags, created, updated

type	status	title	summary	tags	created	updated
resource	reference	Schreibstil	Ton und harte Grenzen für Anleitungen, Handouts, Kunden- und Codedoku — Kaffeepausen-Maßstab, Realität vor Stil, Referenzdokument.	regelwerk schreibstil dokumentation	2026-08-24	2026-09-05

Schreibstil

Angeordnet am 2026-08-24. Gilt für alles, was ein Mensch lesen soll: Anleitungen, Handouts, Kundendokumentation, Bookstack-Artikel, Projektdokumentation, Codedoku unter docs/, Sitzungszusammenfassungen.

Nicht gemeint sind Prüfprotokolle, Regelteile von Compliance-Dokumenten und alles, was jemand später gegen mich hält — dazu unten „Wo der Ton nicht gilt".

Der Maßstab

Erklär es so, wie du es einem guten Freund in der Kaffeepause erklären würdest — und zwar dem, der es hinterher wirklich umsetzen muss.

Das heißt konkret:

• Du sprichst zu jemandem. Nicht ins Leere, nicht in eine Zielgruppe. Also „du brauchst dafür" statt „es wird benötigt".
• Die Reihenfolge folgt dem Gespräch, nicht dem Handbuch. Zuerst wofür das gut ist, dann der Weg, dann die Fallstricke. Nicht: Definition, Architektur, Voraussetzungen, Schritt 1.
• Der Fallstrick kommt da, wo man reinläuft. Nicht gesammelt in einem Kapitel „Bekannte Probleme" am Ende.
• Ganze Sätze. Ein Stichpunkt ist keine Erklärung, sondern die Erinnerung an eine, die mal jemand hatte.
• Kein Vortragston. Keine Einleitung darüber, wie wichtig das Thema ist. Kein Fazit, das wiederholt, was oben stand.

Die Grenze — Realität vor Stil

Der Ton ändert sich, die Aussagen nicht. Vier Regeln, die keinen Ermessensspielraum haben:

1. Nichts erfinden. Keine Zahlen, keine Versionsnummern, keine Pfade, keine Fehlermeldungen aus dem Gedächtnis. Konkretheit kommt aus der Quelle oder gar nicht.
2. Nichts weichzeichnen. Wenn eine Aussage nur unter einer Bedingung stimmt, bleibt die Bedingung im Satz. Auch wenn er dadurch sperrig wird. Ein sperriger Satz, der stimmt, schlägt einen schönen, der beim Kunden bricht.
3. Lücken benennen, nicht überbrücken. „Ob das unter Rocky 10 genauso läuft, habe ich nicht geprüft" ist ein Ergebnis. Ein glatter Satz, der die Frage offen lässt, ohne es zu sagen, ist eine Falle.
4. Keine Position, die das Material nicht hergibt. Eine Empfehlung braucht einen Grund, der im Text steht. Sonst ist es Geschmack im Gewand einer Aussage.

Der Grund für die Härte: Vermenschlichen hat genau eine bekannte Fehlerart — es erfindet Konkretheit, damit der Text weniger nach Modell klingt. Bei einem Blogpost ist das peinlich. Bei einer Kundendokumentation steht am Ende jemand vor einem System, das anders reagiert als beschrieben.

Vorher / Nachher

Statt	Besser
„Im Anschluss erfolgt die Konfiguration des Dienstes."	„Danach konfigurierst du den Dienst."
„Es ist zu beachten, dass unter Umständen Probleme auftreten können."	„Auf Windows-Konsolen bricht das ab, wenn ein Umlaut in der Ausgabe steht — cp1252."
„Diese Lösung bietet zahlreiche Vorteile."	Streichen. Wenn es Vorteile gibt, benenne sie; wenn nicht, war der Satz leer.
„Best Practice ist die Verwendung von X."	„Ich nehme X, weil Y. Z ginge auch, kostet aber W."
„Studien zeigen, dass …"	Quelle nennen oder Behauptung streichen.
„Der Prozess ist nun abgeschlossen."	Streichen. Der Leser merkt, wenn die Anleitung aufhört.

Das Referenzdokument

Ton per Beispiel, nicht per Beschreibung — dieselbe Regel wie bei den Dokumentations-Großprojekten. Wenn ein Set von Dokumenten entsteht, bekommt jeder Subagent ein fertiges Referenzdokument mit. Das hier ist die Vorlage, an der sich alles ausrichtet:

Tote Links im Vault finden

Der Linkcheck zeigt dir, welche Wikilinks ins Leere zeigen. Er lässt Codeblöcke aus. Deshalb meldet er ein [[ $EUID -eq 0 ]] aus einem Bash-Beispiel nicht als toten Link. Der vault_doctor aus dem alten Toolkit tut genau das: Er fand dort 92 Leichen, und keine davon war echt.

PYTHONIOENCODING=utf-8 python .vault-tools/linkcheck/linkcheck.py --vault .

Das python ist kein Tippfehler. python3 startet auf dieser Maschine den Microsoft-Store-Stub und meldet „Python was not found", statt zu laufen. Ohne PYTHONIOENCODING zerlegt die Windows-Konsole außerdem die Umlaute in der Ausgabe.

Was der Linkcheck nicht sieht, sind Pfade in Backticks. Wer in einer Tagesnotiz AI/sessions/… statt [[AI/sessions/…]] schreibt, hat einen Verweis, den keine Prüfung kontrolliert.

Woran man den Ton erkennt: Der erste Satz sagt, wofür das Ding gut ist. Der Fallstrick steht direkt am Befehl, nicht in einem Kapitel weiter unten. Und die Stelle, die das Werkzeug nicht sieht, wird benannt statt umschifft.

Verhältnis zum humanizer-Skill

Diese Datei ist die Voreinstellung — so wird geschrieben, ohne dass jemand danach fragt.

Der humanizer-Skill ist der Nachbearbeitungsgang für Texte, die schon glatt geraten sind: er misst Satzlängen-Varianz objektiv (scripts/rhythmus.py), kennt die deutschen KI-Marker und hat dieselbe harte Regel „Nichts erfinden". Ihn rufen, wenn ein fertiger Entwurf nach Modell klingt oder ein Kundendokument den letzten Schliff braucht — nicht als Ersatz für sauberes Schreiben von Anfang an.

Nur für Claude Fable 5.1

Schreibt Fable 5.1 den Text, kommen drei modellspezifische Punkte aus AI/Regelwerk/fable-5-1 dazu (Abschnitte 5, 6, 7): Die Prosa neigt zu langen, dichten Sätzen ohne Absatzbrüche — also Absätze brechen und die wörtliche Formulierung der bildhaften vorziehen. Im Chat greift es seltener zu Listen und Fettdruck als frühere Modelle — bei vielgliedrigem Inhalt trotzdem eine Liste nehmen. Und beim Zusammenfassen übernimmt es Quellwortlaut eher unmarkiert — entweder als Zitat kennzeichnen oder in eigenen Worten wiedergeben. Andere Modelle entscheiden selbst, ob sie das übernehmen; die Regeln dieser Datei gelten für alle.

Wo der Ton nicht gilt

Gleichförmigkeit ist dort ein Feature, nicht ein Fehler:

• Regelteile von ISMS- und Compliance-Dokumenten. Eine Anforderung wird zitiert, nicht erzählt. Basis- und Zusatzkriterien bleiben getrennt und gekennzeichnet.
• Prüfprotokolle, Nachweise, Abnahmedokumente. Dort steht, was gemessen wurde, mit welchem Befehl, mit welchem Ergebnis.
• Kopfkommentare von Prüfskripten. Geltungsbereich und benannte Lücken, so nüchtern wie möglich — siehe AI/Regelwerk/pruefwerkzeuge.
• Rechtliche und vertragliche Texte. Präzision schlägt Lesbarkeit.

In allen vier Fällen darf der umgebende Text trotzdem in diesem Ton stehen — Einleitung, Begründung, Handlungsempfehlung. Nur der Kern bleibt formal.

Referenzen

• CLAUDE
• AI/Regelwerk/codeworkflow — Abschnitt „Produktivdateien und Codedoku"
• AI/Regelwerk/pruefwerkzeuge
• AI/Regelwerk/fable-5-1 — nur für Fable 5.1: Schreibdichte, Formatierung, Zitieren