Von der Idee bis zum App Store — Release-Harness für Flutter/Flame-Spiele (Claude-Code-Plugin)
(github.com/tjdrhs90)Ich veröffentliche ein Claude-Code-Plugin als Open Source, das Flutter/Flame-Spiele von „Idee → Planung → Entwicklung → QA → Store-Einreichung“ begleitet.
Nachdem ich selbst mehrere Flame-Spiele gebaut und in die Stores gebracht habe, habe ich die immer wiederkehrenden Abläufe und Fallen, in die man jedes Mal erneut tappt, als Harness in Code gegossen. Kein „Vibe Coding“, sondern Delegation des Prozesses an KI — Guardrails → Plan → Generator↔Evaluator-Build-Loop → menschliches Review.
Ablauf: Idee (falls keine vorhanden ist, Empfehlung durch KI) → Plan → Design → Vertrag über Fertigstellungskriterien → Generator↔Evaluator-Loop → Mensch spielt selbst und gibt frei → AdMob·Build·Screenshots·Einreichung
Merkmale
- Skeptischer Evaluator — der Evaluator entscheidet nicht nur anhand des Codes, ob etwas durchgeht, sondern startet das Spiel tatsächlich und bewertet es. Selbst wenn die QA bestanden ist, stoppt der Prozess vor dem Release am Gate für menschliche Freigabe
- Immer spielbar, selbst mit Sourcing 0 — codegeneriertes Audio + per Code gezeichnete Visuals (keine externen Assets nötig)
- Bis hin zu einem „releasefähigen Erscheinungsbild“ — Custom Icon, Splash Screen und App-Name, native Fixierung der Ausrichtung, Entfernung von iPad, verpflichtende Play-Grafiken (512-Icon + 1024×500-Feature-Grafik), automatisches Ausfüllen von Store-Metadaten und Review-Informationen, inklusive CI
- Praxis-Fixes aus 7 veröffentlichten Spielen integriert — Audio-Pooling, Haptik, App-Lifecycle, Vermeidung von ATT-Rejections (2.1), Konsistenz der Bundle-ID usw.
- PRD und UI werden in der Sprache erzeugt, in der der Nutzer kommuniziert (Koreanisch/Englisch)
Das Harness Design von Anthropic (Trennung von Generator und Evaluator · Datei-Handoff · skeptische QA) wurde auf die Domäne des Game-Releases angewendet.
Repo: https://github.com/tjdrhs90/flutter-flame-harness
Feedback ist willkommen 🙏
Noch keine Kommentare.