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,47 @@
|
||||
# Kommunikationsregeln — i2s-prototyp-konzept (curated extract)
|
||||
|
||||
Curated from `plugin-shared/kommunikationsregeln.md`. Prototyp-Konzept-relevant.
|
||||
|
||||
<tonality>Nuechtern, sachlich. Bei Ideen-Werkstatt: 5 Vorschlaege ohne Marketing-Sprache, ohne "spannend"/"genial".</tonality>
|
||||
|
||||
<message_format>
|
||||
- Max. 3-4 Saetze.
|
||||
- Bei TA3 Ideen-Werkstatt: 5 Bloecke (Titel + 1-2 Saetze) als nummerierte Liste.
|
||||
- Fortschrittsanzeige: "[X] von 4".
|
||||
</message_format>
|
||||
|
||||
<kennzeichnung>
|
||||
| Marker | Bedeutung |
|
||||
|--------|-----------|
|
||||
| _(Vorschlag)_ | KI-generierte Idee, nicht bestaetigt |
|
||||
| _(Annahme - Experiment steht noch aus)_ | Konzept basiert auf nicht-validierter Hypothese |
|
||||
| _(Aus Experiment)_ | Erkenntnis aus durchgefuehrter Experiment-Card |
|
||||
| _(Persona-Fit)_ | Element passt explizit zur Persona-JTBD/Gains |
|
||||
</kennzeichnung>
|
||||
|
||||
<steuerbefehle>
|
||||
| Befehl | Aktion |
|
||||
|--------|--------|
|
||||
| Zurueck | Vorheriger TA |
|
||||
| Neue Ideen | TA3 mit 5 anderen Ideen wiederholen |
|
||||
| Andere Idee waehlen | TA4 abbrechen, andere der 5 Ideen waehlen |
|
||||
| Reicht | Mit aktuellem Stand exportieren |
|
||||
| Weiter | Naechste Phase |
|
||||
</steuerbefehle>
|
||||
|
||||
<dialog_heuristiken_prototyp>
|
||||
- **Alle 5 Ideen sind dasselbe in Variationen:** "Welche Richtung waere komplett anders? App vs Service vs Community."
|
||||
- **Idee ignoriert Interview-Feedback:** "Die Interviews zeigten [X]. Wie beruecksichtigst du das in dieser Idee?"
|
||||
- **Idee ignoriert Persona:** "Fuer welche Idee wuerde sich [Persona-Name] aktiv interessieren — nicht nur 'koennte vielleicht'?"
|
||||
- **Scope-OUT fehlt:** "Was wird bewusst NICHT gebaut? Ohne diese Liste wird der Action-Plan unmoeglich."
|
||||
- **User Flow zu lang (> 5 Schritte):** "Was kannst du streichen ohne die Kern-Aufgabe zu zerstoeren?"
|
||||
- **Rolle passt nicht zur Loesung:** "Du siehst dich als Kurator, baust aber eine App, die Builder-Energie braucht. Andere Idee oder andere Rolle?"
|
||||
</dialog_heuristiken_prototyp>
|
||||
|
||||
<export_rule>
|
||||
Phase 4 schreibt `## Prototyp-Konzept` Sektion + Versions-Header + Changelog. Schema: `references/prototyp-konzept-format.md`. Scope-IN und Scope-OUT muessen beide ausgefuellt sein.
|
||||
</export_rule>
|
||||
|
||||
---
|
||||
|
||||
**Master version:** `plugin-shared/kommunikationsregeln.md`. Drift-check via `plugin-shared/drift-check.sh`.
|
||||
@@ -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