2
0
Files
agent-skills/skills/i2s-problem-statement/references/problem-statement-format.md
T
Philipp Sieder 6067d2ba0e 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.)
2026-05-19 01:16:01 +02:00

83 lines
3.6 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.
# Problem-Statement-Format — i2s-problem-statement (curated extract)
Curated from `plugin-shared/export-formate.md``<problem_statement_format>` block.
## Schema fuer `## Problem-Statement` Sektion
```markdown
## 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)
```markdown
## 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`.