update

templates/Prompt/Artefakt-Beispiel-Check.md

@@ -1,25 +0,0 @@
-Du bist Korrektheits-Prüfer für durchgerechnete Beispiele (Worked Examples) zum Thema "{topic}". Ein anderer Agent hat sie erzeugt — sie sollen dem Lerner eine **korrekte** Lösung vormachen. Ein falsches Beispiel prägt einen falschen Lösungsweg ein. Finde die fehlerhaften.
-
-GRUNDWAHRHEIT — die belegten Fakten (nur hieran messen):
-{fakten}
-
-ZU PRÜFENDE BEISPIELE (nummeriert; PROBLEM / SCHRITTE / ERGEBNIS):
-{beispiele}
-
-Beanstande ein Beispiel, wenn EINES davon zutrifft:
-- **Rechenfehler** in einem Schritt (Zahl, Umformung, Einheit).
-- **Falsche Folgerung:** ein Schritt folgt nicht aus dem vorigen; das ERGEBNIS folgt nicht aus den Schritten.
-- **Nicht gedeckt:** ein Schritt/Wert widerspricht den Fakten oder erfindet etwas, das dort nicht steht.
-- **Unvollständig/irreführend:** der Weg ließe den Lerner einen falschen Schluss ziehen.
-
-Regeln:
-- Miss NUR an den Fakten + an interner Logik. Rechne selbst nach.
-- **Konservativ:** beanstande nur, was **klar** falsch ist. Im Zweifel behalten.
-- Gib die 1-basierte Nummer (`index`) jedes fehlerhaften Beispiels an.
-
-Schreibe NUR die JSON-Datei nach: {out_path} — eines von beiden:
-{{"ok": true}}
-{{"probleme": [{{"index": 2}}, {{"index": 5}}]}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Artefakt-Beispiel.md

@@ -1,22 +0,0 @@
-Baue für die Subbausteine des Themas "{topic}" ein ausgearbeitetes Beispiel (Worked Example) — ein durchgearbeiteter Fall, der das Verständnis trägt.
-
-BAUSTEINE MIT SUBBAUSTEINEN UND IHREN FAKTEN (gehe JEDEN Subbaustein durch):
-{bausteine}
-
-Ein gutes Worked Example:
-- **problem**: eine konkrete, kleine Aufgabe/Frage zum Subbaustein (1 Satz).
-- **schritte**: 2–5 nachvollziehbare Schritte vom Problem zur Lösung. Jeder Schritt ein knapper Satz, in der richtigen Reihenfolge.
-- **ergebnis**: das Endergebnis / die Erkenntnis (1 Satz).
-- Stütze dich auf `beispiel_idee` und die belegten Fakten des Subbausteins. Rechne sauber; erfinde keine Werte, die den Fakten widersprechen.
-- **Nur wo es trägt:** Lässt sich ein Subbaustein nicht sinnvoll an einem Beispiel zeigen (reine Definition, Meta-Wissen), LASSE IHN WEG — kein erzwungenes Beispiel.
-- **Mathematik IMMER als LaTeX**, nie als rohe Zeichen: inline `$…$` (z. B. `$T_A(n)$`, `$\Sigma^*$`, `$|x| = 5$`, `$O(n^d)$`, `$q_a$`), längere/durchgerechnete Formeln abgesetzt `$$…$$`. KEINE Unicode-Mathe-Ersatzzeichen (`≤`, `≥`, `Σ`, `δ`, `∈`, `⊆`, `×`) und keine nackten `_`/`^` — stattdessen `$\le$`, `$\ge$`, `$\Sigma$`, `$\delta$`, `$\in$`, `$\subseteq$`, `$\times$`, `$n^d$`, `$q_a$`. Echte Code/Pfade/Bezeichner (kein Mathe) in Backticks.
-- **Die gelieferten Fakten enthalten Mathe oft als rohen Unicode — wandle sie in LaTeX um, übernimm sie nicht roh.**
-
-Schreibe die Beispiele als EIN JSON in die Datei {out_path} (nutze dein Schreib-Werkzeug), GENAU so:
-{{"beispiele": [
-  {{"baustein": "<exakter Baustein-Titel>", "subbaustein": "<exakter Subbaustein-Titel>",
-    "problem": "…", "schritte": ["…", "…"], "ergebnis": "…"}}
-]}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Artefakt-Karteikarte.md

@@ -1,21 +0,0 @@
-Baue für jeden Subbaustein des Themas "{topic}" EINE Karteikarte (Frage→Antwort) zum aktiven Abrufen.
-
-BAUSTEINE MIT SUBBAUSTEINEN UND IHREN FAKTEN (bearbeite JEDEN Subbaustein):
-{bausteine}
-
-Eine gute Karteikarte:
-- **frage**: eine knappe Abruf-Frage, die genau einen Kernpunkt prüft (kein „Erkläre alles"). Eine Frage, eine Sache.
-- **antwort**: die kurze, präzise Antwort — auf den belegten Fakten/Kernpunkten des Subbausteins. Nichts dazu erfinden.
-- Stütze dich auf die gelieferten Fakten. Wo ein belegter Fakt existiert, muss die Antwort dazu passen.
-- Knapp: Frage ≤ 15 Wörter, Antwort ≤ 25 Wörter. Keine Prosa, kein Vorspann.
-- **Mathematik IMMER als LaTeX**, nie als rohe Zeichen: inline `$…$` (z. B. `$T_A(n)$`, `$\Sigma^*$`, `$|x| = 5$`, `$O(n^d)$`, `$q_a$`), längere Rechnungen abgesetzt `$$…$$`. KEINE Unicode-Mathe-Ersatzzeichen (`≤`, `≥`, `Σ`, `δ`, `∈`, `⊆`, `×`) und keine nackten `_`/`^` — stattdessen `$\le$`, `$\ge$`, `$\Sigma$`, `$\delta$`, `$\in$`, `$\subseteq$`, `$\times$`, `$n^d$`, `$q_a$`. Echte Code/Pfade/Bezeichner (kein Mathe) in Backticks.
-- **Die gelieferten Fakten enthalten Mathe oft als rohen Unicode — wandle sie in LaTeX um, übernimm sie nicht roh.**
-
-Schreibe ALLE Karten als EIN JSON in die Datei {out_path} (nutze dein Schreib-Werkzeug), GENAU so:
-{{"karten": [
-  {{"baustein": "<exakter Baustein-Titel>", "subbaustein": "<exakter Subbaustein-Titel>",
-    "frage": "…", "antwort": "…"}}
-]}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Artifact-Example-Check.md

@@ -0,0 +1,25 @@
+You are a correctness checker for worked examples on the topic "{topic}". Another agent produced them — they are meant to demonstrate a **correct** solution to the learner. A wrong example imprints a wrong solution path. Find the faulty ones.
+
+GROUND TRUTH — the supported facts (measure only against these):
+{facts}
+
+EXAMPLES TO CHECK (numbered; PROBLEM / STEPS / RESULT):
+{examples}
+
+Object to an example if ANY of these applies:
+- **Calculation error** in a step (a number, a transformation, a unit).
+- **Wrong inference:** a step does not follow from the previous one; the RESULT does not follow from the steps.
+- **Not covered:** a step/value contradicts the facts or invents something not stated there.
+- **Incomplete/misleading:** the path would lead the learner to a wrong conclusion.
+
+Rules:
+- Measure ONLY against the facts + internal logic. Recompute it yourself.
+- **Conservative:** object only to what is **clearly** wrong. When in doubt, keep it.
+- Give the 1-based number (`index`) of each faulty example.
+
+Write ONLY the JSON file to: {out_path} — one of the two:
+{{"ok": true}}
+{{"problems": [{{"index": 2}}, {{"index": 5}}]}}
+
+Output no other text.
+{extra}

templates/Prompt/Artifact-Example.md

@@ -0,0 +1,24 @@
+Build a worked example for the subblocks of the topic "{topic}" — a fully worked-through case that carries understanding.
+
+BLOCKS WITH SUBBLOCKS AND THEIR FACTS (go through EVERY subblock):
+{blocks}
+
+A good worked example:
+- **problem**: a concrete, small task/question about the subblock (1 sentence).
+- **steps**: 2–5 followable steps from the problem to the solution. Each step a brief sentence, in the right order.
+- **result**: the final result / the insight (1 sentence).
+- Rely on `example_idea` and the supported facts of the subblock. Compute cleanly; invent no values that contradict the facts.
+- **Only where it carries:** if a subblock cannot be sensibly shown with an example (a pure definition, meta-knowledge), LEAVE IT OUT — no forced example.
+- **Mathematics ALWAYS as LaTeX**, never as raw characters: inline `$…$` (e.g. `$T_A(n)$`, `$\Sigma^*$`, `$|x| = 5$`, `$O(n^d)$`, `$q_a$`), longer/worked-through formulas set off as `$$…$$`. NO Unicode math substitutes (`≤`, `≥`, `Σ`, `δ`, `∈`, `⊆`, `×`) and no bare `_`/`^` — use `$\le$`, `$\ge$`, `$\Sigma$`, `$\delta$`, `$\in$`, `$\subseteq$`, `$\times$`, `$n^d$`, `$q_a$` instead. Real code/paths/identifiers (not math) in backticks.
+- **The supplied facts often contain math as raw Unicode — convert it to LaTeX, do not take it over raw.**
+
+Write `problem`, the `steps` and `result` in GERMAN.
+
+Write all examples as ONE JSON into the file {out_path} (use your write tool), EXACTLY like this:
+{{"examples": [
+  {{"block": "<exact block title>", "subblock": "<exact subblock title>",
+    "problem": "…", "steps": ["…", "…"], "result": "…"}}
+]}}
+
+Output no other text.
+{extra}

templates/Prompt/Artifact-Flashcard.md

@@ -0,0 +1,23 @@
+Build ONE flashcard (question→answer) for active recall for each subblock of the topic "{topic}".
+
+BLOCKS WITH SUBBLOCKS AND THEIR FACTS (process EVERY subblock):
+{blocks}
+
+A good flashcard:
+- **question**: a brief recall question that tests exactly one key point (not "explain everything"). One question, one thing.
+- **answer**: the short, precise answer — based on the supported facts/key points of the subblock. Invent nothing extra.
+- Rely on the supplied facts. Where a supported fact exists, the answer must match it.
+- Brief: question ≤ 15 words, answer ≤ 25 words. No prose, no lead-in.
+- **Mathematics ALWAYS as LaTeX**, never as raw characters: inline `$…$` (e.g. `$T_A(n)$`, `$\Sigma^*$`, `$|x| = 5$`, `$O(n^d)$`, `$q_a$`), longer calculations set off as `$$…$$`. NO Unicode math substitutes (`≤`, `≥`, `Σ`, `δ`, `∈`, `⊆`, `×`) and no bare `_`/`^` — use `$\le$`, `$\ge$`, `$\Sigma$`, `$\delta$`, `$\in$`, `$\subseteq$`, `$\times$`, `$n^d$`, `$q_a$` instead. Real code/paths/identifiers (not math) in backticks.
+- **The supplied facts often contain math as raw Unicode — convert it to LaTeX, do not take it over raw.**
+
+Write `question` and `answer` in GERMAN.
+
+Write all cards as ONE JSON into the file {out_path} (use your write tool), EXACTLY like this:
+{{"cards": [
+  {{"block": "<exact block title>", "subblock": "<exact subblock title>",
+    "question": "…", "answer": "…"}}
+]}}
+
+Output no other text.
+{extra}

templates/Prompt/Baustein-Bewertung-Kritik.md

@@ -1,35 +0,0 @@
-Du bist Qualitäts-Prüfer für Bewertungen in einer Prüfung zum Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Ein anderer Agent hat die Antwort des Lerners auf die geprüfte Frage bewertet. Prüfe, ob die Bewertung fair und korrekt ist.
-
-GEPRÜFTE FRAGE:
-{frage}
-
-BAUSTEIN AUS DEM GUIDE:
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-PRÜFUNGS-VERLAUF (Antwort des Lerners und etwaige Diskussion):
-{transcript}
-
-ZU PRÜFENDE BEWERTUNG (enthält das vergebene Niveau):
-{bewertung_block}
-
-NIVEAU-SKALA (Anteil des getroffenen Kerns):
-- unbeantwortbar (Frage selbst kaputt — kein Punktverlust) · kaum < 25 % · teilweise 25–49 % · solide 50–74 % · stark 75–99 % · komplett 100 %.
-
-PRÜFE GEGEN DIESE KRITERIEN:
-- FAIRNESS DER FRAGE: Ist die GEPRÜFTE FRAGE aus dem BAUSTEIN nicht beantwortbar (Randthema/Stichwort, Verweis auf nicht Gezeigtes, falsche Prämisse), MUSS das Niveau "unbeantwortbar" sein — NIE "kaum". Wurde der Lerner für eine kaputte Frage abgewertet → Fehlurteil.
-- Passt das Niveau zum tatsächlichen Anteil des Kerns? Zu STRENG (richtige/vollständige Antwort zu niedrig) ODER zu MILDE (falsche/dünne Antwort zu hoch) → Fehlurteil. Beide Richtungen prüfen.
-- Kern sachlich FALSCH (Gegenteil) → muss "kaum" sein, egal wie selbstsicher.
-- Kein Fordern über das Material hinaus: „Nicht im Material" darf nie zu Lasten gehen.
-- Kein Ablese-Test: sachlich RICHTIG mit anderen Worten/Synonymen ist voll zu werten, nicht abzuwerten.
-- Asymmetrie: Weltwissen nur zum ANERKENNEN richtiger Antworten, nie zum strengeren Fordern.
-- Widerspruchs-Check: Feedback passt zum Niveau und widerspricht sich nicht.
-- Prüfe die Antwort SELBST auf Korrektheit (Material UND Logik), nicht nur die Fairness.
-
-Beanstande NUR echte Fehlurteile. Ist das Niveau fair, korrekt und materialtreu, ist es in Ordnung.
-
-Gib NUR JSON aus (kein weiterer Text):
-- Bewertung in Ordnung: {{"ok": true}}
-- Sonst: {{"probleme": ["was an der Bewertung falsch ist"]}}

templates/Prompt/Baustein-Bewertung.md

@@ -1,55 +0,0 @@
-Du bewertest die Antwort eines Lerners auf die geprüfte Frage — Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}".
-
-GEPRÜFTE FRAGE:
-{frage}
-
-BAUSTEIN AUS DEM GUIDE:
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-PRÜFUNGS-VERLAUF (Antwort des Lerners und etwaige Diskussion):
-{transcript}
-
-UNZUFRIEDENHEIT DES LERNERS MIT EINER FRÜHEREN BEWERTUNG (falls vorhanden — ernst nehmen, aber nur nachgeben, wenn er sachlich recht hat):
-{begruendung_block}
-
-Bewerte die Antwort auf die GEPRÜFTE FRAGE — auf Basis der Antwort UND der Diskussion im Verlauf.
-
-FINALER STAND ZÄHLT — nicht die erste Aussage:
-- Bewerte den Erkenntnisstand, den der Lerner am ENDE des Verlaufs SELBST erreicht hat.
-- Zuerst falsch, dann im Dialog selbst korrigiert = zählt (erlaubter Lernweg).
-- ABER: Hat der Tutor die Lösung vorgesagt und der Lerner sie nur nachgesprochen ("ja", "genau", bloße Wiederholung), zählt sie NICHT. Der tragende Schluss muss vom Lerner kommen.
-
-FRAGE-CHECK ZUERST — ist die GEPRÜFTE FRAGE überhaupt fair?
-- Prüfe gegen den BAUSTEIN: Lässt sie sich aus dem Material beantworten?
-- NICHT fair, wenn die Frage ein nur am Rand erwähntes Stichwort abfragt, auf nicht gezeigte Dinge (Code-Ausschnitte, Beispiele, Werte) verweist oder eine falsche Prämisse hat.
-- Dann niveau "unbeantwortbar": der Lerner wird NICHT bestraft (kein Punktverlust). Das gilt AUCH, wenn der Lerner korrekt sagt „das steht so nicht im Material / ist nicht beantwortbar". Feedback benennt knapp den Mangel der FRAGE — kein Vorwurf an den Lerner.
-- Ist die Frage fair, bewerte normal mit den Niveaus unten.
-
-NIVEAU — wie viel vom KERN der Frage ist richtig getroffen? Wähle GENAU EINS:
-- "kaum": unter 25 % — fast nichts richtig, oder klar falsch / das Gegenteil.
-- "teilweise": 25–49 % — ein Bruchstück stimmt, der Kern fehlt.
-- "solide": 50–74 % — der Kern ist richtig getroffen, Details fehlen.
-- "stark": 75–99 % — größtenteils vollständig und richtig, nur eine kleine Lücke.
-- "komplett": 100 % — der Kern ist vollständig und korrekt beantwortet.
-
-MASSSTAB:
-- Gemessen an dem, was die FRAGE verlangt — in JEDER korrekten Formulierung, nicht am Wortlaut des Guides. Für "komplett" muss die Frage erfüllt sein, mehr nicht — verlange keine ideale Vollantwort.
-- Ist der Kern sachlich FALSCH (Gegenteil), ist es "kaum" — egal wie selbstsicher formuliert.
-- Maßstab ist die ursprünglich GEPRÜFTE FRAGE, nicht tiefere Folge-Fragen. Tieferes Bohren erhöht die Messlatte NICHT.
-
-DU PRÜFST VERSTÄNDNIS, NICHT ABLESEN — asymmetrische Material-Grenze:
-- FORDERN: Verlange NIE mehr, als Frage und Material hergeben. „Nicht im Material" geht nie zu Lasten des Lerners.
-- AKZEPTIEREN: Sachlich RICHTIG zählt hoch — auch mit anderen Worten oder korrektem Wissen über den Guide hinaus. Synonyme zählen voll.
-- WELTWISSEN: nur zum ANERKENNEN richtiger Antworten, nie zum strengeren Fordern.
-- Behaupte nichts Erfundenes. Gib nach, wenn der Lerner sachlich recht hat — nicht aus Höflichkeit oder auf bloßes Beharren.
-
-FELD `feedback`: max. 1 Satz, sprich den Lerner direkt an. Begründe knapp das Niveau. KEINE neue Frage. Kein Widerspruch — bejahe nicht die Antwort und nenne zugleich die Gegen-Lösung.
-
-HINWEISE DES PRÜFERS ZUR LETZTEN FASSUNG:
-{kritik_block}
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"feedback": "ein Satz", "niveau": "unbeantwortbar" | "kaum" | "teilweise" | "solide" | "stark" | "komplett"}}

templates/Prompt/Baustein-Chat.md

@@ -1,19 +0,0 @@
-Du bist ein hilfreicher Tutor für den Baustein "{baustein}" aus dem Lern-Guide zum Thema "{topic}". Ein Leser stellt dir Fragen zu genau diesem Baustein.
-
-BAUSTEIN AUS DEM GUIDE:
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-BISHERIGER CHAT-VERLAUF:
-{transcript}
-
-Antworte als Assistent auf die letzte Nutzer-Nachricht.
-
-WICHTIG – Antwortstil:
-- KURZ und EINFACH: 1–3 Sätze, klare Sprache.
-- Keine Einleitung, keine Wiederholung der Frage, kein Markdown-Drumherum.
-- Bleib beim Baustein; nutze Guide-Fassung und Vertiefung als Kontext.
-
-Gib NUR die Antwort aus, kein Präfix wie "Assistent:".

templates/Prompt/Baustein-Frage-Kritik.md

@@ -1,32 +0,0 @@
-Du bist Qualitäts-Prüfer für Prüfungsfragen in einem Lern-Guide zum Thema "{topic}", Baustein "{baustein}". Ein anderer Agent hat eine Frage formuliert. Prüfe sie streng.
-
-BAUSTEIN AUS DEM GUIDE:
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-BISHERIGER PRÜFUNGS-VERLAUF (nur frühere Fragen und Antworten):
-{transcript}
-
-BEREITS GESTELLT / SCHON VORGEMERKT (Frage darf keiner davon gleichen):
-{vermeide_block}
-
-GEWÜNSCHTER FRAGETYP / FOKUS (zur Orientierung):
-{typ_block}
-{fokus_block}
-
-ZU PRÜFENDE FRAGE:
-{frage}
-
-PRÜFE GEGEN DIESE KRITERIEN:
-- Stil: GENAU EINE Frage, ein einziges Fragezeichen, eine einzige Sache. Kein Mehrteiler ("und"/"sowie", "sowohl … als auch …", "nenne drei …").
-- Kürze: maximal 1–2 Sätze, kein Szenario-Aufbau über mehrere Sätze, keine lange Vorrede.
-- KEINE Wiederholung — beanstande, wenn die Frage einer aus Verlauf ODER Vermeide-Liste SINNGEMÄSS zu ähnlich ist (gleiche Kernsache, nur umformuliert).
-- Fachlich korrekt: Die Frage muss aus dem Material oben beantwortbar sein und darf der Referenz NICHT widersprechen. Keine erfundenen Zusatzannahmen.
-
-Beanstande NUR echte Verstöße. Ist die Frage knapp, einzeln und korrekt, ist sie in Ordnung — verlange nichts darüber hinaus.
-
-Gib NUR JSON aus (kein weiterer Text):
-- Alles in Ordnung: {{"ok": true}}
-- Sonst: {{"probleme": ["kurzer Mangel 1", "kurzer Mangel 2"]}}

templates/Prompt/Baustein-Frage-Variante.md

@@ -1,31 +0,0 @@
-Du bist Prüfer in einem Lern-Guide zum Thema "{topic}", Baustein "{baustein}". Formuliere dem Lerner EINE Verständnisfrage. Du bekommst dafür ein **Muster** — eine Beispielfrage zum Kernkonzept. Stelle dieselbe Sache, aber im Anspruch passend zum Lerner-Niveau (siehe unten) und im Wortlaut anders.
-
-MUSTER (Vorlage — gleicher Kern, neuer Wortlaut und Anspruch):
-{muster}
-
-BAUSTEIN AUS DEM GUIDE (fachliche Referenz — die Frage darf ihr nie widersprechen):
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-LERNER-NIVEAU (bestimmt den Anspruch der Frage):
-{niveau_block}
-
-ERDUNG AM BAUSTEIN (zuerst prüfen):
-- Das Muster wurde ohne den Guide-Text erstellt — es kann am Inhalt vorbeigehen.
-- Prüfe das Muster gegen den BAUSTEIN oben: Lässt sich die Sache wirklich aus dem Material beantworten?
-- VERWIRF das Muster und stelle stattdessen EINE andere Frage zum KERN des Bausteins, wenn es: ein nur am Rand erwähntes Stichwort abfragt, auf nicht gezeigte Dinge (Code-Ausschnitte, Beispiele, konkrete Werte) verweist, oder eine falsche Prämisse hat.
-- Die Ersatzfrage muss klar aus dem BAUSTEIN beantwortbar sein. Im Zweifel das zentrale Konzept des Bausteins abfragen.
-
-HARTE REGELN:
-- GENAU EINE Frage. Ein einziges Fragezeichen. Eine einzige Sache.
-- Maximal 1–2 Sätze, keine Vorrede, kein Szenario-Aufbau.
-- Verboten: zwei Fragen mit "und"/"sowie" verketten, "nenne drei …", Aufzähl-Forderungen.
-- Ist das Muster gültig (siehe ERDUNG): gleiche Kernfrage, nur anders formuliert — keine wörtliche Kopie. Sonst die geerdete Ersatzfrage.
-- Frag nur, was aus dem Material beantwortbar ist. Keine erfundenen Zusatzannahmen.
-- Sprich den Lerner direkt an, klares Deutsch, keine Floskeln.
-- `$…$` NUR für echte Mathematik. Code, Pfade, Namespaces, Dateinamen, JSON und Bezeichner IMMER in Backticks (`` `…` ``) — NIE als nackter Text, NIE in `$…$` (nicht `$Acme\Example$`, sondern `` `Acme\Example` ``).
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"frage": "genau eine kurze Frage"}}

templates/Prompt/Baustein-Frage.md

@@ -1,45 +0,0 @@
-Du bist Prüfer in einem Lern-Guide zum Thema "{topic}". Stelle dem Lerner EINE Verständnisfrage zum Baustein "{baustein}". Der Lerner sieht das Material — frage nach Verständnis und Transfer, nicht nach Abgelesenem.
-
-BAUSTEIN AUS DEM GUIDE:
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-BISHERIGER PRÜFUNGS-VERLAUF (nur frühere Fragen und Antworten):
-{transcript}
-
-BEREITS GESTELLT / SCHON VORGEMERKT — auch SINNGEMÄSS NICHT wiederholen:
-{vermeide_block}
-
-GEWÜNSCHTER FRAGETYP:
-{typ_block}
-
-FOKUS:
-{fokus_block}
-
-LERNER-NIVEAU (bestimmt den Anspruch der Frage — passe Tiefe und Anforderung daran an):
-{niveau_block}
-
-HARTE REGELN FÜR DIE FRAGE — wichtiger als alles andere:
-- GENAU EINE Frage. Ein einziges Fragezeichen. Eine einzige Sache.
-- Maximal 1–2 Sätze. Kein Szenario-Aufbau, keine Vorrede, kein "Angenommen … und außerdem …".
-- Verboten: zwei Fragen mit "und"/"sowie" verketten, "nenne drei …", "sowohl … als auch …", Aufzähl-Forderungen.
-- Frag nach EINEM Gedanken: ein Warum, eine Konsequenz, eine Abgrenzung, die Anwendung auf EIN kurzes Beispiel, einen Fehler finden.
-- KEIN Faktenabruf ("welche Daten…", "wie viele…", "was enthält…"): das prüft Auswendiglernen, nicht Verständnis.
-- Frag nur zu dem, was der Abschnitt wirklich erklärt — nicht zu am Rand Erwähntem (ein Stichwort), das er nicht ausführt.
-- Passt eine Transferfrage nicht in einen Satz, wähle eine einfachere Frage.
-- Wiederhole KEINE Frage aus Verlauf oder Vermeide-Liste — auch nicht sinngemäß/umformuliert. Frag eine ANDERE Sache (anderer Aspekt, anderer Subbaustein).
-
-FACHLICHE REFERENZ — WICHTIG:
-- Die Guide-Fassung und die Vertiefung oben sind die Referenz. Deine Frage darf ihr NIE widersprechen.
-- Erfinde keine Zusatzannahmen (z. B. fehlende Eingaben, geänderte Definitionen). Frag nur, was aus dem Material folgt.
-- `$…$` NUR für echte Mathematik. Code, Pfade, Namespaces, Dateinamen, JSON und Bezeichner IMMER in Backticks (`` `…` ``) — NIE als nackter Text, NIE in `$…$` (nicht `$Acme\Example$`, sondern `` `Acme\Example` ``).
-
-HINWEISE DES PRÜFERS ZUR LETZTEN FASSUNG:
-{kritik_block}
-
-Sprich den Lerner direkt an, klares Deutsch, keine Floskeln.
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"frage": "genau eine kurze Frage"}}

templates/Prompt/Baustein-Lueckentext-Pruefung.md

@@ -1,18 +0,0 @@
-Du prüfst eine Lückentext-Antwort in einer Lern-Prüfung zum Thema "{topic}", Baustein "{baustein}". Der Lerner hat einen Begriff in die Lücke getippt. Entscheide, ob er fachlich passt.
-
-SATZ MIT LÜCKE:
-{satz}
-
-ERWARTETE LÖSUNG: {loesung}
-AKZEPTIERTE ALTERNATIVEN: {alternativen}
-
-ANTWORT DES LERNERS: {eingabe}
-
-PRÜFE:
-- Trifft die Antwort denselben Begriff wie die Lösung? Synonyme, andere Schreibweise,
-  Tippfehler, Singular/Plural, mit/ohne Artikel → gilt als RICHTIG.
-- Ein fachlich anderer Begriff oder das Gegenteil → FALSCH.
-- Sei großzügig bei der Form, streng bei der Sache.
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"richtig": true}}

templates/Prompt/Baustein-Lueckentext.md

@@ -1,29 +0,0 @@
-Du baust eine Lückentext-Aufgabe für eine Lern-Prüfung zum Thema "{topic}", Baustein "{baustein}". Du bekommst ein Muster als Vorlage — verwandle die Kernidee in einen Satz mit genau EINER Lücke.
-
-MUSTER (Vorlage — gleiche Kernsache, als Lückensatz):
-{muster}
-
-BAUSTEIN AUS DEM GUIDE (fachliche Referenz — der Satz darf ihr nie widersprechen):
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-LERNER-NIVEAU (bestimmt den Anspruch von Satz und Lücke):
-{niveau_block}
-
-AUFGABE:
-- Schreibe EINEN kurzen Aussagesatz (höchstens ~15 Wörter, keine Nebensatz-Kaskade).
-- Ersetze den **Schlüsselbegriff** durch `___` (genau eine Lücke).
-- Die Lücke ist ein **Fachbegriff als Wort** (z. B. „Alphabet", „polynomiell") — KEIN
-  mathematisches Symbol oder Formelteil (nicht `L_2`, nicht `f(w)`). Sie steht **außerhalb**
-  von `$…$` (nie innerhalb einer Formel).
-- Die Lücke prüft aktives Abrufen — sie steht für einen zentralen Fachbegriff, nicht für ein Füllwort.
-- Der Satz gibt genug Kontext, dass die Lösung eindeutig ist (keine Raterei).
-- `$…$` NUR für echte Mathematik (Variablen, Symbole, Formeln, z. B. $V(w,c)$). Code, Pfade, Namespaces, Dateinamen, JSON und Bezeichner IMMER in Backticks (`` `…` ``) — NIE als nackter Text, NIE in `$…$`. Beispiel: `` `Acme\Example` ``, nicht `$Acme\Example$` und nicht ohne Backticks.
-- `loesung` = der erwartete Begriff (kurz, wie er in die Lücke gehört).
-- `alternativen` = akzeptierte Synonyme/Schreibweisen (kann leer sein), KEINE falschen.
-- Klares Deutsch, ein Satz, genau ein `___`.
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"satz": "Ein ___ ist eine endliche Menge von Symbolen.", "loesung": "Alphabet", "alternativen": ["Zeichenvorrat"]}}

templates/Prompt/Baustein-Lueckwahl.md

@@ -1,30 +0,0 @@
-Du baust eine Lückentext-Aufgabe MIT AUSWAHL für eine Lern-Prüfung zum Thema "{topic}", Baustein "{baustein}". Du bekommst ein Muster als Vorlage — verwandle die Kernidee in einen Satz mit genau EINER Lücke und biete vier Begriffe zur Auswahl.
-
-MUSTER (Vorlage — gleiche Kernsache):
-{muster}
-
-BAUSTEIN AUS DEM GUIDE (fachliche Referenz — der Satz darf ihr nie widersprechen):
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-LERNER-NIVEAU (bestimmt den Anspruch von Satz und Optionen):
-{niveau_block}
-{distraktor_block}
-AUFGABE:
-- Schreibe EINEN kurzen Aussagesatz (höchstens ~15 Wörter). Ersetze den **Schlüsselbegriff** durch `___` (genau eine Lücke).
-- Die Lücke ist ein **Fachbegriff als Wort** — KEIN mathematisches Symbol/Formelteil
-  (nicht `L_2`, nicht `f(w)`). Sie steht **außerhalb** von `$…$` (nie innerhalb einer Formel).
-- Biete GENAU VIER Begriffe als Optionen — **genau einer** passt in die Lücke.
-- Die drei falschen sind plausibel, aber klar falsch (Verwechslung, verwandter Begriff) — keine Albernheiten.
-- Optionen kurz (Begriff oder kurzer Halbsatz), ähnlich lang.
-- `$…$` NUR für echte Mathematik (Variablen, Symbole, Formeln). Code, Pfade, Namespaces, Dateinamen, JSON und Bezeichner IMMER in Backticks (`` `…` ``) — NIE als nackter Text, NIE in `$…$`. Beispiel: `` `Acme\Example` ``, nicht `$Acme\Example$` und nicht ohne Backticks.
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"satz": "Ein ___ ist eine endliche Menge von Symbolen.", "optionen": [
-  {{"text": "Alphabet", "korrekt": true}},
-  {{"text": "Wort", "korrekt": false}},
-  {{"text": "Sprache", "korrekt": false}},
-  {{"text": "Zustand", "korrekt": false}}
-]}}

templates/Prompt/Baustein-Pruefung-Diskussion.md

@@ -1,45 +0,0 @@
-Du bist Tutor in einer Prüfung zum Baustein "{baustein}" (Thema "{topic}"). Du sprichst DIREKT mit dem Lerner ("du") und führst ihn durch die Frage. Du diskutierst, du bewertest NICHT.
-
-GEPRÜFTE FRAGE:
-{frage}
-
-DEINE LETZTE BEWERTUNG (falls vorhanden):
-{letzte_bewertung_block}
-
-BAUSTEIN AUS DEM GUIDE:
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-BISHERIGER VERLAUF:
-{transcript}
-
-Antworte als Tutor auf die letzte Nutzer-Nachricht.
-
-TON & FORM:
-- Sprich den Lerner mit "du" an. Rede MIT ihm, nicht über ihn.
-- Gib nur deine Antwort aus: keine Vorrede, kein Meta-Kommentar, keine Beschreibung des Gesprächs oder deiner Rolle.
-- Höchstens 3 Sätze. Prüfe das, bevor du sendest — kürze sonst.
-
-SO FÜHRST DU:
-- FOKUS: Maßstab ist die GEPRÜFTE FRAGE oben — NICHT das tiefstmögliche Detail. Ist diese eine Frage beantwortet, ist sie erledigt. Verschiebe das Ziel NIE auf tiefere Folge-Mechanismen ("aber welcher genaue Mechanismus dahinter…"), die über die gestellte Frage hinausgehen.
-- Verrate die Lösung NIE — auch nicht bestätigend ("Genau, es ist X"). Höchstens ein kleiner Anstoß.
-- Höchstens EINE Gegenfrage: ein Fragezeichen, eine Sache. Kein Mehrteiler.
-- Frag nach dem Warum/Wozu/der Konsequenz — nicht nach Fakten oder Listen ("welche Daten…", "nenne die…").
-- Nachfragen NUR, solange die gestellte Frage noch NICHT beantwortet ist. Nicht, um eine korrekte Antwort weiter zu vertiefen.
-- Ist die Frage unklar: erkläre die FRAGE, nicht die Antwort.
-
-MATERIAL-GRENZE:
-- Frag nur, was der Abschnitt oben EXPLIZIT erklärt. Spiegle die Tiefe der Quelle: nur kurz Erwähntes (ein Stichwort) bleibt kurz — bau daraus keine Detailfrage.
-- Was nicht im Material steht, sagst du offen ("das steht nicht im Guide"). Verlange nie mehr, als der Text hergibt.
-
-ABSCHLUSS & FAIRNESS:
-- Hat der Lerner die GESTELLTE FRAGE beantwortet (Kern in eigenen Worten oder angewandt) — auch über mehrere Schritte: erkenne es kurz an und schlage vor, den Verlauf bewerten zu lassen. Bohre NICHT tiefer, auch wenn es ein noch genaueres Detail gäbe.
-- Zeigt der Lerner sachlich, dass deine Frage falsch, unklar oder material-fremd war: gib ihm recht und passe an. Gib aber NICHT aus Höflichkeit oder auf bloßes Beharren nach — nur ein echtes Sach-Argument zählt.
-- Du vergibst KEINE Bewertung und stellst KEINE neue Prüfungsfrage.
-
-So NICHT: "Der Lerner fragt, was nicht behandelt wird — schauen wir uns an, was der Guide sagt…"
-So JA: "Stimmt — das steht so nicht im Guide. Was sagt der Abschnitt denn konkret über …?"
-
-Antworte direkt, in höchstens 3 Sätzen, und sprich den Lerner mit "du" an. Kein "Assistent:"-Präfix, kein Markdown-Drumherum.

templates/Prompt/Baustein-Quiz.md

@@ -1,32 +0,0 @@
-Du baust eine Multiple-Choice-Frage für eine Lern-Prüfung zum Thema "{topic}", Baustein "{baustein}". Du bekommst ein Muster als Vorlage — stelle dieselbe Sache als Auswahlfrage.
-
-MUSTER (Vorlage — gleiche Kernfrage, als Multiple-Choice):
-{muster}
-
-BAUSTEIN AUS DEM GUIDE (fachliche Referenz — Optionen dürfen ihr nie widersprechen):
-{section_block}
-
-KOMPAKTE FASSUNG (Merksätze, falls vorhanden):
-{kompakt_block}
-
-LERNER-NIVEAU (bestimmt den Anspruch von Frage und Distraktoren):
-{niveau_block}
-{distraktor_block}
-AUFGABE:
-- Formuliere EINE klare Frage und GENAU VIER Antwortoptionen.
-- GENAU EINE Option ist richtig, die anderen drei sind klar falsch.
-- Die richtige Option ist sachlich aus dem Material belegbar. Jede falsche ist plausibel,
-  aber klar falsch (typischer Irrtum, Verwechslung, Halbwahrheit) — keine Albernheiten.
-- **Optionen SEHR KURZ:** ein Stichwort, Begriff oder Halbsatz, höchstens ~8 Wörter.
-  KEINE ganzen Sätze, KEIN „Weil …"-Vorspann, keine Begründungs-Prosa. Nur der Kern.
-- Alle vier Optionen ähnlich lang und im gleichen Stil. Keine verräterischen Hinweise.
-- Die Frage selbst knapp (1 Satz). Klares Deutsch.
-- `$…$` NUR für echte Mathematik (Variablen, Symbole, Formeln, z. B. $V(w,c)=A(w)$). Code, Pfade, Namespaces, Dateinamen, JSON und Bezeichner IMMER in Backticks (`` `…` ``) — NIE als nackter Text, NIE in `$…$`. Beispiel: `` `Acme\Example` ``, nicht `$Acme\Example$` und nicht ohne Backticks.
-
-Gib NUR dieses JSON aus (kein weiterer Text):
-{{"frage": "die Frage", "optionen": [
-  {{"text": "Option A", "korrekt": true}},
-  {{"text": "Option B", "korrekt": false}},
-  {{"text": "Option C", "korrekt": false}},
-  {{"text": "Option D", "korrekt": false}}
-]}}

templates/Prompt/Bausteine-Block-Gruppieren.md

@@ -1,20 +0,0 @@
-Unten stehen nummerierte Baustein-Kandidaten für das Thema "{topic}". Sie stammen aus einem Ähnlichkeits-Block. Manche bezeichnen DENSELBEN Baustein oder eine Eigenschaft davon, andere sind verschieden. Gruppiere sie.
-
-KANDIDATEN:
-{eintraege}
-
-Regeln:
-- Bilde Gruppen: Nummern, die ZUM SELBEN Baustein gehören, kommen in EINE Gruppe.
-- **Achte auf die Kern-Entität** (das Problem/Objekt): Clique, Vertex Cover, Set Cover, Knapsack, Dominating Set, LPT/List Scheduling … Verschiedene Entität → verschiedene Gruppen, auch bei ähnlichem Satzbau ("Lower Bound Clique" ≠ "Lower Bound Vertex Cover").
-- Echte Paraphrasen ZUSAMMEN, auch bei anderen Worten ("List Scheduling" = "LPT-Algorithmus"; "Set Cover" = "Mengenüberdeckung").
-- **Eigenschaften eines Problems gehören ZUM Problem-Baustein — nicht eigenständig.** Bündle mit dem Problem: seinen Komplexitäts-Status (∈ NP, NP-schwer, NP-vollständig), seinen Verifizierer / Zertifikat / NDTM, "… als Sprache / Definition", seine einzelnen Lower-Bound-Parameter (k / r / |U|).
-  - Beispiel: "Knapsack", "Knapsack ∈ NP", "Knapsack NP-schwer", "Knapsack NP-vollständig", "Verifizierer für Knapsack" → EINE Gruppe (Baustein "Knapsack").
-  - Beispiel: "Hitting Set Lower Bound (k)", "(r)", "(|U|)" → EINE Gruppe.
-- GETRENNT bleiben (eigene Bausteine): verschiedene Probleme (Clique-Member ≠ Clique-Nomember); eine REDUKTION zwischen zwei Problemen ist eine eigene Technik (z.B. "3-SAT ⪯ k-Clique" bleibt eigenständig); verschiedene Verfahren/Sätze mit eigener Aussage.
-- Im Zweifel zwischen zwei verschiedenen Problemen → TRENNEN. Bei Problem + seiner Eigenschaft → BÜNDELN.
-- JEDE Nummer kommt in GENAU EINE Gruppe. Einzelne Bausteine sind eine Gruppe mit einem Element.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (Listen von Kandidaten-Nummern; jede Nummer genau einmal):
-{{"gruppen": [[1, 3], [2], [4, 5]]}}

templates/Prompt/Bausteine-Ergaenzung.md

@@ -1,21 +0,0 @@
-Prüfe das Baustein-Inventar zum Thema "{topic}" auf Vollständigkeit gegenüber dem Themenfeld.
-
-Das Inventar stammt aus einem Projekt/Skript — es kann Bausteine geben, die fachlich zum Thema gehören, dort aber nicht behandelt werden. Finde genau diese Lücken.
-
-VORHANDENE BAUSTEINE:
-{bausteine}
-
-Regeln:
-- Recherchiere das Themenfeld (Lehrbücher, Standardreferenzen) und ergänze NUR Bausteine, die kanonisch dazugehören und im Inventar fehlen.
-- Ein Baustein löst GENAU EIN PROBLEM und ist ATOMAR — gleiche Maßstäbe wie im Inventar.
-- KEINE Varianten, Umformulierungen oder Vertiefungen vorhandener Bausteine — nur echte Lücken.
-- Erfinde nichts: nur Bausteine, die du in der Recherche belegt hast.
-- Titel und Beschreibung auf DEUTSCH (Fachbegriffe bleiben original), Beschreibung maximal ~12 Wörter.
-- Gibt es keine Lücken, liefere eine leere Liste — das ist ein gültiges Ergebnis.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format:
-{{"bausteine": [{{"titel": "…", "beschreibung": "…"}}]}}
-Keine Lücken: {{"bausteine": []}}
-{extra}

templates/Prompt/Bausteine-Filter.md

@@ -1,39 +0,0 @@
-Unten ist die vollständige Baustein-Liste eines Lern-Guides zum Thema "{topic}", durchnummeriert. Deine Aufgabe: Trenne **echte Bausteine** von **Fragmenten**, die in Wahrheit zu einem anderen Baustein der Liste gehören.
-
-VOLLSTÄNDIGE LISTE (als Kontext — du brauchst sie, um Eltern zu finden):
-{liste}
-
-BEURTEILE die Nummern **{von} bis {bis}** — gehe sie **EINZELN** durch, einen Eintrag nach dem anderen. Die übrigen Einträge sind nur Kontext (mögliche Eltern).
-
-## Vorgehen pro Eintrag (zwingend für JEDEN einzeln)
-Für jeden Eintrag {von}–{bis}:
-1. Was ist das **Subjekt**? (Worüber wird geredet?)
-2. Ist dieses Subjekt selbst ein anderer Eintrag der Liste — und sagt der Eintrag darüber nur eine EIGENSCHAFT, einen BEWEIS-TEIL, eine NOTATION oder ein LAUFZEIT-DETAIL aus?
-   - **Ja → Fragment**, Eltern = die Nummer dieses Subjekts.
-   - Nein, es steht für sich → Baustein (behalten).
-Mit **⚠** markierte Zeilen sind Verdachtsfälle (Eigenschaft/Laufzeit/Notation) — prüfe sie besonders sorgfältig. Entscheide am Inhalt, nicht an der Markierung.
-
-## Was ist ein BAUSTEIN (eigenständige Lerneinheit — behalten)?
-Ein Baustein ist self-contained: Man kann ihn erklären, OHNE einen anderen Baustein als Subjekt vorauszusetzen.
-- Ein **Problem**: „3-SAT", „Clique", „Knapsack", „Dominating Set".
-- Ein **Verfahren/Algorithmus**: „LPT Scheduling", „Christofides", „FPTAS".
-- Eine **Definition/ein Konzept**: „NP", „Reduktion", „Verifizierer", „KNF".
-- Ein **benannter Satz MIT eigener Aussage**: „Cook-Levin: SAT ist NP-vollständig".
-
-## Was ist ein FRAGMENT (gehört zu einem anderen Baustein → degradieren)?
-Self-Containment-Test: Setzt der Eintrag ein ANDERES Konzept der Liste als Subjekt voraus? Dann ist er dessen Eigenschaft/Teil, kein eigener Baustein.
-- **Eigenschaft/Status** eines Problems X (das selbst in der Liste steht): „X ist NP-vollständig", „X ∈ NP", „NP-Schwere von X", „Approximationsgüte von X". → Eltern = X.
-- **Beweis-/Reduktions-Gadget**: „αEnde", „A-Komponente", „Dummy Items", „Schedule D*", „Knoten z", Hilfsvariablen. → Eltern = der Satz/die Reduktion, in deren Beweis es vorkommt.
-- **Reine Notation/Symbol**: „|x|", „Σ∗", „Güte 2". → Eltern = die definierende Definition.
-- **Laufzeit-/Größen-Detail**: „O(|V|⁴) Verifizierer-Laufzeit", „|V'| = |V| bei Reduktion", „Reduktion in O(|E|)". → Eltern = der Algorithmus/die Reduktion.
-
-## Regeln
-- Ein Fragment wird NUR degradiert, wenn sein **Eltern-Baustein in der Liste steht** (gib dessen Nummer an). Findest du keinen Eltern → behalte es (kein „Eltern").
-- Zweifel betrifft die EIGENSTÄNDIGKEIT: Ist unklar, ob ein Eintrag für sich steht → behalten. Aber eine klare Eigenschaft/Notation/ein Beweis-Teil MIT Eltern in der Liste IST ein Fragment — nicht aus Vorsicht behalten.
-- Eine eigenständige **Reduktion zwischen zwei Problemen** ist ein Baustein, KEIN Fragment („3-SAT ≤ Clique").
-- Urteile am INHALT (nach dem „—"), nicht am Titel.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (nur die Fragment-Nummern aus {von}–{bis}, je mit Eltern-Nummer; `fragmente` darf leer sein):
-{{"fragmente": {{"12": 5, "13": 5, "27": 19}}}}

templates/Prompt/Bausteine-Klaerung.md

@@ -1,32 +0,0 @@
-Zum Thema "{topic}" stehen unten Baustein-Kandidaten, jeder als "Titel — Beschreibung". **Beurteile am INHALT (nach dem —), nicht am Titel.** Entscheide für JEDEN Eintrag: echter, eigenständiger Baustein → `aufnehmen`, sonst verwerfen (in keine Liste).
-
-KANDIDATEN (jeweils entscheiden):
-{rest}
-
-Was ein Baustein IST: eine eigenständige LERNEINHEIT — ein Konzept, ein Verfahren, ein Problem, eine Definition, ein benannter Satz MIT inhaltlicher Aussage.
-
-**Define-Test (entscheidend):** Beschreibt der INHALT ein eigenständiges Konzept, das man einem Lernenden erklären kann — OHNE Bezug auf einen konkreten Beweisschritt oder eine bestimmte Skript-Stelle? Ja → aufnehmen. Nein → verwerfen.
-
-Was KEIN Baustein ist (→ verwerfen, AUCH wenn eine Beschreibung dabei steht):
-- Hilfskonstrukte, die nur INNERHALB eines Beweises/einer Reduktion existieren: "Knoten z", "Hilfsvariable", "Bedingung (**)" (ein Hilfsknoten / eine markierte Bedingung — kein eigenständiges Konzept).
-- Beweis-Fragmente/Zwischenschritte: "Beweis (b) Güte", "Beweis ⊂ Richtung", "Eigenschaft (a)".
-- Generische Platzhalter ohne eigenes Konzept: "Optimale Lösung", "Lösung" (nur im Kontext eines konkreten Problems sinnvoll).
-- Reine Verweise OHNE inhaltliche Beschreibung: "Satz 7.18" (nichts Sprechendes nach dem —).
-- Zu Vages oder erkennbar Erfundenes.
-
-**Verweis-Titel MIT echtem Inhalt → aufnehmen UND umbenennen:** Hat ein Eintrag einen nichtssagenden Titel ("Satz 7.18", "Korollar 6.18", "Lemma 6.2"), beschreibt die Beschreibung aber ein echtes Konzept → nimm ihn auf und gib im Feld `umbenennen` einen sprechenden Namen aus dem Inhalt. Im `aufnehmen`-Eintrag bleibt der **Original-Titel** stehen (für die Zuordnung); der neue Name steht NUR in `umbenennen`.
-
-Beispiele:
-- "Clique-Member — k-Clique, die einen festen Knoten v enthält" → **aufnehmen** (eigenständiges Problem).
-- "Satz 7.18 — MGA hat Worst-Case-Güte 2" → **aufnehmen** + `umbenennen`: "Satz 7.18" → "MGA-Algorithmus (Güte 2)".
-- "Bedingung (**) — Ungleichungen pi ≤ pk im Scheduling-Beweis" → **verwerfen** (Hilfskonstrukt im Beweis).
-- "Satz 7.18" (keine Beschreibung) → **verwerfen** (bloßer Verweis).
-
-Regeln:
-- Im Zweifel an der Eigenständigkeit → eher aufnehmen. Dubletten werden später separat entfernt; hier zählt nur: echter Baustein oder Müll.
-- Übernimm aufgenommene Einträge WÖRTLICH ("Titel — Kurzbeschreibung"), nicht umformulieren.{final}
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (kein weiterer Text in der Datei; `umbenennen` darf leer sein):
-{{"aufnehmen": ["Titel — Kurzbeschreibung"], "umbenennen": {{"alter Titel": "sprechender Name"}}, "rest": []}}

templates/Prompt/Bausteine-Paar-Filter.md

@@ -1,20 +0,0 @@
-Zwei Recherchen haben Bausteine für das Thema "{topic}" notiert. Entscheide für JEDES Paar, ob A und B DENSELBEN Baustein bezeichnen (dasselbe Konzept, nur anders formuliert) → **ja**, oder ob es ZWEI UNTERSCHIEDLICHE Bausteine sind → **nein**.
-
-PAARE:
-{paare}
-
-Regeln:
-- **Achte zuerst auf die KERN-ENTITÄT** (das Problem/Objekt, um das es geht): Clique, Vertex Cover, Independent Set, Dominating Set, Set Cover, FVS, Knapsack … Sind die Entitäten VERSCHIEDEN → **nein**, egal wie gleich der Satzbau ist.
-- Gleicher Satzbau täuscht. Diese Paare sind **nein** (verschiedene Entität trotz fast identischer Formulierung):
-  - "Lower Bound **Clique** bzgl. Knoten" ↔ "Lower Bound **Vertex Cover** bzgl. Knoten"
-  - "Lower Bound Clique bzgl. **Knoten**" ↔ "Lower Bound Clique bzgl. **Kanten**"
-  - "Verifizierer für **FVS**" ↔ "Verifizierer für **Knapsack**"
-  - "**Cliquenproblem**" ↔ "**Vertex-Cover-Problem**"
-- **ja** nur bei echter Bedeutungsgleichheit: gleiche Lösung desselben Problems, dieselbe Entität, nur andere Formulierung/Benennung (z. B. "SET COVER" ↔ "Mengenüberdeckungsproblem", "Cliquenproblem" ↔ "k-CLIQUE", "List Scheduling" ↔ "LPT-Algorithmus").
-- **nein** auch bei verschiedenen Aspekten desselben Problems: "Set Cover (Problem)" ↔ "Set Cover ETH-Schranke"; ein Problem ↔ seine Reduktion auf ein anderes; ein Problem ↔ sein Verifizierer.
-- Im Zweifel **nein** — lieber zwei getrennte Bausteine als zwei Konzepte fälschlich verschmelzen.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (jede Paar-Nummer aus der Liste mit "ja" oder "nein"; kein weiterer Text in der Datei):
-{{"paare": {{"1": "ja", "2": "nein"}}}}

templates/Prompt/Bausteine-Quelle-Link.md

@@ -1 +0,0 @@
-Die Quelle wurde von einer Website gecrawlt und liegt als Text-Dateien im Ordner {project} (Seiten als .txt, PDFs als gleichnamige .txt — lies IMMER die .txt). Jede Seiten-Datei beginnt mit einer `QUELLE:`-Zeile (Ursprungs-URL). Verschaffe dir mit Bash (ls/find) einen Überblick und lies die Dateien mit dem Read-Tool. ZIEL: Klausur-Vorbereitung. Erfasse die PRÜFUNGSRELEVANTEN Bausteine: Definitionen, Kernkonzepte, Verfahren/Algorithmen, Formeln, typische Aufgaben. Nur was in den Dateien steht — nichts Erfundenes, kein externes Wissen dazu.

templates/Prompt/Bausteine-Quelle-Projekt.md

@@ -1 +0,0 @@
-Das Thema ist das Projekt unter {project}. Verschaffe dir mit Bash (ls/find) einen Überblick und lies README, Doku-Ordner und den relevanten Quellcode mit dem Read-Tool. PDFs liegen als gleichnamige .txt-Dateien vor — lies IMMER die .txt, nie das PDF. ZIEL: das Projekt VERSTEHEN, nicht nachprogrammieren. Erfasse die Bausteine, die erklären, wie es funktioniert: die Features/Funktionen, die Architektur und Komponenten, die wichtigen Abläufe/Flows (z.B. Request→Response, Datenfluss), die zentralen Konzepte und Entscheidungen. Nicht Zeile-für-Zeile-Code, sondern das Verständnis-Gerüst. Die Bausteine müssen das echte Projekt widerspiegeln, nichts Erfundenes.

templates/Prompt/Bausteine-Quelle-Thema.md

@@ -1 +0,0 @@
-Recherchiere per Websuche und gehe systematisch vor: arbeite die Struktur der maßgeblichen Quellen ab — bei Software/Tools die offizielle Dokumentation (Handbuch-Kapitel, Feature-Übersichten, Release Notes der letzten Versionen), bei Sprachen und Konzept-Themen Lehrbücher, Curricula und Standardwerke — und erfasse jeden Baustein, dem ein Lerner begegnen kann — von Grundlagen bis Spezialfälle. Achte darauf, dass Versionsangaben bzw. der fachliche Stand aktuell sind.

templates/Prompt/Bausteine-Quelle-Uni.md

@@ -1 +0,0 @@
-Das Lernmaterial liegt im Ordner {project} (z.B. Vorlesungsfolien, Skripte, Übungsblätter; PDFs liegen als gleichnamige .txt-Dateien vor — lies IMMER die .txt, nie das PDF). Verschaffe dir mit Bash (ls/find) einen Überblick und lies die Dateien mit dem Read-Tool. ZIEL: Klausur-Vorbereitung. Erfasse die PRÜFUNGSRELEVANTEN Bausteine: Definitionen, Kernkonzepte, Verfahren/Algorithmen, Formeln und Sätze, typische Aufgaben- und Fragetypen. Die Bausteine müssen das echte Material widerspiegeln — nur was darin vorkommt, nichts Erfundenes, kein externes Lehrbuchwissen dazuerfinden.

templates/Prompt/Bausteine-Recherche-Mapping.md

@@ -1,16 +0,0 @@
-{n} Recherche-Agenten haben unabhängig voneinander die Bausteine des Themas "{topic}" ermittelt. Exakt gleiche Titel wurden bereits zusammengeführt; die Zahl in Klammern sagt, wie viele Recherchen den Baustein nennen. Konsolidiere die Liste.
-
-{eintraege}
-
-Regeln:
-- Erkenne GLEICHE Konzepte unter verschiedenen Titeln und führe sie zu einem Baustein zusammen. Die Nennungszahlen der zusammengeführten Einträge addieren sich dabei (pro Recherche zählt ein Konzept nur einmal).
-- Ein Baustein löst GENAU EIN PROBLEM. Einträge, die Varianten derselben Lösung sind, werden zu EINEM Baustein zusammengefasst (richtig: ein Baustein `<input>` für alle Typen, ein Baustein "Modalverben" für alle Modalverben; falsch: je ein Eintrag pro input-Typ oder pro Verb, aber auch Sammeleinträge, die mehrere Probleme mischen).
-- Ein Baustein ist ATOMAR: genau eine Idee, vollständig in sich. Test: Man kann nichts entfernen, ohne ihn unvollständig zu machen — und es fehlt nichts, um ihn zu verstehen.
-- KONSOLIDIERE die Granularität: ein Baustein ist eine LERNEINHEIT, kein Lexikon-Eintrag. Liefern die Recherchen dutzende Mikro-Einträge derselben Sorte (eine CSS-Eigenschaft, ein Verb, eine Geste pro Eintrag), fasse sie nach Problem zusammen (richtig: "Flexbox-Ausrichtung" statt sechs Einträge für justify-content, align-items, …). Mehr als ~150 Bausteine sind fast immer ein Granularitäts-Problem — prüfe dann gezielt auf solche Serien.
-- Teile danach in zwei Listen: Bausteine, die (nach dem Zusammenführen) von MINDESTENS ZWEI Recherchen genannt werden → `bausteine`. Nur einmal Genanntes oder fachlich Zweifelhaftes → `rest`. Verwirf nur, was offensichtlich erfunden ist.
-- Lass die Quellen weg. Titel und Kurzbeschreibung (max. ~12 Wörter) auf DEUTSCH (Code-Bezeichner bleiben original). Jeder Titel muss EINDEUTIG sein.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (jeder Eintrag ein String "Titel — Kurzbeschreibung"; kein weiterer Text in der Datei):
-{{"bausteine": ["Titel — Kurzbeschreibung"], "rest": ["Titel — Kurzbeschreibung"]}}

templates/Prompt/Bausteine-Recherche.md

@@ -1,25 +0,0 @@
-Ermittle ALLE Bausteine (Konzepte, Techniken, Regeln, Funktionen — die kleinsten lernbaren Einheiten) des Themas "{topic}" für einen Lern-Guide.
-
-{source}
-
-Regeln:
-- Ein Baustein löst GENAU EIN PROBLEM. Varianten derselben Lösung gehören in den einen Baustein, nicht als eigene Einträge (richtig: `<p>` ist ein Baustein, `<input>` mit allen Typen ist ein Baustein, "Ich-Botschaften" ist ein Baustein, "Present Perfect" mit allen Signalwörtern ist ein Baustein; falsch: 21 Einträge für jeden input-Typ oder je ein Eintrag pro unregelmäßigem Verb, aber auch Sammeleinträge, die mehrere Probleme mischen).
-- Ein Baustein ist ATOMAR: genau eine Idee, vollständig in sich. Test: Man kann nichts entfernen, ohne ihn unvollständig zu machen — und es fehlt nichts, um ihn zu verstehen.
-- Granularität: ein Baustein ist eine LERNEINHEIT, kein Lexikon-Eintrag. Familien, die zusammen gelernt werden (z. B. die font-*-Eigenschaften, die Modalverben), sind EIN Baustein.
-- Ebene (wichtig): ein Baustein ist self-contained — erklärbar, OHNE einen ANDEREN Baustein als Subjekt vorauszusetzen. Das sind Probleme, Verfahren/Algorithmen, Definitionen, benannte Sätze mit eigener Aussage. Ein Detail, das ein anderes Konzept voraussetzt, gehört IN dessen Baustein (als Teil), nicht als eigener Eintrag:
-  - Eine EIGENSCHAFT eines Konzepts gehört zum Konzept: „Clique" ist ein Baustein; „Clique ist NP-vollständig", „Clique ∈ NP", „Laufzeit von Clique" sind Teile davon — kein eigener Eintrag.
-  - Ein BEWEIS-/Reduktions-Bauteil gehört zum Satz/zur Reduktion: „A-Komponente", „Dummy-Item", „αEnde", „Hilfsvariable" — kein eigener Eintrag.
-  - Reine NOTATION/Symbole gehören zu ihrer Definition: „|x|", „Σ∗" — kein eigener Eintrag.
-  - Eine eigenständige REDUKTION zwischen zwei Problemen ist dagegen ein eigener Baustein („3-SAT ≤ Clique").
-- KEINE Kategorien, KEINE Bewertung, KEINE Reihenfolge nach Wichtigkeit — nur eine flache, durchnummerierte Liste.
-- Es gibt KEINE Ziel-Anzahl. Höre erst auf, wenn die Recherche nichts Neues mehr hergibt.
-- Erfinde nichts: nimm nur Bausteine auf, die du in der Recherche belegt hast. Notiere pro Baustein die Quelle (URL bzw. Dateipfad). Gibt es keine Einzel-Quelle, reicht die Sammel-Quelle (Handbuch-Kapitel, Lehrbuch, Übersichtsseite, Verzeichnis).
-- Schreibe Titel und Beschreibung auf DEUTSCH (Fachbegriffe/Code-Bezeichner bleiben original).
-- Beschreibung maximal ~12 Wörter.
-
-Schreibe NUR die Markdown-Datei nach: {bausteine_path}
-
-Format: GENAU eine Zeile pro Baustein: `N. Titel — Kurzbeschreibung — Quelle`
-Die Quelle (3. Segment) MUSS der exakte Dateiname bzw. die URL der Crawl-Seite sein, aus der der Baustein stammt — sie steuert die Abdeckungs-Prüfung.
-{fokus}
-{extra}

templates/Prompt/Block-Chat.md

@@ -0,0 +1,19 @@
+You are a helpful tutor for the block "{block}" from the learning guide on the topic "{topic}". A reader is asking you questions about exactly this block.
+
+BLOCK FROM THE GUIDE:
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+CHAT TRANSCRIPT SO FAR:
+{transcript}
+
+Reply as the assistant to the latest user message.
+
+IMPORTANT – answer style:
+- SHORT and SIMPLE: 1–3 sentences, plain language.
+- No preamble, no restating the question, no Markdown wrapper.
+- Stay on the block; use the guide version and the deep-dive as context.
+
+Write your answer in GERMAN. Output ONLY the answer, with no prefix like "Assistent:".

templates/Prompt/Block-Exam-Discussion.md

@@ -0,0 +1,45 @@
+You are the tutor in an exam on the block "{block}" (topic "{topic}"). You speak DIRECTLY with the learner ("du") and guide them through the question. You discuss; you do NOT grade.
+
+TESTED QUESTION:
+{question}
+
+YOUR LAST RATING (if any):
+{last_rating_block}
+
+BLOCK FROM THE GUIDE:
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+TRANSCRIPT SO FAR:
+{transcript}
+
+Reply as the tutor to the latest user message.
+
+TONE & FORM:
+- Address the learner as "du". Talk WITH them, not about them.
+- Output only your reply: no preamble, no meta-commentary, no description of the conversation or your role.
+- At most 3 sentences. Check this before you send — otherwise shorten.
+
+HOW YOU GUIDE:
+- FOCUS: the yardstick is the TESTED QUESTION above — NOT the deepest possible detail. Once this one question is answered, it is done. NEVER shift the goal to deeper follow-up mechanisms ("but which exact mechanism behind it…") that go beyond the question asked.
+- NEVER reveal the solution — not even confirmingly ("Exactly, it's X"). At most a small nudge.
+- At most ONE counter-question: one question mark, one thing. No multi-parter.
+- Ask about the why/what-for/consequence — not for facts or lists ("which data…", "name the…").
+- Follow up ONLY while the question asked is NOT yet answered. Not to deepen an already correct answer.
+- If the question is unclear: explain the QUESTION, not the answer.
+
+MATERIAL BOUNDARY:
+- Only ask what the block above EXPLICITLY explains. Mirror the depth of the source: something only briefly mentioned (a keyword) stays brief — do not build a detail question out of it.
+- What is not in the material, you say openly ("that is not in the guide"). Never demand more than the text provides.
+
+CLOSING & FAIRNESS:
+- If the learner has answered the QUESTION ASKED (the core in their own words or applied) — even across several steps: acknowledge it briefly and suggest having the transcript graded. Do NOT dig deeper, even if a still more precise detail existed.
+- If the learner shows on the merits that your question was wrong, unclear or off-material: agree and adjust. But do NOT give in out of politeness or on mere insistence — only a real factual argument counts.
+- You assign NO rating and ask NO new exam question.
+
+NOT like this: "Der Lerner fragt, was nicht behandelt wird — schauen wir uns an, was der Guide sagt…"
+LIKE this: "Stimmt — das steht so nicht im Guide. Was sagt der Block denn konkret über …?"
+
+Reply directly, in at most 3 sentences, and address the learner as "du". No "Assistent:" prefix, no Markdown wrapper. Write your reply in GERMAN.

templates/Prompt/Block-Gapchoice.md

@@ -0,0 +1,31 @@
+You build a cloze (fill-in-the-blank) task WITH CHOICES for a learning exam on the topic "{topic}", block "{block}". You receive a pattern as a template — turn its core idea into a sentence with exactly ONE blank and offer four terms to choose from.
+
+PATTERN (template — same core point):
+{pattern}
+
+BLOCK FROM THE GUIDE (the factual reference — the sentence must never contradict it):
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+LEARNER TIER (sets how demanding the sentence and options are):
+{tier_block}
+{distractor_block}
+TASK:
+- Write ONE short declarative sentence (at most ~15 words). Replace the **key term** with `___` (exactly one blank).
+- The blank is a **technical term as a word** — NOT a mathematical symbol/part of a formula
+  (not `L_2`, not `f(w)`). It sits **outside** `$…$` (never inside a formula).
+- Offer EXACTLY FOUR terms as options — **exactly one** fits the blank.
+- The three wrong ones are plausible but clearly wrong (a mix-up, a related term) — no silly ones.
+- Keep options short (a term or short half-sentence), similar in length.
+- `$…$` ONLY for real mathematics (variables, symbols, formulas). Code, paths, namespaces, file names, JSON and identifiers ALWAYS in backticks (`` `…` ``) — NEVER as bare text, NEVER in `$…$`. Example: `` `Acme\Example` ``, not `$Acme\Example$` and not without backticks.
+- Write the sentence and all options in GERMAN.
+
+Output ONLY this JSON (no other text):
+{{"sentence": "Ein ___ ist eine endliche Menge von Symbolen.", "options": [
+  {{"text": "Alphabet", "correct": true}},
+  {{"text": "Wort", "correct": false}},
+  {{"text": "Sprache", "correct": false}},
+  {{"text": "Zustand", "correct": false}}
+]}}

templates/Prompt/Block-Gaptext-Exam.md

@@ -0,0 +1,18 @@
+You are checking a cloze answer in a learning exam on the topic "{topic}", block "{block}". The learner has typed a term into the blank. Decide whether it fits technically.
+
+SENTENCE WITH BLANK:
+{sentence}
+
+EXPECTED SOLUTION: {solution}
+ACCEPTED ALTERNATIVES: {alternatives}
+
+LEARNER'S ANSWER: {input}
+
+CHECK:
+- Does the answer hit the same term as the solution? Synonym, different spelling,
+  typo, singular/plural, with/without article → counts as CORRECT.
+- A technically different term or the opposite → WRONG.
+- Be generous about form, strict about substance.
+
+Output ONLY this JSON (no other text):
+{{"correct": true}}

templates/Prompt/Block-Gaptext.md

@@ -0,0 +1,29 @@
+You build a cloze (fill-in-the-blank) task for a learning exam on the topic "{topic}", block "{block}". You receive a pattern as a template — turn its core idea into a sentence with exactly ONE blank.
+
+PATTERN (template — same core point, as a cloze sentence):
+{pattern}
+
+BLOCK FROM THE GUIDE (the factual reference — the sentence must never contradict it):
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+LEARNER TIER (sets how demanding the sentence and blank are):
+{tier_block}
+
+TASK:
+- Write ONE short declarative sentence (at most ~15 words, no cascade of subclauses).
+- Replace the **key term** with `___` (exactly one blank).
+- The blank is a **technical term as a word** (e.g. „Alphabet", „polynomiell") — NOT a
+  mathematical symbol or part of a formula (not `L_2`, not `f(w)`). It sits **outside**
+  `$…$` (never inside a formula).
+- The blank tests active recall — it stands for a central technical term, not a filler word.
+- The sentence gives enough context that the solution is unambiguous (no guessing).
+- `$…$` ONLY for real mathematics (variables, symbols, formulas, e.g. $V(w,c)$). Code, paths, namespaces, file names, JSON and identifiers ALWAYS in backticks (`` `…` ``) — NEVER as bare text, NEVER in `$…$`. Example: `` `Acme\Example` ``, not `$Acme\Example$` and not without backticks.
+- `solution` = the expected term (short, as it belongs in the blank).
+- `alternatives` = accepted synonyms/spellings (may be empty), NO wrong ones.
+- Clear German, one sentence, exactly one `___`.
+
+Output ONLY this JSON (no other text):
+{{"sentence": "Ein ___ ist eine endliche Menge von Symbolen.", "solution": "Alphabet", "alternatives": ["Zeichenvorrat"]}}

templates/Prompt/Block-Pruefen.md

@@ -1,25 +1,25 @@
-Prüfe EINEN Abschnitt (Markdown-Block) einer Section eines Lern-Guides zum Thema "{topic}" gegen die Guide-Regeln und gib ihn KORRIGIERT zurück. Zielgruppe: Anfänger ohne Vorwissen.
+Check ONE passage (a Markdown block) within a section of a learning guide on the topic "{topic}" against the guide rules, and return it CORRECTED. Target audience: beginners with no prior knowledge.
 
 {facts}
 
-SECTION-SPEZIFIKATION (Soll-Zustand):
+SECTION SPECIFICATION (target state):
 {spec}
 
-SUBBAUSTEINE der Section (Kontext):
-{subbausteine}
+SUBBLOCKS of the section (context):
+{subblocks}
 
-GANZE SECTION (nur Kontext — NICHT mit ausgeben):
-{kontext}
+WHOLE SECTION (context only — do NOT output it):
+{context}
 
-ZU PRÜFENDER ABSCHNITT:
-{block}
+PASSAGE TO CHECK:
+{snippet}
 
-{hinweis}
+{hint}
 
-Prüfe den Abschnitt auf echte Mängel und behebe sie — was in Ordnung ist, bleibt unverändert:
-- Fachliche Fehler, falsche oder erfundene Fakten/Werte.
-- Verständlichkeit für Anfänger; Lesbarkeit (Sätze über ~25 Wörter, Schachtelsätze, Textwand, eine Aufzählung als Fließtext-Satz, unerklärte Fachbegriffe).
-- Beispiel passend und korrekt, Format laut Spezifikation.
-- Formeln laut Spezifikation (lange/mehrteilige als abgesetzte `$$…$$`, keine Prosa in `\text{{…}}`); sauberes Markdown.
+Check the passage for genuine flaws and fix them — anything that is fine stays unchanged:
+- Factual errors, wrong or invented facts/values.
+- Comprehensibility for beginners; readability (sentences over ~25 words, nested clauses, walls of text, a list crammed into a running-text sentence, unexplained technical terms).
+- The example is fitting and correct; format per the specification.
+- Formulas per the specification (long/multi-part ones set off as `$$…$$`, no prose inside `\text{{…}}`); clean Markdown.
 
-Gib NUR den korrigierten Abschnitt als Markdown zurück — kein weiterer Text, keine Erklärung, keine Marker. Ist nichts zu ändern, gib den Abschnitt unverändert zurück.
+Return ONLY the corrected passage as Markdown — no other text, no explanation, no markers. If nothing needs changing, return the passage unchanged. Keep the content in GERMAN.

templates/Prompt/Block-Question-Critique.md

@@ -0,0 +1,32 @@
+You are a quality reviewer for exam questions in a learning guide on the topic "{topic}", block "{block}". Another agent has written a question. Check it strictly.
+
+BLOCK FROM THE GUIDE:
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+EXAM TRANSCRIPT SO FAR (only earlier questions and answers):
+{transcript}
+
+ALREADY ASKED / ALREADY QUEUED (the question must match none of them):
+{avoid_block}
+
+DESIRED QUESTION TYPE / FOCUS (for orientation):
+{type_block}
+{fokus_block}
+
+QUESTION TO REVIEW:
+{question}
+
+CHECK AGAINST THESE CRITERIA:
+- Style: EXACTLY ONE question, a single question mark, a single thing. No multi-parter ("und"/"sowie", "both … and …", "name three …").
+- Brevity: at most 1–2 sentences, no scenario build-up across several sentences, no long preamble.
+- NO repetition — object if the question is too close in meaning to one from the transcript OR the avoid list (same core point, just reworded).
+- Factually correct: the question must be answerable from the material above and must NOT contradict the reference. No invented extra assumptions.
+
+Object ONLY to genuine violations. If the question is short, single and correct, it is fine — demand nothing beyond that.
+
+Output ONLY JSON (no other text). Write the problem notes in GERMAN:
+- All fine: {{"ok": true}}
+- Otherwise: {{"problems": ["short flaw 1", "short flaw 2"]}}

templates/Prompt/Block-Question-Variante.md

@@ -0,0 +1,31 @@
+You are the examiner in a learning guide on the topic "{topic}", block "{block}". Pose the learner ONE comprehension question. You are given a **pattern** — an example question about the core concept. Ask the same thing, but at a difficulty matching the learner tier (see below) and in different wording.
+
+PATTERN (template — same core, new wording and difficulty):
+{pattern}
+
+BLOCK FROM THE GUIDE (the factual reference — the question must never contradict it):
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+LEARNER TIER (sets how demanding the question is):
+{tier_block}
+
+GROUNDING IN THE BLOCK (check first):
+- The pattern was created without the guide text — it may miss the content.
+- Check the pattern against the BLOCK above: can the thing really be answered from the material?
+- DISCARD the pattern and pose a DIFFERENT question about the CORE of the block instead, if it: asks about a keyword only mentioned in passing, refers to things never shown (code snippets, examples, concrete values), or rests on a false premise.
+- The replacement question must be clearly answerable from the BLOCK. When in doubt, ask about the block's central concept.
+
+HARD RULES:
+- EXACTLY ONE question. A single question mark. A single thing.
+- At most 1–2 sentences, no preamble, no scenario build-up.
+- Forbidden: chaining two questions with "und"/"sowie", "name three …", any list demands.
+- If the pattern is valid (see GROUNDING): same core question, just reworded — no verbatim copy. Otherwise the grounded replacement question.
+- Only ask what is answerable from the material. No invented extra assumptions.
+- Address the learner directly, in clear German, no fluff.
+- `$…$` ONLY for real mathematics. Code, paths, namespaces, file names, JSON and identifiers ALWAYS in backticks (`` `…` ``) — NEVER as bare text, NEVER in `$…$` (not `$Acme\Example$`, but `` `Acme\Example` ``).
+
+Output ONLY this JSON (no other text):
+{{"question": "exactly one short question"}}

templates/Prompt/Block-Question.md

@@ -0,0 +1,45 @@
+You are the examiner in a learning guide on the topic "{topic}". Ask the learner ONE comprehension question about the block "{block}". The learner can see the material — ask for understanding and transfer, not for what can be read off.
+
+BLOCK FROM THE GUIDE:
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+EXAM TRANSCRIPT SO FAR (only earlier questions and answers):
+{transcript}
+
+ALREADY ASKED / ALREADY QUEUED — do not repeat them, not even in meaning:
+{avoid_block}
+
+DESIRED QUESTION TYPE:
+{type_block}
+
+FOCUS:
+{fokus_block}
+
+LEARNER TIER (sets how demanding the question is — match depth and difficulty to it):
+{tier_block}
+
+HARD RULES FOR THE QUESTION — more important than anything else:
+- EXACTLY ONE question. A single question mark. A single thing.
+- At most 1–2 sentences. No scenario build-up, no preamble, no "Suppose … and also …".
+- Forbidden: chaining two questions with "und"/"sowie", "name three …", "both … and …", any list demands.
+- Ask about ONE thought: one why, one consequence, one distinction, applying it to ONE short example, finding one error.
+- NO fact retrieval ("which data…", "how many…", "what does it contain…"): that tests memorization, not understanding.
+- Only ask about what the block really explains — not about something mentioned in passing (a keyword) that it does not elaborate.
+- If a transfer question does not fit in one sentence, choose a simpler question.
+- Do NOT repeat any question from the transcript or the avoid list — not even in meaning/reworded. Ask about a DIFFERENT thing (another aspect, another subblock).
+
+FACTUAL REFERENCE — IMPORTANT:
+- The guide version and the deep-dive above are the reference. Your question must NEVER contradict them.
+- Invent no extra assumptions (e.g. missing inputs, changed definitions). Only ask what follows from the material.
+- `$…$` ONLY for real mathematics. Code, paths, namespaces, file names, JSON and identifiers ALWAYS in backticks (`` `…` ``) — NEVER as bare text, NEVER in `$…$` (not `$Acme\Example$`, but `` `Acme\Example` ``).
+
+CHECKER'S NOTES ON THE LAST VERSION:
+{kritik_block}
+
+Address the learner directly, in clear German, no fluff.
+
+Output ONLY this JSON (no other text):
+{{"question": "exactly one short question"}}

templates/Prompt/Block-Quiz.md

@@ -0,0 +1,32 @@
+You build a multiple-choice question for a learning exam on the topic "{topic}", block "{block}". You receive a pattern as a template — pose the same thing as a multiple-choice question.
+
+PATTERN (template — same core question, as multiple choice):
+{pattern}
+
+BLOCK FROM THE GUIDE (the factual reference — the options must never contradict it):
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+LEARNER TIER (sets how demanding the question and distractors are):
+{tier_block}
+{distractor_block}
+TASK:
+- Write ONE clear question and EXACTLY FOUR answer options.
+- EXACTLY ONE option is correct, the other three are clearly wrong.
+- The correct option is factually supported by the material. Each wrong one is plausible
+  but clearly wrong (a typical error, a mix-up, a half-truth) — no silly ones.
+- **Options VERY SHORT:** a keyword, term or half-sentence, at most ~8 words.
+  NO full sentences, NO "Because …" lead-in, no justification prose. Just the core.
+- All four options similar in length and in the same style. No giveaway cues.
+- Keep the question itself short (1 sentence). Clear German.
+- `$…$` ONLY for real mathematics (variables, symbols, formulas, e.g. $V(w,c)=A(w)$). Code, paths, namespaces, file names, JSON and identifiers ALWAYS in backticks (`` `…` ``) — NEVER as bare text, NEVER in `$…$`. Example: `` `Acme\Example` ``, not `$Acme\Example$` and not without backticks.
+
+Output ONLY this JSON (no other text):
+{{"question": "the question", "options": [
+  {{"text": "Option A", "correct": true}},
+  {{"text": "Option B", "correct": false}},
+  {{"text": "Option C", "correct": false}},
+  {{"text": "Option D", "correct": false}}
+]}}

templates/Prompt/Block-Rating-Critique.md

@@ -0,0 +1,35 @@
+You are a quality reviewer for ratings in an exam on the block "{block}" from the learning guide on the topic "{topic}". Another agent has graded the learner's answer to the tested question. Check whether the rating is fair and correct.
+
+TESTED QUESTION:
+{question}
+
+BLOCK FROM THE GUIDE:
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+EXAM TRANSCRIPT (the learner's answer and any discussion):
+{transcript}
+
+RATING TO REVIEW (contains the assigned tier):
+{rating_block}
+
+TIER SCALE (share of the core that is hit):
+- unbeantwortbar (the question itself is broken — no loss of points) · kaum < 25 % · teilweise 25–49 % · solide 50–74 % · stark 75–99 % · komplett 100 %.
+
+CHECK AGAINST THESE CRITERIA:
+- FAIRNESS OF THE QUESTION: if the TESTED QUESTION cannot be answered from the BLOCK (a side topic/keyword, a reference to something not shown, a false premise), the tier MUST be "unanswerable" — NEVER "barely". If the learner was marked down for a broken question → misjudgment.
+- Does the tier match the actual share of the core? Too STRICT (a correct/complete answer rated too low) OR too LENIENT (a wrong/thin answer rated too high) → misjudgment. Check both directions.
+- Core factually WRONG (the opposite) → must be "barely", no matter how confident.
+- No demanding beyond the material: "not in the material" must never count against the learner.
+- No recitation test: factually CORRECT in other words/synonyms must count fully, not be marked down.
+- Asymmetry: world knowledge only to RECOGNIZE correct answers, never to demand more strictly.
+- Contradiction check: the feedback matches the tier and does not contradict itself.
+- Check the answer ITSELF for correctness (material AND logic), not just the fairness.
+
+Object ONLY to genuine misjudgments. If the tier is fair, correct and faithful to the material, it is fine.
+
+Output ONLY JSON (no other text). Write the problem notes in GERMAN:
+- Rating is fine: {{"ok": true}}
+- Otherwise: {{"problems": ["what is wrong with the rating"]}}

templates/Prompt/Block-Rating.md

@@ -0,0 +1,55 @@
+You are grading a learner's answer to the tested question — block "{block}" from the learning guide on the topic "{topic}".
+
+TESTED QUESTION:
+{question}
+
+BLOCK FROM THE GUIDE:
+{section_block}
+
+COMPACT VERSION (key takeaways, if any):
+{compact_block}
+
+EXAM TRANSCRIPT (the learner's answer and any discussion):
+{transcript}
+
+THE LEARNER'S DISSATISFACTION WITH AN EARLIER RATING (if any — take it seriously, but only give in if they are factually right):
+{reason_block}
+
+Grade the answer to the TESTED QUESTION — based on the answer AND the discussion in the transcript.
+
+THE FINAL STATE COUNTS — not the first statement:
+- Grade the understanding the learner reached BY THEMSELVES at the END of the transcript.
+- Wrong at first, then self-corrected through dialogue = counts (a valid learning path).
+- BUT: if the tutor gave the solution away and the learner only echoed it ("yes", "exactly", mere repetition), it does NOT count. The decisive conclusion must come from the learner.
+
+QUESTION CHECK FIRST — is the TESTED QUESTION even fair?
+- Check it against the BLOCK: can it be answered from the material?
+- NOT fair if the question asks about a keyword only mentioned in passing, refers to things never shown (code snippets, examples, values), or rests on a false premise.
+- Then use the tier "unanswerable": the learner is NOT penalized (no loss of points). This also applies when the learner correctly says "that is not in the material / cannot be answered". The feedback briefly names the flaw in the QUESTION — no blame on the learner.
+- If the question is fair, grade normally with the tiers below.
+
+TIER — how much of the CORE of the question is correctly hit? Choose EXACTLY ONE:
+- "barely": under 25 % — almost nothing right, or clearly wrong / the opposite.
+- "partial": 25–49 % — a fragment is right, the core is missing.
+- "solid": 50–74 % — the core is right, details are missing.
+- "strong": 75–99 % — largely complete and correct, only a small gap.
+- "complete": 100 % — the core is fully and correctly answered.
+
+YARDSTICK:
+- Measured against what the QUESTION asks for — in ANY correct wording, not against the guide's exact phrasing. For "complete" the question must be satisfied, nothing more — do not demand an ideal full answer.
+- If the core is factually WRONG (the opposite), it is "barely" — no matter how confidently phrased.
+- The yardstick is the originally TESTED QUESTION, not deeper follow-up questions. Digging deeper does NOT raise the bar.
+
+YOU ARE TESTING UNDERSTANDING, NOT RECITATION — an asymmetric material boundary:
+- DEMANDING: never demand more than the question and material provide. "Not in the material" must never count against the learner.
+- ACCEPTING: factually CORRECT counts high — even in other words or with correct knowledge beyond the guide. Synonyms count fully.
+- WORLD KNOWLEDGE: only to RECOGNIZE correct answers, never to demand more strictly.
+- Assert nothing made up. Give in when the learner is factually right — not out of politeness or on mere insistence.
+
+FIELD `feedback`: max. 1 sentence, address the learner directly. Briefly justify the tier. NO new question. No contradiction — do not affirm the answer and name the counter-solution at the same time. Write `feedback` in GERMAN.
+
+CHECKER'S NOTES ON THE LAST VERSION:
+{kritik_block}
+
+Output ONLY this JSON (no other text):
+{{"feedback": "one sentence", "tier": "unanswerable" | "barely" | "partial" | "solid" | "strong" | "complete"}}

templates/Prompt/Blocks-Block-Grouping.md

@@ -0,0 +1,20 @@
+Below are numbered block candidates for the topic "{topic}". They come from a similarity cluster. Some refer to the SAME block or a property of it, others are distinct. Group them.
+
+CANDIDATES:
+{entries}
+
+Rules:
+- Form groups: numbers that belong to the SAME block go into ONE group.
+- **Watch the core entity** (the problem/object): Clique, Vertex Cover, Set Cover, Knapsack, Dominating Set, LPT/List Scheduling … Different entity → different groups, even with similar phrasing ("Lower Bound Clique" ≠ "Lower Bound Vertex Cover").
+- True paraphrases go TOGETHER, even when worded differently ("List Scheduling" = "LPT-Algorithmus"; "Set Cover" = "Mengenüberdeckung").
+- **A problem's properties belong TO the problem block — not on their own.** Bundle with the problem: its complexity status (∈ NP, NP-schwer, NP-vollständig), its verifier / certificate / NDTM, "… als Sprache / Definition", its individual lower-bound parameters (k / r / |U|).
+  - Example: "Knapsack", "Knapsack ∈ NP", "Knapsack NP-schwer", "Knapsack NP-vollständig", "Verifizierer für Knapsack" → ONE group (the "Knapsack" block).
+  - Example: "Hitting Set Lower Bound (k)", "(r)", "(|U|)" → ONE group.
+- Keep SEPARATE (own blocks): different problems (Clique-Member ≠ Clique-Nomember); a REDUCTION between two problems is its own technique (e.g. "3-SAT ⪯ k-Clique" stays separate); different methods/theorems with their own statement.
+- When in doubt between two different problems → SEPARATE. For a problem + its property → BUNDLE.
+- EVERY number goes into EXACTLY ONE group. A standalone block is a group with one element.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (lists of candidate numbers; each number exactly once):
+{{"groups": [[1, 3], [2], [4, 5]]}}

templates/Prompt/Blocks-Filter.md

@@ -0,0 +1,39 @@
+Below is the complete block list of a learning guide for the topic "{topic}", numbered. Your task: separate **real blocks** from **fragments** that actually belong to another block in the list.
+
+COMPLETE LIST (as context — you need it to find parents):
+{list}
+
+JUDGE the numbers **{from_n} to {to_n}** — go through them **ONE BY ONE**, one entry after another. The remaining entries are only context (possible parents).
+
+## Procedure per entry (mandatory for EACH one)
+For each entry {from_n}–{to_n}:
+1. What is the **subject**? (What is being talked about?)
+2. Is this subject itself another entry in the list — and does the entry only state a PROPERTY, a PROOF PART, a NOTATION, or a RUNTIME DETAIL about it?
+   - **Yes → fragment**, parent = the number of that subject.
+   - No, it stands on its own → block (keep).
+Lines marked with **⚠** are suspected cases (property/runtime/notation) — check them especially carefully. Decide by the content, not by the marking.
+
+## What is a BLOCK (standalone learning unit — keep)?
+A block is self-contained: you can explain it WITHOUT presupposing another block as its subject.
+- A **problem**: „3-SAT", „Clique", „Knapsack", „Dominating Set".
+- A **method/algorithm**: „LPT Scheduling", „Christofides", „FPTAS".
+- A **definition/concept**: „NP", „Reduktion", „Verifizierer", „KNF".
+- A **named theorem WITH its own statement**: „Cook-Levin: SAT ist NP-vollständig".
+
+## What is a FRAGMENT (belongs to another block → demote)?
+Self-containment test: does the entry presuppose ANOTHER concept in the list as its subject? Then it is that concept's property/part, not its own block.
+- **Property/status** of a problem X (that is itself in the list): „X ist NP-vollständig", „X ∈ NP", „NP-Schwere von X", „Approximationsgüte von X". → parent = X.
+- **Proof/reduction gadget**: „αEnde", „A-Komponente", „Dummy Items", „Schedule D*", „Knoten z", auxiliary variables. → parent = the theorem/reduction in whose proof it appears.
+- **Pure notation/symbol**: „|x|", „Σ∗", „Güte 2". → parent = the defining definition.
+- **Runtime/size detail**: „O(|V|⁴) Verifizierer-Laufzeit", „|V'| = |V| bei Reduktion", „Reduktion in O(|E|)". → parent = the algorithm/reduction.
+
+## Rules
+- A fragment is demoted ONLY if its **parent block is in the list** (give its number). If you find no parent → keep it (don't list it).
+- The doubt concerns STANDALONE-NESS: if it's unclear whether an entry stands on its own → keep it. But a clear property/notation/proof part WITH a parent in the list IS a fragment — don't keep it out of caution.
+- A standalone **reduction between two problems** is a block, NOT a fragment („3-SAT ≤ Clique").
+- Judge by the CONTENT (after the „—"), not the title.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (only the fragment numbers from {from_n}–{to_n}, each with its parent number; `fragments` may be empty):
+{{"fragments": {{"12": 5, "13": 5, "27": 19}}}}

templates/Prompt/Blocks-Klaerung.md

@@ -0,0 +1,32 @@
+For the topic "{topic}", below are block candidates, each as "Title — Description". **Judge by the CONTENT (after the —), not the title.** Decide for EACH entry: a real, standalone block → `keep`, otherwise discard (into no list).
+
+CANDIDATES (decide on each):
+{rest}
+
+What a block IS: a standalone LEARNING UNIT — a concept, a method, a problem, a definition, a named theorem WITH substantive content.
+
+**Define test (decisive):** Does the CONTENT describe a standalone concept you can explain to a learner — WITHOUT reference to a specific proof step or a particular spot in the script? Yes → include. No → discard.
+
+What is NOT a block (→ discard, EVEN if a description is attached):
+- Auxiliary constructs that exist only WITHIN a proof/reduction: "Knoten z", "Hilfsvariable", "Bedingung (**)" (a helper node / a marked condition — not a standalone concept).
+- Proof fragments/intermediate steps: "Beweis (b) Güte", "Beweis ⊂ Richtung", "Eigenschaft (a)".
+- Generic placeholders without their own concept: "Optimale Lösung", "Lösung" (only meaningful in the context of a concrete problem).
+- Pure references WITHOUT substantive description: "Satz 7.18" (nothing meaningful after the —).
+- Too vague or evidently fabricated.
+
+**Reference title WITH real content → include AND rename:** If an entry has an uninformative title ("Satz 7.18", "Korollar 6.18", "Lemma 6.2") but the description describes a real concept → include it and give a speaking name (in GERMAN) drawn from the content in the `rename` field. In the `keep` entry the **original title** stays (for matching); the new name goes ONLY in `rename`.
+
+Examples:
+- "Clique-Member — k-Clique, die einen festen Knoten v enthält" → **keep** (standalone problem).
+- "Satz 7.18 — MGA hat Worst-Case-Güte 2" → **keep** + `rename`: "Satz 7.18" → "MGA-Algorithmus (Güte 2)".
+- "Bedingung (**) — Ungleichungen pi ≤ pk im Scheduling-Beweis" → **verwerfen** (auxiliary construct in the proof).
+- "Satz 7.18" (no description) → **verwerfen** (mere reference).
+
+Rules:
+- When in doubt about standalone-ness → lean toward including. Duplicates are removed separately later; here only this counts: real block or junk.
+- Copy included entries VERBATIM ("Title — Kurzbeschreibung"), do not rephrase.{final}
+
+Write ONLY the JSON file to: {out_path}
+
+Format (no other text in the file; `rename` may be empty):
+{{"keep": ["Title — Kurzbeschreibung"], "rename": {{"alter Title": "sprechender Name"}}, "rest": []}}

templates/Prompt/Blocks-Paar-Filter.md

@@ -0,0 +1,20 @@
+Two research passes have noted blocks for the topic "{topic}". For EACH pair, decide whether A and B denote the SAME block (the same concept, just worded differently) → **ja**, or whether they are TWO DIFFERENT blocks → **nein**.
+
+PAIRS:
+{pairs}
+
+Rules:
+- **Watch the CORE ENTITY first** (the problem/object in question): Clique, Vertex Cover, Independent Set, Dominating Set, Set Cover, FVS, Knapsack … If the entities are DIFFERENT → **nein**, no matter how identical the phrasing.
+- Identical phrasing is deceptive. These pairs are **nein** (different entity despite nearly identical wording):
+  - "Lower Bound **Clique** bzgl. Knoten" ↔ "Lower Bound **Vertex Cover** bzgl. Knoten"
+  - "Lower Bound Clique bzgl. **Knoten**" ↔ "Lower Bound Clique bzgl. **Kanten**"
+  - "Verifizierer für **FVS**" ↔ "Verifizierer für **Knapsack**"
+  - "**Cliquenproblem**" ↔ "**Vertex-Cover-Problem**"
+- **ja** only on genuine semantic equivalence: same solution to the same problem, the same entity, just different wording/naming (e.g. "SET COVER" ↔ "Mengenüberdeckungsproblem", "Cliquenproblem" ↔ "k-CLIQUE", "List Scheduling" ↔ "LPT-Algorithmus").
+- **nein** also for different aspects of the same problem: "Set Cover (Problem)" ↔ "Set Cover ETH-Schranke"; a problem ↔ its reduction to another; a problem ↔ its verifier.
+- When in doubt **nein** — better two separate blocks than wrongly merging two concepts.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (each pair number from the list with "ja" or "nein"; no other text in the file):
+{{"pairs": {{"1": "ja", "2": "nein"}}}}

templates/Prompt/Blocks-Research-Mapping.md

@@ -0,0 +1,16 @@
+{n} research agents have independently determined the blocks of the topic "{topic}". Exactly identical titles have already been merged; the number in parentheses says how many research passes name the block. Consolidate the list.
+
+{entries}
+
+Rules:
+- Recognize the SAME concepts under different titles and merge them into one block. The mention counts of the merged entries add up (each research pass counts a concept only once).
+- A block solves EXACTLY ONE PROBLEM. Entries that are variants of the same solution are combined into ONE block (right: one block `<input>` for all types, one block "Modalverben" for all modal verbs; wrong: one entry per input type or per verb, but also collective entries that mix several problems).
+- A block is ATOMIC: exactly one idea, complete in itself. Test: you can remove nothing without making it incomplete — and nothing is missing to understand it.
+- CONSOLIDATE the granularity: a block is a LEARNING UNIT, not a dictionary entry. If the research passes deliver dozens of micro-entries of the same kind (one CSS property, one verb, one gesture per entry), group them by problem (right: "Flexbox-Ausrichtung" instead of six entries for justify-content, align-items, …). More than ~150 blocks is almost always a granularity problem — then check specifically for such series.
+- Then split into two lists: blocks that (after merging) are named by AT LEAST TWO research passes → `blocks`. Named only once or doubtful on the merits → `rest`. Discard only what is obviously fabricated.
+- Drop the sources. Title and short description (max. ~12 words) in GERMAN (code identifiers stay original). Every title must be UNIQUE.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (each entry a string "Title — Kurzbeschreibung"; no other text in the file):
+{{"blocks": ["Title — Kurzbeschreibung"], "rest": ["Title — Kurzbeschreibung"]}}

templates/Prompt/Blocks-Research.md

@@ -0,0 +1,25 @@
+Determine ALL blocks (concepts, techniques, rules, functions — the smallest learnable units) of the topic "{topic}" for a learning guide.
+
+{source}
+
+Rules:
+- A block solves EXACTLY ONE PROBLEM. Variants of the same solution belong in the one block, not as separate entries (right: `<p>` is one block, `<input>` with all types is one block, "Ich-Botschaften" is one block, "Present Perfect" with all signal words is one block; wrong: 21 entries for each input type or one entry per irregular verb, but also collective entries that mix several problems).
+- A block is ATOMIC: exactly one idea, complete in itself. Test: you can remove nothing without making it incomplete — and nothing is missing to understand it.
+- Granularity: a block is a LEARNING UNIT, not a dictionary entry. Families learned together (e.g. the font-* properties, the modal verbs) are ONE block.
+- Abstraction level (important): a block is self-contained — explainable WITHOUT presupposing ANOTHER block as its subject. These are problems, methods/algorithms, definitions, named theorems with their own statement. A detail that presupposes another concept belongs IN that concept's block (as a part), not as its own entry:
+  - A PROPERTY of a concept belongs to the concept: „Clique" is a block; „Clique ist NP-vollständig", „Clique ∈ NP", „Laufzeit von Clique" are parts of it — not their own entry.
+  - A PROOF/reduction component belongs to the theorem/reduction: „A-Komponente", „Dummy-Item", „αEnde", „Hilfsvariable" — not its own entry.
+  - Pure NOTATION/symbols belong to their definition: „|x|", „Σ∗" — not their own entry.
+  - A standalone REDUCTION between two problems, however, is its own block („3-SAT ≤ Clique").
+- NO categories, NO ranking, NO ordering by importance — only a flat, numbered list.
+- There is NO target count. Stop only when the research yields nothing new.
+- Invent nothing: include only blocks you have backed by research. Note the source per block (URL or file path). If there is no individual source, the collective source suffices (handbook chapter, textbook, overview page, directory).
+- Write title and description in GERMAN (technical terms/code identifiers stay original).
+- Description at most ~12 words.
+
+Write ONLY the Markdown file to: {blocks_path}
+
+Format: EXACTLY one line per block: `N. Title — Kurzbeschreibung — Source`
+The source (3rd segment) MUST be the exact file name or URL of the crawl page the block comes from — it drives the coverage check.
+{focus}
+{extra}

templates/Prompt/Blocks-Source-Link.md

@@ -0,0 +1 @@
+The source was crawled from a website and is stored as text files in the folder {project} (pages as .txt, PDFs as same-named .txt — ALWAYS read the .txt). Each page file begins with a `QUELLE:` line (the origin URL). Get an overview with Bash (ls/find) and read the files with the Read tool. GOAL: exam preparation. Capture the EXAM-RELEVANT blocks: definitions, core concepts, methods/algorithms, formulas, typical exercises. Only what is in the files — nothing invented, no external knowledge added.

templates/Prompt/Blocks-Source-Projekt.md

@@ -0,0 +1 @@
+The topic is the project under {project}. Get an overview with Bash (ls/find) and read the README, docs folder, and the relevant source code with the Read tool. PDFs are provided as same-named .txt files — ALWAYS read the .txt, never the PDF. GOAL: UNDERSTAND the project, not reimplement it. Capture the blocks that explain how it works: the features/functions, the architecture and components, the important flows (e.g. request→response, data flow), the central concepts and decisions. Not line-by-line code, but the scaffold for understanding. The blocks must reflect the real project, nothing invented.

templates/Prompt/Blocks-Source-Thema.md

@@ -0,0 +1 @@
+Research via web search and proceed systematically: work through the structure of the authoritative sources — for software/tools the official documentation (handbook chapters, feature overviews, release notes of the latest versions), for languages and conceptual topics textbooks, curricula, and standard works — and capture every block a learner may encounter — from fundamentals to special cases. Make sure version information or the technical state of the art is current.

templates/Prompt/Blocks-Source-Uni.md

@@ -0,0 +1 @@
+The learning material is in the folder {project} (e.g. lecture slides, scripts, problem sheets; PDFs are provided as same-named .txt files — ALWAYS read the .txt, never the PDF). Get an overview with Bash (ls/find) and read the files with the Read tool. GOAL: exam preparation. Capture the EXAM-RELEVANT blocks: definitions, core concepts, methods/algorithms, formulas and theorems, typical exercise and question types. The blocks must reflect the actual material — only what appears in it, nothing invented, no external textbook knowledge added.

templates/Prompt/Blocks-Supplement.md

@@ -0,0 +1,21 @@
+Check the block inventory for the topic "{topic}" for completeness against the subject area.
+
+The inventory comes from a project/script — there may be blocks that technically belong to the topic but aren't covered there. Find exactly those gaps.
+
+EXISTING BLOCKS:
+{blocks}
+
+Rules:
+- Research the subject area (textbooks, standard references) and add ONLY blocks that canonically belong and are missing from the inventory.
+- A block solves EXACTLY ONE PROBLEM and is ATOMIC — same standards as the inventory.
+- NO variants, rephrasings, or deep-dives of existing blocks — only genuine gaps.
+- Invent nothing: only blocks you have backed by research.
+- Title and description in GERMAN (technical terms stay original), description at most ~12 words.
+- If there are no gaps, return an empty list — that is a valid result.
+
+Write ONLY the JSON file to: {out_path}
+
+Format:
+{{"blocks": [{{"title": "…", "description": "…"}}]}}
+No gaps: {{"blocks": []}}
+{extra}

templates/Prompt/Chat.md

@@ -1,19 +1,19 @@
-Du bist ein hilfreicher Tutor zum Lern-Guide "{topic}" (Format: {format_name}). Ein Leser stellt dir Fragen, während er den Guide liest.
+You are a helpful tutor for the learning guide "{topic}" (format: {format_name}). A reader is asking you questions while reading the guide.
 
-GLIEDERUNG DES GUIDES:
+GUIDE OUTLINE:
 {outline_block}
 
-AKTUELLER ABSCHNITT, DEN DER LESER GERADE LIEST:
+CURRENT SECTION THE READER IS READING:
 {section_block}
 
-BISHERIGER CHAT-VERLAUF:
+CHAT TRANSCRIPT SO FAR:
 {transcript}
 
-Antworte als Assistent auf die letzte Nutzer-Nachricht.
+Reply as the assistant to the latest user message.
 
-WICHTIG – Antwortstil:
-- KURZ und EINFACH: 1–3 Sätze, klare Sprache.
-- Keine Einleitung, keine Wiederholung der Frage, kein Markdown-Drumherum.
-- Beantworte nur die Frage; nutze den Abschnitt und die Gliederung als Kontext.
+IMPORTANT – answer style:
+- SHORT and SIMPLE: 1–3 sentences, plain language.
+- No preamble, no restating the question, no Markdown wrapper.
+- Answer only the question; use the section and the outline as context.
 
-Gib NUR die Antwort aus, kein Präfix wie "Assistent:".
+Write your answer in GERMAN. Output ONLY the answer, with no prefix like "Assistent:".

templates/Prompt/Element-Chat.md

@@ -1,29 +1,29 @@
-Du hilfst, ein Lern-Element einer persönlichen Zusammenfassung zum Thema "{topic}" anzupassen. Du änderst NICHTS direkt — du schlägst Änderungen vor, der Nutzer bestätigt jede einzeln.
+You help adapt a learning element of a personal summary on the topic "{topic}". You change NOTHING directly — you propose changes, and the user confirms each one individually.
 
-AKTUELLES ELEMENT (JSON):
+CURRENT ELEMENT (JSON):
 {element_json}
 
-BISHERIGER CHAT-VERLAUF:
+CHAT TRANSCRIPT SO FAR:
 {transcript}
 
-Setze die letzte Nutzer-Anweisung in Änderungs-Vorschläge um. Halte die Element-Regeln ein:
-1. title — prägnanter Titel (max. 8 Wörter, reiner Text ohne Markdown/Backticks)
-2. description — was es ist und wozu: MAXIMAL 1–2 Sätze
-3. examples — KURZ und SIMPEL: das Minimalbeispiel im themengerechten Format (Codeblock mit Sprachangabe bei Code-Themen, sonst Beispielsätze/Mini-Dialog/Mini-Szenario als normaler Text). Jedes mit Varianten-Label: Code-Kommentar (z. B. `<!-- Einzelner Absatz -->`) bzw. **fettes** Label (z. B. **Höfliche Bitte:**).
-4. hints — jeder Hinweis muss WICHTIG oder NÜTZLICH sein. Telegrammstil: nur die Kernaussage. Beispiel: "Keine Blockelemente in `<p>`."
+Turn the latest user instruction into change proposals. Keep the element rules:
+1. title — a concise title (max. 8 words, plain text, no Markdown/backticks)
+2. description — what it is and what for: AT MOST 1–2 sentences
+3. examples — SHORT and SIMPLE: the minimal example in a topic-appropriate format (a code block with language tag for code topics, otherwise example sentences/mini-dialogue/mini-scenario as plain text). Each with a variant label: a code comment (e.g. `<!-- Einzelner Absatz -->`) or a **bold** label (e.g. **Höfliche Bitte:**).
+4. hints — every hint must be IMPORTANT or USEFUL. Telegraphic style: just the core statement. Example: "Keine Blockelemente in `<p>`."
 
-Umfang: SO LANG WIE NÖTIG und SO KURZ WIE MÖGLICH. Markdown: `inline-code` für Bezeichner, Tags und Befehle — IMMER in Backticks. Tonalität: klares Deutsch, direkt, keine Füllsätze.
+Length: AS LONG AS NEEDED and AS SHORT AS POSSIBLE. Markdown: `inline-code` for identifiers, tags and commands — ALWAYS in backticks. Tone: clear German, direct, no filler sentences.
 
-Jeder Vorschlag:
-- text: kurz, was geändert wird (max. 12 Wörter, reiner Text)
-- action: "entfernen" | "anpassen" | "hinzufuegen"
+Each proposal:
+- text: short, what is changed (max. 12 words, plain text)
+- action: "remove" | "adjust" | "add"
 - target: "title" | "description" | "examples" | "hints"
-- index: 0-basierte Position im AKTUELLEN examples- bzw. hints-Array (bei title/description und hinzufuegen: null)
-- content: der neue vollständige Inhalt (bei entfernen: leer)
+- index: 0-based position in the CURRENT examples or hints array (null for title/description and for "add")
+- content: the new complete content (empty for "remove")
 
-"entfernen" nur für examples/hints. Nur Vorschläge machen, die die Nutzer-Anweisung verlangt.
+"remove" only for examples/hints. Only make proposals that the user instruction calls for.
 
-Gib NUR gültiges JSON aus, ohne Code-Fence, ohne weiteren Text:
-{{"reply": "kurze Antwort an den Nutzer (1–2 Sätze)", "changes": [{{"text": "...", "action": "anpassen", "target": "hints", "index": 0, "content": "..."}}]}}
+Write the user-facing fields (`reply`, `text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
+{{"reply": "short reply to the user (1–2 sentences)", "changes": [{{"text": "...", "action": "adjust", "target": "hints", "index": 0, "content": "..."}}]}}
 
-Reine Frage ohne Änderungswunsch → beantworte sie in reply, "changes": []
+A pure question with no change request → answer it in reply, "changes": []

templates/Prompt/Element-Check.md

@@ -1,19 +1,19 @@
-Du recherchierst, welche Informationen in einem Lern-Element einer persönlichen Zusammenfassung zum Thema "{topic}" noch fehlen könnten.
+You research what information might still be missing from a learning element of a personal summary on the topic "{topic}".
 
-AKTUELLES ELEMENT (JSON):
+CURRENT ELEMENT (JSON):
 {element_json}
 
-KONTEXT (Auszüge aus dem Themen-Material):
+CONTEXT (excerpts from the topic material):
 {context}
 
-RECHERCHE — sammle breit alle Kandidaten: fehlende Kernaussagen, wichtige Varianten, typische Stolperfallen, Best Practices. Lieber einen Kandidaten zu viel als einen zu wenig — die Bewertung passiert in einem zweiten Schritt. Nichts vorschlagen, was das Element schon enthält.
+RESEARCH — gather candidates broadly: missing key points, important variants, common pitfalls, best practices. Better one candidate too many than one too few — the evaluation happens in a second step. Propose nothing the element already contains.
 
-Jeder Kandidat:
-- text: kurze Beschreibung der Lücke (max. 12 Wörter, reiner Text)
+Each candidate:
+- text: a short description of the gap (max. 12 words, plain text)
 - target: "description" | "examples" | "hints"
-- content: fertiger Inhalt zum Einfügen. SO KURZ WIE MÖGLICH, so lang wie nötig. Markdown: `inline-code` für Bezeichner, examples im themengerechten Format (Codeblock mit Sprachangabe bei Code, sonst Beispielsätze/Mini-Szenario als normaler Text), jeweils mit Varianten-Label (Code-Kommentar bzw. **fettes** Label), hints nur wenn WICHTIG oder NÜTZLICH, im Telegrammstil (nur Kernaussage, z. B. "Keine Blockelemente in `<p>`."). Tags/Bezeichner im Fließtext IMMER in Backticks.
+- content: ready-to-insert content. AS SHORT AS POSSIBLE, as long as needed. Markdown: `inline-code` for identifiers; examples in a topic-appropriate format (a code block with language tag for code, otherwise example sentences/mini-scenario as plain text), each with a variant label (a code comment or a **bold** label); hints only if IMPORTANT or USEFUL, in telegraphic style (just the core statement, e.g. "Keine Blockelemente in `<p>`."). Tags/identifiers in running text ALWAYS in backticks.
 
-Gib NUR gültiges JSON aus, ohne Code-Fence, ohne weiteren Text:
+Write the candidate fields (`text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
 {{"suggestions": [{{"text": "...", "target": "hints", "content": "..."}}]}}
 
-Keine Kandidaten → {{"suggestions": []}}
+No candidates → {{"suggestions": []}}

templates/Prompt/Element-Create.md

@@ -1,32 +1,32 @@
-Du erstellst ein kurzes Lern-Element für eine persönliche Zusammenfassung zum Thema "{topic}".
+You create a short learning element for a personal summary on the topic "{topic}".
 
-STICHWORT VOM NUTZER:
+KEYWORD FROM THE USER:
 {hint}
 
-KONTEXT (Auszüge aus dem Themen-Material):
+CONTEXT (excerpts from the topic material):
 {context}
 
-Erstelle GENAU EIN Element zum Stichwort:
-1. title — prägnanter Titel (max. 8 Wörter, reiner Text ohne Markdown/Backticks)
-2. description — was es ist und wozu: MAXIMAL 1–2 Sätze
-3. examples — GENAU EIN Beispiel: KURZ und SIMPEL, das Minimalbeispiel im themengerechten Format (siehe BEISPIELFORMAT), keine Realwelt-Komplexität.
-4. hints — IMMER leere Liste. Hinweise ergänzt der Nutzer später selbst. (Falls je gefordert: TELEGRAMMSTIL, max. 10 Wörter.)
+Create EXACTLY ONE element for the keyword:
+1. title — a concise title (max. 8 words, plain text, no Markdown/backticks)
+2. description — what it is and what for: AT MOST 1–2 sentences
+3. examples — EXACTLY ONE example: SHORT and SIMPLE, the minimal example in a topic-appropriate format (see EXAMPLE FORMAT), no real-world complexity.
+4. hints — ALWAYS an empty list. The user adds hints later. (If ever required: TELEGRAPHIC style, max. 10 words.)
 
-BEISPIELFORMAT — am Thema ausrichten, nicht pauschal an Code:
-- Code-/Tool-Thema (Sprache, Framework, CLI, Konfiguration): Codeblock mit Sprachangabe, wenige Zeilen, Minimalbeispiel.
-- Sprach-Thema (Vokabeln, Grammatik, Formulierungen): 1–3 Beispielsätze oder ein Mini-Dialog, fremdsprachiger Teil *kursiv*, deutsche Übersetzung in Klammern wo nötig.
-- Konzept-Thema (Psychologie, Kommunikation, Methoden, Theorie): ein Mini-Szenario in 2–4 Sätzen (Situation → Anwendung → Wirkung), ein Schema oder eine Formel.
-Mischthemen: pro Beispiel das Format wählen, das den Punkt am direktesten zeigt.
-Ein Beispiel ist immer KONKRET (echter Code, echte Sätze, echte Situation) — nie die Beschreibung, was ein Beispiel zeigen würde.
-Jedes Beispiel benennt seine Variante: in Code als Kommentar in der Code-Syntax (z. B. `<!-- Einzelner Absatz -->`, `// Mit Default-Wert`), in Prosa als vorangestelltes fettes Label (z. B. **Höfliche Bitte:**).
+EXAMPLE FORMAT — align to the topic, not blanket to code:
+- Code/tool topic (language, framework, CLI, configuration): a code block with language tag, a few lines, minimal example.
+- Language topic (vocabulary, grammar, phrasing): 1–3 example sentences or a mini-dialogue, the foreign-language part in *italics*, German translation in parentheses where needed.
+- Concept topic (psychology, communication, methods, theory): a mini-scenario in 2–4 sentences (situation → application → effect), a schema or a formula.
+Mixed topics: per example, choose the format that shows the point most directly.
+An example is always CONCRETE (real code, real sentences, a real situation) — never a description of what an example would show.
+Each example names its variant: in code as a comment in the code syntax (e.g. `<!-- Einzelner Absatz -->`, `// Mit Default-Wert`), in prose as a leading **bold** label (e.g. **Höfliche Bitte:**).
 
-Das Element ist ATOMAR: allein verständlich, ohne dass der Leser etwas anderes gelesen hat. Benutzte Begriffe in einem Halbsatz auflösen.
+The element is ATOMIC: understandable on its own, without the reader having read anything else. Resolve any terms used in a half-sentence.
 
-Umfang: SO KURZ WIE MÖGLICH, so lang wie nötig — gilt für description, examples und hints. Jedes Wort muss seinen Platz verdienen: Füllwörter, Nebensätze ohne Informationswert und Selbstverständliches streichen. Die Länge kommt aus der ZAHL der Beispiele (Varianten), nie aus langen Texten.
+Length: AS SHORT AS POSSIBLE, as long as needed — applies to description, examples and hints. Every word must earn its place: cut filler words, subclauses without informational value, and the self-evident. The length comes from the NUMBER of examples (variants), never from long texts.
 
-Tonalität: klares Deutsch, direkt, praxisorientiert. Fachbegriffe beim ersten Auftreten kurz erklären. Keine Füllsätze, keine Einleitungsfloskeln.
+Tone: clear German, direct, practical. Explain technical terms briefly on first use. No filler sentences, no introductory clichés.
 
-Markdown in description und examples: normale Absätze, `inline-code` für Bezeichner, **fett** sparsam für Kernaussagen. Keine Überschriften. Code-Beispiele IMMER als Codeblock mit Sprachangabe (```sprache), nie als Inline-Code; Prosa-Beispiele (Sätze, Dialoge, Szenarien) als normaler Text, NIE in einen Codeblock zwingen. Bezeichner, Tags und Befehle (z. B. `<p>`, `git add`) im Fließtext IMMER in Backticks — nie nackt.
+Markdown in description and examples: normal paragraphs, `inline-code` for identifiers, **bold** sparingly for key points. No headings. Code examples ALWAYS as a code block with language tag (```sprache), never as inline code; prose examples (sentences, dialogues, scenarios) as plain text, NEVER forced into a code block. Identifiers, tags and commands (e.g. `<p>`, `git add`) in running text ALWAYS in backticks — never bare.
 
-Gib NUR gültiges JSON aus, ohne Code-Fence, ohne weiteren Text:
-{{"title": "...", "description": "...", "examples": ["```sprache\n...\n``` ODER **Variante:** Prosa-Beispiel"], "hints": []}}
+Write the element (title, description, examples) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
+{{"title": "...", "description": "...", "examples": ["```sprache\n...\n``` OR **Variante:** prose example"], "hints": []}}

templates/Prompt/Element-Refine.md

@@ -1,24 +1,24 @@
-Du überarbeitest GENAU EINEN Änderungs-Vorschlag für ein Lern-Element zum Thema "{topic}" nach einer Nutzer-Anweisung.
+You revise EXACTLY ONE change proposal for a learning element on the topic "{topic}", following a user instruction.
 
-AKTUELLES ELEMENT (JSON):
+CURRENT ELEMENT (JSON):
 {element_json}
 
-AKTUELLER VORSCHLAG (JSON):
+CURRENT PROPOSAL (JSON):
 {suggestion_json}
 
-ANWEISUNG DES NUTZERS:
+USER INSTRUCTION:
 {instruction}
 
-Passe den Vorschlag gemäß der Anweisung an. Behalte action/target/index bei, außer die Anweisung verlangt anderes.
+Adjust the proposal per the instruction. Keep action/target/index, unless the instruction requires otherwise.
 
-Stil-Regeln für content: SO LANG WIE NÖTIG und SO KURZ WIE MÖGLICH. `inline-code` für Bezeichner, Tags und Befehle — IMMER in Backticks. examples im themengerechten Format (Codeblock mit Sprachangabe NUR bei Code, sonst Beispielsätze/Mini-Szenario) mit Varianten-Label (Code-Kommentar bzw. **fettes** Label). hints im Telegrammstil: nur die Kernaussage.
+Style rules for content: AS LONG AS NEEDED and AS SHORT AS POSSIBLE. `inline-code` for identifiers, tags and commands — ALWAYS in backticks. examples in a topic-appropriate format (a code block with language tag ONLY for code, otherwise example sentences/mini-scenario) with a variant label (a code comment or a **bold** label). hints in telegraphic style: just the core statement.
 
-Felder:
-- text: kurz, was geändert wird (max. 12 Wörter, reiner Text)
-- action: "entfernen" | "anpassen" | "hinzufuegen"
+Fields:
+- text: short, what is changed (max. 12 words, plain text)
+- action: "remove" | "adjust" | "add"
 - target: "title" | "description" | "examples" | "hints"
-- index: 0-basierte Position im examples-/hints-Array (sonst null)
-- content: der neue vollständige Inhalt (bei entfernen: leer)
+- index: 0-based position in the examples/hints array (otherwise null)
+- content: the new complete content (empty for "remove")
 
-Gib NUR gültiges JSON aus, ohne Code-Fence, ohne weiteren Text:
-{{"change": {{"text": "...", "action": "anpassen", "target": "hints", "index": 0, "content": "..."}}}}
+Write the user-facing fields (`text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
+{{"change": {{"text": "...", "action": "adjust", "target": "hints", "index": 0, "content": "..."}}}}

templates/Prompt/Element-Stil.md

@@ -1,37 +0,0 @@
-Du prüfst ein Lern-Element einer persönlichen Zusammenfassung zum Thema "{topic}" auf Stil-Regeln und schlägst Änderungen vor. Das Element wird NICHT direkt geändert — der Nutzer bestätigt jede Änderung einzeln.
-
-AKTUELLES ELEMENT (JSON):
-{element_json}
-
-STIL-REGELN:
-1. title — prägnant, max. 8 Wörter, reiner Text ohne Markdown/Backticks
-2. description — was es ist und wozu: MAXIMAL 1–2 Sätze
-3. examples — KURZ und SIMPEL: das Minimalbeispiel im themengerechten Format (siehe BEISPIELFORMAT), keine Realwelt-Komplexität. Ein Beispiel pro relevanter Variante, geordnet vom Üblichen zum Speziellen. Ein Codeblock um ein Prosa-Beispiel ist ein Stil-Verstoß — ebenso ein Code-Beispiel ohne Codeblock.
-
-   BEISPIELFORMAT — am Thema ausrichten, nicht pauschal an Code:
-   - Code-/Tool-Thema (Sprache, Framework, CLI, Konfiguration): Codeblock mit Sprachangabe, wenige Zeilen, Minimalbeispiel.
-   - Sprach-Thema (Vokabeln, Grammatik, Formulierungen): 1–3 Beispielsätze oder ein Mini-Dialog, fremdsprachiger Teil *kursiv*, deutsche Übersetzung in Klammern wo nötig.
-   - Konzept-Thema (Psychologie, Kommunikation, Methoden, Theorie): ein Mini-Szenario in 2–4 Sätzen (Situation → Anwendung → Wirkung), ein Schema oder eine Formel.
-   Mischthemen: pro Beispiel das Format wählen, das den Punkt am direktesten zeigt.
-   Ein Beispiel ist immer KONKRET (echter Code, echte Sätze, echte Situation) — nie die Beschreibung, was ein Beispiel zeigen würde.
-   Jedes Beispiel benennt seine Variante: in Code als Kommentar in der Code-Syntax (z. B. `<!-- Einzelner Absatz -->`, `// Mit Default-Wert`), in Prosa als vorangestelltes fettes Label (z. B. **Höfliche Bitte:**).
-4. hints — jeder Hinweis muss WICHTIG oder NÜTZLICH sein: Stolperfalle, Merksatz oder Best Practice mit echtem Praxiswert. Selbstverständliches, Nischenwissen und Redundantes zum Element entfernen. Telegrammstil: nur die Kernaussage, Füllverben und Herleitungen streichen.
-   Vorher: "Browser fügen standardmäßig vertikalen Abstand vor und nach `<p>` ein — anpassbar mit `margin`."
-   Nachher: "Browser-Abstand um `<p>` per `margin` anpassbar."
-5. Umfang: SO LANG WIE NÖTIG und SO KURZ WIE MÖGLICH. Jedes Wort muss seinen Platz verdienen — Füllwörter, Nebensätze ohne Informationswert und Selbstverständliches streichen. Aber: Kürze nie auf Kosten der Verständlichkeit oder Korrektheit.
-6. Markdown: `inline-code` für Bezeichner, Tags und Befehle im Fließtext (z. B. `<p>`, `git add`) — IMMER in Backticks, nie nackt. Fremdsprachige Beispielsätze *kursiv*. **fett** sparsam. Keine Überschriften.
-7. Tonalität: klares Deutsch, direkt, praxisorientiert. Keine Füllsätze.
-
-Schlage für jeden Stil-Verstoß GENAU EINE Änderung vor:
-- text: kurz, was und warum (max. 12 Wörter, reiner Text)
-- action: "entfernen" | "anpassen" | "hinzufuegen"
-- target: "title" | "description" | "examples" | "hints"
-- index: 0-basierte Position im AKTUELLEN examples- bzw. hints-Array (bei title/description: null; bei hinzufuegen: null)
-- content: der neue/vollständige Inhalt (bei entfernen: leer)
-
-"entfernen" nur für examples/hints. "hinzufuegen" sparsam — nur wenn eine Stil-Regel es verlangt (z. B. fehlender Varianten-Kommentar gehört zu "anpassen", nicht "hinzufuegen"). Erfüllt etwas die Regeln schon: NICHT anfassen.
-
-Gib NUR gültiges JSON aus, ohne Code-Fence, ohne weiteren Text:
-{{"changes": [{{"text": "...", "action": "anpassen", "target": "hints", "index": 0, "content": "..."}}]}}
-
-Kein Stil-Verstoß → {{"changes": []}}

templates/Prompt/Element-Style.md

@@ -0,0 +1,37 @@
+You check a learning element of a personal summary on the topic "{topic}" against the style rules and propose changes. The element is NOT changed directly — the user confirms each change individually.
+
+CURRENT ELEMENT (JSON):
+{element_json}
+
+STYLE RULES:
+1. title — concise, max. 8 words, plain text, no Markdown/backticks
+2. description — what it is and what for: AT MOST 1–2 sentences
+3. examples — SHORT and SIMPLE: the minimal example in a topic-appropriate format (see EXAMPLE FORMAT), no real-world complexity. One example per relevant variant, ordered from the usual to the special. A code block around a prose example is a style violation — as is a code example without a code block.
+
+   EXAMPLE FORMAT — align to the topic, not blanket to code:
+   - Code/tool topic (language, framework, CLI, configuration): a code block with language tag, a few lines, minimal example.
+   - Language topic (vocabulary, grammar, phrasing): 1–3 example sentences or a mini-dialogue, the foreign-language part in *italics*, German translation in parentheses where needed.
+   - Concept topic (psychology, communication, methods, theory): a mini-scenario in 2–4 sentences (situation → application → effect), a schema or a formula.
+   Mixed topics: per example, choose the format that shows the point most directly.
+   An example is always CONCRETE (real code, real sentences, a real situation) — never a description of what an example would show.
+   Each example names its variant: in code as a comment in the code syntax (e.g. `<!-- Einzelner Absatz -->`, `// Mit Default-Wert`), in prose as a leading **bold** label (e.g. **Höfliche Bitte:**).
+4. hints — every hint must be IMPORTANT or USEFUL: a pitfall, a mnemonic or a best practice with real practical value. Remove the self-evident, niche knowledge and anything redundant with the element. Telegraphic style: just the core statement, cut filler verbs and derivations.
+   Before: "Browser fügen standardmäßig vertikalen Abstand vor und nach `<p>` ein — anpassbar mit `margin`."
+   After: "Browser-Abstand um `<p>` per `margin` anpassbar."
+5. Length: AS LONG AS NEEDED and AS SHORT AS POSSIBLE. Every word must earn its place — cut filler words, subclauses without informational value, and the self-evident. But: never shorten at the cost of comprehensibility or correctness.
+6. Markdown: `inline-code` for identifiers, tags and commands in running text (e.g. `<p>`, `git add`) — ALWAYS in backticks, never bare. Foreign-language example sentences in *italics*. **bold** sparingly. No headings.
+7. Tone: clear German, direct, practical. No filler sentences.
+
+For each style violation propose EXACTLY ONE change:
+- text: short, what and why (max. 12 words, plain text)
+- action: "remove" | "adjust" | "add"
+- target: "title" | "description" | "examples" | "hints"
+- index: 0-based position in the CURRENT examples or hints array (null for title/description; null for "add")
+- content: the new/complete content (empty for "remove")
+
+"remove" only for examples/hints. "add" sparingly — only when a style rule requires it (e.g. a missing variant comment belongs to "adjust", not "add"). If something already meets the rules: do NOT touch it.
+
+Write the user-facing fields (`text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
+{{"changes": [{{"text": "...", "action": "adjust", "target": "hints", "index": 0, "content": "..."}}]}}
+
+No style violation → {{"changes": []}}

templates/Prompt/Element-Verify.md

@@ -1,23 +1,23 @@
-Du verifizierst Ergänzungs-Kandidaten für ein Lern-Element einer persönlichen Zusammenfassung zum Thema "{topic}". Das Element soll KURZ bleiben — nur wirklich Wichtiges kommt durch.
+You verify candidate additions to a learning element of a personal summary on the topic "{topic}". The element should stay SHORT — only what is truly important gets through.
 
-AKTUELLES ELEMENT (JSON):
+CURRENT ELEMENT (JSON):
 {element_json}
 
-KANDIDATEN (JSON):
+CANDIDATES (JSON):
 {candidates_json}
 
-KONTEXT (Auszüge aus dem Themen-Material):
+CONTEXT (excerpts from the topic material):
 {context}
 
-Prüfe JEDEN Kandidaten kritisch:
-1. WICHTIG? Muss ein Lerner das wissen? Nice-to-haves und Nischenwissen ablehnen.
-2. REDUNDANT? Steckt die Info schon im Element oder in einem anderen Kandidaten? Ablehnen bzw. Duplikate zusammenführen.
-3. KORREKT? Fachlich falsch oder irreführend → ablehnen.
-4. PASST das target ("description" | "examples" | "hints")? Sonst korrigieren.
+Check EACH candidate critically:
+1. IMPORTANT? Does a learner need to know this? Reject nice-to-haves and niche knowledge.
+2. REDUNDANT? Is the info already in the element or in another candidate? Reject, or merge duplicates.
+3. CORRECT? Factually wrong or misleading → reject.
+4. Does the target fit ("description" | "examples" | "hints")? Otherwise correct it.
 
-Behalte nur Kandidaten, die alle Prüfungen bestehen. Verbessere dabei content auf die Stil-Regeln: SO LANG WIE NÖTIG und SO KURZ WIE MÖGLICH; `inline-code` für Bezeichner; examples im themengerechten Format (Codeblock mit Sprachangabe bei Code, sonst Beispielsätze/Mini-Szenario) mit Varianten-Label; hints im Telegrammstil (nur Kernaussage, Kürze nie auf Kosten der Verständlichkeit).
+Keep only candidates that pass all checks. While doing so, improve content toward the style rules: AS LONG AS NEEDED and AS SHORT AS POSSIBLE; `inline-code` for identifiers; examples in a topic-appropriate format (a code block with language tag for code, otherwise example sentences/mini-scenario) with a variant label; hints in telegraphic style (just the core statement, never shorten at the cost of comprehensibility).
 
-Gib NUR gültiges JSON aus, ohne Code-Fence, ohne weiteren Text:
+Write the candidate fields (`text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
 {{"suggestions": [{{"text": "...", "target": "hints", "content": "..."}}]}}
 
-Kein Kandidat besteht → {{"suggestions": []}}
+No candidate passes → {{"suggestions": []}}

templates/Prompt/Facts-Check.md

@@ -0,0 +1,26 @@
+You are the fact-checker for the learning facts of the topic "{topic}". Another agent has extracted facts per subblock. Check ONLY the **backed facts** for truth — not the examples.
+
+{source}
+
+FACTS TO CHECK (per subblock):
+{facts}
+
+Check per subblock:
+1. **Evidence fidelity**: Does each `cited_facts` entry appear that way in the source (accurate in substance)? Is the source citation correct? With a source file: check against the file. Without a source: is it established standard knowledge?
+2. **Factual correctness**: Are formulas, values, definitions, signatures technically correct? A wrong formula/value is a defect.
+3. **Fact vs. example**: Is a self-computed/invented example wrongly declared as `cited_facts`? That is a defect — it belongs in `example_idea`.
+4. Do NOT check examples (`example_idea`) for source evidence — they are generative.
+
+Note only REAL defects (wrong fact, wrong source, example disguised as a fact). Not matters of taste.
+
+**Discard vs. correct** — decide per defect:
+- `verwerfen: true` — the subblock is substantively **not backable**: an invented claim, a bound/formula/assertion not findable in the material, or simply technically wrong. The subblock is then REMOVED. Be sure — when in doubt, `false`.
+- `verwerfen: false` — the core is right, only a fact/value/source is imprecise and correctable.
+
+Write ONLY the JSON file to: {out_path}
+
+Format — all in order:
+{{"ok": true}}
+Otherwise (subblock title EXACTLY as above):
+{{"problems": [{{"subblock": "<exakter Subblock-Title>", "problem": "…", "discard": true}}]}}
+{extra}

templates/Prompt/Facts-Research.md

@@ -0,0 +1,30 @@
+Extract the learning facts for each subblock of the topic "{topic}". These facts are the binding basis from which the guide text, the levels, and the exam questions are later created — they must be **correct**.
+
+{source}
+
+BLOCKS WITH SUBBLOCKS (process EVERY subblock):
+{blocks}
+
+Collect per subblock ONLY the essentials (superfluous material harms learning); write all field content in GERMAN (technical terms/code identifiers stay original):
+- **key_points**: 1–3 concise statements — what must one understand about this subblock?
+- **prerequisites**: what must one know beforehand (a half-sentence)? Empty if nothing.
+- **hurdles**: typical beginner misconception (a half-sentence). Empty if none.
+- **cited_facts**: hard facts (definitions, formulas, values, names, signatures) — **only what you can back up**. Each with a source:
+  - With a source file/script: cite **accurately in substance** and give the location (e.g. „Skript Def. 6.3, Z.66"). Invent no values, compute nothing yourself.
+  - Without a source (pure topic): only established standard knowledge; verify uncertain points via web search; source = „allgemein" or the URL.
+- **example_idea**: ONE example that carries understanding — freely phrased. **Here** is where self-formed sentences, mini-scenarios, worked examples belong. Empty if an example adds nothing.
+
+HARD SEPARATION — important:
+- `cited_facts` = only backable material from the source/established knowledge. **NEVER** output a self-computed or invented example as a backed fact.
+- A worked example, an invented sentence, a constructed case → belongs in `example_idea`, not in `cited_facts`.
+- When in doubt: better to leave out than to claim falsely.
+
+Write ALL subblocks as ONE JSON to the file {out_path} (use your write tool), EXACTLY in this format:
+{{"facts": [
+  {{"block": "<exakter Block-Title>", "subblock": "<exakter Subblock-Title>",
+    "key_points": ["…"], "prerequisites": "…", "hurdles": "…",
+    "cited_facts": [{{"text": "…", "source": "…"}}], "example_idea": "…"}}
+]}}
+
+Output no other text.
+{extra}

templates/Prompt/Facts-Supplement.md

@@ -0,0 +1,25 @@
+You are filling **gaps**. For each subblock of the topic "{topic}", the facts already captured are listed below. A first pass extracted them — and experience shows backable material slips through. Your task: add **only what is missing** from the source.
+
+{source}
+
+SUBBLOCKS WITH FACTS ALREADY CAPTURED:
+{blocks}
+
+Rules:
+- Output **only NEW** points per subblock that are backed by the source and still **missing** above.
+- **Repeat nothing** from what is already "captured" — not even rephrased. If it's already there → leave it out.
+- **Only backable material.** With a source file/script: cite accurately in substance + give the location. Invent no values, compute nothing yourself. Without a source file (pure topic): only established standard knowledge.
+- **HARD SEPARATION:** `cited_facts` = only backable material. A self-computed/invented example belongs in `example_idea`, NEVER in `cited_facts`.
+- Add `key_points` only if an **essential** aspect is missing — no duplications, no trivialities.
+- **If you find nothing new for a subblock → leave it out.** If you find nothing at all → empty list. Better nothing than fabrication.
+- Write all field content (key_points, prerequisites, hurdles, cited_facts text, example_idea) in GERMAN, matching the source material (technical terms/code identifiers stay original).
+
+Write ONLY the NEW facts as ONE JSON to the file {out_path}, EXACTLY in this format:
+{{"facts": [
+  {{"block": "<exakter Block-Title>", "subblock": "<exakter Subblock-Title>",
+    "key_points": ["…"], "prerequisites": "…", "hurdles": "…",
+    "cited_facts": [{{"text": "…", "source": "…"}}], "example_idea": "…"}}
+]}}
+
+Output no other text.
+{extra}

templates/Prompt/Fakten-Check.md

@@ -1,26 +0,0 @@
-Du bist Faktenprüfer für die Lern-Fakten des Themas "{topic}". Ein anderer Agent hat je Subbaustein Fakten extrahiert. Prüfe NUR die **belegten Fakten** auf Wahrheit — nicht die Beispiele.
-
-{source}
-
-ZU PRÜFENDE FAKTEN (je Subbaustein):
-{fakten}
-
-Prüfe je Subbaustein:
-1. **Beleg-Treue**: Steht jeder `belegte_fakten`-Eintrag so in der Quelle (sinngemäß-genau)? Stimmt die Quellenangabe? Mit Quelldatei: gegen die Datei prüfen. Ohne Quelle: ist es gesichertes Standardwissen?
-2. **Sachliche Korrektheit**: Sind Formeln, Werte, Definitionen, Signaturen fachlich richtig? Eine falsche Formel/ein falscher Wert ist ein Mangel.
-3. **Fakt vs. Beispiel**: Ist ein selbst gerechnetes/erfundenes Beispiel fälschlich als `belegte_fakten` deklariert? Das ist ein Mangel — es gehört in `beispiel_idee`.
-4. Beispiele (`beispiel_idee`) NICHT auf Quellen-Beleg prüfen — sie sind generativ.
-
-Notiere nur ECHTE Mängel (falscher Fakt, falsche Quelle, Beispiel als Fakt getarnt). Geschmacksfragen nicht.
-
-**Verwerfen vs. korrigieren** — entscheide je Mangel:
-- `verwerfen: true` — der Subbaustein ist inhaltlich **nicht belegbar**: eine erfundene Aussage, eine im Material nicht auffindbare Schranke/Formel/Behauptung, oder fachlich schlicht falsch. Der Subbaustein wird dann ENTFERNT. Sei sicher — im Zweifel `false`.
-- `verwerfen: false` — der Kern stimmt, nur ein Fakt/Wert/eine Quelle ist ungenau und korrigierbar.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format — alles in Ordnung:
-{{"ok": true}}
-Sonst (Subbaustein-Titel EXAKT wie oben):
-{{"probleme": [{{"subbaustein": "<exakter Subbaustein-Titel>", "problem": "…", "verwerfen": true}}]}}
-{extra}

templates/Prompt/Fakten-Ergaenzung.md

@@ -1,24 +0,0 @@
-Du füllst **Lücken**. Für jeden Subbaustein des Themas "{topic}" sind unten die bereits erfassten Fakten gelistet. Ein erster Durchlauf hat sie extrahiert — dabei fällt erfahrungsgemäß Belegbares durch. Deine Aufgabe: **nur das Fehlende** aus der Quelle nachtragen.
-
-{source}
-
-SUBBAUSTEINE MIT BEREITS ERFASSTEN FAKTEN:
-{bausteine}
-
-Regeln:
-- Gib pro Subbaustein **nur NEUE** Punkte aus, die in der Quelle belegt sind und oben **noch fehlen**.
-- **Wiederhole nichts** aus „Erfasst" — auch nicht umformuliert. Steht es schon da → weglassen.
-- **Nur Belegbares.** Mit Quelldatei/Skript: sinngemäß-genau zitieren + Stelle angeben. Erfinde keine Werte, rechne nichts selbst aus. Ohne Quelldatei (reines Thema): nur gesichertes Standardwissen.
-- **HARTE TRENNUNG:** `belegte_fakten` = nur Belegbares. Ein selbst gerechnetes/erdachtes Beispiel gehört in `beispiel_idee`, NIE in `belegte_fakten`.
-- `kernpunkte` nur ergänzen, wenn ein **wesentlicher** Aspekt fehlt — keine Dopplungen, keine Trivialitäten.
-- **Findest du für einen Subbaustein nichts Neues → lass ihn weg.** Findest du gar nichts → leere Liste. Lieber nichts als Erfundenes.
-
-Schreibe NUR die NEUEN Fakten als EIN JSON in die Datei {out_path}, GENAU in diesem Format:
-{{"fakten": [
-  {{"baustein": "<exakter Baustein-Titel>", "subbaustein": "<exakter Subbaustein-Titel>",
-    "kernpunkte": ["…"], "voraussetzungen": "…", "huerden": "…",
-    "belegte_fakten": [{{"text": "…", "quelle": "…"}}], "beispiel_idee": "…"}}
-]}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Fakten-Recherche.md

@@ -1,30 +0,0 @@
-Extrahiere die Lern-Fakten für jeden Subbaustein des Themas "{topic}". Diese Fakten sind die verbindliche Grundlage, aus der später der Guide-Text, die Stufen und die Prüfungsfragen entstehen — sie müssen **stimmen**.
-
-{source}
-
-BAUSTEINE MIT SUBBAUSTEINEN (bearbeite JEDEN Subbaustein):
-{bausteine}
-
-Sammle pro Subbaustein NUR das Wesentliche (überflüssiges Material schadet dem Lernen):
-- **kernpunkte**: 1–3 knappe Aussagen — was muss man an diesem Subbaustein verstehen?
-- **voraussetzungen**: was muss man vorher kennen (ein Halbsatz)? Leer, wenn nichts.
-- **huerden**: typischer Anfänger-Irrtum (ein Halbsatz). Leer, wenn keiner.
-- **belegte_fakten**: harte Fakten (Definitionen, Formeln, Werte, Namen, Signaturen) — **nur was du belegen kannst**. Jeder mit Quelle:
-  - Mit Quelldatei/Skript: zitiere **sinngemäß-genau** und gib die Stelle an (z. B. „Skript Def. 6.3, Z.66"). Erfinde keine Werte, rechne nichts selbst aus.
-  - Ohne Quelle (reines Thema): nur gesichertes Standardwissen; Unsicheres per Websuche prüfen; Quelle = „allgemein" oder die URL.
-- **beispiel_idee**: EIN Beispiel, das das Verständnis trägt — frei formuliert. **Hier** gehören selbst gebildete Sätze, Mini-Szenarien, durchgerechnete Beispiele hin. Leer, wenn ein Beispiel nichts beiträgt.
-
-HARTE TRENNUNG — wichtig:
-- `belegte_fakten` = nur Belegbares aus Quelle/gesichertem Wissen. **NIEMALS** ein selbst gerechnetes oder erfundenes Beispiel als belegten Fakt ausgeben.
-- Ein durchgerechnetes Beispiel, ein erdachter Satz, ein konstruierter Fall → gehört in `beispiel_idee`, nicht in `belegte_fakten`.
-- Im Zweifel: lieber weglassen als falsch behaupten.
-
-Schreibe ALLE Subbausteine als EIN JSON in die Datei {out_path} (nutze dein Schreib-Werkzeug), GENAU in diesem Format:
-{{"fakten": [
-  {{"baustein": "<exakter Baustein-Titel>", "subbaustein": "<exakter Subbaustein-Titel>",
-    "kernpunkte": ["…"], "voraussetzungen": "…", "huerden": "…",
-    "belegte_fakten": [{{"text": "…", "quelle": "…"}}], "beispiel_idee": "…"}}
-]}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Frage-Muster-Kritik.md

@@ -1,21 +0,0 @@
-Du bist Qualitäts-Prüfer für den Fragen-Vorrat einer Lern-Prüfung zum Thema "{topic}". Ein anderer Agent hat Frage-Muster für **mehrere Bausteine** erstellt — genau ein Muster je Subbaustein. Prüfe sie und gib eine **bereinigte** Endfassung zurück.
-
-ZU PRÜFENDE MUSTER (gruppiert je Baustein; Zeilen: (subbaustein) Frage):
-{tabelle}
-
-PRÜFE UND BEREINIGE GEGEN DIESE KRITERIEN (je Baustein getrennt):
-- **Stil:** jede Frage GENAU EINE Frage, ein Fragezeichen, eine Sache. Kein "und"/"sowie", keine Aufzählung. Maximal 1–2 Sätze. Verstöße → umformulieren.
-- **Eindeutig beantwortbar:** aus dem Baustein-Wissen klar beantwortbar, keine erfundenen Annahmen. Unbeantwortbares → korrigieren.
-- **Kern-Treffer:** die Frage trifft das Kernkonzept des Subbausteins, neutral formuliert (nicht extra leicht/schwer — die Schwierigkeit setzt später das Lerner-Niveau). Verfehlt sie den Kern → umformulieren.
-- **Genau eins je Subbaustein:** pro Subbaustein bleibt genau ein Muster. Doppelte → eines behalten.
-- `baustein` und `subbaustein` der Einträge unverändert übernehmen (nur `frage` darf sich ändern); nicht neu erfinden.
-
-Behalte gute Muster unverändert. Ändere nur, was wirklich gegen die Kriterien verstößt.
-
-Schreibe die bereinigte Endfassung ALLER Bausteine als EIN JSON in die Datei {out_path} (nutze dein Schreib-Werkzeug), GENAU in diesem Format:
-{{"muster": [
-  {{"baustein": "<exakter Baustein-Titel>", "subbaustein": "<exakter Titel>", "frage": "<eine konkrete Frage>"}}
-]}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Frage-Muster-Recherche.md

@@ -1,26 +0,0 @@
-Du baust den Fragen-Vorrat für eine Lern-Prüfung zum Thema "{topic}". Erzeuge **Frage-Muster** — **genau eine** konkrete Beispielfrage **pro Subbaustein**. Aus jedem Muster wird später bei der Prüfung eine leicht abgewandelte Frage formuliert — passend zum Niveau des Lerners (Anfänger bis Experte). Die Schwierigkeit steckt also NICHT im Muster, sondern kommt erst bei der Prüfung. Frag deshalb nach dem **Kernkonzept** des Subbausteins, neutral formuliert.
-
-Du bearbeitest **mehrere Bausteine**. Jeder Baustein hat seine eigenen Subbausteine — viele mit Kernpunkten, belegten Fakten und einem Beispiel:
-{bausteine}
-
-AUFGABE (für **jeden** der Bausteine oben):
-- Erzeuge für **jeden** seiner Subbausteine **genau ein** Muster — eine konkrete, knappe Frage zum Kernkonzept dieses Subbausteins.
-- Jedes Muster ist EINE konkrete Frage (1–2 Sätze, genau ein Fragezeichen, eine Sache) — kein Mehrteiler, keine Aufzählung.
-- Die Frage muss aus dem Baustein-Wissen beantwortbar sein. Erfinde keine Zusatzannahmen.
-- Stütze die Frage auf die gelieferten **Kernpunkte und belegten Fakten** (die verlässliche Grundlage). Triff das KERNKONZEPT des Subbausteins, nicht ein auswendig zu lernendes Detail. Setze NICHTS voraus, was nicht in den Fakten steht: keine „gezeigten" Code-Ausschnitte/Diagramme, keine konkreten Werte/Listen/Zahlen aus einem späteren Guide-Text.
-- Die Frage trifft den **Kern** des Subbausteins — den zentralen Punkt, den man verstanden haben muss. Nicht zu eng auf ein Detail, nicht zu breit über den ganzen Baustein.
-- `baustein` ist exakt einer der Baustein-Titel oben. `subbaustein` ist exakt einer der Subbaustein-Titel des jeweiligen Bausteins.
-
-HARTE STIL-REGELN JE FRAGE:
-- Genau EINE Frage, ein Fragezeichen, eine Sache. Kein "und"/"sowie", kein "nenne drei …".
-- Maximal 1–2 Sätze, keine Vorrede, kein Szenario-Aufbau.
-- Neutral formuliert — nicht extra leicht, nicht extra schwer. Die Schwierigkeit setzt die Prüfung über das Lerner-Niveau.
-- Direkte Ansprache, klares Deutsch.
-{extra}
-
-Schreibe ALLE Muster aller Bausteine als EIN JSON in die Datei {out_path} (nutze dein Schreib-Werkzeug), GENAU in diesem Format:
-{{"muster": [
-  {{"baustein": "<exakter Baustein-Titel>", "subbaustein": "<exakter Subbaustein-Titel>", "frage": "<eine konkrete Frage>"}}
-]}}
-
-Gib sonst keinen Text aus.

templates/Prompt/Gliederung-Voraussetzungen.md

@@ -1,17 +0,0 @@
-Ermittle die **Lern-Voraussetzungen** zwischen den Bausteinen des Themas "{topic}". Daraus wird die Reihenfolge des Guides berechnet.
-
-BAUSTEINE (Nummer, Titel; manche nennen unter „braucht vorher" die Voraussetzungen ihrer Inhalte):
-{bausteine}
-
-AUFGABE:
-- Für **jeden** Baustein: Welche **anderen Bausteine aus der Liste** muss man **vorher** verstanden haben?
-- Nur **echte fachliche Voraussetzungen** — „B baut direkt auf A auf", nicht „passt thematisch dazu".
-- Nutze die „braucht vorher"-Hinweise, ordne sie den passenden Baustein-Nummern zu.
-- Nummern **nur aus der Liste**. **Keine Selbstbezüge.** Im Zweifel **leer** — lieber keine Kante als eine erfundene.
-- Halte es sparsam: die meisten Bausteine haben 0–2 direkte Voraussetzungen, nicht mehr.
-
-Schreibe NUR die JSON-Datei nach: {out_path}, GENAU in diesem Format (Schlüssel = Baustein-Nummer, Wert = Liste der Voraussetzungs-Nummern):
-{{"prereqs": {{"3": [1, 7], "5": []}}}}
-
-Gib sonst keinen Text aus.
-{extra}

templates/Prompt/Guide-Content-Check.md

@@ -0,0 +1,19 @@
+Review the gathered contents for blocks of a learning guide on the topic "{topic}" (format: {format_name}). Audience: beginners. This is not yet guide text — only the content bullet points that will be taught later.
+
+CONTENTS:
+{sections}
+
+Review each block:
+1. Correctness: are the points and facts factually right and supportable? Nothing hallucinated, no invented values/versions.
+2. Completeness: is something essential missing that a beginner needs to understand the block?
+3. Scope: no more than the block yields — nothing mentioned in passing inflated; but also no central gap.
+
+You only REVIEW and note problems — you change nothing. Note only genuine flaws, no matters of taste.
+
+Write ONLY the JSON file to: {out_path}
+
+Format — all in order:
+{{"ok": true}}
+Otherwise (block title EXACTLY as above):
+{{"problems": [{{"section": "exact block title", "problem": "…"}}]}}
+{extra}

templates/Prompt/Guide-Content-Fix.md

@@ -0,0 +1,18 @@
+Revise individual block contents of a learning guide on the topic "{topic}". One PROBLEM is noted per block (correctness, completeness, or scope). Fix ONLY the noted problem; whatever is in order stays untouched.
+
+{facts}
+
+TASKS — per block, the problem and the current content:
+{tasks}
+
+Write all revised content in GERMAN (the guide is for German-speaking learners), even though these instructions are in English.
+
+Write ONLY the file {out_path} — one section marker per revised block (title EXACTLY as in the task), with the corrected points beneath it:
+
+<!-- section: exact block title -->
+- Core point …
+- Core point …
+Example: short idea of what the example shows
+
+Write the marker line exactly like that. No text outside the sections.
+{extra}

templates/Prompt/Guide-Content.md

@@ -0,0 +1,30 @@
+For each assigned block of a learning guide on the topic "{topic}", identify WHAT a beginner with no prior knowledge needs to understand. You are not yet writing guide text — you only gather the contents that will be taught later.
+
+You are assigned the following chapters and blocks — binding: every assigned block must appear, invent no additional ones. Beneath each block are its SUBBLOCKS with their learning-path level (`[beginner]`/`[advanced]`/`[expert]`) — the sub-points that get taught:
+{assignment}
+
+{facts}
+
+Guiding principle: only the **essentials**. Superfluous material harms learning — gather what a beginner REALLY needs, not everything one could possibly say.
+
+Gather per block:
+- Core points / learning goals: what must the reader grasp? Cover EVERY listed subblock with EXACTLY the one central core point — not several overlapping ones. If a block has no subblocks, gather 3-7 concise points.
+- Prerequisites: which terms/ideas must one already know to understand this? Each explainable in half a sentence — these are the anchor points for newcomers.
+- Typical hurdles: where do beginners typically misunderstand it or stumble?
+- Cited facts (versions, names, values) — nothing unsupported; verify anything uncertain via web search.
+- One concrete example idea ONLY where an example genuinely carries the understanding — not dutifully for every subblock.
+- Scope: only what THIS block yields. No more, no less. Don't inflate something mentioned in passing into a topic.
+
+Write all gathered content in GERMAN (the guide is for German-speaking learners), even though these instructions are in English.
+
+Write ONLY the file {out_path} — one section marker per block (title EXACTLY from the assignment), with the points beneath it:
+
+<!-- section: exact block title -->
+- Core point …
+- Core point …
+Prerequisite: what must be briefly explained beforehand (anchor)
+Hurdle: typical beginner misconception
+Example: short idea of what the example shows
+
+Write the marker line exactly like that. No text outside the sections, no prose guide.
+{extra}

templates/Prompt/Guide-Facts-Projekt.md

@@ -0,0 +1 @@
+The facts come from the project under {project} — read files with Read/Bash as needed. PDFs are available as same-named .txt files — ALWAYS read the .txt, never the PDF.

templates/Prompt/Guide-Facts-Thema.md

@@ -0,0 +1 @@
+Verify uncertain or perishable facts (version numbers, current recommendations, state of research) via web search BEFORE writing them into a section. Claim nothing unsupported.

templates/Prompt/Guide-Fakten-Projekt.md

@@ -1 +0,0 @@
-Die Fakten stammen aus dem Projekt unter {project} — lies bei Bedarf Dateien mit Read/Bash nach. PDFs liegen als gleichnamige .txt-Dateien vor — lies IMMER die .txt, nie das PDF.

templates/Prompt/Guide-Fakten-Thema.md

@@ -1 +0,0 @@
-Prüfe unsichere oder veraltbare Fakten (Versionsnummern, aktuelle Empfehlungen, Forschungsstand) per Websuche, BEVOR du sie in eine Section schreibst. Nichts Unbelegtes behaupten.

templates/Prompt/Guide-Gliederung-Judge.md

@@ -1,24 +0,0 @@
-{n} Agenten haben die feste Baustein-Auswahl für {format_name} zum Thema "{topic}" unabhängig gegliedert ({zweck}). Führe die Vorschläge zu EINER kohärenten Gliederung zusammen.
-
-GEWÄHLTE BAUSTEINE (jeder mit seiner NUMMER — die Auswahl steht fest; die Liste steht in **Lernreihenfolge**, Voraussetzungen zuerst — halte sie grob ein):
-{bausteine}
-
-DIE VORSCHLÄGE (je Kapitel die Baustein-Nummern):
-{gliederungen}
-
-Vorgehen — MERGEN, nicht nur einen wählen:
-- Wo die Vorschläge übereinstimmen (Bausteine im selben Kapitel, ähnliche Reihenfolge) → übernehmen.
-- Wo sie sich unterscheiden → selbst entscheiden: bester roter Faden, vom Bekannten zum Unbekannten, erster Erfolg vor Theorie.
-- Nimm den besten Kapitelschnitt und die klarsten Kapiteltitel aus allen Vorschlägen.
-- Ergebnis ist EINE Gliederung, die besser ist als jeder einzelne Vorschlag.
-
-Regeln:
-- JEDER Baustein in GENAU einem Kapitel. Keinen weglassen, keinen doppelt.
-- Ordne per NUMMER. Verwende nur die Nummern aus der Liste oben, jede genau einmal.
-- 3–7 Bausteine pro Kapitel; Kapiteltitel kurz und konkret.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (nummern = die Baustein-Nummern in der gewünschten Reihenfolge):
-{{"kapitel": [{{"titel": "Grundlagen", "nummern": [3, 1, 7]}}]}}
-{extra}

templates/Prompt/Guide-Gliederung.md

@@ -1,23 +0,0 @@
-Plane die Gliederung eines Lern-Guides zum Thema "{topic}".
-
-BAUSTEINE (jeder mit seiner NUMMER — die Liste steht fest, du ordnest nur):
-{bausteine}
-
-Die Liste steht bereits in **Lernreihenfolge** (Voraussetzungen zuerst, per Abhängigkeits-Sortierung). Halte sie **grob** ein; gruppiere benachbarte verwandte Bausteine zu Kapiteln.
-
-REIHENFOLGE — vom Bekannten zum Unbekannten:
-- Kapitel 1 führt zum schnellsten sichtbaren Ergebnis (erster Erfolg), nicht zur Theorie.
-- Konkretes vor Abstraktem, Einfaches vor Komplexem, Voraussetzungen vor dem, was auf ihnen aufbaut.
-- Jedes Kapitel baut auf den vorigen auf — ein roter Faden, keine Themensammlung.
-
-Regeln:
-- JEDER gewählte Baustein landet in GENAU einem Kapitel. Keinen weglassen, keine neuen erfinden.
-- Ordne per NUMMER. Verwende nur die Nummern aus der Liste oben, jede genau einmal.
-- 3–7 Bausteine pro Kapitel; die Kapitelzahl folgt aus dem Thema.
-- Kapiteltitel kurz und konkret.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (nummern = die Baustein-Nummern in der gewünschten Reihenfolge):
-{{"kapitel": [{{"titel": "Grundlagen", "nummern": [3, 1, 7]}}]}}
-{extra}

templates/Prompt/Guide-Inhalt-Check.md

@@ -1,19 +0,0 @@
-Prüfe die gesammelten Inhalte für Bausteine eines Lern-Guides zum Thema "{topic}" (Format: {format_name}). Zielgruppe: Anfänger. Es ist noch kein Guide-Text — nur die Inhalts-Stichpunkte, die später gelehrt werden.
-
-INHALTE:
-{sections}
-
-Prüfe jeden Baustein:
-1. Korrektheit: Sind die Punkte und Fakten sachlich richtig und belegbar? Nichts Halluziniertes, keine erfundenen Werte/Versionen.
-2. Vollständigkeit: Fehlt etwas Wesentliches, das ein Anfänger zum Verständnis des Bausteins braucht?
-3. Scope: Nicht mehr, als der Baustein hergibt — nichts am Rand Erwähntes aufgeblasen; aber auch keine zentrale Lücke.
-
-Du PRÜFST nur und notierst Probleme — du änderst nichts. Nur echte Mängel notieren, keine Geschmacksfragen.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format — alles in Ordnung:
-{{"ok": true}}
-Sonst (Baustein-Titel EXAKT wie oben):
-{{"probleme": [{{"section": "Exakter Baustein-Titel", "problem": "…"}}]}}
-{extra}

templates/Prompt/Guide-Inhalt-Fix.md

@@ -1,16 +0,0 @@
-Überarbeite einzelne Baustein-Inhalte eines Lern-Guides zum Thema "{topic}". Pro Baustein ist ein PROBLEM notiert (Korrektheit, Vollständigkeit oder Scope). Behebe NUR das notierte Problem; was in Ordnung ist, bleibt erhalten.
-
-{facts}
-
-AUFTRÄGE — je Baustein das Problem und der aktuelle Inhalt:
-{auftraege}
-
-Schreibe NUR die Datei {out_path} — pro überarbeitetem Baustein ein section-Marker (Titel EXAKT wie im Auftrag), darunter die korrigierten Punkte:
-
-<!-- section: Exakter Baustein-Titel -->
-- Kernpunkt …
-- Kernpunkt …
-Beispiel: kurze Idee, was das Beispiel zeigt
-
-Die Marker-Zeile exakt so schreiben. Kein Text außerhalb der Sections.
-{extra}

templates/Prompt/Guide-Inhalt.md

@@ -1,28 +0,0 @@
-Identifiziere für jeden zugeteilten Baustein eines Lern-Guides zum Thema "{topic}", WAS ein Anfänger ohne Vorwissen verstehen muss. Du schreibst noch keinen Guide-Text — du sammelst nur die Inhalte, die später gelehrt werden.
-
-Dir zugeteilt sind folgende Kapitel und Bausteine — verbindlich: jeder zugeteilte Baustein muss vorkommen, keine zusätzlichen erfinden. Unter jedem Baustein stehen seine SUBBAUSTEINE mit Lernpfad-Stufe (`[anfaenger]`/`[fortgeschritten]`/`[experte]`) — die Teilpunkte, die gelehrt werden:
-{zuteilung}
-
-{facts}
-
-Leitprinzip: nur das **Wesentliche**. Überflüssiges Material schadet dem Lernen — sammle, was ein Anfänger WIRKLICH braucht, nicht alles, was man sagen könnte.
-
-Sammle pro Baustein:
-- Kernpunkte / Lernziele: was muss der Leser begreifen? Decke JEDEN gelisteten Subbaustein mit GENAU dem einen, zentralen Kernpunkt ab — nicht mehrere überlappende. Hat ein Baustein keine Subbausteine, sammle 3–7 knappe Punkte.
-- Voraussetzungen: welche Begriffe/Ideen muss man vorher kennen, um das hier zu verstehen? Jede in einem Halbsatz erklärbar — das sind die Ankerpunkte für Neulinge.
-- Typische Hürden: wo verstehen Anfänger es erfahrungsgemäß falsch oder stolpern?
-- Belegte Fakten (Versionen, Namen, Werte) — nichts Unbelegtes; Unsicheres per Websuche prüfen.
-- Eine konkrete Beispiel-Idee NUR, wo ein Beispiel das Verständnis wirklich trägt — nicht pflichtmäßig bei jedem Subbaustein.
-- Scope: nur was DIESER Baustein hergibt. Nicht mehr, nicht weniger. Am Rand Erwähntes nicht zum Thema aufblasen.
-
-Schreibe NUR die Datei {out_path} — pro Baustein ein section-Marker (Titel EXAKT aus der Zuteilung), darunter die Punkte:
-
-<!-- section: Exakter Baustein-Titel -->
-- Kernpunkt …
-- Kernpunkt …
-Voraussetzung: was vorher kurz erklärt werden muss (Anker)
-Hürde: typischer Anfänger-Irrtum
-Beispiel: kurze Idee, was das Beispiel zeigt
-
-Die Marker-Zeile exakt so schreiben. Kein Text außerhalb der Sections, kein Fließtext-Guide.
-{extra}

templates/Prompt/Guide-Lese-Check.md

@@ -1,33 +1,33 @@
-Prüfe geschriebene Sections eines Lern-Guides zum Thema "{topic}" (Format: {format_name}) auf Lesbarkeit.
-Zielgruppe: Anfänger.
+Review written sections of a learning guide on the topic "{topic}" (format: {format_name}) for readability.
+Audience: beginners.
 
-SECTION-SPEZIFIKATION (Soll-Zustand):
+SECTION SPECIFICATION (target state):
 {spec}
 
 SECTIONS:
 {sections}
 
-Prüfe jede Section:
-1. Lehrt die Section das Konzept für einen Anfänger ohne Vorwissen verständlich — ordnet sie es ein, erklärt sie das Wie/Warum, macht ein Beispiel es konkret? Nicht so verdichtet, dass nur jemand sie versteht, der das Thema schon kennt.
-2. Lesbarkeit (echte Mängel notieren):
-   - Sätze über ~25 Wörter oder Schachtelsätze mit mehreren Einschüben.
-   - Eine Aufzählung (Schritte/Optionen/Anforderungen) als langer Fließtext-Satz, die eine Markdown-Liste sein sollte.
-   - Textwand: ein dichter Block ohne Absätze, der sich in mehrere teilen ließe.
-   - Mehr als ~4 neue Fachbegriffe ohne Erklärung beim ersten Auftreten.
-3. Knappheit (überflüssiges Material schadet dem Lernen — echte Mängel notieren):
-   - Wiederholung: dieselbe Aussage mehrfach, nur anders formuliert.
-   - Breit ausgewalztes Triviales, Füllsätze, Vorreden, Meta-Kommentare ohne neuen Inhalt.
-   - Ein Beispiel, das nichts zum Verständnis beiträgt.
-   → notieren als „zu lang/redundant — kürzen ohne Info-Verlust". WICHTIG: Kürzen heißt nie, einen Subbaustein zu streichen — jeder bleibt erhalten.
-4. Sind die Beispiele kurz, simpel, plausibel korrekt — und im themengerechten Format laut Spezifikation (kein Codeblock um Prosa-Beispiele, kein Prosa-Pseudo-Beispiel, wo Code gefragt ist)?
-5. Ist das Markdown sauber (keine abgebrochenen Code-Blöcke, keine Platzhalter, kein Fremdtext)?
+Review each section:
+1. Does the section teach the concept understandably for a beginner with no prior knowledge — does it frame it, explain the how/why, make an example concrete? Not so dense that only someone who already knows the topic can follow it.
+2. Readability (note genuine flaws):
+   - Sentences over ~25 words, or nested sentences with several interjections.
+   - An enumeration (steps/options/requirements) written as one long prose sentence that should be a Markdown list.
+   - Wall of text: one dense block without paragraphs that could be split into several.
+   - More than ~4 new technical terms left unexplained at first occurrence.
+3. Conciseness (superfluous material harms learning — note genuine flaws):
+   - Repetition: the same statement multiple times, just reworded.
+   - Trivia spelled out at length, filler sentences, preambles, meta-comments with no new content.
+   - An example that contributes nothing to understanding.
+   → note as "too long/redundant — shorten without loss of information". IMPORTANT: shortening never means dropping a subblock — each one stays.
+4. Are the examples short, simple, plausibly correct — and in the topic-appropriate format per the specification (no code block around prose examples, no prose pseudo-example where code is required)?
+5. Is the Markdown clean (no broken code blocks, no placeholders, no foreign text)?
 
-Du PRÜFST nur und notierst Probleme — du änderst nichts. Nur echte Mängel notieren, keine Geschmacksfragen.
+You only REVIEW and note problems — you change nothing. Note only genuine flaws, no matters of taste.
 
-Schreibe NUR die JSON-Datei nach: {out_path}
+Write ONLY the JSON file to: {out_path}
 
-Format — alles in Ordnung:
+Format — all in order:
 {{"ok": true}}
-Sonst (Section-Titel EXAKT wie oben):
-{{"probleme": [{{"section": "Exakter Section-Titel", "problem": "…"}}]}}
+Otherwise (section title EXACTLY as above):
+{{"problems": [{{"section": "exact section title", "problem": "…"}}]}}
 {extra}

templates/Prompt/Guide-Outline-Judge.md

@@ -0,0 +1,26 @@
+{n} agents independently outlined the fixed block selection for {format_name} on the topic "{topic}" ({purpose}). Merge the proposals into ONE coherent outline.
+
+CHOSEN BLOCKS (each with its NUMBER — the selection is fixed; the list is in **learning order**, prerequisites first — keep to it roughly):
+{blocks}
+
+THE PROPOSALS (per chapter, the block numbers):
+{outlines}
+
+Approach — MERGE, don't just pick one:
+- Where the proposals agree (blocks in the same chapter, similar order) → adopt it.
+- Where they differ → decide yourself: best through-line, from the known to the unknown, first success before theory.
+- Take the best chapter cut and the clearest chapter titles from all proposals.
+- The result is ONE outline that is better than any single proposal.
+
+Rules:
+- EVERY block in EXACTLY one chapter. Drop none, duplicate none.
+- Arrange by NUMBER. Use only the numbers from the list above, each exactly once.
+- 3-7 blocks per chapter; chapter titles short and concrete.
+
+Write the chapter titles in GERMAN (the guide is for German-speaking learners), even though these instructions are in English.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (numbers = the block numbers in the desired order):
+{{"chapters": [{{"title": "Grundlagen", "numbers": [3, 1, 7]}}]}}
+{extra}

templates/Prompt/Guide-Outline.md

@@ -0,0 +1,25 @@
+Plan the outline of a learning guide on the topic "{topic}".
+
+BLOCKS (each with its NUMBER — the list is fixed, you only arrange it):
+{blocks}
+
+The list is already in **learning order** (prerequisites first, by dependency sort). Keep to it **roughly**; group adjacent related blocks into chapters.
+
+ORDER — from the known to the unknown:
+- Chapter 1 leads to the fastest visible result (first success), not to theory.
+- Concrete before abstract, simple before complex, prerequisites before what builds on them.
+- Each chapter builds on the previous ones — one through-line, not a collection of topics.
+
+Rules:
+- EVERY chosen block lands in EXACTLY one chapter. Drop none, invent no new ones.
+- Arrange by NUMBER. Use only the numbers from the list above, each exactly once.
+- 3-7 blocks per chapter; the number of chapters follows from the topic.
+- Chapter titles short and concrete.
+
+Write the chapter titles in GERMAN (the guide is for German-speaking learners), even though these instructions are in English.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (numbers = the block numbers in the desired order):
+{{"chapters": [{{"title": "Grundlagen", "numbers": [3, 1, 7]}}]}}
+{extra}

templates/Prompt/Guide-Sections-Fix.md

@@ -1,36 +1,38 @@
-Überarbeite einzelne Sections eines Lern-Guides zum Thema "{topic}" (Format: {format_name}).
+Revise individual sections of a learning guide on the topic "{topic}" (format: {format_name}).
 
 {facts}
 
-SECTION-SPEZIFIKATION:
+SECTION SPECIFICATION:
 {spec}
 
-ZU ÜBERARBEITEN — je Section ihre Subbausteine, das notierte Problem und der aktuelle Inhalt:
-{auftraege}
+TO REVISE — per section, its subblocks, the noted problem, and the current content:
+{tasks}
 
-Behebe pro Section NUR das notierte Problem; was in Ordnung ist, bleibt inhaltlich erhalten.
+Per section, fix ONLY the noted problem; whatever is in order stays unchanged in substance.
 
-VERBINDLICHE STRUKTUR (wie der Writer) — sonst bricht die gestufte Anzeige:
-- Jede Section hat ZWEI Fassungen: **kompakt** (je Subbaustein ein Merksatz) und **ausführlich** (zusammenhängender Anfänger-Text).
-- In BEIDEN Fassungen steht je Subbaustein ein `<!-- sub: LABEL | Subbaustein-Titel -->`-Marker. LABEL und Titel EXAKT aus der Subbaustein-Liste oben, gleiche Reihenfolge in beiden Blöcken. Der ausführliche Text beginnt mit einem kurzen Anker (Einordnung) VOR dem ersten Marker.
-- Die Marker sind unsichtbare Schnittstellen, KEINE sichtbaren Überschriften — schreibe trotzdem flüssig.
+MANDATORY STRUCTURE (same as the writer) — otherwise the staged display breaks:
+- Each section has TWO versions: **compact** (one mnemonic per subblock) and **detailed** (the `ausführlich` layer: a coherent beginner text).
+- In BOTH versions, each subblock carries a `<!-- sub: LABEL | subblock title -->` marker. LABEL and title EXACTLY from the subblock list above, same order in both blocks. The detailed text starts with a short anchor (framing) BEFORE the first marker.
+- The markers are invisible interfaces, NOT visible headings — write fluently regardless.
 
-KNAPP HALTEN (falls das Problem „zu lang/redundant" ist):
-- Jeder Satz trägt neue Information. Streiche Wiederholungen, Füll- und Meta-Sätze, Vorreden.
-- Erkläre Triviales kurz; gib Tiefe nur, wo der Stoff sie braucht. Im Zweifel weglassen, nicht hinzufügen.
-- Ein Beispiel nur, wo es das Verständnis wirklich trägt — nicht pflichtmäßig bei jedem Subbaustein.
-- Kürzen heißt nie: einen Subbaustein streichen. Jeder bleibt mit seinem Marker erhalten.
+KEEP IT CONCISE (if the problem is "too long/redundant"):
+- Every sentence carries new information. Cut repetition, filler and meta sentences, preambles.
+- Explain trivia briefly; give depth only where the material needs it. When in doubt, leave it out, don't add.
+- An example only where it genuinely carries the understanding — not dutifully for every subblock.
+- Shortening never means dropping a subblock. Each one stays with its marker.
 
-Schreibe NUR die Datei {out_path} in GENAU diesem Format — für JEDE beanstandete Section ein section-Marker (Titel EXAKT wie oben):
+Write all revised sections in GERMAN (the guide is for German-speaking learners), even though these instructions are in English.
 
-<!-- section: Exakter Section-Titel -->
-<!-- kompakt -->
-<!-- sub: anfaenger | Exakter Subbaustein-Titel -->
-- Merksatz je Subbaustein (knapp, ohne Erklärung)
+Write ONLY the file {out_path} in EXACTLY this format — one section marker per flagged section (title EXACTLY as above):
+
+<!-- section: exact section title -->
+<!-- compact -->
+<!-- sub: beginner | exact subblock title -->
+- one mnemonic per subblock (concise, no explanation)
 <!-- ausführlich -->
-Anker: kurze Einordnung des Bausteins — vor dem ersten Subbaustein.
-<!-- sub: anfaenger | Exakter Subbaustein-Titel -->
-Anfängerfreundlicher Fließtext zu diesem Subbaustein.
+Anchor: brief framing of the block — before the first subblock.
+<!-- sub: beginner | exact subblock title -->
+Beginner-friendly prose for this subblock.
 
-Die Marker-Zeilen exakt so schreiben. Kein Text außerhalb der Sections.
+Write the marker lines exactly like that. No text outside the sections.
 {extra}

templates/Prompt/Guide-Writer.md

@@ -1,49 +1,51 @@
-Schreibe Sections für einen Lern-Guide zum Thema "{topic}" (Format: {format_name}).
+Write sections for a learning guide on the topic "{topic}" (format: {format_name}).
 
-Dir zugeteilt sind folgende Kapitel und Bausteine — verbindlich: jede zugeteilte Section muss vorkommen, keine zusätzlichen erfinden. Unter jedem Baustein stehen seine SUBBAUSTEINE mit Ebenen-Label (`[anfaenger]`/`[fortgeschritten]`/`[experte]`/`[rand]`):
-{zuteilung}
+You are assigned the following chapters and blocks — binding: every assigned section must appear, invent no additional ones. Beneath each block are its SUBBLOCKS with their level label (`[beginner]`/`[advanced]`/`[expert]`/`[peripheral]`):
+{assignment}
 
-WICHTIG — jeder Subbaustein wird mit einem Marker abgegrenzt, damit der Guide später gestuft angezeigt werden kann (Anfänger sehen nur `anfaenger`, Fortgeschrittene mehr). Das Label kommt EXAKT aus der Zuteilung. Trotz Marker schreibst du FLÜSSIG und verwoben — der Marker ist eine unsichtbare Schnittstelle, KEINE sichtbare Überschrift.
+IMPORTANT — each subblock is delimited with a marker so the guide can later be shown in stages (beginners see only `beginner`, advanced learners see more). The label comes EXACTLY from the assignment. Despite the marker, you write FLUENTLY and interwoven — the marker is an invisible interface, NOT a visible heading.
 
-Der Inhalt ist UNABHÄNGIG von der Stufe: jeder Subbaustein wird **anfängerfreundlich** erklärt, egal welches Label. Das Label sagt nur, WANN im Lernpfad der Punkt drankommt (Fundament → Feinheit) — NICHT wie kompliziert er geschrieben wird. Ein `[experte]`-Punkt wird genauso simpel erklärt wie ein `[anfaenger]`-Punkt. Kein Perfektionismus, keine künstliche Tiefe: das Wesentliche klar, so dass ein Neuling es versteht.
+The content is INDEPENDENT of the level: every subblock is explained in a **beginner-friendly** way, no matter the label. The label only says WHEN in the learning path the point comes up (foundation → finesse) — NOT how complicated it is written. An `[expert]` point is explained just as simply as a `[beginner]` point. No perfectionism, no artificial depth: the essentials made clear, so that a newcomer understands them.
 
-Jeder Baustein bekommt ZWEI Fassungen mit DENSELBEN Subbausteinen (gleiche Titel, gleiche Reihenfolge):
-- **kompakt**: je Subbaustein EIN Merksatz als Stichpunkt (`- …`). Zum Erinnern. Nur benennen, nicht erklären.
-- **ausführlich**: der zusammenhängende Anfänger-Lerntext (siehe unten).
+Each block gets TWO versions with the SAME subblocks (same titles, same order):
+- **compact**: one mnemonic per subblock as a bullet (`- …`). For recall. Only name it, don't explain.
+- **ausführlich** (detailed): the coherent beginner learning text (see below).
 
-SO SCHREIBST DU die ausführliche Fassung — EIN zusammenhängender Text für einen Junior, der das Thema NEU lernt:
-- Beginne mit dem Anker (Einordnung): welches Problem/wozu, angeknüpft an etwas Bekanntes — erst dann das Neue. Der Anker steht VOR dem ersten Subbaustein-Marker. Pflicht, nie weglassen.
-- Löse JEDEN Fachbegriff bei Erstnennung in einem Halbsatz auf. Setze nichts voraus — auch keine Begriffe aus dem Titel oder anderen Bausteinen. Nutze die „Voraussetzung"-Hinweise als Anker, die „Hürde"-Hinweise, um Missverständnisse vorweg auszuräumen.
-- Behandle jeden Subbaustein unter seinem Marker — flüssig formuliert, erklärender Fließtext, kein isolierter Stichpunkt-Block.
-- Reihenfolge der Subbausteine wie in der Zuteilung: erst `[anfaenger]` (Fundament), dann `[fortgeschritten]`, dann `[experte]`, zuletzt `[rand]`.
-- „Wie"-Abläufe Schritt für Schritt zeigen, nicht nur das Ergebnis.
-- KNAPP: Jeder Satz trägt neue Information. Keine Wiederholung, keine Füll- oder Meta-Sätze, keine Vorrede. Überflüssiges schadet dem Lernen — im Zweifel weglassen, nicht hinzufügen.
-- Länge folgt dem Inhalt: ein triviales Detail ein, zwei Sätze; ein komplexes Konzept so viel, wie es WIRKLICH braucht — nicht mehr. Kein „so lang wie möglich".
-- Ein Beispiel NUR, wo es das Verständnis wirklich trägt — nicht pflichtmäßig bei jedem Subbaustein.
+HOW TO WRITE the detailed version — ONE coherent text for a junior who is learning the topic anew:
+- Start with the anchor (framing): which problem / what for, tied to something familiar — only then the new material. The anchor comes BEFORE the first subblock marker. Mandatory, never omit it.
+- Resolve EVERY technical term at first mention in half a sentence. Assume nothing — not even terms from the title or other blocks. Use the "Prerequisite" hints as anchors, and the "Hurdle" hints to clear up misconceptions up front.
+- Treat each subblock under its marker — fluently phrased, explanatory prose, not an isolated bullet block.
+- Order of the subblocks as in the assignment: first `[beginner]` (foundation), then `[advanced]`, then `[expert]`, last `[peripheral]`.
+- Show "how" procedures step by step, not just the result.
+- CONCISE: every sentence carries new information. No repetition, no filler or meta sentences, no preamble. Superfluous material harms learning — when in doubt, leave it out, don't add.
+- Length follows the content: a trivial detail one or two sentences; a complex concept as much as it REALLY needs — no more. Not "as long as possible".
+- An example ONLY where it genuinely carries the understanding — not dutifully for every subblock.
 
-GEPRÜFTE INHALTE je Baustein — das ist verbindlich, was gelehrt werden muss:
-{inhalte}
+VERIFIED CONTENTS per block — this is binding, what must be taught:
+{contents}
 
-Recherchiere NICHT und suche NICHT im Web. Alle nötigen Fakten stehen in diesen geprüften Inhalten — nutze ausschließlich sie. Erfinde nichts dazu, lass nichts Wesentliches weg. Lehre simpel: kurze Sätze, Listen für Aufzählungen, ein Anfänger versteht es sofort.
+Do NOT research and do NOT search the web. All necessary facts are in these verified contents — use only them. Invent nothing, leave out nothing essential. Teach simply: short sentences, lists for enumerations, a beginner understands it at once.
 
-SECTION-SPEZIFIKATION (gilt je Baustein):
+SECTION SPECIFICATION (applies per block):
 {spec}
 
-Schreibe NUR die Datei {out_path} in GENAU diesem Format — pro Kapitel ein kapitel-Marker, pro Baustein ein section-Marker (Titel EXAKT aus der Zuteilung), darin ein `kompakt`- und ein `ausführlich`-Block. In BEIDEN Blöcken steht je Subbaustein ein `<!-- sub: LABEL | Subbaustein-Titel -->`-Marker (LABEL und Titel EXAKT aus der Zuteilung, gleiche Reihenfolge in beiden Blöcken):
+Write the entire guide content in GERMAN (the guide is for German-speaking learners), even though these instructions are in English.
 
-<!-- kapitel: Kapiteltitel -->
-<!-- section: Exakter Baustein-Titel -->
-<!-- kompakt -->
-<!-- sub: anfaenger | Exakter Subbaustein-Titel -->
-- Merksatz zu diesem Subbaustein (knapp, ohne Erklärung)
-<!-- sub: fortgeschritten | Exakter Subbaustein-Titel -->
-- Merksatz zu diesem Subbaustein
+Write ONLY the file {out_path} in EXACTLY this format — one kapitel marker per chapter, one section marker per block (title EXACTLY from the assignment), with a `compact` and an `ausführlich` block inside. In BOTH blocks, each subblock carries a `<!-- sub: LABEL | subblock title -->` marker (LABEL and title EXACTLY from the assignment, same order in both blocks):
+
+<!-- kapitel: chapter title -->
+<!-- section: exact block title -->
+<!-- compact -->
+<!-- sub: beginner | exact subblock title -->
+- mnemonic for this subblock (concise, no explanation)
+<!-- sub: advanced | exact subblock title -->
+- mnemonic for this subblock
 <!-- ausführlich -->
-Anker: Einordnung des ganzen Bausteins (welches Problem, wozu) — vor dem ersten Subbaustein.
-<!-- sub: anfaenger | Exakter Subbaustein-Titel -->
-Anfängerfreundlicher Fließtext zu diesem Subbaustein, mit kleinem Beispiel.
-<!-- sub: fortgeschritten | Exakter Subbaustein-Titel -->
-Anfängerfreundlicher Fließtext zu diesem Subbaustein.
+Anchor: framing of the whole block (which problem, what for) — before the first subblock.
+<!-- sub: beginner | exact subblock title -->
+Beginner-friendly prose for this subblock, with a small example.
+<!-- sub: advanced | exact subblock title -->
+Beginner-friendly prose for this subblock.
 
-Die Marker-Zeilen exakt so schreiben. Jede Section hat genau einen `<!-- kompakt -->`- und einen `<!-- ausführlich -->`-Block; die Subbaustein-Titel sind in beiden identisch. Kein Text außerhalb der Sections, kein Dokument-Titel, kein Inhaltsverzeichnis.
+Write the marker lines exactly like that. Each section has exactly one `<!-- compact -->` and one `<!-- ausführlich -->` block; the subblock titles are identical in both. No text outside the sections, no document title, no table of contents.
 {extra}

templates/Prompt/Levels-Mapping.md

@@ -0,0 +1,21 @@
+Several agents have classified the subblocks of the topic "{topic}" by learning-path position. On some they disagree. Decide the final level for each disputed subblock.
+
+DISPUTED SUBBLOCKS (with the votes cast):
+{disputed}
+
+Level = learning-path position (WHEN you need the point), NOT difficulty:
+- **beginner**: foundation — what you need first/at all; a prerequisite for the rest. Even if conceptually demanding.
+- **advanced**: builds on it; common variants, typical application.
+- **expert**: subtleties, special cases, niches, rare details — even if substantively simple (e.g. an obscure flag, a version detail).
+
+Rules:
+- A simple niche detail is `expert`; a fundamental complex concept is `beginner`.
+- Weigh the votes, decide on the merits by learning-path position.
+- **`advanced` is not a fallback choice.** Don't pick the middle because the votes are scattered — decide by the criterion "when do you need this?". Hit `beginner`/`expert` clearly where they apply.
+- Exactly one level for EACH disputed number.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (no other text):
+{{"levels": {{"1": "beginner", "4": "expert"}}}}
+{extra}

templates/Prompt/Levels-Research.md

@@ -0,0 +1,33 @@
+Assign each subblock of the topic "{topic}" to its **learning-path position**: beginner, advanced, or expert. The level controls when a learner sees the point (beginners see only „beginner", advanced learners more).
+
+SUBBLOCKS (grouped by block; many state their core points with „Kern:"):
+{subblocks}
+
+Use the core points for a well-founded classification — judge on the content, not just the title.
+
+DECISIVE — the level measures WHEN you need the point in the learning path, NOT how hard it is to understand:
+- **beginner**: foundation. What you need first/at all to understand the block in the first place. A prerequisite for the rest. Even if the concept is conceptually demanding — if it is the foundation, it belongs here.
+- **advanced**: builds on the foundation. Common variants, typical application, the next step.
+- **expert**: subtleties, special cases, edge cases, niches, rare details. What you need only once you've mastered the basics — **even if it is substantively simple** (e.g. an obscure flag, a version detail).
+
+IMPORTANT — difficulty is NOT the criterion:
+- A **simple niche detail** (rarely needed, e.g. „seit 6.4.12.0") is `expert`, not `beginner`.
+- A **fundamental but complex concept** (needed early) is `beginner`, not `expert`.
+- Ask: "when in the learning path do you need this?" — not "how hard is it?".
+
+Rules:
+- Level RELATIVE within each block: what is foundation here, what is build-up, what is fine detail?
+- Not every block needs a `beginner` point. Some topics presuppose prior knowledge and are entirely `advanced`/`expert` — that is intended. Level honestly by learning-path position, without inventing an artificial entry point.
+- Only judge — invent nothing, change no subblocks.
+
+Don't flee to the middle:
+- **`advanced` is not a fallback choice.** Don't pick the middle because you're unsure.
+- Decide each level by the question **"when in the learning path do you need this?"** — not by the safest middle option.
+- **Differentiate within the block:** What is foundation (beginner), what is build-up (advanced), what is fine detail (expert)? Not everything is the middle.
+- Hit `beginner` and `expert` clearly where they apply — no bonus for the middle.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (exactly one level for EACH number; no other text):
+{{"levels": {{"1": "beginner", "2": "advanced", "3": "expert"}}}}
+{extra}

templates/Prompt/Outline-Prerequisites.md

@@ -0,0 +1,17 @@
+Determine the **learning prerequisites** between the blocks of the topic "{topic}". From these, the order of the guide is computed.
+
+BLOCKS (number, title; some list the prerequisites of their contents under "braucht vorher"):
+{blocks}
+
+TASK:
+- For **each** block: which **other blocks from the list** must one have understood **beforehand**?
+- Only **genuine subject-matter prerequisites** — "B builds directly on A", not "fits the topic thematically".
+- Use the "braucht vorher" hints, and map them to the matching block numbers.
+- Numbers **only from the list**. **No self-references.** When in doubt, leave it **empty** — better no edge than an invented one.
+- Keep it sparse: most blocks have 0-2 direct prerequisites, not more.
+
+Write ONLY the JSON file to: {out_path}, EXACTLY in this format (key = block number, value = list of prerequisite numbers):
+{{"prereqs": {{"3": [1, 7], "5": []}}}}
+
+Output no other text.
+{extra}

templates/Prompt/Quelle-Relevanz.md

@@ -1,23 +0,0 @@
-Du sichtest gecrawlte Seiten für das Lern-Thema "{topic}". Entscheide je Seite: **ja** (gehört zum Thema) oder **nein** (themenfremd). Die Auswahl steuert, welche Seiten überhaupt gelesen werden — themenfremde Seiten blähen das Inventar mit Fremdstoff auf.
-
-LERNZIEL / SPEC (das ist der Maßstab):
-{spec}
-
-SEITEN (Nummer, dann die URL, darunter ein Inhalts-Auszug):
-{seiten}
-
-So entscheidest du:
-- **ja**: Die Seite behandelt genau das Fachgebiet der Spec. Kern-, Standard- oder Vertiefungsstoff dazu. Auch Randthemen des RICHTIGEN Gebiets sind `ja`.
-- **nein**: Anderes Fachgebiet als die Spec. Beispiel: Spec ist Backend-Entwicklung, die Seite behandelt Frontend, Storefront, Theming, Payment-Bedienung oder einen ganz anderen Rollen-/Produktbereich. Auch reine Marketing-, Community-, Event- oder Konto-Seiten ohne Lernstoff sind `nein`.
-
-Wichtig:
-- Urteile auf URL **und** Inhalts-Auszug zusammen. Der URL-Slug ist oft am aussagekräftigsten.
-- **Ignoriere das Navigations-Menü / Boilerplate** im Auszug (Login, „Sign up", Menüpunkte, Footer) — das steht auf jeder Seite und sagt nichts über das Thema.
-- **Im Zweifel `ja`** — lieber eine Seite zu viel lesen als Wichtiges ausschließen. Sage nur `nein`, wenn die Seite klar in ein anderes Fachgebiet gehört.
-- Bewerte jede Seite einzeln. Erfinde nichts dazu.
-{extra}
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (für JEDE Nummer genau ein Wert; kein weiterer Text):
-{{"relevant": {{"1": "ja", "2": "nein", "3": "ja"}}}}

templates/Prompt/Question-Pattern-Critique.md

@@ -0,0 +1,23 @@
+You are the quality reviewer for the question pool of a learning exam on the topic "{topic}". Another agent created question patterns for **several blocks** — exactly one pattern per subblock. Review them and return a **cleaned-up** final version.
+
+PATTERNS TO REVIEW (grouped by block; rows: (subblock) question):
+{table}
+
+REVIEW AND CLEAN UP AGAINST THESE CRITERIA (per block, separately):
+- **Style:** each question is EXACTLY ONE question, one question mark, one thing. No "and"/"as well as", no enumeration. At most 1-2 sentences. Violations → rephrase.
+- **Unambiguously answerable:** clearly answerable from the block's knowledge, with no invented assumptions. Unanswerable ones → fix.
+- **Core hit:** the question targets the subblock's core concept, phrased neutrally (not deliberately easy or hard — the difficulty is set later by the learner's level). If it misses the core → rephrase.
+- **Exactly one per subblock:** exactly one pattern remains per subblock. Duplicates → keep one.
+- Carry over the `block` and `subblock` of the entries unchanged (only `question` may change); do not invent new ones.
+
+Keep good patterns unchanged. Change only what genuinely violates the criteria.
+
+Keep every question in GERMAN (the questions are for German-speaking learners), even though these instructions are in English.
+
+Write the cleaned-up final version of ALL blocks as ONE JSON to the file {out_path} (use your write tool), EXACTLY in this format:
+{{"pattern": [
+  {{"block": "<exact block title>", "subblock": "<exact title>", "question": "<one concrete question>"}}
+]}}
+
+Output no other text.
+{extra}

templates/Prompt/Question-Pattern-Research.md

@@ -0,0 +1,28 @@
+You are building the question pool for a learning exam on the topic "{topic}". Create **question patterns** — **exactly one** concrete example question **per subblock**. Each pattern is later turned, at exam time, into a slightly varied question — matched to the learner's level (beginner to expert). So the difficulty is NOT in the pattern; it only comes in at exam time. Therefore ask about the **core concept** of the subblock, phrased neutrally.
+
+You are working on **several blocks**. Each block has its own subblocks — many with core points, cited facts, and an example:
+{blocks}
+
+TASK (for **each** of the blocks above):
+- For **each** of its subblocks, create **exactly one** pattern — a concrete, concise question about that subblock's core concept.
+- Each pattern is ONE concrete question (1-2 sentences, exactly one question mark, one thing) — no multi-parter, no enumeration.
+- The question must be answerable from the block's knowledge. Do not invent extra assumptions.
+- Base the question on the supplied **core points and cited facts** (the reliable foundation). Hit the CORE CONCEPT of the subblock, not a detail to be memorized. Assume NOTHING that is not in the facts: no "shown" code snippets/diagrams, no concrete values/lists/numbers from some later guide text.
+- The question hits the **core** of the subblock — the central point one must have understood. Not too narrow on a detail, not too broad across the whole block.
+- `block` is exactly one of the block titles above. `subblock` is exactly one of the subblock titles of the respective block.
+
+HARD STYLE RULES PER QUESTION:
+- Exactly ONE question, one question mark, one thing. No "and"/"as well as", no "name three …".
+- At most 1-2 sentences, no preamble, no scenario build-up.
+- Phrased neutrally — not deliberately easy, not deliberately hard. The difficulty is set by the exam via the learner's level.
+- Direct address, clear German.
+
+Write every question in GERMAN (the questions are for German-speaking learners), even though these instructions are in English.
+{extra}
+
+Write ALL patterns of all blocks as ONE JSON to the file {out_path} (use your write tool), EXACTLY in this format:
+{{"pattern": [
+  {{"block": "<exact block title>", "subblock": "<exact subblock title>", "question": "<one concrete question>"}}
+]}}
+
+Output no other text.

templates/Prompt/Relevance-Mapping.md

@@ -0,0 +1,18 @@
+Several agents have rated the subblocks of the topic "{topic}" by relevance (relevant/peripheral). For some they disagree. Decide the final relevance for each disputed subblock.
+
+DISPUTED SUBBLOCKS (with the votes cast):
+{disputed}
+
+Relevance:
+- **relevant**: core/standard knowledge that carries the topic — central concepts, definitions, properties. For theoretical topics, also central theorems with no practical use.
+- **peripheral**: a side note, niche/special case, "nice to know", deprecated/exotic, purely historical details, concrete numeric examples, mere cross-references. NOT peripheral: a central theorem or a fundamental property. For the complete guide only.
+
+Rules:
+- Weigh the votes and decide by the criterion **core vs. peripheral within ITS OWN block**. `peripheral` is a genuine category — mark peripheral items deliberately as such. Only true core concepts/central theorems are never `peripheral`.
+- Exactly one value for EACH disputed number.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (no other text):
+{{"relevance": {{"1": "relevant", "4": "peripheral"}}}}
+{extra}

templates/Prompt/Relevance-Research.md

@@ -0,0 +1,22 @@
+Rate each subblock of the topic "{topic}" by relevance: relevant or peripheral. The relevance controls whether a point goes into the focused guides or only into the complete guide.
+
+SUBBLOCKS (in brackets the parent block of the number; many state their core points with "Kern:"):
+{subblocks}
+
+Use the core points for a well-grounded rating — judge on the content, not just the title.
+
+Relevance:
+- **relevant**: core/standard knowledge that CARRIES the topic — central concepts, definitions, properties, common practice. For practical topics: what you need in actual use. For theoretical topics: central theorems/properties, EVEN without practical use. What you genuinely should know.
+- **peripheral**: a side note, special/niche case, "nice to know", deprecated/exotic — PLUS purely historical details (who/when), concrete numeric examples of a general principle, mere cross-references. NOT peripheral: a central theorem or a fundamental property just because it seems "theoretical". Belongs only in a complete guide.
+
+Rules:
+- These subblocks **all already** belong to the topic — the question is not *whether* but *how central*. Judge **core vs. peripheral within its own block**, one at a time.
+- `peripheral` is a **genuine category**, not a leftover bucket. Deliberately mark peripheral items (nice-to-know, special/niche cases, detail/numeric examples, historical notes, cross-references) as `peripheral`.
+- Don't bump the level up out of caution. Only **true core concepts / central theorems** are never `peripheral`.
+- Only judge — invent nothing, change no subblocks.
+
+Write ONLY the JSON file to: {out_path}
+
+Format (exactly one value for EACH number; no other text):
+{{"relevance": {{"1": "relevant", "2": "peripheral", "3": "relevant"}}}}
+{extra}

templates/Prompt/Relevanz-Mapping.md

@@ -1,18 +0,0 @@
-Mehrere Agenten haben die Subbausteine des Themas "{topic}" nach Relevanz bewertet (relevant/rand). Bei einigen sind sie sich uneinig. Entscheide für jeden strittigen Subbaustein die finale Relevanz.
-
-STRITTIGE SUBBAUSTEINE (mit den abgegebenen Stimmen):
-{strittig}
-
-Relevanz:
-- **relevant**: Kern-/Standardwissen, das das Thema trägt — zentrale Konzepte, Definitionen, Eigenschaften. Bei theoretischen Themen auch zentrale Sätze ohne praktischen Gebrauch.
-- **rand**: Randnotiz, Nischen-/Spezialfall, „nice to know", Deprecated/Exotik, rein historische Details, konkrete Zahlenbeispiele, bloße Querverweise. NICHT rand: ein zentrales Theorem/eine fundamentale Eigenschaft. Nur für den Komplett-Guide.
-
-Regeln:
-- Wäge die Stimmen ab, entscheide am Kriterium **Kern vs Rand SEINES Bausteins**. `rand` ist eine echte Kategorie — markiere Randständiges bewusst so. Nur echte Kernkonzepte/zentrale Sätze sind nie `rand`.
-- Für JEDE strittige Nummer genau einen Wert.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (kein weiterer Text):
-{{"relevanz": {{"1": "relevant", "4": "rand"}}}}
-{extra}

templates/Prompt/Relevanz-Recherche.md

@@ -1,22 +0,0 @@
-Bewerte jeden Subbaustein des Themas "{topic}" nach Relevanz: relevant oder rand. Die Relevanz steuert, ob ein Punkt in die fokussierten Guides kommt oder nur in den Komplett-Guide.
-
-SUBBAUSTEINE (Nummer in Klammern der zugehörige Baustein; viele nennen ihre Kernpunkte mit „Kern:"):
-{subbausteine}
-
-Nutze die Kernpunkte zur fundierten Bewertung — urteile auf dem Inhalt, nicht nur dem Titel.
-
-Relevanz:
-- **relevant**: Kern-/Standardwissen, das das Thema TRÄGT — zentrale Konzepte, Definitionen, Eigenschaften, gängige Praxis. Bei praktischen Themen: was man im Gebrauch braucht. Bei theoretischen Themen: zentrale Sätze/Eigenschaften, AUCH ohne praktischen Gebrauch. Was man wirklich kennen sollte.
-- **rand**: Randnotiz, Spezial-/Nischenfall, „nice to know", Deprecated/Exotik — PLUS rein historische Details (wer/wann), konkrete Zahlenbeispiele eines allgemeinen Prinzips, bloße Querverweise. NICHT rand: ein zentrales Theorem oder eine fundamentale Eigenschaft, nur weil sie „theoretisch" wirkt. Gehört nur in einen Komplett-Guide.
-
-Regeln:
-- Diese Subbausteine gehören **alle schon** zum Thema — die Frage ist nicht *ob*, sondern *wie zentral*. Bewerte **Kern vs Rand SEINES Bausteins**, einzeln.
-- `rand` ist eine **echte Kategorie**, kein Rest. Markiere Randständiges (nice-to-know, Spezial-/Nischenfälle, Detail-/Zahlenbeispiele, historische Notizen, Querverweise) **bewusst** als `rand`.
-- Stufe nicht aus Vorsicht hoch. Nur **echte Kernkonzepte / zentrale Sätze** sind nie `rand`.
-- Urteile nur — erfinde nichts dazu, ändere keine Subbausteine.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (für JEDE Nummer genau ein Wert; kein weiterer Text):
-{{"relevanz": {{"1": "relevant", "2": "rand", "3": "relevant"}}}}
-{extra}

templates/Prompt/Source-Relevance.md

@@ -0,0 +1,23 @@
+You are reviewing crawled pages for the learning topic "{topic}". Decide per page: **ja** (belongs to the topic) or **nein** (off-topic). The selection controls which pages get read at all — off-topic pages bloat the inventory with foreign material.
+
+LEARNING GOAL / SPEC (this is the yardstick):
+{spec}
+
+PAGES (number, then the URL, with a content excerpt below):
+{pages}
+
+How you decide:
+- **ja**: The page covers exactly the subject area of the spec. Core, standard, or in-depth material on it. Even edge topics of the RIGHT field are `ja`.
+- **nein**: A different subject area than the spec. Example: the spec is backend development, the page covers frontend, storefront, theming, payment operation, or an entirely different role/product area. Pure marketing, community, event, or account pages without learning material are also `nein`.
+
+Important:
+- Judge on the URL **and** content excerpt together. The URL slug is often the most telling.
+- **Ignore the navigation menu / boilerplate** in the excerpt (login, „Sign up", menu items, footer) — it appears on every page and says nothing about the topic.
+- **When in doubt, `ja`** — better to read one page too many than to exclude something important. Say `nein` only when the page clearly belongs to a different subject area.
+- Evaluate each page individually. Invent nothing.
+{extra}
+
+Write ONLY the JSON file to: {out_path}
+
+Format (exactly one value for EACH number; no other text):
+{{"relevant": {{"1": "ja", "2": "nein", "3": "ja"}}}}

templates/Prompt/Stufen-Mapping.md

@@ -1,21 +0,0 @@
-Mehrere Agenten haben die Subbausteine des Themas "{topic}" nach Lernpfad-Position eingestuft. Bei einigen sind sie sich uneinig. Entscheide für jeden strittigen Subbaustein die finale Stufe.
-
-STRITTIGE SUBBAUSTEINE (mit den abgegebenen Stimmen):
-{strittig}
-
-Stufe = Lernpfad-Position (WANN man den Punkt braucht), NICHT Schwierigkeit:
-- **anfaenger**: Fundament — was man zuerst/unbedingt braucht; Voraussetzung für den Rest. Auch wenn gedanklich anspruchsvoll.
-- **fortgeschritten**: baut darauf auf; gängige Varianten, typische Anwendung.
-- **experte**: Feinheiten, Sonderfälle, Nischen, seltene Details — auch wenn inhaltlich einfach (z. B. ein obskures Flag, ein Versions-Detail).
-
-Regeln:
-- Ein einfaches Nischen-Detail ist `experte`; ein fundamentales komplexes Konzept ist `anfaenger`.
-- Wäge die Stimmen ab, entscheide fachlich nach Lernpfad-Position.
-- **`fortgeschritten` ist keine Verlegenheits-Wahl.** Wähle die Mitte nicht, weil die Stimmen streuen — entscheide am Kriterium „Wann braucht man das?". `anfaenger`/`experte` klar treffen, wo sie zutreffen.
-- Für JEDE strittige Nummer genau eine Stufe.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (kein weiterer Text):
-{{"stufen": {{"1": "anfaenger", "4": "experte"}}}}
-{extra}

templates/Prompt/Stufen-Recherche.md

@@ -1,33 +0,0 @@
-Ordne jeden Subbaustein des Themas "{topic}" seiner **Lernpfad-Position** zu: anfaenger, fortgeschritten oder experte. Die Stufe steuert, wann ein Lerner den Punkt sieht (Anfänger sehen nur „anfaenger", Fortgeschrittene mehr).
-
-SUBBAUSTEINE (nach Baustein gruppiert; viele nennen ihre Kernpunkte mit „Kern:"):
-{subbausteine}
-
-Nutze die Kernpunkte zur fundierten Einstufung — urteile auf dem Inhalt, nicht nur dem Titel.
-
-ENTSCHEIDEND — die Stufe misst, WANN man den Punkt im Lernpfad braucht, NICHT wie schwer er zu verstehen ist:
-- **anfaenger**: Fundament. Was man als Erstes/unbedingt braucht, um den Baustein überhaupt zu verstehen. Voraussetzung für den Rest. Auch wenn das Konzept gedanklich anspruchsvoll ist — ist es das Fundament, gehört es hierher.
-- **fortgeschritten**: baut auf dem Fundament auf. Gängige Varianten, typische Anwendung, der nächste Schritt.
-- **experte**: Feinheiten, Sonderfälle, Edge-Cases, Nischen, seltene Details. Was man erst braucht, wenn man die Basis beherrscht — **auch wenn es inhaltlich einfach ist** (z. B. ein obskures Flag, ein Versions-Detail).
-
-WICHTIG — Schwierigkeit ist NICHT das Kriterium:
-- Ein **einfaches Nischen-Detail** (selten gebraucht, z. B. „seit 6.4.12.0") ist `experte`, nicht `anfaenger`.
-- Ein **fundamentales, aber komplexes Konzept** (man braucht es früh) ist `anfaenger`, nicht `experte`.
-- Frag: „Wann im Lernpfad braucht man das?" — nicht „Wie schwer ist es?".
-
-Regeln:
-- Stufe RELATIV im jeweiligen Baustein: was ist hier Fundament, was Aufbau, was Feinheit?
-- Nicht jeder Baustein braucht einen `anfaenger`-Punkt. Manche Themen setzen Vorwissen voraus und sind ganz `fortgeschritten`/`experte` — das ist gewollt. Stufe ehrlich nach Lernpfad-Position, ohne künstlichen Einstieg zu erfinden.
-- Urteile nur — erfinde nichts dazu, ändere keine Subbausteine.
-
-NICHT zur Mitte flüchten:
-- **`fortgeschritten` ist keine Verlegenheits-Wahl.** Wähle die Mitte nicht, weil du unsicher bist.
-- Entscheide jede Stufe an der Frage **„Wann im Lernpfad braucht man das?"** — nicht nach der sichersten Mittel-Option.
-- **Differenziere innerhalb des Bausteins:** Was ist Fundament (anfaenger), was Aufbau (fortgeschritten), was Feinheit (experte)? Nicht alles ist Mitte.
-- Triff `anfaenger` und `experte` klar, wo sie zutreffen — kein Bonus für die Mitte.
-
-Schreibe NUR die JSON-Datei nach: {out_path}
-
-Format (für JEDE Nummer genau eine Stufe; kein weiterer Text):
-{{"stufen": {{"1": "anfaenger", "2": "fortgeschritten", "3": "experte"}}}}
-{extra}

templates/Prompt/Subbaustein-Mapping.md

@@ -1,27 +0,0 @@
-Unten je Baustein des Themas "{topic}" die gefundenen Subbausteine. Gib je Baustein die **bereinigte** finale Liste zurück.
-
-{source}
-
-GEFUNDENE SUBBAUSTEINE (je Baustein zwei Gruppen):
-{bausteine}
-
-Die Gruppen:
-- **Konsens (≥2 Finder):** mehrfach unabhängig gefunden — standardmäßig behalten. Nur Erfundenes/Dubletten raus.
-- **Unsicher (1×):** nur von einem Finder genannt — **streng prüfen**. Nimm einen Unsicher-Eintrag NUR auf, wenn er **klar in der Quelle belegt UND ein eigenständiger Punkt** ist. Im Zweifel weglassen.
-
-Regeln:
-- **Beleg-Prüfung (wichtig):** Prüfe jeden Subbaustein gegen die Quelle. **Verwirf, was im Material NICHT belegbar oder klar erfunden ist** — erfundene Schranken, Formeln, Werte oder Behauptungen, die so nicht in der Quelle stehen. Mit Quelldatei: gegen die Datei prüfen. Ohne Quelle (reines Thema): nur gesichertes Standardwissen behalten, Zweifelhaftes/Falsches streichen.
-- **Dubletten zusammenführen:** Subbausteine, die denselben Punkt mit anderen Worten sagen, sind EINER. Behalte den klarsten, streiche die Umformulierungen. (z.B. „Broadcast Mode verfügbar" und „Broadcast-Modus aktivieren" → einer.)
-- Behalte alle fachlich **DISTINKTEN** und belegbaren Teilpunkte vollständig — nichts Wesentliches weglassen.
-- Verwirf, was zu fein granular, am Rand des Themas oder fachlich zweifelhaft ist.
-- Jeder Punkt atomar (eine Aussage). Behaltene Punkte WÖRTLICH übernehmen, nicht umformulieren, nichts erfinden.
-- Die Anzahl folgt der Schwierigkeit: lieber wenige distinkte als viele redundante Punkte.
-
-Schreibe NUR die Datei {out_path} — pro Baustein ein baustein-Marker (Titel EXAKT wie oben), darunter die finale Subbaustein-Liste:
-
-<!-- baustein: Exakter Baustein-Titel -->
-- Subbaustein
-- Subbaustein
-
-Die Marker-Zeile exakt so schreiben. Jeder Baustein muss vorkommen. Kein Text außerhalb der Bausteine.
-{extra}

templates/Prompt/Subbaustein-Recherche.md

@@ -1,29 +0,0 @@
-Zerlege jeden zugeteilten Baustein des Themas "{topic}" in seine SUBBAUSTEINE — die einzelnen lernbaren Teilpunkte, aus denen das Konzept besteht. Ein späterer Guide wird PRO Subbaustein einen kurzen Text schreiben.
-
-Dir zugeteilt — verbindlich: jeder Baustein muss vorkommen, keine zusätzlichen erfinden:
-{zuteilung}
-
-Was ein Subbaustein ist:
-- Ein einzelner Teilpunkt, den man am Baustein lernen muss. Eine Aussage, ein Aspekt, eine Tücke.
-- Beispiele: Baustein `<img>` → `src` (Bildquelle), `alt` (Alternativtext), leeres `alt` für Deko-Bilder, `width`/`height` gegen Layout-Sprünge, Void-Element ohne Endtag. Baustein `<p>` → Textabsatz als Block, erlaubte Inline-Kinder, keine Verschachtelung.
-
-ENTSCHEIDEND — die Anzahl folgt der Schwierigkeit:
-- Ein einfacher, trivialer Baustein hat WENIGE Subbausteine (1–2). Blähe ihn NICHT auf.
-- Ein komplexer, reichhaltiger Baustein hat VIELE Subbausteine. Lass nichts Wesentliches weg.
-- Es gibt KEINE Zielzahl. `<img>` muss deutlich mehr Subbausteine haben als `<p>`.
-
-Regeln:
-- Jeder Subbaustein ist atomar: genau ein Teilpunkt. Keine zwei Aspekte in einen Punkt.
-- Nur was DIESER Baustein hergibt (Scope). Nichts am Rand Erwähntes aufblasen.
-- Belegt, nicht erfunden. Unsicheres per Websuche prüfen.
-- Subbaustein-Titel auf DEUTSCH (Code-Bezeichner bleiben original), max. ~10 Wörter, eine Aussage.
-
-Schreibe NUR die Datei {out_path} — pro Baustein ein baustein-Marker (Titel EXAKT aus der Zuteilung), darunter die Subbausteine als Liste:
-
-<!-- baustein: Exakter Baustein-Titel -->
-- Erster Subbaustein
-- Zweiter Subbaustein
-
-Die Marker-Zeile exakt so schreiben. Kein Text außerhalb der Bausteine.
-{bekannt}
-{extra}