update

templates/Prompt/Blocks-Supplement-Beleg.md

@@ -0,0 +1,14 @@
+You are the material gate for supplement proposals on the topic "{topic}". A research agent proposed blocks that canonically belong to the subject — but the inventory must ONLY contain what the LEARNING MATERIAL itself covers. Decide per proposal: do the excerpts show the material actually TREATS this block → **ja**, or does the material never treat it → **nein**?
+
+PROPOSALS (each with its best-matching material excerpts):
+{proposals}
+
+Rules:
+- **ja** requires real coverage: a heading, definition, algorithm, proof or exercise about the proposal's subject.
+- Passing mentions, shared vocabulary or generic words (e.g. „Algorithmus" appears everywhere) are NOT coverage → **nein**.
+- When in doubt → **nein**. The inventory already covers the material — supplements are a bonus, scope creep is not.
+
+Reply with ONLY the JSON — no other text, no code fences.
+Format (one verdict per number):
+{{"relevant": {{"1": "ja", "2": "nein"}}}}
+{extra}

templates/Prompt/Blocks-Supplement.md

@@ -7,6 +7,7 @@ EXISTING BLOCKS:
 
 Rules:
 - Research the subject area (textbooks, standard references) and add ONLY blocks that canonically belong and are missing from the inventory.
+- The inventory mirrors a CONCRETE source (script/project). Propose only gaps the MATERIAL itself covers — no textbook canon beyond the source. Proposals without material coverage are discarded downstream.
 - 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.

templates/Prompt/Element-Chat.md

@@ -1,29 +0,0 @@
-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.
-
-CURRENT ELEMENT (JSON):
-{element_json}
-
-CHAT TRANSCRIPT SO FAR:
-{transcript}
-
-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>`."
-
-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.
-
-Each proposal:
-- text: short, what is changed (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 and for "add")
-- content: the new complete content (empty for "remove")
-
-"remove" only for examples/hints. Only make proposals that the user instruction calls for.
-
-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": "..."}}]}}
-
-A pure question with no change request → answer it in reply, "changes": []

templates/Prompt/Element-Check.md

@@ -1,19 +0,0 @@
-You research what information might still be missing from a learning element of a personal summary on the topic "{topic}".
-
-CURRENT ELEMENT (JSON):
-{element_json}
-
-CONTEXT (excerpts from the topic material):
-{context}
-
-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.
-
-Each candidate:
-- text: a short description of the gap (max. 12 words, plain text)
-- target: "description" | "examples" | "hints"
-- 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.
-
-Write the candidate fields (`text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
-{{"suggestions": [{{"text": "...", "target": "hints", "content": "..."}}]}}
-
-No candidates → {{"suggestions": []}}

templates/Prompt/Element-Create.md

@@ -1,32 +0,0 @@
-You create a short learning element for a personal summary on the topic "{topic}".
-
-KEYWORD FROM THE USER:
-{hint}
-
-CONTEXT (excerpts from the topic material):
-{context}
-
-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.)
-
-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:**).
-
-The element is ATOMIC: understandable on its own, without the reader having read anything else. Resolve any terms used in a half-sentence.
-
-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.
-
-Tone: clear German, direct, practical. Explain technical terms briefly on first use. No filler sentences, no introductory clichés.
-
-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.
-
-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 +0,0 @@
-You revise EXACTLY ONE change proposal for a learning element on the topic "{topic}", following a user instruction.
-
-CURRENT ELEMENT (JSON):
-{element_json}
-
-CURRENT PROPOSAL (JSON):
-{suggestion_json}
-
-USER INSTRUCTION:
-{instruction}
-
-Adjust the proposal per the instruction. Keep action/target/index, unless the instruction requires otherwise.
-
-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.
-
-Fields:
-- text: short, what is changed (max. 12 words, plain text)
-- action: "remove" | "adjust" | "add"
-- target: "title" | "description" | "examples" | "hints"
-- index: 0-based position in the examples/hints array (otherwise null)
-- content: the new complete content (empty for "remove")
-
-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-Style.md

@@ -1,37 +0,0 @@
-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 +0,0 @@
-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.
-
-CURRENT ELEMENT (JSON):
-{element_json}
-
-CANDIDATES (JSON):
-{candidates_json}
-
-CONTEXT (excerpts from the topic material):
-{context}
-
-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.
-
-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).
-
-Write the candidate fields (`text`, `content`) in GERMAN. Output ONLY valid JSON, no code fence, no other text:
-{{"suggestions": [{{"text": "...", "target": "hints", "content": "..."}}]}}
-
-No candidate passes → {{"suggestions": []}}