feat(i2s-problem-statement): extract from monolith

Step 5 of i2s-skill-split refactor. Second atomic sub-skill.

Contents:
- SKILL.md: 5 numbered phases (load context, 7 TAs, consistency,
  3 variants, export). description with explicit HMW/Problem-Statement
  triggers, anti-triggers naming klarheit-mit-idea2self (router),
  i2s-discovery, i2s-persona. Precondition check formalized.
- workflows/problem-statement.md: full workflow (git mv from monolith,
  rename detection preserved, required_reading paths updated to local
  curated refs).
- references/kommunikationsregeln.md: curated (PS-specific dialog
  heuristics: loesung-vs-problem, "alle als zielgruppe", widerspruch
  zu idee).
- references/problem-statement-format.md: curated extract from
  plugin-shared/export-formate.md, problem_statement_format block.
  Includes versions header rules and a filled example.
- references/artefakt-pipeline.md: curated (pipeline position +
  rueckwaerts-updates rules for PS -> ## Idee back-propagation).

Tools: Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoRead,
TodoWrite. (No WebFetch/WebSearch — recherche lives in i2s-recherche.)

skills/i2s-problem-statement/references/kommunikationsregeln.md

@@ -0,0 +1,48 @@
+# Kommunikationsregeln — i2s-problem-statement (curated extract)
+
+Curated from `plugin-shared/kommunikationsregeln.md`. PS-Workflow-relevante Regeln.
+
+<tonality>
+Nuechtern, sachlich, ruhig. Keine motivierenden Formulierungen, keine Emojis, keine Superlative. Alltagssprache statt Fachbegriffe. Sprache des Nutzers beibehalten. Kurze Saetze.
+</tonality>
+
+<message_format>
+- Max. 3-4 Saetze pro Nachricht im Dialog.
+- Fortschrittsanzeige: "[X] von 7" bei jeder TA-Frage.
+- Bei Varianten-Phase: 3 Bloecke (A/B/C) klar abgegrenzt zeigen.
+</message_format>
+
+<kennzeichnung>
+| Marker | Bedeutung |
+|--------|-----------|
+| _(Vorschlag)_ | KI-generiert, nicht bestaetigt — z.B. geschaerfte Variante B/C |
+| _(Annahme)_ | Vom Nutzer geaeussert ohne Datengrundlage |
+| _(Aus ## Idee uebernommen)_ | Import aus frueherer Sektion |
+</kennzeichnung>
+
+<steuerbefehle>
+| Befehl | Aktion |
+|--------|--------|
+| Zurueck | Vorheriger Teilaspekt |
+| Ich weiss es nicht | Plausibler Vorschlag, kein Drang |
+| Ueberspringen | TA als "Nicht erarbeitet" markieren |
+| Weiter | Naechster TA oder Phase |
+| Variante A/B/C | In Phase 4: Auswahl der Variante |
+</steuerbefehle>
+
+<dialog_heuristiken_problem_statement>
+- **Loesung statt Problem:** "Du beschreibst gerade eine Loesung ([X]). Welches Problem dahinter willst du loesen?"
+- **"Alle als Zielgruppe":** "Wer hat das Problem am DRINGENDSTEN? Welche Untergruppe leidet zuerst?"
+- **Zu abstrakt:** Konkretes Beispiel einfordern. "Erzaehl von einer konkreten Person, die das vergangene Woche erlebt hat."
+- **Beduerfnis aus Loesungs-Sicht formuliert:** "Was wuerde sich fuer die Zielgruppe konkret aendern, ohne dass du etwas vorgibst?"
+- **Widerspruch zu ## Idee:** explizit benennen. "In `## Idee` steht [A], jetzt sagst du [B]. Was gilt? Soll `## Idee` aktualisiert werden?"
+- **Perfektionismus / endlose Iteration:** Cut nach 1 Variante-Iteration. "Das ist v0.1. Wir koennen spaeter ueberarbeiten."
+</dialog_heuristiken_problem_statement>
+
+<export_rule>
+Phase 5 schreibt `## Problem-Statement` Sektion + Versions-Header + Changelog-Eintrag. Schema: `references/problem-statement-format.md`. Nicht behandelte TAs erscheinen als "Nicht erarbeitet". Vorschlaege als `_(Vorschlag)_` belassen, bis Nutzer bestaetigt.
+</export_rule>
+
+---
+
+**Master version:** `plugin-shared/kommunikationsregeln.md`. Drift-check via `plugin-shared/drift-check.sh`.