Files
creator/templates/Prompt/Element-Stil.md
team3 fb5fc7bff9 Prompts: Element-Familie domänen-adaptiv, _fence entfernt
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-12 07:48:22 +02:00

38 lines
3.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
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 12 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): 13 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 24 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": []}}