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.)
This commit is contained in:
@@ -0,0 +1,82 @@
|
||||
# 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`.
|
||||
Reference in New Issue
Block a user