Regelwerk, Agenten, Skills und Werkzeuge veröffentlichen

Erster Stand des öffentlichen Ausschnitts aus dem Vault. Die .gitignore
arbeitet als Positivliste: ausgeschlossen ist alles, eingeschlossen nur,
was ausdrücklich wieder aufgenommen wird. Notizen, Projekte, Finanzen,
das Sitzungsgedächtnis und settings.local.json bleiben damit außen vor.

Der Kundenname in AI/Regelwerk/seo.md ist durch eine neutrale
Bezeichnung ersetzt; die Regeln selbst sind unverändert.

Co-Authored-By: Claude Opus 5 <[email protected]>

AI/Regelwerk/schreibstil.md

@@ -0,0 +1,95 @@
+---
+type: resource
+status: reference
+title: Schreibstil
+summary: Ton und harte Grenzen für Anleitungen, Handouts, Kunden- und Codedoku — Kaffeepausen-Maßstab, Realität vor Stil, Referenzdokument.
+tags: [regelwerk, schreibstil, dokumentation]
+created: 2026-08-24
+updated: 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.
+>
+> ```bash
+> 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|fable-5-1.md]] 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|pruefwerkzeuge.md]].
+- **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|↑ Claude.md (Stamm)]]
+- [[AI/Regelwerk/codeworkflow|Codeworkflow]] — Abschnitt „Produktivdateien und Codedoku"
+- [[AI/Regelwerk/pruefwerkzeuge|Prüfwerkzeuge]]
+- [[AI/Regelwerk/fable-5-1|fable-5-1.md]] — nur für Fable 5.1: Schreibdichte, Formatierung, Zitieren