Die AGENTS.md ist die Bedienungsanleitung Ihres Repositorys für Coding-Agenten wie OpenAI Codex. In Mobile-Projekten entscheidet sie darüber, ob der Agent sinnvoll baut und testet oder ob er an Zertifikaten herumschraubt und Projektdateien beschädigt. Dieser Ratgeber zeigt, welche Inhalte in eine AGENTS.md für iOS- und Android-Apps gehören, wie Sie Regeln für Signierung und Veröffentlichung formulieren und wie Store-Anforderungen schon während der Entwicklung mitgeprüft werden.
Warum Mobile-Projekte eigene Regeln brauchen
Bei Web-Projekten genügt oft ein Satz wie npm test vor jedem Commit. Mobile-Projekte sind komplexer: Es gibt zwei Plattformen, unterschiedliche Build-Werkzeuge, Simulatoren und Emulatoren, empfindliche Projektdateien und Konfigurationen, die direkte Auswirkungen auf das Store-Review haben. Ein Agent ohne Anleitung probiert Befehle aus, installiert fehlende Werkzeuge an falscher Stelle oder ändert Bundle-IDs, weil ein Build-Fehler das scheinbar nahelegt.
Die AGENTS.md wird von Codex automatisch gelesen, auch in verschachtelten Ordnern. Damit können Sie für ios, android und ein gemeinsames Modul jeweils eigene, kurze Regeln ablegen, die nur dort gelten.
Diese Abschnitte gehören hinein
Eine praxistaugliche AGENTS.md für ein Mobile-Projekt enthält mindestens folgende Bausteine, jeweils knapp und als konkrete Anweisung formuliert:
- Sie beschreiben den Projektaufbau in wenigen Sätzen: Frameworks, Ordner, gemeinsame und plattformspezifische Teile.
- Sie nennen die exakten Befehle für Installation, Build, Unit-Tests, UI-Tests und Lint je Plattform, inklusive Simulator- oder Emulatorname.
- Sie definieren, wann eine Aufgabe als erledigt gilt, etwa grüne Tests auf beiden Plattformen und keine neuen Lint-Warnungen.
- Sie legen Code-Konventionen fest, etwa Architekturmuster, Benennung und den Umgang mit Übersetzungen.
- Sie formulieren Verbote, zum Beispiel keine Änderungen an Signing, Entitlements, Bundle-ID oder applicationId ohne Rückfrage.
- Sie listen Store-relevante Pflichten auf, die bei jeder Änderung mitzudenken sind.
Signing-Regeln eindeutig formulieren
Formulieren Sie Signing-Regeln so, dass kein Interpretationsspielraum bleibt. Gute Beispiele: Zertifikate, Provisioning Profiles, Keystores und deren Passwörter werden niemals ins Repository geschrieben. Die Signing-Konfiguration in Xcode und in der build.gradle wird nicht verändert. Release-Builds entstehen ausschließlich in der CI. Schlägt ein Build wegen Signierung fehl, bricht der Agent ab und beschreibt das Problem, statt es zu umgehen.
Ergänzen Sie, welche Konfigurationsdateien zwar existieren, aber geheim sind, etwa eine lokale Datei mit Schlüsseln, die in der gitignore steht. So weiß der Agent, warum sie fehlt, und versucht nicht, sie neu anzulegen.
Ebenso wichtig sind Regeln für Identitäten. Bundle-ID, applicationId, App-Gruppen und Associated Domains wirken harmlos, sind aber mit bestehenden Store-Einträgen und Backend-Konfigurationen verknüpft. Eine geänderte applicationId bedeutet für Google Play eine völlig neue App. Schreiben Sie deshalb ausdrücklich hinein, dass diese Werte unveränderlich sind, und nennen Sie die richtigen Werte für Debug- und Release-Varianten. So verhindern Sie, dass ein Agent beim Beheben eines Build-Fehlers versehentlich eine zweite App erzeugt, die sich nicht mehr als Update der bestehenden installieren lässt.
Store-Checks direkt im Entwicklungsalltag
Viele Ablehnungen lassen sich vermeiden, wenn der Agent bei jeder Änderung an bestimmte Pflichten erinnert wird. Nehmen Sie Regeln auf wie: Neue Berechtigungen benötigen einen verständlichen Begründungstext in Info.plist und eine Prüfung, ob das Privacy Manifest angepasst werden muss. Neue SDKs werden in einer Liste mit Zweck und Datenarten dokumentiert, damit App Privacy Labels und Data-safety-Formular aktuell bleiben. Jede Registrierungsfunktion braucht eine In-App-Kontolöschung. Digitale Inhalte werden nur über In-App-Käufe verkauft.
Diese Regeln ersetzen keinen Review-Prozess, sorgen aber dafür, dass Probleme beim Entstehen auffallen und nicht erst eine Woche vor dem Release. Bitten Sie Codex zusätzlich, am Ende jeder Aufgabe ausdrücklich zu melden, ob einer dieser Punkte berührt wurde.
AGENTS.md gemeinsam erarbeiten
Eine gute AGENTS.md entsteht iterativ: Jedes Mal, wenn der Agent etwas falsch macht, wird die Regel ergänzt, die das künftig verhindert. In den Workshops von neooutput erarbeiten wir mit Ihrem Team Playbooks für AGENTS.md und CLAUDE.md direkt an Ihrem Repository, inklusive Review-Regeln und Teststrategie für iOS und Android. Vereinbaren Sie ein kostenloses 15-Minuten-Erstgespräch.
Häufige Fragen
Wie lang sollte eine AGENTS.md sein?
So kurz wie möglich, so ausführlich wie nötig. Eine bis zwei Bildschirmseiten im Hauptverzeichnis plus kurze Ergänzungen in Unterordnern haben sich bewährt.
Kann ich dieselbe Datei für Claude Code verwenden?
Claude Code liest standardmäßig die CLAUDE.md. Viele Teams pflegen die Inhalte an einer Stelle und verweisen aus der anderen Datei darauf, damit beide Agenten dieselben Regeln kennen.
Gehören Secrets-Namen in die AGENTS.md?
Die Namen von Umgebungsvariablen und Secrets dürfen hinein, damit der Agent sie korrekt referenziert. Die Werte selbst gehören niemals in die Datei oder ins Repository.