agent-skills/skills/i2s-problem-statement/references/problem-statement-format.md

Problem-Statement-Format — i2s-problem-statement (curated extract)

Curated from plugin-shared/export-formate.md — <problem_statement_format> block.

Schema fuer ## Problem-Statement Sektion

## Problem-Statement

> **„Wie koennen wir [Kontext] fuer [Zielgruppe] neu gestalten, damit [Beduerfnis] befriedigt wird – unter Beruecksichtigung von [Einschraenkungen]."**

_Version [V1/V2/...] vom [Datum]_
_Vorgaengerversion: [V<n-1> vom <Datum>] / Keine - Neuerstellung_

### Kontext – Was wird neu gestaltet?
[Zusammenfassung aus TA1 (WAS), TA4 (WO), TA5 (WANN), TA6 (BISHERIGE ANSAETZE).]

### Zielgruppe – Fuer wen?
[Zusammenfassung aus TA2. Konkretes Segment, nicht "alle". Konkrete Anker-Person erlaubt.]

### Beduerfnis – Was soll erreicht werden?
[Zusammenfassung aus TA3. Aus Zielgruppen-Sicht formuliert, nicht aus Loesungs-Sicht.]

### Einschraenkungen – Was muss beruecksichtigt werden?
[Zusammenfassung aus TA4, TA5, TA6 — Constraints, Ressourcen, was bisherige Loesungen NICHT koennen.]

### Loesungsrichtung _(Hintergrund)_
[Zusammenfassung aus TA7. Wird als Hintergrund markiert, NICHT Teil des HMW-Statements.]

### Offene Punkte
- [ ] [Nur wenn geparkte Gedanken aus dem PS-Workflow vorhanden]

Schreibregeln

1. HMW-Satz als Markdown-Blockquote (>) — visuell hervorgehoben.
2. Versions-Header: V1 fuer Erstellung, V[n+1] fuer Iteration. Vorgaengerversion mit Datum referenzieren.
3. TAs mit "Nicht erarbeitet": Sub-Sektion bleibt mit dem Text Nicht erarbeitet (nicht weglassen).
4. Vorschlag-Marker: KI-Ergaenzungen (z.B. wenn TA-Antwort verdichtet wurde) mit _(Vorschlag)_.
5. Annahme-Marker: Nutzer-Aussagen ohne Datengrundlage mit _(Annahme)_.
6. Aus-Idee-Marker: Imports aus ## Idee mit _(Aus Idee uebernommen)_.
7. Loesungsrichtung: explizit als _(Hintergrund)_ markieren, damit klar ist dass dies NICHT Teil des HMW-Statements ist.

Beispiel (gefuellt, V1)

## Problem-Statement

> **„Wie koennen wir die geringe Nutzung lokaler Tauschmoeglichkeiten fuer Mieter in mittelgrossen Mehrfamilienhaeusern (8-30 Parteien) neu gestalten, damit das Beduerfnis nach niedrigschwelligem Geben/Nehmen ohne App-Pflicht befriedigt wird – unter Beruecksichtigung von Print-only-Distribution und 4-6h/Woche Founder-Zeitbudget."**

_Version V1 vom 2026-05-19_
_Vorgaengerversion: Keine - Neuerstellung_

### Kontext – Was wird neu gestaltet?
Die alltaegliche Frage "Wer hat eine Bohrmaschine kurz fuer mich?". Heute via
Whatsapp-Gruppe (wenn vorhanden) oder gar nicht. Karten-basiert _(Annahme)_
senkt die Schwelle fuer App-averse Nachbarn.

### Zielgruppe – Fuer wen?
Mieter in Mehrfamilienhaeusern mit 8-30 Parteien in deutschen Staedten.
Anker-Person: Anna, 38, 6 Jahre im Haus, kennt 4 Nachbarn mit Namen.

### Beduerfnis – Was soll erreicht werden?
Spontane, niedrigschwellige Verfuegbarkeit von Werkzeugen/Gegenstaenden
zwischen Nachbarn — ohne App, ohne Account, ohne Marketplace-Friction.

### Einschraenkungen – Was muss beruecksichtigt werden?
- Kein Smartphone-Zwang (existierende Whatsapp-Loesungen scheitern hier).
- Print-Distribution muss skalieren ohne Founder-Zeitexplosion.
- Hausverwaltung als Distributions-Hebel ist offen _(Annahme)_.

### Loesungsrichtung _(Hintergrund)_
Karten-Set + Hausflur-Aushaengetafel, ggf. spaeter web-Liste fuer Hausverwaltung.

### Offene Punkte
- [ ] Druckkosten fuer ein Karten-Set pruefen.
- [ ] Hausverwaltungs-Hypothese in Recherche validieren.

---

Master version: plugin-shared/export-formate.md. Drift-check via plugin-shared/drift-check.sh.