Prompts: Bausteine-Granularität und OnePager domänen-adaptiv

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
team3
2026-06-12 07:50:16 +02:00
parent fb5fc7bff9
commit d97ec48bf1
9 changed files with 22 additions and 20 deletions

View File

@@ -7,7 +7,7 @@ KONSOLIDIERTE LISTE:
{auswahl}
Prüfe genau zwei Dinge:
1. FEHLT ein Konzept, das in den Recherchen vorkommt, aber in der konsolidierten Liste nicht enthalten ist — auch nicht unter anderem Titel oder in einem Sammeleintrag?
1. FEHLT ein Konzept, das in den Recherchen vorkommt, aber in der konsolidierten Liste nicht enthalten ist — auch nicht unter anderem Titel oder in einem Sammeleintrag? Die Zusammenfassung mehrerer Mikro-Einträge zu einer Lerneinheit ist KEIN Verlust — fehlend ist ein Konzept nur, wenn es nirgends, auch nicht innerhalb eines zusammengefassten Bausteins, enthalten ist.
2. Beschreiben mehrere Einträge der Liste DASSELBE Konzept? Der beste bleibt, die übrigen werden gestrichen.
Schreibe NUR die JSON-Datei nach: {out_path}

View File

@@ -4,9 +4,10 @@ Drei Recherche-Agenten haben unabhängig voneinander die Bausteine des Themas "{
Regeln:
- Vereinige die Listen: erkenne gleiche Konzepte unter verschiedenen Titeln und führe sie zu einem Baustein zusammen.
- 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; falsch: je ein Eintrag pro input-Typ, aber auch Sammeleinträge, die mehrere Probleme mischen).
- 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.
- Verwirf Bausteine ohne Quelle oder die erfunden wirken. Behalte im Zweifel, was mindestens eine Recherche belegt.
- 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.
- Verwirf Bausteine, die erfunden wirken. Eine fehlende Quelle allein ist kein Streichgrund, wenn mindestens zwei Recherchen den Baustein unabhängig nennen. Behalte im Zweifel, was mindestens eine Recherche belegt.
- KEINE Kategorien, KEINE Bewertung — eine flache, durchnummerierte Liste.
- Lass die Quellen weg. Titel und Kurzbeschreibung (max. ~12 Wörter) auf DEUTSCH (Code-Bezeichner bleiben original). Jeder Titel muss EINDEUTIG sein.

View File

@@ -1 +1 @@
Recherchiere per Websuche und gehe systematisch vor: arbeite die Struktur der offiziellen Dokumentation ab (Handbuch-Kapitel, Feature-Übersichten, Release Notes der letzten Versionen) und erfasse jeden Baustein, dem ein Anwender begegnen kann — von Grundlagen bis Spezialfälle. Achte darauf, dass Versionsangaben und Fakten aktuell sind.
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.

View File

@@ -1,13 +1,14 @@
Ermittle ALLE Bausteine (Konzepte/Funktionen/Features) des Themas "{topic}" für einen Lern-Guide.
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; falsch: 21 Einträge für jeden input-Typ, aber auch Sammeleinträge, die mehrere Probleme mischen).
- 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.
- 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).
- 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.

View File

@@ -4,19 +4,19 @@ FAKTENBASIS (alleinige Quelle, nichts hinzuerfinden):
{recherche}
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).
- "info" — Titel: "{topic}". Kurzbeschreibung in 12 Sätzen, darunter Eckdaten als Stichpunkte (je nach Thema: Art/Typ, Version/Lizenz/Verbreitung ODER Ursprung/Stand/Anwendungsfelder).
- "eigenschaften" — Titel: "Kerneigenschaften". Was einen IM Thema erwartet: kleine Übersicht der Inhalte/Teilgebiete.
- "beispiel" — Titel: "Beispiel". EIN anschauliches, typisches Codebeispiel (Markdown-Codeblock) mit einem Satz Erklärung.
- "beispiel" — Titel: "Beispiel". EIN anschauliches, typisches Beispiel mit einem Satz Erklärung — Markdown-Codeblock bei Code-Themen, sonst Beispielsätze oder Mini-Szenario als normaler Text.
- "zusammenhaenge" — Titel: "Zusammenhänge". Mit welchen ANDEREN Themen es zusammenhängt — Nachbarthemen außerhalb dieses Themas, keine Inhalte des Themas selbst.
- "voraussetzungen" — Titel: "Voraussetzungen". Welche Themen man vorher bearbeitet haben sollte, um hier klarzukommen.
- "modern" — Titel: "Moderne Features". NUR was in den letzten Jahren neu dazugekommen ist. Gibt es nichts Neues: ehrlich "Keine." mit einem Satz Begründung.
- "veraltet" — Titel: "Veraltete Features". Was nicht mehr verwendet wird. Gibt es nichts Veraltetes: ehrlich "Keine." mit einem Satz Begründung — nichts erfinden.
- "modern" — Titel: "Neu & aktuell". NUR was in den letzten Jahren neu dazugekommen ist (Features, Erkenntnisse, Empfehlungen). Gibt es nichts Neues: ehrlich "Keine." mit einem Satz Begründung.
- "veraltet" — Titel: "Veraltet & überholt". Was nicht mehr verwendet wird bzw. als überholt gilt. Gibt es nichts Veraltetes: ehrlich "Keine." mit einem Satz Begründung — nichts erfinden.
KOMPAKTHEIT — der OnePager muss OHNE Scrollen auf eine Bildschirmseite passen:
- Maximal 5 Stichpunkte pro Karte, je maximal ~8 Wörter (Schlagwort + halber Satz).
- Nur das Wichtigste — nicht alle Varianten aufzählen. Weglassen schlägt Vollständigkeit.
- Keine Tabellen, keine verschachtelten Listen, keine Einleitungssätze.
- Codebeispiel maximal ~12 kurze Zeilen.
- Beispiel maximal ~12 kurze Zeilen (Code) bzw. ~5 Zeilen (Prosa).
Inhalt auf DEUTSCH, alles aus der Faktenbasis belegbar.
Stichpunkte als Markdown-Liste mit fettem Schlagwort: `- **Schlagwort**: Rest` (kein rohes •).
@@ -25,5 +25,5 @@ Code-Bezeichner und HTML-Tags im Text IMMER in Backticks (`<p>`, `src`) — nie
Schreibe NUR die JSON-Datei nach: {out_path}
Format:
{{"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": "…"}}}}}}
{{"karten": {{"info": {{"titel": "{topic}", "md": "…"}}, "eigenschaften": {{"titel": "Kerneigenschaften", "md": "…"}}, "beispiel": {{"titel": "Beispiel", "md": "…"}}, "zusammenhaenge": {{"titel": "Zusammenhänge", "md": "…"}}, "voraussetzungen": {{"titel": "Voraussetzungen", "md": "…"}}, "modern": {{"titel": "Neu & aktuell", "md": "…"}}, "veraltet": {{"titel": "Veraltet & überholt", "md": "…"}}}}}}
{extra}

View File

@@ -1 +1 @@
Recherchiere per Websuche: aktuelle Version, die Kernkonzepte und die wichtigsten Fakten zu "{topic}". Nimm nur auf, was du in der Recherche belegt hast.
Recherchiere per Websuche: aktuellen Stand (Version bzw. Forschungs-/Praxisstand), die Kernkonzepte und die wichtigsten Fakten zu "{topic}". Nimm nur auf, was du in der Recherche belegt hast.

View File

@@ -5,15 +5,15 @@ FAKTENBASIS:
Sie muss diese Dimensionen abdecken:
1. Kurzbeschreibung (12 Sätze)
2. Technische Daten (Art/Typ, Version/Stand, Lizenz/Kosten)
2. Eckdaten (Art/Typ; bei Software: Version, Lizenz/Kosten; bei Sprachen, Methoden, Theorien: Ursprung/Urheber, heutiger Stand, Anwendungsfelder)
3. Inhaltsübersicht (was einen im Thema erwartet)
4. Ein typisches Beispiel
4. Ein typisches Beispiel im themengerechten Format (Code, Beispielsätze oder Mini-Szenario)
5. Zusammenhänge mit ANDEREN Themen (Nachbarthemen, nicht Inhalte des Themas selbst)
6. Voraussetzungen (vorher zu bearbeitende Themen)
7. Neuerungen der letzten Jahre vs. nicht mehr Verwendetes (oder die ausdrückliche Feststellung, dass es jeweils nichts gibt)
Prüfe:
1. Ist jede Dimension mit konkreten Fakten belegt (Namen, Versionen, Zahlen — nicht vage)?
1. Ist jede Dimension mit konkreten Fakten belegt (Namen, Zahlen, Versionen bzw. Urheber/Jahreszahlen — nicht vage)?
2. Hat jeder Punkt eine Quelle?
3. Wirkt etwas erfunden oder widersprüchlich?

View File

@@ -4,9 +4,9 @@ Sammle die Faktenbasis für einen OnePager — ein Übersichtsblatt auf einer Se
Recherchiere gezielt diese Dimensionen:
1. Kurzbeschreibung: Was ist "{topic}" in 12 Sätzen?
2. Technische Daten: Art/Typ, aktuelle Version/Stand, Lizenz/Kosten, Verbreitung.
2. Eckdaten: Art/Typ des Themas; bei Software: aktuelle Version, Lizenz/Kosten, Verbreitung; bei Sprachen, Methoden, Theorien: Ursprung/Urheber, heutiger Stand, typische Anwendungsfelder.
3. Inhaltsübersicht: Was erwartet einen im Thema — die wichtigsten Inhalte/Teilgebiete.
4. Beispiel: ein minimales, typisches Code-/Anwendungsbeispiel.
4. Beispiel: ein minimales, typisches Beispiel im themengerechten Format (Code-Beispiel, Beispielsätze/Mini-Dialog oder Mini-Szenario).
5. Zusammenhänge: mit welchen ANDEREN Themen es zusammenhängt (Nachbarthemen außerhalb von "{topic}").
6. Voraussetzungen: welche Themen man vorher bearbeitet haben sollte.
7. Neuerungen vs. Veraltetes: was in den letzten Jahren neu dazugekommen ist — und was nicht mehr verwendet wird (falls es nichts gibt, jeweils ausdrücklich notieren).

View File

@@ -10,7 +10,7 @@ Prüfe:
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. Ist jede Karte KOMPAKT — maximal 5 kurze Stichpunkte (je ~8 Wörter), keine Tabellen, Beispiel maximal ~12 Zeilen? Zu lange Karten sind ein Problem.
4. Ist jede Karte für sich verständlich? Ist das Beispiel ein lauffähig plausibler Codeblock?
4. Ist jede Karte für sich verständlich? Ist das Beispiel konkret und plausibel — lauffähig wirkender Code bzw. realistische Sätze/realistisches Szenario?
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).