diff --git a/prompts/kapitel.md b/prompts/kapitel.md index 493fbd4..e88ea27 100644 --- a/prompts/kapitel.md +++ b/prompts/kapitel.md @@ -7,7 +7,7 @@ Aufgabe: **Kapitel {{n}} – {{kapitel_titel}}**, Datei `buch/{{datei}}`, mit ge Arbeite in diesem Loop: 1. RECHERCHE in den lokalen Quellen (siehe QUELLEN.md): Verstehe die Sache anhand von Quellcode, Referenz, Doku bzw. Abstracts, bevor du schreibst. Online nur, wenn lokal nicht klärbar und QUELLEN.md es erlaubt. 2. SCHREIBEN mit Write (bei Länge in mehreren Schritten, dann anhängen). -3. VERIFIZIEREN: Lies das fertige Kapitel vollständig. Prüfe JEDE Tatsachenangabe (Bezeichner, Signaturen, Versionsangaben, Namen, Jahre, Zahlen, Studienergebnisse) gegen die Quellen; führe Codebeispiele aus, wo STIL.md das verlangt. Korrigiere oder entschärfe alles Unbelegte. +3. VERIFIZIEREN: Lies das fertige Kapitel vollständig. Prüfe JEDE Tatsachenangabe (Bezeichner, Signaturen, Versionsangaben, Namen, Jahre, Zahlen, Studienergebnisse) gegen die Quellen; führe Codebeispiele aus, wo STIL.md das verlangt – im Gerüst unter `arbeit/`, ins Buch kommt nur der Kern. Korrigiere oder entschärfe alles Unbelegte. 4. PRÜFEN gegen STIL.md: Überschriften exakt wie in der Gliederung, keine Übungen/Merkkästen/Zusammenfassungen/Literaturlisten, Prosa statt Listenwüste, keine Verweisklammern, keine Wiederholung von Themen anderer Kapitel, Umfang, Umlaute. Überarbeite, bis alles passt. Arbeitsdateien (Testskripte, Notizen) nur unter `arbeit/kapitel-{{n}}/` anlegen, nicht in `buch/` oder `quellen/`. Keine persönlichen Daten an externe Dienste senden. diff --git a/prompts/pruefung.md b/prompts/pruefung.md index bc6e293..eae7817 100644 --- a/prompts/pruefung.md +++ b/prompts/pruefung.md @@ -11,7 +11,7 @@ Loop, bis nichts mehr zu korrigieren ist: 1. Lies das Kapitel komplett. Extrahiere alle überprüfbaren Behauptungen: Bezeichner und Signaturen, Versionsangaben, Studien (Autoren, Jahr, Design, Stichprobe, Ergebnis, Effektgröße), Zahlen, Zitate, Verhaltensbeschreibungen („was passiert wann“), Zuschreibungen („X hat Y eingeführt“), Textdiagramme (jedes Element und jeder Pfeil gegen Quellcode/Doku) und Ausgabeblöcke (gegen den eigenen Testlauf). 2. Verifiziere möglichst ALLE gegen die lokalen Quellen (QUELLEN.md). Priorisiere nach Fehlerwahrscheinlichkeit. Führe Codebeispiele aus bzw. teste beschriebenes Verhalten mit kleinen Skripten, wo STIL.md das vorsieht. Versionsangaben gegen Tags/Changelogs prüfen. Achte besonders auf: falsche Zuschreibungen, verdrehte Effektrichtungen, überzogene Kausalaussagen aus Korrelationsstudien, erfundene Stichprobengrößen, veraltete oder erfundene Bezeichner, Doku-Aussagen, die dem Quellcode widersprechen (dann gilt der Quellcode). 3. Korrigiere Fehler direkt in der Datei mit Edit (minimal-invasiv, Stil beibehalten). Unbelegbares vorsichtiger formulieren oder streichen. -4. Prüfe Form: Überschriften exakt wie GLIEDERUNG.md; keine Übungen/Merkkästen/Zusammenfassungen/Literaturlisten; keine Verweisklammern „(→ …)“ und keine Rückverweise auf frühere Abschnitte; Vorausverweise nur als Halbsatz und nur, wenn das Thema dort laut Gliederung steht; keine größeren Doppelungen mit Themen, die in andere Kapitel gehören (dann kürzen und verweisen); Rechtschreibung, Umlaute, Markdown. Satzbau: Sätze über 30 Wörter in mehrere auflösen, Inhalt unverändert; Zielschnitt unter 20 Wörter je Satz. Sätze mit drei und mehr Code-Bezeichnern entflechten: in Worten erklären, Namenslisten in eine Tabelle oder ein Codebeispiel. Verständlichkeit: Begriffe, die der Abschnitt benutzt, ohne sie bis dahin eingeführt zu haben, kurz erklären oder auf die Einführung verweisen; Interna, die kein sichtbares Verhalten erklären, streichen; Zwischenabschnitte unter 150 Wörtern mit dem Nachbarn zusammenlegen; Gedankensprünge schließen, wo zwischen zwei Sätzen oder Absätzen die Verbindung fehlt. Umfang: Abschnitte über 120 % ihres Richtwerts aus der Gliederung (`(kurz)` ≈ 800, ohne Angabe ≈ 1.300, `(lang)` ≈ 2.000 Wörter) straffen – zuerst Wiederholungen und Quellenformeln ohne Informationswert, keine Fakten oder Beispiele streichen. +4. Prüfe Form: Überschriften exakt wie GLIEDERUNG.md; keine Übungen/Merkkästen/Zusammenfassungen/Literaturlisten; keine Verweisklammern „(→ …)“ und keine Rückverweise auf frühere Abschnitte; Vorausverweise nur als Halbsatz und nur, wenn das Thema dort laut Gliederung steht; keine größeren Doppelungen mit Themen, die in andere Kapitel gehören (dann kürzen und verweisen); Rechtschreibung, Umlaute, Markdown. Satzbau: Sätze über 30 Wörter in mehrere auflösen, Inhalt unverändert; Zielschnitt unter 20 Wörter je Satz. Sätze mit drei und mehr Code-Bezeichnern entflechten: in Worten erklären, Namenslisten streichen. Verständlichkeit: Begriffe, die der Abschnitt benutzt, ohne sie bis dahin eingeführt zu haben, kurz erklären oder auf die Einführung verweisen; Interna, die kein sichtbares Verhalten erklären, streichen; Zwischenabschnitte unter 150 Wörtern mit dem Nachbarn zusammenlegen; Gedankensprünge schließen, wo zwischen zwei Sätzen oder Absätzen die Verbindung fehlt. Umfang: Abschnitte über 120 % ihres Richtwerts aus der Gliederung (`(kurz)` ≈ 800, ohne Angabe ≈ 1.300, `(lang)` ≈ 2.000 Wörter) straffen – zuerst Wiederholungen und Quellenformeln ohne Informationswert, keine Fakten oder Beispiele streichen. 5. Wiederhole, bis du keine Fehler mehr findest. Ändere nur `buch/{{datei}}`. Arbeitsdateien nur unter `arbeit/pruefung-{{n}}/`. Keine persönlichen Daten an externe Dienste senden. diff --git a/prompts/stil_basis.md b/prompts/stil_basis.md index 44f40ea..c85ac0c 100644 --- a/prompts/stil_basis.md +++ b/prompts/stil_basis.md @@ -5,13 +5,16 @@ Ein deutschsprachiges Sachbuch, das **Verständnis** vermittelt: Wie ist die Sac - Sprache: Deutsch, korrekte Umlaute und ß, gut lesbare Sachbuchprosa. Keine direkte Anrede als Stilmittel; „wir“ sparsam. - Satzbau: Sätze meist 14–18 Wörter, selten über 25, nie über 35. Höchstens ein Nebensatz je Satz, keine Semikolon-Ketten. Ein Gedanke je Satz; Bedingung und Folge dürfen zusammenstehen. Aktiv statt Nominalstil. - Wortwahl: Verben statt Substantivierungen („prüfen“ statt „eine Prüfung vornehmen“, „wahrnehmen“ statt „die Wahrnehmung erfolgt“). Lange zusammengesetzte Wörter nur, wenn sie der Fachbegriff sind; sonst umschreiben oder bei der ersten Nennung erklären. Keine Füllwörter („grundsätzlich“, „im Wesentlichen“, „durchaus“). -- Code-Bezeichner im Fließtext nur, wenn der Satz von genau diesem Bezeichner handelt. Erst in Worten erklären, was etwas tut, dann den Namen nennen. Keine Aufzählungen von Methoden- oder Klassennamen im Satz: Solche Listen gehören in eine kleine Tabelle (Name | Zweck) oder in ein Codebeispiel. Faustregel: höchstens ein Bezeichner je Satz, selten zwei. +- Code-Bezeichner im Fließtext nur, wenn der Satz von genau diesem Bezeichner handelt. Erst in Worten erklären, was etwas tut, dann den Namen nennen. Keine Aufzählungen von Methoden-, Eigenschafts- oder Klassennamen, weder im Satz noch als Tabelle: Solche Listen weglassen. Faustregel: höchstens ein Bezeichner je Satz, selten zwei. - **Keine** Übungen, Selbsttests, Lernziele, Merkkästen, Checklisten, „Praxistipps“, Schritt-für-Schritt-Anleitungen als Selbstzweck, Zusammenfassungen am Kapitelende, Literaturlisten. -- Überwiegend Fließtext. Listen und Tabellen nur, wo sie echte Klarheit bringen – sparsam. +- Überwiegend Fließtext. Listen und Tabellen nur, wo sie echte Klarheit bringen – sparsam. Eine Tabelle vergleicht Varianten mit ihren Kosten; sie zählt nie Methoden, Eigenschaften, Konstanten oder Einstellungen auf. +- Kein Nachschlagewissen: keine Einstellungspfade (eine Projekteinstellung wird in Worten genannt, nicht als `pfad/zur/einstellung`), keine Standardwerte, Grenzwerte, Signaturen oder Parameterpositionen, die nur beim Bauen helfen. Keine Versionsnotizen („seit 4.3“, „in Godot 3 hieß“, „bis 4.2“): Das Buch beschreibt den Stand der Referenzversion, als hätte es nie einen anderen gegeben. +- Keine Autoren als Erzählgerüst: nicht „X beschreibt“, „X hält“, „X rät“, sondern die Sache selbst erklären und begründen. Der Erfinder eines Verfahrens wird höchstens einmal genannt, wenn das Verfahren nach ihm heißt. Keine Jahreszahlen, Daten, Lebensläufe oder Anekdoten ohne Erklärwert. Keine Testberichte im Text („Im Testlauf …“, „Das Skript läuft ohne Fehler“, „Ein Versuch zeigt“): Die Ausgabe spricht für sich. - Fachbegriffe bei der ersten Nennung kurz erklären; englische Fachbegriffe nennen, wo sie üblich sind. -- Keine Quellenangaben im Text, weder in Klammern noch als „laut Dokumentation“: Quellen dienen der Prüfung, nicht dem Leser. Klassen und Befehle in `Code`-Formatierung, Versionsangaben („seit 4.3“) nur, wenn geprüft. +- Keine Quellenangaben im Text, weder in Klammern noch als „laut Dokumentation“: Quellen dienen der Prüfung, nicht dem Leser. Klassen und Befehle in `Code`-Formatierung. - Keine Querverweise: keine Verweisklammern „(→ Abschnitt 8.2)“, keine Rückverweise („wie Abschnitt 3.2 zeigte“). Das Buch wird von vorn nach hinten gelesen; der Leser hat das Frühere gerade gelesen. Ein Thema wird nur in seinem Kapitel erklärt, anderswo höchstens in einem Halbsatz gestreift. Kommt ein Begriff vor seinem Kapitel vor, genügt ein Halbsatz wie „das erklärt Kapitel 8“. -- Codebeispiele (falls das Thema Software ist): kurz (typisch 5–30 Zeilen), nur wo sie ein Konzept erklären, mit Sprachangabe im Codeblock, im Text erklärt. +- Codebeispiele (falls das Thema Software ist): kurz (typisch 5–20 Zeilen), nur der Kern einer Idee, so wie er in einem Spielskript stünde (etwa `extends Node2D` mit `_ready()` oder `_process()`), mit Sprachangabe im Codeblock, im Text erklärt. Kein Testgerüst im Buch: kein `extends SceneTree`, kein `_init()`, kein `quit()`, keine Warteschleifen, Frame-Zähler, simulierten Eingaben, Fenstergrößen oder Hilfsfunktionen, die nicht abgedruckt sind. Zum Prüfen darf der Autor den Kern in ein Gerüst unter `arbeit/` stecken; abgedruckt wird nur der Kern. +- Code-Bezeichner (Variablen, Funktionen, Klassen, Signale, Knotennamen) sind englisch wie die Engine-API. Kommentare im Code und ausgegebene Texte sind deutsch. - Hat ein Codebeispiel eine Ausgabe, steht die tatsächliche Ausgabe des eigenen Testlaufs als ```text-Block direkt darunter, gekürzt auf das Wesentliche (höchstens etwa 10 Zeilen). - Strukturdiagramme: Baum-, Ablauf- und Zustandsstrukturen, die aus Quellcode oder Doku belegt sind, als Textdiagramm mit Kästen und Pfeilen in einem ```diagramm-Block (Zeichen ┌─┐│└┘├┤┬┴ und ▶ ▼, höchstens 60 Zeichen breit, höchstens eines je Abschnitt). Jedes Element im Diagramm kommt auch im Text vor. Keine Illustrationen, keine Szenen, nichts Erfundenes. diff --git a/prompts/vorwort.md b/prompts/vorwort.md index 6ef4272..04d630d 100644 --- a/prompts/vorwort.md +++ b/prompts/vorwort.md @@ -5,7 +5,7 @@ Lies: `deutung.json`, `buch/STIL.md`, `buch/GLIEDERUNG.md`, die Einleitungen (Te Schreibe `buch/00-vorwort.md` (Markdown, Überschrift `# Vorwort`, 350–600 Wörter): - Worum es geht und für wen das Buch ist; was es nicht ist (kein Tutorial, kein Ratgeber, keine Referenz). - Wie das Buch aufgebaut ist (die Teile in einem Absatz, keine Liste). -- Woran sich die Darstellung orientiert (Referenzversion bzw. Literaturstand) und wie die Angaben geprüft wurden – ehrlich, ohne Übertreibung; welche Grenzen bleiben. +- Referenzversion bzw. Literaturstand in einem Satz und welche Grenzen bleiben. Kein Prüfprotokoll: keine Zahlen zu geprüften Aussagen, keine Beschreibung der Prüfschritte. - Bei Gesundheitsthemen: ein Satz, dass das Buch informiert und nicht berät, mit Hinweis auf Hilfsangebote (Deutschland: 116 117, Telefonseelsorge 0800 111 0 111 / 0800 111 0 222). Sachbuchprosa, keine Anrede des Lesers, keine Werbung. Antworte am Ende mit einer Zeile.