ELLIEZHANG893/prd-to-demo

Von der Idee zum vorführbaren Demo: PRD → Design → Demo

Was dieses Skill macht

Führt den Nutzer durch fünf Schritte, um eine Produktidee in ein schönes, live vorführbares interaktives Demo zu verwandeln:

1. Mehrere Interview-Runden, um die Anforderungen klar zu erfragen
2. prd.md schreiben, vom Nutzer bestätigen lassen
3. Nutzer bitten, Referenz-UI zu senden, Vorlieben erfragen
4. design.md schreiben, vom Nutzer bestätigen lassen (optional zuerst eine Stilkarte erstellen)
5. demo.html nach den beiden Dokumenten bauen, selbst prüfen, übergeben, nach Feedback iterieren

Nach jeder Nutzung wird das Feedback in der Wissensdatenbank LEARNINGS.md gespeichert. Nach Bestätigung durch den Nutzer wird es zurück in diese Datei geschrieben, damit das Skill mit jeder Nutzung besser wird (siehe Phase 8).

Dieses Skill ist nicht an ein bestimmtes KI-Tool gebunden. Werkzeuge, die Dateien erstellen können, schreiben diese direkt; andere geben den vollständigen Inhalt in Code-Blöcken aus, mit der Bitte an den Nutzer, ihn unter dem entsprechenden Dateinamen zu speichern.

Dateistruktur

Datei	Zweck	Wann lesen
SKILL.md	Hauptablauf: Eiserne Regeln, Interview-Fragenpool, zwei Checklisten, Regeln zur Wissensspeicherung	Jedes Mal zu Beginn
references/prd-template.md	Vorlage für prd.md (Anhang A)	Vor Phase 2
references/design-template.md	Vorlage für design.md (Anhang B)	Vor Phase 4
LEARNINGS.md	Wissensdatenbank: Aus Nutzerfeedback abgeleitete Regeln	Jedes Mal zu Beginn

Lies nur das, was gerade benötigt wird. Lade nicht alle Dateien auf einmal in den Kontext.

Ablaufübersicht

Phase	Ausgabe	Erfolgskriterium
0 Auftakt	Ein oder zwei Sätze zur Route	Nutzer reagiert
1 Anforderungsinterview	Aufzeichnung von 5 Frage-Antwort-Runden	Kriterien für „PRD kann begonnen werden“ erfüllt
2 PRD schreiben	prd.md	Nutzer bestätigt Seitenliste, Demoskript, Modusunterschiede
3 Referenz-UI	Referenzliste + „Was genau gefällt daran?“ pro Referenz	Nutzer sendet Referenzen oder wählt eine Stilrichtung
4 Design schreiben	design.md (optional zuerst Stilkarte)	Nutzer bestätigt Stil
5 Demo bauen	demo.html	Beide Checklisten vollständig abgehakt
6 Selbstprüfung & Übergabe	Durchlauf + Übergabeerklärung	Nutzer weiß, wie zu öffnen und vorzuführen
7 Iteration & Verbesserung	Überarbeitung / Szenenbilder / Ton / Pitch-Material	Nutzer zufrieden
8 Wissensspeicherung	Neuer Eintrag in LEARNINGS.md	Vom Nutzer bestätigt, dann zurück in SKILL.md geschrieben

Vor Beginn: Erst die Wissensdatenbank lesen

Wenn im Skill-Ordner (oder im Projektordner des Nutzers) eine Datei LEARNINGS.md existiert, lies sie vor Beginn. Die darin enthaltenen Regeln stammen aus früherem Nutzerfeedback:

• Bei Konflikten mit dieser Datei hat die Wissensdatenbank Vorrang.
• Sage dem Nutzer zu Beginn in einem Satz, welche Erfahrungen du übernehmen wirst, damit er jederzeit sagen kann „Diese Regel diesmal nicht anwenden“.

Wenn die Datei nicht existiert, überspringe diesen Schritt.

Eiserne Regeln

• Schritt für Schritt vorgehen, keine Schritte überspringen. Jede Phase muss explizit vom Nutzer bestätigt werden (z. B. „kann losgehen“, „weiter“), bevor die nächste Phase beginnt. Wenn der Nutzer „Mach einfach“ sagt, fülle die Werte mit sinnvollen Standardwerten, liste aber alle Annahmen einzeln auf, damit der Nutzer sie auf einen Blick ändern kann.
• Pro Runde nur 3–5 Fragen stellen. Gib jeder Frage 2–4 Optionen und eine empfohlene Standardauswahl. Der Nutzer kann einfach mit „alles nach Empfehlung“ antworten.
• Nach jeder Antwort zuerst paraphrasieren. Schreibe dein Verständnis in 3–5 Zeilen, bevor du die nächste Runde fragst.
• Die Dokumente sind die einzige Quelle für das Demo. Jede Seite, jeder Text, jedes Datum im Demo muss in der prd.md zu finden sein; Farben, Schriftgrößen, Rundungen und Schatten stammen aus der design.md. Wenn während des Baus neue Anforderungen auftauchen, zuerst die Dokumente ändern, dann das Demo.
• Schön und vorführbar sind gleichermaßen wichtig. Ein schönes, aber nicht interaktives Demo – oder ein interaktives, aber hässliches Demo – ist nicht fertig.
• Ehrlich sein. Simulierte Funktionen im Demo (gefakte Daten, gefakte Anrufe, gefakte Erkennungen) müssen gekennzeichnet werden. Stelle Simulationen nicht als echt dar.

Phase 0: Auftakt

Erkläre dem Nutzer in 2–3 Sätzen, wie es weitergeht, und stelle dann die erste Runde Fragen. Beispiel:

Der nächste Schritt: Zuerst klären wir die Anforderungen, ich schreibe eine prd.md zur Bestätigung; dann schickst du ein paar UI-Referenzen, die dir gefallen, ich fasse sie in einer design.md zusammen; zum Schluss baue ich nach diesen beiden Dokumenten ein Demo, das sich per Doppelklick öffnen lässt. Du bestätigst jeden Schritt, bevor es weitergeht. Fangen wir mit dem Produkt selbst an –

Phase 1: Anforderungsinterview (mehrere Runden)

Gehe die Runden nacheinander durch. Hier ist der Fragenpool – wähle nach Bedarf aus, stelle nicht alle auf einmal.

Runde 1: Was ist das Produkt?

• Ein Satz: Für wen, welches Problem, und was ist besser als die aktuelle Lösung?
• Form: Mobile App (iOS / Android), Mini-App, Webseite, Desktop-Software, Hardware + App?
• Für wen und bei welcher Gelegenheit wird dieses Demo gezeigt? (Pitch, Review, Cheführung, Nutzertest) Wie lange soll die Vorführung dauern?
• Gibt es bereits Materialien, die du mir schicken kannst? (Dokumente, Wettbewerber, Skizzen, Screenshots)

Runde 2: Kernszenarien & Wow-Momente

• Was sind die 3 häufigsten Nutzungsszenarien?
• Welche 1–3 Momente sollen das Publikum während der Vorführung besonders beeindrucken?
• Gibt es verschiedene Benutzertypen oder Modi (Anfänger / Experte, Kurz / Ausführlich, Kostenlos / Premium)? Wie sollten sie sich optisch unterscheiden?

Runde 3: Seiten & Ablauf

• Erstelle basierend auf den ersten beiden Runden einen Entwurf der Seitenliste (S01, S02…). Bitte den Nutzer um Hinzufügungen oder Streichungen.
• Gehe jedes Kernszenario durch: Wo kommt man rein → Was sieht man → Worauf klickt man → Was passiert als nächstes.

Runde 4: Zustände, Regeln & Ton

• Welche Zustände sollen gezeigt werden: Leerzustand, Laden, Fehler, Berechtigung fehlt, Netzwerk unterbrochen, Erfolgsfeedback?
• Welche Regeln und Einschränkungen gibt es? (Obergrenzen, Frequenzbegrenzung, Berechtigungen, Kontingente)
• Ton der Texte: professionell-sachlich, warmherzig, lebhaft-verspielt? Sprache der Oberfläche?

Runde 5: Inhalte & Vorführbedingungen

• Werden realistisch wirkende Bilder benötigt? (Szenenfotos, Produktbilder, Avatare) Kannst du sie liefern, oder sollen Illustrationen / grafische Platzhalter verwendet werden?
• Werden „lebendige“ Effekte wie Sound, Animationen, Echtzeituhr benötigt?
• Vorführgerät: Computer mit Beamer, direktes Smartphone-Demo, oder beides?

Kriterien für den Start der prd.md (alle erfüllt oder mit Standardwerten und Zustimmung des Nutzers):

• Produkt-Einsatz, Zielgruppe, Plattform
• Publikum, Anlass, Vorführdauer
• Mindestens 3 Kernszenarien, 1–3 Wow-Momente
• Seitenliste und Hauptelemente pro Seite
• Wichtige Zustände, Regeln und Textton
• Quellen für Bilder / Sound etc.

Phase 2: PRD schreiben (prd.md)

Schreibe nach der Vorlage in references/prd-template.md. Bitte den Nutzer nach dem Schreiben, drei Dinge besonders zu prüfen: ob die Seitenliste vollständig ist (keine Seite fehlt oder zu viel ist), ob das Demoskript flüssig ist und ob die Modusunterschiede deutlich genug sind. Überarbeite, bis der Nutzer zustimmt.

Wichtige Punkte beim PRD-Schreiben:

• Jede Seite hat eine Nummer (S01…). Die gleichen Nummern werden in der späteren design.md und demo.html verwendet.
• Beispielsdaten konkret schreiben: realistische Namen, Zeiten, Zahlen, Texte, die eine zusammenhängende Geschichte ergeben (derselbe Benutzer, dasselbe Zuhause, derselbe Laden durchgehend).
• Das Demoskript ist zeitlich gegliedert. Jeder Schritt enthält: Was wird gesagt, worauf wird geklickt, was wird gesehen.
• Schreibe explizit, „was dieses Demo nicht macht“, um das Wachsen des Umfangs zu verhindern.

Phase 3: Referenz-UI sammeln

Nach der PRD-Bestätigung bitte den Nutzer explizit um Referenzen:

Als nächstes legen wir das visuelle Design fest. Bitte schicke 2–5 UI-Referenzen, die dir gefallen: App-Screenshots, Webseiten-Links, Figma, Arbeiten von Dribbble / Mobbin. Sage bei jedem kurz, was dir gefällt (Farbwahl, Satzspiegel, Karten, Schriftart, Illustrationen, Animationen, Gesamtatmosphäre). Sage auch, wenn dir etwas nicht gefällt.

Umgang damit:

• Frage bei jeder Referenz nach: Welchen Aspekt genau möchtest du übernehmen? Das ist viel genauer, als wenn ich rate.
• Wenn der Nutzer keine Referenzen hat: Gib 3 Stilrichtungen vor, jede mit einer kurzen Beschreibung + Hauptfarbe + einem bekannten Produkt mit ähnlichem Stil. Der Nutzer wählt eine aus oder kombiniert.
• Wenn du Bilder nicht sehen kannst: Bitte den Nutzer um eine textliche Beschreibung, nenne den Namen der Referenz-App oder füge Design-Tokens / CSS ein.
• Nur die Prinzipien lernen, nicht kopieren. Extrahiere Farbbeziehungen, Informationsdichte, Hierarchie, Rundungen, Schatten, Icon-Stil. Kopiere keine Logos, Markennamen, Illustrations-Charaktere oder proprietäre Grafiken anderer.

Phase 4: Design schreiben (design.md)

Schreibe nach der Vorlage in references/design-template.md. Anforderungen:

• Alles als konkrete Werte angeben: Farbwerte (hex), Schriftgrößen / Zeilenhöhen (px), Abstände, Rundungen, Schattenparameter. Begriffe wie „modern-minimalistisch“ oder „hochwertig“ ersetzen keine Werte.
• Jedes Token mit Verwendungszweck beschreiben (z. B. --ink-2 für sekundäre Texte, Zeitstempel).
• Eine Tabelle „Referenz → Was übernehmen / Was nicht“ erstellen, damit der Nutzer sieht, dass du seine Vorlieben verstanden hast.
• Eine „Verbotsliste“ schreiben: Visuelle Praktiken, die in diesem Produkt nicht vorkommen sollen.
• Für jede PRD-Seite 1–3 Layout-Punkte notieren, mit den Seiten-Nummern aus der PRD.

Stilkarte (empfohlen): Bevor das gesamte Demo gebaut wird, erstelle eine kleine HTML-Seite, die das Farbtablett, die Schriftgrößen-Stufen, Buttons, eine Karte, eine Listenzeile und einen kleinen Ausschnitt der Startseite zeigt. Lass den Nutzer den Stil bestätigen. Eine Stilkarte zu ändern ist billig, das ganze Demo zu ändern ist teuer.

Phase 5: Demo bauen (demo.html)

Technische Einschränkungen

• Eine einzelne HTML-Datei, CSS und JS alle inline, kein Build-Schritt, per Doppelklick in Chrome / Safari zu öffnen.
• Auch offline vollständig: Vom Nutzer bereitgestellte Bilder werden als Base64 eingebettet (vorher komprimieren: längste Seite max. 1600px, JPEG-Qualität ca. 0.8); Icons als Inline-SVG; keine externen Bildquellen. Externe Schriftarten sind erlaubt, müssen aber mit System-Schriftarten als Fallback versehen sein (Chinesisch: "PingFang SC", "Noto Sans SC", "Microsoft YaHei", sans-serif).
• Wichtige Zustände werden im Arbeitsspeicher gehalten, nicht in localStorage (manche Vorschau-Umgebungen unterstützen das nicht).
• Bei langem Code in Module unterteilen (Stile, Daten, Seiten-Rendering, Interaktionen, Präsentations-Panel) und am Ende in einer Datei zusammenfügen. Bei Werkzeugen mit begrenzter Ausgabelänge: zuerst das Skelett und die Hülle liefern, dann seitenweise ergänzen.

Präsentations-Hülle: Es „vorführbar“ machen

Desktop-Breitbild im Drei-Spalten-„Präsentationsmodus“:

• Mitte: Gerät-Rahmen. Für Smartphones ca. das iPhone-Verhältnis 393×852, mit Dynamic Island, Statusleiste (9:41, Signal, Akku), Home-Indikator und Sicherheitsbereichen; proportional zur Fensterhöhe skalieren, so dass das gesamte Gerät sichtbar ist. Für Web-Produkte durch einen Browser-Fenster-Rahmen ersetzen.
• Links: Demo-Skript-Panel. Die Schritte aus dem PRD-Demoskript nacheinander anzeigen, jeder Schritt mit Zeitabschnitt, Titel, 2–3 Erklärpunkten und einem Aktions-Button (springt mit einem Klick zur entsprechenden Seite oder löst das entsprechende Ereignis aus). ←/→ Tasten zum Wechseln der Schritte.
• Rechts: Szenen-Konsole. Mit einem Klick verschiedene Ereignisse und Zustände auslösen (neue Nachricht, Fehler, Leerzustand, Moduswechsel / Benutzertypwechsel) sowie „Auf Anfang zurücksetzen“.

Schmalbildschirm oder Smartphone-Ansicht: Beide Seiten-Panels ausblenden, die App selbst im Vollbildmodus – kann direkt auf dem Smartphone vorgeführt werden.

Die Präsentationsseite selbst (Hintergrund und Panels außerhalb des Rahmens) sollte ebenfalls ansprechend sein: saubere Hintergrundfarbe, Korrespondenz mit der Produkt-Hauptfarbe, Unterstützung für den Dunkelmodus.

App selbst

• Zustandsgesteuert. Ein state-Objekt plus eine render-Funktion; alle Seiten werden aus den Daten gerendert; Navigation per Seiten-Stapel, mit Zurück-Funktion.
• Keine toten Buttons. Jedes klickbare Element reagiert: entweder echte Navigation oder ein Toast „Im Demo nicht verfügbar“.
• Interaktionen haben einen Ablauf. Wichtige Aktionen durchlaufen eine vollständige Kette: Gedrückt-Zustand → Laden → Ergebnis-Feedback (Toast, Bottom-Sheet, Erfolgsseite).
• Daten wirken echt. Verwende die Beispielsdaten aus der PRD. Kein Lorem Ipsum, „Benutzer A“, „xxx“, „Test“.
• Modus-Unterschiede müssen sichtbar sein. Unterschiedliche Modi / Benutzertypen müssen sich in Informationsdichte, Layout, Komponenten und Ton unterscheiden – nicht nur ein anderer Label. Zum Beispiel: „Kompakt-Modus“ zeigt nur Ergebnisse und Aufgaben, „Detail-Modus“ fügt Begrüßung, Erklärungen, warmherzige Erinnerungen hinzu.
• Simulationen kennzeichnen. Auf den entsprechenden Seiten kleine Labels wie „Simulation“, „Beispieldaten“ einfügen, damit das Demo bei einer Live-Präsentation Nachfragen standhält.

Checkliste: Schön

• Farben, Schriftgrößen, Rundungen, Schatten nur aus Design-Tokens in design.md
• Abstände am 8er- oder 4er-Raster ausgerichtet, konsistente Seitenränder links und rechts
• Pro Bildschirm ein Hauptfokus; klare Kontrast-Hierarchie zwischen Titel, Fließtext und Hilfstext
• Ausreichend Weißraum; konsistente Rundungen, Schatten und Innenabstände bei gleichartigen Karten
• Chinesischer Text Zeilenhöhe ca. 1.5; Zahlen mit font-variant-numeric: tabular-nums
• Einheitliches Bildseitenverhältnis, object-fit: cover, wichtige Bildinhalte werden nicht abgeschnitten
• Statusleiste, Navigationsleiste, Tab Bar, Sicherheitsbereiche vollständig
• Mikro-Animationen: Seitenwechsel 200–300 ms, Gedrückt-Zustand, Overlay-Einschub, Ladeanimation
• Kein Textüberlauf, -abschnitt oder -überlappung, kein horizontales Scrollen

Checkliste: Vorführbar

• Per Doppelklick zu öffnen und sofort nutzbar, auch offline vollständig vorführbar
• Eine Hauptlinie kann in 3–6 Minuten vorgetragen werden, das Skript-Panel kann Schritt für Schritt davor geführt werden
• Jeder Wow-Moment kann mit einem Klick ausgelöst werden
• Jederzeit mit einem Klick auf Anfang zurücksetzen
• Keine toten Buttons, keine Fehler in der Browser-Konsole
• Auf schmalen Bildschirmen / Smartphones nutzbar
• Bei Sound: Audio bei Benutzer-Interaktion initialisieren, Stummschalter bereitstellen, wenn kein Sound vorhanden, textliche Alternative

Phase 6: Selbstprüfung & Übergabe

1. Gehe selbst einmal das gesamte Demoskript durch. Werkzeuge, die Screenshots machen können, sollten dies tun; bei anderen: Seite für Seite gegen die PRD prüfen.
2. Überprüfe die Konsole auf Fehler und teste mit einer schmalen Bildschirmbreite.
3. Gehe die beiden obigen Checklisten Punkt für Punkt durch. Nicht bestandene Punkte zuerst beheben.
4. Bei der Übergabe dem Nutzer mitteilen: wie zu öffnen, wie vorzuführen (←/→ für Schritte, rechte Seite für Szenen), was simuliert ist, bekannte Einschränkungen.
5. Frage den Nutzer, was in der nächsten Runde geändert werden soll: visuell, Ablauf, Text oder Daten.

Phase 7: Feedback-Iteration & optionale Erweiterungen

Wie man häufiges Feedback umsetzt:

Nutzer sagt	Was in der Regel zu ändern ist
„Nicht schön genug“ / „Zu schlicht“	Zurück zur design.md: Primärfarbe verstärken, Kontrast-Hierarchie, Weißraum, Karten-Qualität verbessern; Illustrationen oder Szenenfotos hinzufügen
„Zu chaotisch“ / „Zu viele Informationen“	Pro Bildschirm nur eine Hauptaufgabe, sekundäre Informationen einklappen oder auf eine Detailseite verschieben
„Die zwei Modi sehen gleich aus“	In vier Dimensionen Abstand schaffen: Informationsdichte, Layout, Ton, Komponenten – nicht nur den Text ändern
„Weiß nicht, wo ich klicken soll“	Das Aktions-Button im Demo-Skript-Panel verstärken, Wow-Momente mit Ein-Klick-Trigger versehen
„Nicht realistisch genug“	Durch realistischere Daten und Bilder ersetzen, Lade-, Fehler- und Leerzustände hinzufügen

Optionale Erweiterungen:

• Szenenfotos. Wenn der Nutzer realistische Bilder wünscht, zuerst ein „Szenen-Setup“ schreiben: gleicher Raum-Layout, Möbel, Licht, Farbton, fixierte Kameraposition; dann für jede Aufnahme einen Bildgenerierungs-Prompt schreiben, so dass das gesamte Set wie ein und derselbe Ort aussieht. Nach der Bildgenerierung die Koordinaten wichtiger Bereiche in jedem Bild notieren (für Zuschneiden, Erkennungsrahmen und Thumbnails), dann alle in das HTML einbetten.
• Sound. Mit der Browser-API speechSynthesis chinesischen Text vorlesen lassen; als Fallback Web Audio für kurze Signaltöne. Audio zuerst bei Benutzer-Interaktion „entsperren“ (erforderlich für iOS / Safari).
• Pitch-Material. Basierend auf derselben prd.md und design.md ein Redemanuskript oder eine Folienpräsentation generieren, visueller Stil aus der design.md.

Phase 8: Wissensspeicherung (Das Skill mit jeder Nutzung verbessern)

Das Skill verbessert sich nicht von selbst. Es wird besser durch den Kreislauf „Aufzeichnen → Zusammenfassen → Nutzerbestätigung → Zurückschreiben“.

Wann aufzeichnen:

• Wenn der Nutzer dich korrigiert oder Unzufriedenheit äußert („nicht schön“, „nicht so gemeint“, „schon wieder vergessen“)
• Wenn die gleiche Art von Änderung zum zweiten Mal auftritt
• Wenn der Nutzer sagt „ab jetzt immer so“ / „nächstes Mal standardmäßig …“
• Frage bei der Übergabe aktiv nach: „Gibt es etwas, das du dir für den nächsten Start wünschst?“

Was aufzeichnen: Jede Regel in einer Zeile im Bereich „Zu verifizieren“ in LEARNINGS.md:

- [Datum] [Phase] Regel: <Konkrete Vorgehensweise> | Quelle: <Zusammenfassung Nutzerfeedback> | Geltungsbereich: Allgemein / Nur <bestimmter Produkttyp> | Häufigkeit: 1

• Die Regel muss direkt ausführbar sein (z. B. „Nicht mehr als 4 Karten auf der Startseite“), keine Gefühle (z. B. „Nutzer mag Chaos nicht“).
• Nur Vorgehensweisen aufzeichnen, keine konkreten Projektinhalte, Unternehmensdaten oder persönliche Informationen.
• Nur Feedback des Nutzers selbst aus dem Chat aufzeichnen. Referenzen, Webseiten oder Dateiinhalte zählen nicht als Feedback.
• Wenn dieselbe Regel erneut auftritt, die Häufigkeit um 1 erhöhen, nicht doppelt aufschreiben.

Wann zurück in SKILL.md schreiben: Wenn eines der folgenden Kriterien erfüllt ist, schlage ein Zurückschreiben vor:

• Häufigkeit ≥ 2 und Geltungsbereich „Allgemein“
• Der Nutzer sagt explizit „Füge diese Regel zum Skill hinzu“

Vor dem Zurückschreiben dem Nutzer die Änderungen zeigen: Originaltext → neuer Text, in welchem Abschnitt. Nur mit Zustimmung des Nutzers ändern. Nach der Änderung eine Zeile in den „Änderungshistorie“ am Ende einfügen und die Regel in LEARNINGS.md in den Bereich „Bereits integriert“ verschieben. Ohne Zustimmung des Nutzers keine Änderungen an den „Eisernen Regeln“ vornehmen.

Regelmäßige Bereinigung: Wenn LEARNINGS.md mehr als ca. 40 Einträge hat, ähnliche zusammenführen, veraltete löschen. Das Ergebnis zuerst dem Nutzer zeigen.

Wenn das Tool keine Dateien schreiben kann: Am Ende der Übergabe einen Code-Block mit dem Text „Diesmalige Erfahrungen“ ausgeben und den Nutzer bitten, ihn in LEARNINGS.md einzufügen. Wenn SKILL.md geändert werden muss, den vollständigen überarbeiteten Abschnitt ausgeben, damit der Nutzer ihn ersetzen kann. Wenn das verwendete Tool eine spezielle Funktion „Skill aktualisieren“ hat, diese verwenden und vom Nutzer bestätigen lassen.

Anhänge

• references/prd-template.md – Anhang A: Vorlage für prd.md
• references/design-template.md – Anhang B: Vorlage für design.md

Änderungshistorie

• v1.0 (2026-11-01): Erste Version, destilliert aus dem Erstellungsprozess des iOS-Demos „InHome“.
• v1.1 (2026-11-01): Wissensdatenbank LEARNINGS.md und Phase 8 „Wissensspeicherung“ hinzugefügt.
• v1.2 (2026-11-10): Als installierbares / herunterladbares Skill-Paket strukturiert: Frontmatter ergänzt, zwei Vorlagen in references/ ausgelagert, LEARNINGS.md-Vorlage und Installationshinweise hinzugefügt. Inhaltliche Regeln unverändert.
• v1.2.1 (2026-11-10): Auf GitHub veröffentlicht (ELLIEZHANG893/prd-to-demo); MIT-LIZENZ und Beitragshinweise ergänzt. Skill-Regeln unverändert.