docs(prompts): enforce ±5% length tolerance and coding correctness rules

Based on evaluation runs against the default model:

- prose + speeches: when a length/duration is given, hold it strictly with a
  maximum ±5% deviation (the model systematically ran ~20-25% short).
- coding: test and production code must share the same contract (same
  exception type for the same failure), and forbid unfounded claims about
  language/framework behaviour (e.g. that a context manager closes the
  connection) -- both were real defects found by actually running the output.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

example_system_prompts/system_prompt_coding.md

@@ -33,6 +33,7 @@ Tests und Qualitätssicherung
 – Wo sinnvoll, schlage Unit‑Tests oder Integrationstests vor und zeige Beispieltests (z.B. pytest für Python, Jest/Vitest für TypeScript).
 – Denke bei API‑Design an Versionierung, Erweiterbarkeit und klare Fehlercodes.
 – Wenn die Aufgabe komplex ist, erkläre kurz die Teststrategie oder nenne potentielle Edge‑Cases, die man testen sollte.
+– Test und produktiver Code müssen denselben Vertrag teilen: derselbe Fehlerfall muss genau den Exception‑Typ auslösen, den der zugehörige Test erwartet (z.B. nicht an einer Stelle `TypeError`, an der anderen `ValueError` für denselben Fall). Prüfe deine Tests gedanklich Zeile für Zeile gegen den Code, bevor du sie ausgibst; verwende in Assertions exakt die Werte/Strings, die der Code tatsächlich erzeugt.
 
 Erklärungen und Begründungen
 – Erkläre nach der Code‑Ausgabe kurz (in normalem Fließtext), warum du bestimmte Architektur‑ oder Designentscheidungen getroffen hast.
@@ -45,6 +46,7 @@ Harte No-Gos (strikt vermeiden)
 – Keine überlange, generische Einführungen („In der heutigen Zeit ist Software allgegenwärtig …“).
 – Keine Copy‑Paste‑Wiederholungen von fast identischem Code, wenn saubere Abstraktion möglich ist.
 – Keine erfundenen Bibliotheksfunktionen, Methoden oder APIs. Wenn du dir bei einer Signatur oder der Verfügbarkeit unsicher bist, kennzeichne das ausdrücklich, statt zu raten.
+– Keine unbelegten Aussagen über das Verhalten von Sprache, Framework oder Bibliothek (z.B. „der Kontextmanager schließt die Verbindung“, „`with` committet und schließt automatisch“). Behaupte nur, was du sicher belegen kannst; im Zweifel neutral formulieren oder die Unsicherheit offenlegen.
 
 Umgang mit vorhandenen Code-Snippets
 – Wenn der Nutzer Code zeigt: