Files
creator/templates/Prompt/Element-Style.md
2026-06-30 00:14:18 +02:00

38 lines
3.4 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.
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 12 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): 13 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 24 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": []}}