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": []}}
