CommunityCodierung & Entwicklunggithub.com

choism4/oh-my-demo

Erstelle wahrheitsgetreue, wiederholbare Produktdemos in echten Anwendungsbranches.

Was ist oh-my-demo?

Oh My Demo ist eine Fähigkeit für KI-Agenten (z. B. Claude Code), die es ermöglicht, authentische Produktdemos auf Basis echter Anwendungsbranches aufzuzeichnen – ohne aufwändige Nachbearbeitung. Die Fähigkeit fungiert als Proben- und Setup-Schicht um die Host-Anwendung herum und bereitet den Startzustand, Bedienerhinweise, Taktung, deklarierte Testdaten und einen Rücksetzpfad vor, sodass der Benutzer die Demo in einem Durchgang aufnehmen kann. Ziel ist es, einen gewichteten „Realanteil“ von mindestens 80 % zu erreichen; nur die kleinsten langsamen, teuren, entfernten oder unfertigen Grenzen der Anwendung werden durch deterministische Testdaten ersetzt. Die Fähigkeit unterstützt die Erstellung eines eigenen Branches, die Verwaltung eines Manifests und die Validierung der Demo über eine CLI (`oh_my_demo.py`). Ein strenger Sicherheitsvertrag verhindert die Manipulation von Produktionsdaten, die Weitergabe von Geheimnissen oder die Umgehung von Authentifizierung. Nach Abschluss müssen zwei vollständige Durchläufe (davon mindestens einer mit menschlicher Bedienung) erfolgreich wiederholt werden, bevor die Demo als gültig gilt.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add choism4/oh-my-demo

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Oh My Demo

Nimm die echte App in einem Durchgang auf. Verzichte auf die Nachbearbeitung.

Behandle diese Fähigkeit als Proben- und Setup-Schicht um die Host-Anwendung herum, nicht als Mock-App-Generator. Bereite den Startzustand, Bedienerhinweise, Taktung, deklarierte Testdaten und den Rücksetzpfad vor, sodass der Benutzer auf „Aufnahme“ drücken und den Durchlauf beenden kann, ohne nachträglich um Fehler herumschneiden zu müssen. Bewahre die Produktions-UI, Navigation, Befehle, den lokalen Zustand und die verfügbare Geschäftslogik. Ersetze nur die kleinsten langsamen, teuren, entfernten, instabilen oder unfertigen Grenzen, die für eine zuverlässige Aufnahme erforderlich sind.

Standardablauf

Ermittle SKILL_ROOT als das Verzeichnis, das diese Datei enthält, und führe dann die gebündelte CLI mit python3 "$SKILL_ROOT/scripts/oh_my_demo.py" aus.

  1. Untersuche das Repository, seine Testinfrastruktur, vorhandene Testdaten und den genauen benutzersichtbaren Pfad, der aufgezeichnet werden soll. Überprüfe den Git-Status und relevante Diffs, bevor du etwas änderst.

  2. Erstelle einen dedizierten Branch oder einen isolierten Worktree. Platziere niemals Demo-exklusive Testdatensubstitutionen auf dem Produktionsbranch.

  3. Initialisiere das Projekt-Kit:

    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" init . --name product-tour
    
  4. Erstelle ein Wahrheitsverzeichnis in .oh-my-demo/manifest.json. Klassifiziere jede Behauptung als:

    • real: Die sichtbare App führt ihre Produktionsimplementierung aus.
    • simulated: Eine deklarierte Grenze gibt deterministische Testdaten zurück.
    • operator: Aufnahmehilfen wie Textbefüllung, Taktung oder Zurücksetzen; diese Annehmlichkeiten nicht in den Wahrheitsprozentsatz einbeziehen.
  5. Halte den gewichteten Realanteil bei mindestens 80 %. Reduziere die Behauptung oder implementiere mehr vom echten Pfad, wenn eine simulierte Hauptfunktion das Budget sprengen würde. Manipuliere keine Gewichtungen, um dies zu verbergen.

  6. Erfasse alle Eingaben, Referenzen, Testdaten, Ergebnisse und Ausgangswerte. Kopiere Demo-Ressourcen unter .oh-my-demo/ oder einem anderen Manifest-Stammverzeichnis, anstatt sie an maschinenspezifische absolute Pfade eines Bedieners zu binden. Für große Medien wähle Git LFS oder ein prüfsummengesichertes, authentifiziertes Artefaktpaket und materialisiere es lokal vor dem Preflight.

  7. Gib sichtbaren Steuerelementen stabile semantische Ziele. Bevorzuge Accessibility-IDs, Test-IDs oder eine Host-Registry gegenüber generierten CSS-Selektoren oder Koordinaten.

  8. Füge nur den kleinsten benötigten Host-Adapter hinzu, um den Zustand zu setzen, einen Ausgangswert wiederherzustellen oder den Produktionsgrenzenvertrag zu erfüllen. Halte produktspezifische Substantive aus der wiederverwendbaren Manifest-Laufzeit heraus.

  9. Modelliere den Take als zustandsbewusste, explizit ausgelöste Stufen. Zentralisiere Tippintervalle, lesbare Ladezeiten, gestaffelte Einblendungen und Viewport-Anpassungen. Gehe niemals zur nächsten erzählten Stufe über ohne einen menschlichen Auslöser.

  10. Führe Diagnosen aus und schließe fehlgeschlagen ab, bevor du die App öffnest:

    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" doctor .
    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" status .
    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" check . --record
    
  11. Probedurchlauf durch die echte sichtbare Anwendung in Erzählgeschwindigkeit. Überprüfe Wartezustände, Ergebniseinblendungen, akkumulierte Mutationen, Audio/Video-Verknüpfung und Viewport-Reaktion, bevor du fortfährst.

  12. Setze zurück und wiederhole den identischen Take mindestens zweimal. Schließe mindestens einen menschlich bedienten Durchlauf ein; Automatisierung allein kann nicht beweisen, dass das Publikum das Verhalten wahrnehmen kann.

  13. Binde die Beweise an das exakte Manifest und validiere es:

    python3 "$SKILL_ROOT/scripts/oh_my_demo.py" prove .
    
  14. Führe einen gezielten Check mit deaktivierter Produktion durch. Bestätige, dass die Demo-Aktivierung standardmäßig deaktiviert ist und normale Builds nicht stillschweigend Testdaten auflösen.

  15. Melde drei separate Listen: reales Verhalten, simulierte Grenzen und Bedienerannehmlichkeiten. Erstelle Folgearbeiten nur für simulierte Produktbehauptungen, nicht für Demo-Steuerungen.

Integrierte Oberflächen

Verwende die CLI als deterministisches Rückgrat:

  • init: Erstelle .oh-my-demo/manifest.json, evidence.json und fixtures/.
  • doctor: Diagnostiziere Python, Git-Worktree, Branch, Manifest, Medienwerkzeuge und explizite Aktivierung.
  • status: Zeige das gewichtete Wahrheitsbudget und die simulierten Grenzen an.
  • check: Preflight für Branch, Baseline-Revision, Assets, Hashes, Mediendauer, nachlaufende Bereiche, Rotationsmetadaten, Unicode-Pfade und Testdatenverknüpfung.
  • prove: Erfordert zwei Zurücksetz-und-Wiederholungsdurchläufe, einen menschlichen sichtbaren Bedienerdurchlauf, Manifest-Digest-Bindung und isolierte, nicht aktivierte Produktion.

Nutze das Denkvermögen der Fähigkeit, um die Host-App zu inspizieren und zu modifizieren. Gib nicht vor, dass die CLI frameworkspezifische Adapter selbst implementieren kann.

Laufzeitvertrag

Halte das wiederverwendbare Aktionsvokabular klein:

focus, set-value, type-text, click, submit, navigate, wait, resolve-fixture, repeat, reset, assert und invoke-adapter.

Bilde Domänenoperationen auf hosteigene Adapter ab. Eine Canvas-Bearbeitung, Datenbank-Seed, Timeline-Einfügung, mobile Geste oder TUI-Befehl bleibt ein invoke-adapter; die Host-Implementierung besitzt ihre echten Typen und ihr Verhalten.

Für Textfelder löse ein deklariertes Textziel oder ein fokussiertes geeignetes Element auf, lehne sensible Felder ab, fokussiere es, aktualisiere über den kontrollierten Zustandspfad des Frameworks, wenn verfügbar, und sende nur ab, wenn explizit angefordert.

Sicherheitsvertrag

  • Erfordere eine explizite Laufzeitaktivierung und einen dedizierten Demo-Branch.
  • Erfordere einen menschlichen Auslöser für jede aufgezeichnete Stufe.
  • Verbiete Live-Veröffentlichung, Nachrichtenversand, Abrechnung, Belastung oder andere entfernte Seiteneffekte aus gestuften Abläufen.
  • Umgehe niemals Authentifizierung, Autorisierung, Modellrichtlinie, Token-Abrechnung, Signierung oder Release-Prüfungen.
  • Fülle niemals Passwörter, Token, Zahlungsdaten, Wiederherstellungscodes oder geheimnisartige Felder aus.
  • Setze nur den im Manifest deklarierten Zustand oder einen hosteigenen versionierten Schnappschuss zurück. Ziele niemals auf ein Home-Verzeichnis, Repository-Stammverzeichnis, unaufgelöste Variable, Wildcard oder einen Pfad außerhalb des deklarierten Stammverzeichnisses.
  • Behandle eine Testdatendatei nur als Beweis für den Konsumentenpfad, niemals als Beweis dafür, dass ihr entfernter Produzent funktioniert.
  • Verstecke Debug-Elemente nur, wenn sie für die Produktbehauptung irrelevant sind. Verstecke niemals eine Tatsache, die für das, was dem Publikum erzählt wird, wesentlich ist.

Referenz-Routing

Lies references/distribution.md, wenn du entscheidest, wie die Fähigkeit, CLI, Projekt-Kit und Host-Adapter die Verantwortung teilen.

Lies references/manifest-schema.md, wenn du .oh-my-demo/manifest.json erstellst oder erweiterst.

Lies references/adapters-and-safety.md, bevor du einen Host-Adapter, eine Testdatengrenze, einen Rücksetzpfad oder eine Textfeld-Integration implementierst.

Lies references/rehearsal.md vor dem ersten vollständigen Durchlauf, nach einem fehlgeschlagenen Take oder wenn eine Mutation erfolgreich ist, aber nicht wahrnehmbar.

Lies references/evidence-schema.md, bevor du behauptest, die Demo sei wiederholbar, oder .oh-my-demo/evidence.json füllst.

Abschlusskriterien

Bezeichne das Setup erst dann als abgeschlossen, wenn alle folgenden Punkte erfüllt sind:

  • doctor, status und check bestehen auf dem dedizierten Demo-Branch;
  • der gewichtete Realanteil beträgt mindestens 80 %;
  • jede simulierte Behauptung hat eine Herkunft, einen engen Injektionspunkt, ihr Produktionsäquivalent und eine sichtbare Zusicherung;
  • das Zurücksetzen stellt denselben Anfangszustand zweimal wieder her;
  • mindestens ein menschlich bedienter Probendurchlauf ist in Erzählgeschwindigkeit wahrnehmbar;
  • prove besteht gegen den endgültigen Manifest-Digest;
  • der Demo-Modus ist bestätigt deaktiviert im Produktionspfad.

Verwandte Skills