This commit is contained in:
Team3
2026-06-07 09:00:20 +02:00
parent fce82fbd16
commit 8d6d1bf089
22 changed files with 876 additions and 274 deletions

View File

@@ -0,0 +1,24 @@
Prüfe die Baustein-Auswahl für einen Lern-Guide zum Thema "{topic}" (Format: {format_name}).
Der Auftrag an die Auswahl war: {auswahl_auftrag}
INVENTAR (alle verfügbaren Bausteine):
{bausteine}
GETROFFENE AUSWAHL:
{auswahl}
Prüfe:
1. Fehlt etwas, das der Leser für diesen Zweck zwingend braucht?
2. Ist etwas drin, das dem Zweck nicht dient — Interna, Nischenfälle, Doppelungen (mehrere Lösungen fürs selbe Problem)?
3. Passt der Umfang zum Auftrag?
Du PRÜFST nur und notierst Probleme — du änderst die Auswahl nicht.
Schreibe NUR die JSON-Datei nach: {out_path}
Format — Auswahl in Ordnung:
{{"ok": true}}
Sonst (kurz und konkret, maximal 10 Punkte, Baustein-Titel exakt nennen):
{{"probleme": ["…", "…"]}}
{extra}

View File

@@ -0,0 +1,21 @@
Korrigiere die Baustein-Auswahl für einen Lern-Guide zum Thema "{topic}" (Format: {format_name}).
Der Auftrag an die Auswahl war: {auswahl_auftrag}
INVENTAR (alle verfügbaren Bausteine):
{bausteine}
BISHERIGE AUSWAHL:
{auswahl}
NOTIERTE PROBLEME (von der Prüfung):
{probleme}
Behebe NUR die notierten Probleme — alles andere bleibt unverändert.
Verwende die Titel EXAKT so, wie sie im Inventar stehen. Keine neuen erfinden.
Schreibe NUR die vollständige, korrigierte JSON-Datei nach: {out_path}
Format:
{{"bausteine": ["Exakter Titel", "Exakter Titel"]}}
{extra}

View File

@@ -0,0 +1,18 @@
Wähle die Bausteine für einen Lern-Guide zum Thema "{topic}" (Format: {format_name}).
BAUSTEINE (unsortiertes Inventar):
{bausteine}
{auswahl_auftrag}
Denke vom Ziel her: Was soll der Leser am Ende KÖNNEN?
- Wähle, was der Leser dafür praktisch braucht und wirklich benutzt.
- Lass weg: Interna (was das Werkzeug intern tut, ohne dass man es anfasst), Spezialfälle und Alternativen zum selben Problem — ein Weg reicht.
- "Klingt fundamental" ist kein Kriterium. Frage stattdessen: Fasst der Leser das selbst an?
- Verwende die Titel EXAKT so, wie sie in der Liste stehen. Keine neuen erfinden.
Schreibe NUR die JSON-Datei nach: {out_path}
Format:
{{"bausteine": ["Exakter Titel", "Exakter Titel"]}}
{extra}

View File

@@ -0,0 +1,24 @@
Prüfe die Gliederung eines Lern-Guides zum Thema "{topic}" (Format: {format_name}).
Zielgruppe: Anfänger. Zweck: {zweck}.
GEWÄHLTE BAUSTEINE (müssen alle vorkommen):
{auswahl}
GLIEDERUNG:
{gliederung}
Prüfe:
1. Kommt jeder gewählte Baustein in GENAU einem Kapitel vor (nichts fehlt, nichts doppelt, nichts erfunden)?
2. Führt Kapitel 1 zum schnellsten sichtbaren Ergebnis — oder beginnt es mit Theorie/Interna?
3. Stehen Voraussetzungen vor dem, was auf ihnen aufbaut? Konkretes vor Abstraktem?
4. Kapitelgrößen 37, Kapiteltitel kurz und konkret?
Du PRÜFST nur und notierst Probleme — du änderst die Gliederung nicht.
Schreibe NUR die JSON-Datei nach: {out_path}
Format — Gliederung in Ordnung:
{{"ok": true}}
Sonst (kurz und konkret, maximal 10 Punkte):
{{"probleme": ["…", "…"]}}
{extra}

View File

@@ -0,0 +1,20 @@
Korrigiere die Gliederung eines Lern-Guides zum Thema "{topic}" (Format: {format_name}).
GEWÄHLTE BAUSTEINE (müssen alle vorkommen):
{auswahl}
BISHERIGE GLIEDERUNG:
{gliederung}
NOTIERTE PROBLEME (von der Prüfung):
{probleme}
Behebe NUR die notierten Probleme — alles andere bleibt unverändert.
- JEDER gewählte Baustein landet in GENAU einem Kapitel.
- Verwende die Titel EXAKT so, wie sie in der Liste stehen.
Schreibe NUR die vollständige, korrigierte JSON-Datei nach: {out_path}
Format:
{{"kapitel": [{{"titel": "Grundlagen", "bausteine": ["Exakter Titel", "Exakter Titel"]}}]}}
{extra}

View File

@@ -1,22 +1,15 @@
Plane die Gliederung eines Lern-Guides zum Thema "{topic}" (Format: {format_name}).
BAUSTEINE (unsortiertes Inventar):
GEWÄHLTE BAUSTEINE (unsortiert — die Auswahl steht fest, du ordnest nur):
{bausteine}
{auswahl_auftrag}
AUSWAHL — denke vom Ziel her: Was soll der Leser am Ende KÖNNEN?
- Wähle, was der Leser dafür praktisch braucht und wirklich benutzt.
- Lass weg: Interna (was das Werkzeug intern tut, ohne dass man es anfasst), Spezialfälle und Alternativen zum selben Problem — ein Weg reicht.
- "Klingt fundamental" ist kein Kriterium. Frage stattdessen: Fasst der Leser das selbst an?
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. Keine neuen erfinden.
- JEDER gewählte Baustein landet in GENAU einem Kapitel. Keinen weglassen, keine neuen erfinden.
- Verwende die Titel EXAKT so, wie sie in der Liste stehen.
- 37 Bausteine pro Kapitel; die Kapitelzahl folgt aus dem Thema.
- Kapiteltitel kurz und konkret.

View File

@@ -0,0 +1,23 @@
Prüfe geschriebene Sections eines Lern-Guides zum Thema "{topic}" (Format: {format_name}) auf Lesbarkeit.
Zielgruppe: Anfänger.
SECTION-SPEZIFIKATION (Soll-Zustand):
{spec}
SECTIONS:
{sections}
Prüfe jede Section:
1. Ist die Beschreibung für Anfänger verständlich und maximal 12 Sätze?
2. Sind die Beispiele kurz, simpel und plausibel korrekt?
3. Ist das Markdown sauber (keine abgebrochenen Code-Blöcke, keine Platzhalter, kein Fremdtext)?
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 (Section-Titel EXAKT wie oben):
{{"probleme": [{{"section": "Exakter Section-Titel", "problem": "…"}}]}}
{extra}

View File

@@ -0,0 +1,24 @@
Überarbeite einzelne Sections eines Lern-Guides zum Thema "{topic}" (Format: {format_name}).
{facts}
SECTION-SPEZIFIKATION:
{spec}
ZU ÜBERARBEITEN — je Section der aktuelle Inhalt und das notierte Problem:
{auftraege}
Behebe pro Section NUR das notierte Problem; was in Ordnung ist, bleibt inhaltlich erhalten.
Schreibe NUR die Datei {out_path} in GENAU diesem Format — für JEDE beanstandete Section ein section-Marker (Titel EXAKT wie oben), darunter der vollständige neue Markdown-Body:
<!-- section: Exakter Section-Titel -->
Beschreibung…
### Beispiel
```sprache
```
Die Marker-Zeilen exakt so schreiben. Kein Text außerhalb der Sections.
{extra}

View File

@@ -1,21 +1,21 @@
Baue aus der Faktenbasis einen OnePager zum Thema "{topic}" — ein Einordnungs- und Entscheidungsdokument auf einer Seite. Danach muss der Leser verstehen, was das Thema ist, wo es hingehört und ob es das ist, was er sucht.
Baue aus der Faktenbasis einen OnePager zum Thema "{topic}" — ein Übersichtsblatt im 3×3-Raster auf einer Seite.
FAKTENBASIS (alleinige Quelle, nichts hinzuerfinden):
{recherche}
Erstelle GENAU diese 7 Karten (Titel exakt so):
1. "Was ist {topic}?" — Definition in 12 Sätzen
2. "Welches Problem löst es?" — der Schmerzpunkt, für den es gebaut wurde
3. "Wann nehmen — wann nicht?" — konkrete Entscheidungshilfe in 24 Stichpunkten
4. "Einordnung & Alternativen" — die wichtigsten Nachbarn und der Unterschied
5. "So sieht es aus" — EIN minimales, typisches Codebeispiel (Markdown-Codeblock)
6. "Fakten" — Version, Reife, Lizenz/Kosten, Verbreitung
7. "Erste Schritte" — wie man anfängt, in 12 Zeilen
Erstelle GENAU diese 7 Karten (JSON-Schlüssel exakt so):
- "info" — Titel: "{topic}". Kurzbeschreibung in 12 Sätzen, darunter technische Daten als Stichpunkte (Art/Typ, Version/Stand, Lizenz/Kosten).
- "eigenschaften" — Titel: "Kerneigenschaften". Die 47 prägenden Eigenschaften des Systems als Stichpunkte.
- "beispiel" — Titel: "Beispiel". EIN anschauliches, typisches Codebeispiel (Markdown-Codeblock) mit einem Satz Erklärung.
- "zusammenhaenge" — Titel: "Zusammenhänge". Mit welchen Systemen/Themen es zusammenhängt — Stichpunkte mit je einem halben Satz.
- "voraussetzungen" — Titel: "Voraussetzungen". Was man vorher können oder haben muss.
- "modern" — Titel: "Moderne Features". Was aktuell ist und heute verwendet wird.
- "veraltet" — Titel: "Veraltete Features". Was es noch gibt, aber nicht mehr verwendet werden sollte. Gibt es nichts Veraltetes: ehrlich "Keine." mit einem Satz Begründung — nichts erfinden.
Inhalt pro Karte kompakt (14 Sätze bzw. Stichpunkte, Markdown erlaubt), auf DEUTSCH, alles aus der Faktenbasis belegbar.
Inhalt pro Karte kompakt (Markdown erlaubt), auf DEUTSCH, alles aus der Faktenbasis belegbar.
Schreibe NUR die JSON-Datei nach: {out_path}
Format:
{{"karten": [{{"titel": "Was ist {topic}?", "merksatz": "…"}}]}}
{extra}
{{"karten": {{"info": {{"titel": "{topic}", "md": "…"}}, "eigenschaften": {{"titel": "Kerneigenschaften", "md": "…"}}, "beispiel": {{"titel": "Beispiel", "md": "…"}}, "zusammenhaenge": {{"titel": "Zusammenhänge", "md": "…"}}, "voraussetzungen": {{"titel": "Voraussetzungen", "md": "…"}}, "modern": {{"titel": "Moderne Features", "md": "…"}}, "veraltet": {{"titel": "Veraltete Features", "md": "…"}}}}}}
{extra}

View File

@@ -0,0 +1,18 @@
Korrigiere die Karten eines OnePagers zum Thema "{topic}".
FAKTENBASIS (alleinige Quelle, nichts hinzuerfinden):
{recherche}
BISHERIGE KARTEN:
{karten}
NOTIERTE PROBLEME (von der Prüfung):
{probleme}
Behebe NUR die notierten Probleme — alle anderen Karten bleiben unverändert.
Schreibe NUR die vollständige, korrigierte JSON-Datei (alle 7 Karten) nach: {out_path}
Format:
{{"karten": {{"info": {{"titel": "…", "md": "…"}}, "eigenschaften": {{"titel": "…", "md": "…"}}, "beispiel": {{"titel": "…", "md": "…"}}, "zusammenhaenge": {{"titel": "…", "md": "…"}}, "voraussetzungen": {{"titel": "…", "md": "…"}}, "modern": {{"titel": "…", "md": "…"}}, "veraltet": {{"titel": "…", "md": "…"}}}}}}
{extra}

View File

@@ -0,0 +1,27 @@
Prüfe die Faktenbasis für einen OnePager zum Thema "{topic}".
FAKTENBASIS:
{recherche}
Sie muss diese Dimensionen abdecken:
1. Kurzbeschreibung (12 Sätze)
2. Technische Daten (Art/Typ, Version/Stand, Lizenz/Kosten)
3. Kerneigenschaften des Systems
4. Ein typisches Beispiel
5. Zusammenhänge mit anderen Systemen/Themen
6. Voraussetzungen
7. Moderne vs. veraltete Features (oder die ausdrückliche Feststellung, dass nichts veraltet ist)
Prüfe:
1. Ist jede Dimension mit konkreten Fakten belegt (Namen, Versionen, Zahlen — nicht vage)?
2. Hat jeder Punkt eine Quelle?
3. Wirkt etwas erfunden oder widersprüchlich?
Du PRÜFST nur und notierst Probleme — du änderst nichts.
Schreibe NUR die JSON-Datei nach: {out_path}
Format — alles in Ordnung:
{{"ok": true}}
Sonst (kurz und konkret, maximal 10 Punkte):
{{"probleme": ["…", "…"]}}

View File

@@ -0,0 +1,16 @@
Überarbeite die Faktenbasis für einen OnePager zum Thema "{topic}".
{source}
BISHERIGE FAKTENBASIS:
{recherche}
NOTIERTE PROBLEME (von der Prüfung):
{probleme}
Behebe NUR die notierten Probleme — fehlende Dimensionen nachrecherchieren, Vages konkretisieren, Unbelegtes belegen oder streichen. Alles andere bleibt erhalten.
Schreibe die VOLLSTÄNDIGE, überarbeitete Markdown-Datei nach: {out_path}
Kompakt, faktenorientiert, mit Quelle pro Punkt.
{extra}

View File

@@ -1,15 +1,15 @@
Sammle die Faktenbasis für einen OnePager — ein Einordnungs- und Entscheidungsdokument — zum Projekt "{topic}".
Sammle die Faktenbasis für einen OnePager — ein Übersichtsblatt auf einer Seite — zum Projekt "{topic}".
{source}
Erfasse gezielt diese Dimensionen:
1. Definition: Was ist "{topic}" in 12 Sätzen (Art des Projekts, Gegenstand)?
2. Problem: Welches Problem löst es, für wen ist es gedacht?
3. Abgrenzung: Was deckt das Projekt ab, was ausdrücklich nicht?
4. Einordnung: In welchem Kontext steht es (Umfeld, Abhängigkeiten, angrenzende Systeme/Themen)?
5. Anschauung: Ein typisches, konkretes Beispiel aus dem Projekt (zentraler Code-Flow bzw. Kerninhalt).
6. Fakten: Technologie/Format, Umfang (Dateien/Seiten/Module), Stand/Aktualität.
7. Einstieg: Wo fängt man an — wie startet man es bzw. was liest man zuerst?
1. Kurzbeschreibung: Was ist "{topic}" in 12 Sätzen (Art des Projekts, Gegenstand)?
2. Technische Daten: Technologie/Format, Umfang (Dateien/Seiten/Module), Stand/Aktualität.
3. Kerneigenschaften: die prägenden Konzepte, Komponenten oder Inhalte des Projekts.
4. Beispiel: ein typisches, konkretes Beispiel aus dem Projekt (zentraler Code-Flow bzw. Kerninhalt).
5. Zusammenhänge: in welchem Umfeld es steht (Abhängigkeiten, angrenzende Systeme/Themen).
6. Voraussetzungen: was man können oder haben muss, um es zu nutzen bzw. zu verstehen.
7. Moderne vs. veraltete Teile: was aktueller Stand ist — und was als Altlast gilt (falls nichts veraltet ist, ausdrücklich notieren).
Schreibe NUR die Markdown-Datei nach: {out_path}

View File

@@ -1,17 +1,17 @@
Sammle die Faktenbasis für einen OnePager — ein Einordnungs- und Entscheidungsdokument — zum Thema "{topic}".
Sammle die Faktenbasis für einen OnePager — ein Übersichtsblatt auf einer Seite — zum Thema "{topic}".
{source}
Recherchiere gezielt diese Dimensionen:
1. Definition: Was ist "{topic}" in 12 Sätzen?
2. Problem: Welches Problem löst es, wer braucht es?
3. Abgrenzung: Wofür ist es geeignet, wofür ausdrücklich nicht?
4. Einordnung: Die wichtigsten Alternativen/Nachbarn und wie sich "{topic}" davon unterscheidet.
5. Anschauung: Ein minimales, typisches Code-/Anwendungsbeispiel.
6. Fakten: Aktuelle Version, Reife/Alter, Lizenz/Kosten, Verbreitung.
7. Einstieg: Wie fängt man an (Installation/erster Schritt)?
1. Kurzbeschreibung: Was ist "{topic}" in 12 Sätzen?
2. Technische Daten: Art/Typ, aktuelle Version/Stand, Lizenz/Kosten, Verbreitung.
3. Kerneigenschaften: die prägenden Eigenschaften und Merkmale des Systems.
4. Beispiel: ein minimales, typisches Code-/Anwendungsbeispiel.
5. Zusammenhänge: mit welchen Systemen/Themen es zusammenhängt (Ökosystem, Nachbarn, typische Kombinationen).
6. Voraussetzungen: was man vorher können oder haben muss.
7. Moderne vs. veraltete Features: was heute verwendet wird — und was es noch gibt, aber nicht mehr verwendet werden sollte (falls nichts veraltet ist, ausdrücklich notieren).
Schreibe NUR die Markdown-Datei nach: {out_path}
Kompakt, faktenorientiert, mit Quelle (URL bzw. Dateipfad) pro Punkt. Die Datei ist die alleinige Faktenbasis für den OnePager.
{extra}
{extra}

View File

@@ -1,4 +1,4 @@
Verifiziere einen OnePager zum Thema "{topic}" gegen seine Faktenbasis.
Prüfe einen OnePager zum Thema "{topic}" gegen seine Faktenbasis.
FAKTENBASIS:
{recherche}
@@ -7,13 +7,15 @@ ONEPAGER-KARTEN:
{karten}
Prüfe:
1. Sind alle 7 Pflicht-Karten vorhanden und vollständig ausgefüllt (keine abgebrochenen oder leeren Inhalte)? — "Was ist {topic}?", "Welches Problem löst es?", "Wann nehmen — wann nicht?", "Einordnung & Alternativen", "So sieht es aus", "Fakten", "Erste Schritte"
1. Sind alle 7 Karten vollständig ausgefüllt (keine abgebrochenen oder leeren Inhalte, keine Platzhalter)?
2. Stimmen alle Aussagen mit der Faktenbasis überein? Nichts Erfundenes?
3. Beantwortet der OnePager die Leserfrage „Ist das das, was ich suche?" — ist die Abgrenzung konkret genug?
3. Ist jede Karte kompakt und für sich verständlich? Ist das Beispiel ein lauffähig plausibler Codeblock?
Du PRÜFST nur und notierst Probleme — du änderst nichts. Nenne die betroffene Karte über ihren Schlüssel (info, eigenschaften, beispiel, zusammenhaenge, voraussetzungen, modern, veraltet).
Schreibe NUR die JSON-Datei nach: {out_path}
Format — alles in Ordnung:
{{"ok": true}}
Sonst die vollständige, korrigierte Karten-Liste:
{{"karten": [{{"titel": "…", "merksatz": "…"}}]}}
Sonst (kurz und konkret, maximal 10 Punkte):
{{"probleme": ["beispiel: …", "fakten in info veraltet: …"]}}