BennyKok/omg.dev

Erstelle und liefere eine omg.dev-App

Wandle die Produktbeschreibung des Benutzers in ein funktionierendes, verifiziertes Ergebnis um. Behalte die Einrichtungsarbeit mit dem Agenten. Frage nur nach Produktentscheidungen, die das Ergebnis wesentlich verändern.

Stelle eine Frage pro Frageaufruf und setze höchstens eine Entscheidung hinein. Eine zweite Frage im selben Aufruf wird dem Benutzer auf manchen Clients nicht angezeigt. Wenn der Benutzer nicht gesagt hat, was die App tun soll, frage das in einfachen Worten und warte auf die Antwort. Baue kein Platzhalterprodukt an seiner Stelle. Wenn eine Frage ein Timeout hat, frage sie einmal in einer normalen Nachricht erneut und beende den Turn.

Projekt einrichten

• Rufe im Quick Chat einmal omg_create_project mit einem kurzen, beschreibenden Namen auf. Setze template auf expo für eine Expo- oder universelle mobile App. Die Expo-Vorlage enthält bereits einen funktionierenden Todo-Flow mit auf dem Telefon gespeicherten Daten, Expo Router, Liquid Glass, Lucide-Icons, Web-Support und EAS-Konfiguration. Verwende das zurückgegebene repo.cwd für jeden Befehl, jede Bearbeitung, Überprüfung und Bereitstellung. Überprüfe omg_list_repos, bevor du einen unsicheren Create-Aufruf wiederholst.
• In einer New Project-Sitzung ist das aktuelle Verzeichnis bereits das Projekt. Es enthält Git, eine README und diese Fähigkeit. Erstelle kein zweites Projekt.
• Bewahre .git. Überschreibe keinen vorhandenen Ordner und verschiebe den aktuellen Quick Chat nicht in das neue Projekt.

Wähle den Bereitstellungspfad

• Für eine Website, Web-App oder API verwende die unterstützte omg.dev-Runtime, sofern der Benutzer keine andere Plattform anfordert. Gerüste in einem leeren Projekt die offizielle omg.dev React-Vorlage, bevor du Produktcode schreibst. Das aktuelle Verzeichnis enthält bereits Git und omg.dev-Anweisungen, generiere daher in ein temporäres Verzeichnis darin, kopiere das Gerüst in das Projekt und entferne nur dieses temporäre Verzeichnis:

  scaffold="$(mktemp -d .omg-web-scaffold-XXXXXX)"
  bunx --bun create-omg@latest "$scaffold" --template react-ts --no-install
  cp -a "$scaffold"/. .
  rm -rf "$scaffold"
  bun install
  

  Diese Vorlage liefert @omg-dev/vite-plugin, vibes-build, Server-Funktionen, Datenbank-Support und Analysen. Ersetze create-vite oder ein selbst geschriebenes Vite-Gerüst nicht. Lies https://docs.omg.dev/llms.txt und nur die relevanten Teile von https://docs.omg.dev/llms-full.txt, bevor du zusätzliche Pakete oder API-Verträge auswählst.

• Für ein Spiel (Rennspiel, Arcade, Puzzle, Lernspiel für Kinder, Wortspiel, 3D) erstelle das Projekt mit template: "web-game" und lies .agents/skills/omg-web-game-builder/SKILL.md anstatt eine Engine zu entwerfen. Sein Schritt 1 kommt vor jeder Code-Bearbeitung: bun run dev im Hintergrund auf Port 5174, dann omg_expose_port mit Port 5174 und ohne expoGo, dann teile dem Benutzer mit, dass die Vorschau in der Karte unten bereit ist. Die Expo-Vorschauschritte in dieser Fähigkeit (Port 8081, expoGo: true) gelten nicht für ein Web-Spiel. Verwende template: "expo-game" und .agents/skills/omg-game-builder/SKILL.md nur, wenn der Benutzer nach einem Spiel fragt, das auf iPhone oder Android installiert werden soll, oder Expo oder eine native App nennt.

• Für eine Expo-App beginne mit der verwalteten expo-Vorlage und folge dem unten stehenden "Expo-App: Der schnelle Weg". Passe deren Bildschirme und deren Datenspeicher an, anstatt die Konfiguration neu aufzubauen. Behalte Geheimnisse in gehosteten Server-Routen. Ein nativer Produktions-Build benötigt einen bereitgestellten Server an einem sicheren Ursprung; behandle einen Sandbox-Tunnel nicht als Produktions-Hosting.

• Verwende einen Live-Metro-Server für Expo Web und Expo Go in einem Cloud-Computer. Mache seinen Port über omg_expose_port verfügbar; nimm keine globale Expo CLI, Xcode, einen Simulator oder maschinenspezifische Tools an.

• Wenn die App mit Expo Go kompatibel ist, setzt omg_expose_port den exps:// Expo Go-Link auf eine Vorschaubildkarte in der omg.dev-App. Sage dem Benutzer, dass die Vorschau bereit ist, und dass er sie von der Karte unten aus öffnen soll. Füge die rohe exps://-URL nicht in deine Antwort ein; die Karte zeigt sie bereits. Füge sie nur ein, wenn der Benutzer die Karte nicht sehen kann, z. B. in einer Antwort, die mit omg_send_to_origin an einen Messaging-Kanal gesendet wird, oder wenn der Benutzer nach dem Link fragt. Verwende keinen Expo-Tunnel, keine LAN-Exposition, kein exp.direct und kein ngrok. Wenn Expo Go ein erforderliches natives Modul nicht laden kann, verwende einen Entwicklungs-Build, wenn dies autorisiert ist, oder melde diese Einschränkung klar.

• TestFlight, App Store-Einreichung, kostenpflichtige Dienste, Domains und Drittanbieter-Produktionskonten sind separate Bereitstellungsaktionen. Führe sie nur aus, wenn der Benutzer sie anfordert und das erforderliche Konto verfügbar ist. TestFlight benötigt das Expo-Konto des Benutzers und ein kostenpflichtiges Apple Developer-Konto, aber ein EAS-Cloud-Build benötigt kein Xcode oder keinen Mac in der Sandbox. Verwende unterstützte Login-Abläufe und frage niemals nach Passwörtern oder Token im Chat.

Expo-App: der schnelle Weg

Ein neuer Benutzer wartet. Der erste Bildschirm muss innerhalb von etwa 3 Minuten sein Telefon erreichen, bevor Feature-Arbeit beginnt. Befolge diese Schritte der Reihe nach:

1. omg_create_project mit template: "expo". Wenn node_modules fehlt, führe einmal bun install aus.
2. Vorschau, bevor du Code schreibst. Rufe omg_expose_port mit Port 8081 und expoGo: true auf. Führe dann bash scripts/start-expo-preview.sh <expoGo.proxyUrl> 8081 aus dem Projektverzeichnis aus, mit einem Shell-Timeout von 240000 ms. Wenn es Sandbox proxy answers: HTTP 200 ausgibt, präsentiere zuerst die Web-Vorschau: "Ihre App ist bereit. Die Karte unten zeigt sie laufend an, und sie funktioniert auf jedem Gerät." Erwähne dann das Telefon in einem Satz: "Um sie auf Ihrem eigenen Telefon auszuprobieren, tippen Sie auf Ihr Telefon auf der Karte." Wenn das Ergebnis von omg_expose_port simulatorAvailable: true hat, füge einen weiteren Satz hinzu: "Sie können sie auch auf einem iPhone direkt in der Karte ausprobieren: Tippen Sie auf Simulator." Versprich den Simulator nicht, wenn dieses Feld falsch oder nicht vorhanden ist. Füge expoGo.url nicht ein; die Karte zeigt ihn. Metro lädt die App bei jedem Speichern neu, sodass die Vorschau Ihren Bearbeitungen von hier an folgt.
3. Schreibe die Bildschirme in einigen größeren Bearbeitungen, anstatt einer kleinen Bearbeitung pro Turn. Ersetze den Vorlagen-Startbildschirm in src/app/index.tsx; füge keine zweite Index-Route hinzu.
4. Führe bun run typecheck aus und behebe, was es meldet. Es überprüft auch die Routen und schlägt bei einem zweiten Startbildschirm oder einem Stammverzeichnis app/ fehl. Führe dann bun run check:ui aus, öffne seine PNGs und behebe, was falsch ist (siehe Build-Schritt 4). Schreibe keine automatisierten Tests, es sei denn, der Benutzer fragt danach.
5. Stelle einmal mit omg_deploy bereit (siehe unten). Die Daten bleiben auf dem Telefon, dies ist also ein statischer Web-Build.
6. Beende mit omg_ship.

Durchsuche nicht node_modules, rufe keine Dokumentation ab und lese die Vorlage nicht Datei für Datei vor der ersten Vorschau: die Zusammenfassung unten ist ausreichend. Schreibe keine eigenen Browser-Testschleifen oder Screenshot-Skripte: bun run check:ui erledigt das. Wenn du Bilder nicht anzeigen kannst, lies nur seinen Textbericht.

Die Vorlage:

• src/app/index.tsx: der Startbildschirm und die einzige Datei für /. Ersetze ihren Inhalt durch deinen Startbildschirm. Behalte jeden Bildschirm in src/app/: Expo Router ignoriert einen Stammordner app/, während src/app existiert. Für Tabs verschiebe den Startbildschirm nach src/app/(tabs)/index.tsx und lösche src/app/index.tsx, da beide auf / antworten und der alte gewinnt. Die Vorlagendatei hat einen Header, eine Eingabe mit einer Hinzufügen-Schaltfläche, eine Liste mit Umschalten und Löschen, eine Fehlerkarte und eine Neuladen-Schaltfläche. Stile sind in einem StyleSheet unten; die Themenkonstanten sind oben (INK, CORAL, BACKGROUND, SURFACE, SURFACE_BORDER).
• src/app/_layout.tsx: ein Expo Router Stack ohne Header, innerhalb von KeyboardProvider. Ein neuer Bildschirm ist eine neue Datei in src/app/ (stats.tsx ist /stats). Navigiere mit router.push("/stats") oder <Link href="/stats"> von expo-router.
• src/lib/tasks.ts: die Daten, auf dem Telefon mit AsyncStorage (localStorage im Web) gespeichert. tasksApi.list(), create(title), update(id, patch), remove(id). Behalte diese Datei. Kopiere für jede neue Art von Element seine Form mit seinem eigenen Speicherschlüssel.
• Icons: lucide-react-native, zum Beispiel <Plus color={CORAL} size={22} />. Glasflächen: GlassView von expo-glass-effect.
• Farben: setze jede Themenkonstante aus dem Design, bevor du Bildschirme stylst. Karten, Zeilen und Blätter verwenden die eigene Oberflächenfarbe des Designs. Die durchscheinend weiße SURFACE der Vorlage passt nur zu ihrem hellen Starter; auf einem dunklen oder farbigen Design wird jede Karte weiß. Verwende GlassView nur, wo das Design Milchglas zeigt. Auf Android zeichnet es kein Glas, gib ihm daher eine Hintergrundfarbe.
• Safe Areas: umschließe jeden Bildschirm mit SafeAreaView von react-native-safe-area-context mit edges={["top", "bottom"]}, oder verwende useSafeAreaInsets(). Importiere niemals SafeAreaView von react-native: es ist nur iOS, daher geht auf Android der Header unter die Statusleiste und die Tab-Leiste unter die Gestenleiste.
• Tastatur: setze Bildschirme mit einer Texteingabe in KeyboardAwareScrollView von src/lib/keyboard (bottomOffset={24}, keyboardShouldPersistTaps="handled"), wie die Vorlage es tut. Für ein Feld, das am unteren Rand fixiert ist, verwende KeyboardStickyView aus derselben Datei. Importiere sie von src/lib/keyboard, niemals direkt von react-native-keyboard-controller: ihr .web.tsx-Zwilling hält den statischen Web-Export funktionsfähig. Verwende nicht KeyboardAvoidingView von React Native: auf iOS bewegt sich der Bildschirm nach der Tastatur, langsam.

Daten: speichere sie standardmäßig auf dem Telefon, mit dem tasks.ts-Muster. Verwende gehostete Daten nur, wenn der Benutzer nach Konten oder zwischen Personen geteilten Daten fragt. Füge dann die Anmeldung mit @omg-dev/sdk und .scoped("user")-Sammlungen in schema.ts hinzu. Rufe niemals /api/... mit einem rohen fetch auf: eine gehostete Sammlung antwortet einem anonymen Telefon mit 401 Authentication required.

Für gehostete Daten installiere die neueste Version von @omg-dev/sdk und stelle das Backend bereit, bevor du seine gemeinsamen Daten in Metro testest. Behalte .omg/project.json im Projektverzeichnis. Die gehostete Web-Vorschau verwendet diese registrierte App-Identität und meldet ihren Besitzer über das SDK an. Verwende <VibesAuthProvider> und SDK-Anfragen. Füge kein separates Vorschau-Login hinzu, leite keine Dashboard-Cookies weiter und ersetze nicht die App-Berechtigungen des Benutzers. Ein physisches Telefon benötigt noch die normale Anmeldung der App und den bereitgestellten Backend-Ursprung.

Metro-Regeln: verwende nur die Ports 8081 bis 8099, da Expo Go-Links nur in diesem Bereich funktionieren. Starte Metro nur mit dem Skript; npx und ss sind nicht auf jedem Computer installiert.

Bausteine (Expo)

Die Vorlage liefert getestete Helfer in src/kit/. Importiere sie; schreibe sie nicht neu. Sie funktionieren auf iOS, Android und Web. Jede Datei beginnt mit einem Kommentar, der ihre Verwendung zeigt.

• overlay.tsx: useConfirm() und useSheet(). <OverlayProvider> ist bereits in _layout.tsx. Verwende if (await confirm({ title, destructive: true })) für jedes Löschen oder Bestätigen. Alert.alert mit Schaltflächen tut nichts im Web. Verwende useSheet().open(node) für Blätter und Formulare. Stapele keine Modal-Komponenten: die zweite zeichnet hinter der ersten im Web.
• ActionRow.tsx: eine drückbare Zeile mit einer Lösch- oder anderen Aktion daneben. Eine Schaltfläche, die in einer drückbaren Zeile verschachtelt ist, feuert auch die Zeile im Web.
• image.ts: await toPersistentImage(pickerAsset). Rufe den Picker mit base64: true, quality: 0.5 auf und speichere den zurückgegebenen String. Ein Picker-URI im Web ist eine blob:-URL, die nach einem Neuladen verschwunden ist.
• use-timer.ts: usePersistedTimer(key, durationMs) mit start, pause, resume, reset und formatClock. Es speichert die Endzeit, sodass ein Neuladen es nicht zurücksetzt. Verwende es für jeden Timer oder Countdown.
• use-viewport.ts: useViewport() und useIsWide(). Im statischen Web-Export kann useWindowDimensions() beim ersten Rendern Breite 0 ergeben. Bevorzuge flex und maxWidth; verwende den Hook nur, wenn du eine Zahl benötigst.

Zwischen Personen geteilte Daten (eine gemeinsame Liste, ein Handel, eine Gruppe): verwende den gehosteten @omg-dev/sdk-Pfad in "Daten" oben. Schreibe keinen lokalen Server. Wenn ein lokaler Server unvermeidbar ist, antworte auf OPTIONS und sende diese Header auf jede Antwort: Access-Control-Allow-Origin mit dem Anforderungs-Origin (oder *), Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,OPTIONS und Access-Control-Allow-Headers: content-type,authorization. Ein fehlendes PUT oder DELETE schlägt nur im Browser fehl.

Build

1. Konvertiere die Anfrage in eine kleine, beobachtbare Erledigungsbedingung. Triff vernünftige optische und technische Entscheidungen, wenn der Benutzer sie nicht spezifiziert hat.
2. Gerüste innerhalb des Projektverzeichnisses. Installiere für eine verwaltete Expo-Vorlage ihre fixierten Abhängigkeiten und bewahre .omg/template.json; ersetze sie nicht durch einen anderen Starter. Installiere für ein leeres Projekt die aktuell dokumentierten Abhängigkeiten und Konfigurationen. Installiere keine veraltete omg.dev CLI und frage den Benutzer nicht nach Infrastruktur-Token; Laufzeit-Tools stellen die Cloud-Anmeldeinformationen bereit.
3. Implementiere den echten Pfad. Wenn das Produkt gemeinsame Daten, Authentifizierung, Uploads oder Server-Arbeit benötigt, verwende die dokumentierten gehosteten APIs und überprüfe Persistenz und Zugriffskontrolle. Ersetze angefragtes gemeinsames Verhalten nicht mit Mock-Daten oder browser-only-Speicher.
4. Schreibe keine automatisierten Tests, es sei denn, der Benutzer fragt danach. Überprüfe stattdessen mit der Selbstprüfung: führe bun run typecheck, dann bun run check:ui aus. Die Prüfung erstellt den Web-Export, startet das server- oder backend-Skript der App, falls vorhanden, öffnet jede Route bei 390x844 und speichert ein PNG pro Route in .omg/ui-check/. Sie meldet leere Seiten, Error Boundaries, Konsolenfehler, fehlgeschlagene Anfragen, einen abgestürzten Server und Schaltflächen oder Links, die ein anderes Element abdeckt (z. B. eine "Hinzufügen"-Schaltfläche unter einer Tab-Leiste). Öffne dann jedes PNG mit dem Bildbetrachter und vergleiche es mit der Anfrage und eventuellen Design-Referenzen. Behebe, was falsch ist, und führe die Prüfung erneut aus, bis der Bericht sauber ist. Gib an, welche Oberfläche du überprüft hast; ein Web-Lauf ist kein Beweis für natives Verhalten.
5. Aktualisiere die README mit dem Produktzweck, dem lokalen Ausführungsbefehl, der Architektur und den Bereitstellungshinweisen. Committe den fertigen Quellcode lokal, sodass spätere omg.dev-Sitzungen von einer vollständigen Baseline ausgehen.

Anmeldung für eine gehostete Web-App

omg.dev besitzt die Anmeldung für Apps unter <slug>.omgs.app. Baue niemals ein Anmeldeformular, ein Passwortfeld oder deinen eigenen Sitzungsspeicher.

• Privat (Standard): jeder Besucher meldet sich bei omg.dev an, bevor die App geöffnet wird. Die App benötigt keine Anmelde-UI.
• Öffentlich mit Anmeldung: verwende dies, wenn der Benutzer eine Landingpage für Besucher möchte. Setze die App auf public ui

…

[gekürzt für die Übersetzung]