From 2ca19c9452e73ac6624be99c23619e3658e66a7d Mon Sep 17 00:00:00 2001 From: dschlueter Date: Tue, 7 Jul 2026 20:10:15 +0200 Subject: [PATCH] =?UTF-8?q?docs(prompts):=20enforce=20=C2=B15%=20length=20?= =?UTF-8?q?tolerance=20and=20coding=20correctness=20rules?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- example_system_prompts/system_prompt_coding.md | 2 ++ example_system_prompts/system_prompt_prosa.md | 1 + example_system_prompts/system_prompt_reden.md | 1 + 3 files changed, 4 insertions(+) diff --git a/example_system_prompts/system_prompt_coding.md b/example_system_prompts/system_prompt_coding.md index dfad0a4..fc1f0b6 100644 --- a/example_system_prompts/system_prompt_coding.md +++ b/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: diff --git a/example_system_prompts/system_prompt_prosa.md b/example_system_prompts/system_prompt_prosa.md index d3a2c14..1f5835d 100644 --- a/example_system_prompts/system_prompt_prosa.md +++ b/example_system_prompts/system_prompt_prosa.md @@ -59,6 +59,7 @@ Arbeitsweise pro Auftrag Umgang mit Nutzer-Vorgaben – Folge Vorgaben zu Genre, Länge, Perspektive, Epoche, Setting und Ton so genau wie möglich. – Wenn keine Länge vorgegeben ist, wähle eine dem Genre angemessene (Kurzgeschichte etwa 1000–1500 Wörter) und halte sie ein. +– Ist eine Länge vorgegeben (Wort- oder Zeichenzahl), halte sie strikt ein: erlaubt ist eine Abweichung von höchstens ±5 %. Zähle beim Schreiben mit und erweitere oder straffe gezielt, um die Vorgabe zu treffen; brich den Text nicht vorzeitig ab und blähe ihn nicht mit Füllsätzen auf. – Wenn Vorgaben widersprüchlich wirken, löse sie kreativ, aber konsistent (z.B. „humorvolle Dystopie“ → dunkles Setting mit feiner Ironie). – Frage nur dann nach Klarstellung, wenn die Aufgabe ohne Präzisierung nicht sinnvoll lösbar ist; ansonsten entscheide eigenständig, aber plausibel. diff --git a/example_system_prompts/system_prompt_reden.md b/example_system_prompts/system_prompt_reden.md index 03fecb7..c5518de 100644 --- a/example_system_prompts/system_prompt_reden.md +++ b/example_system_prompts/system_prompt_reden.md @@ -61,6 +61,7 @@ Arbeitsweise pro Redeauftrag Umgang mit Nutzer-Vorgaben – Folge Vorgaben zu Dauer/Länge (z.B. 5‑Minuten‑Rede vs. 30‑Minuten‑Rede) und Zielgruppe so genau wie möglich. Faustregel für gesprochenes Deutsch: ca. 130–150 Wörter pro Minute (5 Minuten ≈ 700 Wörter, 10 Minuten ≈ 1400 Wörter). +– Ist eine Länge oder Dauer vorgegeben, halte sie strikt ein: erlaubt ist eine Abweichung von höchstens ±5 % (bei Dauer bezogen auf die Wortzahl nach obiger Faustregel). Zähle beim Schreiben mit und straffe oder ergänze gezielt, um die Vorgabe zu treffen; brich nicht vorzeitig ab. – Wenn der Nutzer keine Angaben zur Zielgruppe macht, schreibe für ein erwachsenes, gemischtes Publikum mit durchschnittlichem Vorwissen. – Passe Niveau und Dichte an: für Laien mehr Beispiele und Erklärungen, für Fachpublikum mehr Präzision und Tiefe.