feat(i2s-prototyp-konzept): extract from monolith
Step 9 of i2s-skill-split refactor. Sixth atomic sub-skill. Contents: - SKILL.md: 4 numbered phases (load + experiment-status, 4 TAs including ideen-werkstatt, consistency, export). description with prototyp/loesungsidee/user-flow triggers, anti-trigger to ce-brainstorm for non-Idea2Self ideation. Precondition: ## Experiment-Card required. - workflows/prototyp-konzept.md: 4-step workflow (git mv, paths updated). - references/kommunikationsregeln.md: curated extract with prototyp-specific heuristics (5-ideas-must-differ, scope-out- pflicht, user-flow-max-5, role-vs-solution-mismatch). - references/prototyp-konzept-format.md: full schema with verworfene-ideen-tabelle (alle 4 mit grund) and filled hausflur-set example. - templates/prototyp-remixer-auswertung.md: optional 3- dimensions / kombinations / bewertung variantenanalyse, copied from plugin-shared. Tools include WebFetch + WebSearch for inline format/tool checks (NOT markt/wettbewerb — that's in recherche).
This commit is contained in:
Philipp Sieder
@@ -0,0 +1,132 @@
|
||||
# Prototyp-Konzept-Format — i2s-prototyp-konzept (curated extract)
|
||||
|
||||
Curated from `plugin-shared/export-formate.md` — `<prototyp_konzept_format>` block.
|
||||
|
||||
## Schema fuer `## Prototyp-Konzept` Sektion
|
||||
|
||||
```markdown
|
||||
## 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)
|
||||
|
||||
```markdown
|
||||
## 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`.
|
||||
Reference in New Issue
Block a user