agent-skills/skills/i2s-prototyp-konzept/references/prototyp-konzept-format.md

Prototyp-Konzept-Format — i2s-prototyp-konzept (curated extract)

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

Schema fuer ## Prototyp-Konzept Sektion

## Prototyp-Konzept

_Version [V1/V2/...] vom [Datum]_
_Vorgaengerversion: [V<n-1> vom <Datum>] / Keine - Neuerstellung_
_Experiment-Status: [durchgefuehrt am <Datum> | steht noch aus]_

### Gewaehlte Idee
**Titel:** [Kurzer, beschreibender Titel]
**Beschreibung:** [2-3 Saetze: was es ist, fuer wen, warum gewaehlt]
**Begruendung der Auswahl:** [1-2 Saetze: warum diese und nicht die anderen 4]
**Rollenpassung:** [Builder / Coach / Kurator / Erklaerer / Gastgeber — mit 1-Satz-Begruendung]

### Verworfene Ideen _(aus Ideen-Werkstatt)_

| Idee | Kurzbeschreibung | Verworfen weil |
|------|------------------|----------------|
| [Idee 2] | [...] | [Grund] |
| [Idee 3] | [...] | [Grund] |
| [Idee 4] | [...] | [Grund] |
| [Idee 5] | [...] | [Grund] |

### Prototyp-Definition

- **Typ:** [App / Service / Kurs / Workshop / Community / Content-Format / Physisches Produkt / ...]
- **Kernfunktionen (3-5):**
  1. [Funktion 1]
  2. [Funktion 2]
  3. [Funktion 3]
  4. [Funktion 4] _(optional)_
  5. [Funktion 5] _(optional)_

### Scope IN — was gebaut wird
- [Konkret 1]
- [Konkret 2]
- [Konkret 3]

### Scope OUT — was bewusst NICHT gebaut wird
- [Konkret 1]
- [Konkret 2]
- [Konkret 3]

### User Flow (3-5 Schritte)
1. [Schritt 1: Nutzer macht / sieht / erlebt ...]
2. [Schritt 2: ...]
3. [Schritt 3: ...]
4. [Schritt 4] _(optional)_
5. [Schritt 5] _(optional)_

### Erkenntnisse aus dem Experiment _(wenn durchgefuehrt)_
- [Was bestaetigt wurde]
- [Was widerlegt / angepasst wurde]
- [Was ueberraschend war]

### Offene Punkte
- [ ] [Nur wenn geparkte Gedanken vorhanden]

Schreibregeln

1. Versions-Header + Experiment-Status beide Pflicht.
2. Verworfene-Ideen-Tabelle: alle 4 verworfenen Ideen mit Verworfen-weil-Grund. Nicht weglassen — die Begruendung zeigt, dass die Auswahl bewusst war.
3. Kernfunktionen 3-5: nicht weniger (zu thin), nicht mehr (Scope-Creep). Wenn der Nutzer 7 Funktionen nennt: 2 in Scope-OUT verschieben.
4. Scope IN + Scope OUT je 3 konkrete Punkte. Beide Listen mit echten Items, nicht "nichts Weiteres".
5. User Flow als nummerierte Liste, max 5 Schritte. Jeder Schritt aus Nutzer-Perspektive ("Anna sieht ..." / "Anna macht ...").
6. Erkenntnisse aus Experiment nur wenn durchgefuehrt — sonst Block weglassen, nicht leer lassen.

Beispiel (Auszug, gefuellt)

## Prototyp-Konzept

_Version V1 vom 2026-05-19_
_Vorgaengerversion: Keine - Neuerstellung_
_Experiment-Status: durchgefuehrt am 2026-05-15 (8 Interviews + 14-Tage-Pilot)_

### Gewaehlte Idee
**Titel:** Nachbarschafts-Tauschkarten "Hausflur-Set"
**Beschreibung:** Ein gedrucktes 4-Karten-Set ("Suche", "Biete", "Frage", "Termin") + minimaler Pinboard-Sticker, der eine Tauschtafel im Hausflur etabliert — ohne App, ohne Account.
**Begruendung der Auswahl:** Die Interviews zeigten App-Schwelle = real (6 von 8 Bewohnern). Karten-Set ist die einzige der 5 Ideen, die diese Schwelle aktiv umgeht.
**Rollenpassung:** Kurator + Gastgeber — Founder produziert das Set und betreut Hausverwaltungen, baut nicht selbst eine Plattform.

### Verworfene Ideen
| Idee | Kurzbeschreibung | Verworfen weil |
|------|------------------|----------------|
| Whatsapp-Templates | Vorgefertigte Gruppen-Nachrichten | Bestehende Whatsapp-Gruppen scheitern an Pflege, nicht an Templates |
| Hausverwaltungs-App | App fuer Hausverwaltungen zur Bewohner-Koordination | Hausverwaltung als Distributions-Hebel ja — aber App ist genau die Schwelle, die wir umgehen wollen |
| Quartiers-Newsletter | Monatlicher gedruckter Newsletter pro Hausgemeinschaft | Pflege-Aufwand zu hoch fuer Nebenprojekt-Zeitbudget |
| Tauschboersen-Workshop | 2h-Workshop-Format fuer Hausgemeinschaften | Skaliert nicht ohne Founder-Praesenz vor Ort |

### Prototyp-Definition

- **Typ:** Physisches Produkt + Service-Komponente (Distributions-Onboarding fuer Hausverwaltung)
- **Kernfunktionen:**
  1. 4-Karten-Set (Suche / Biete / Frage / Termin)
  2. Pinboard-Sticker als Tafel-Markierung
  3. Kurz-Onboarding-Karte fuer Hausverwaltung
  4. Optional: einseitige Bewohner-Erklaerung

### Scope IN
- Print-Produktion: Standard-Karten-Format, 4 Designs, A6.
- Hausverwaltung-Pitch-Material (1-Pager, 1 Beispielfall).
- Erste 5 Pilot-Haeuser in Leipzig.

### Scope OUT
- App, Website, digitale Komponente.
- Bezahlung / Marketplace-Funktionen.
- Skalierung > 50 Parteien pro Haus.
- Nationale Distribution.

### User Flow
1. Hausverwaltung erhaelt Pitch-Pager + Bestaetigung, Tafel im Hausflur erlauben.
2. Bewohner sehen Tafel + Karten-Set im Hausflur, koennen sich Karten kostenlos nehmen.
3. Bewohner schreibt Karte ("Suche Bohrmaschine, Sa 15h") + pinnt sie an die Tafel.
4. Interessierte Nachbarn antworten direkt vor Ort oder via Anruf/SMS auf der Karte.
5. Tausch findet statt — keine App, kein Account, keine Friction.

### Erkenntnisse aus dem Experiment
- App-Schwelle ist real (6/8 Interviews bestaetigt).
- Hausverwaltung als Tueroeffner funktioniert (3 von 3 angefragten Verwaltungen sagten ja).
- UEBERRASCHUNG: Bewohner > 60 nutzten die Karten haeufiger als Bewohner < 40 (im Pilot 5 von 8 Karten-Nutzungen).

---

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