--- name: app-roentgen description: Durchleuchtet eine Android-App systematisch und vollstaendig wie ein Roentgengeraet — extrahiert ALLE Funktionen, Bildschirme, Klick-Pfade, Paywall-Stufen und Hidden Features aus dem Quellcode, damit Werbeaussagen 1:1 gegen die tatsaechliche Funktionalitaet geprueft werden koennen. Nutze diesen Skill IMMER wenn der Benutzer sagt "App durchleuchten", "App roentgen", "Roentgen-Skill", "App-Architektur extrahieren", "Feature-Inventar", "was kann die App genau", "Werbeaussagen pruefen", "Werbeaussagen-Audit", "UWG-Audit", "Paywall-Audit", "Marketing-Compliance", "Feature-Audit", "Compliance-Pruefung", "App-Analyse fuer Rechtssicherheit", "rechtssichere Werbung pruefen", "stimmt was wir versprechen mit der App ueberein", "App komplett analysieren", "alle Funktionen einer App auflisten", oder generell jede Android-App systematisch durchleuchtet werden soll. Auch triggern bei Voice-Schreibweisen wie "Roentgen", "X-Ray", "Durchleuchten" im Kontext von Apps. Funktioniert fuer beliebige Android-Apps (modernes Kotlin/Compose bevorzugt, Java/XML wird auch unterstuetzt). Erzeugt einen sehr detaillierten strukturierten Audit-Bericht mit allen Bildschirmen, Klick-Pfaden, Paywall-Stufen, Permissions-Mappings und einer Werbeaussage-vs-Feature-Matrix. --- # App-Roentgen: Vollstaendiges Architektur- und Werbeaussagen-Audit fuer Android-Apps ## Kernzweck Der Skill durchleuchtet eine Android-App so gruendlich, dass am Ende eine 100-Prozent-vollstaendige Liste vorliegt was die App in jedem einzelnen Bildschirm, bei jedem Klick und in jedem Abbruchpfad genau tut. Ziel ist Rechtssicherheit: Wenn eine Werbeaussage behauptet "Unbegrenzte KI-Analysen" muss der Skill verifizieren ob das im Code wirklich stimmt — oder ob ein Limit von 150 pro Tag drin ist. Der finale Bericht hat vier Teile: 1. **Architektur-Inventar** — alles was die App kann, in 15 Kategorien gegliedert 2. **Wortlaut-Mapping pro Bereich** — fuer JEDEN Bildschirm, Dialog, Bottom-Sheet, jedes Menue und jedes Untermenue (rekursiv, beliebige Tiefe), jedes Settings-Item, jede Notification, jeden Snackbar/Toast/Error-State werden die exakten 1:1-Wortlaute zitiert 3. **Translation-Context** — pro Wortlaut die Daten die ein Uebersetzer braucht (Laengen, xliff:g, Notes, Plurals, HTML, Format-Argumente, Glossar, Du/Sie-Konsistenz) 4. **Werbeaussage-vs-Feature-Matrix** — jede beworbene Aussage gegen die Code-Realitaet geprueft Der Bericht dient zwei nachgelagerten Konsumenten: - **Rechtssicherheits-Skill** — prueft Wortlaute gegen UWG, EU UCPD, DSGVO, Google Play Policy - **Uebersetzungs-Skill** — uebersetzt Wortlaute mit voller Context-Information (Slot, Laenge, Plural-Regeln, Glossar, Argumente) ## Warum 1:1-Wortlaute (KRITISCH) Der Rechtssicherheits-Skill, der nach dem Roentgen-Audit laeuft, prueft jede Formulierung gegen UWG, EU UCPD, Google Play Policy, DSGVO und Verbraucherschutzrecht. **Schon ein einziges falsches oder fehlendes Wort kann eine Abmahnung ausloesen** — Beispiele: "Geld zurueck" statt "Geld-zurueck-Garantie unter Bedingungen X", "unbegrenzt" statt "bis zu 150/Tag", "anonym" statt "pseudonym". Deshalb gilt fuer ALLE Wortlaute im Bericht: | Regel | Bedeutung | |-------|-----------| | **1:1 woertlich** | Exakte Zeichenfolge inkl. Satzzeichen, Gross-/Kleinschreibung, Sonderzeichen, Umlauten, Leerzeichen | | **In Anfuehrungszeichen** | Jeder Wortlaut wird in `"..."` zitiert um sichtbar zu machen wo er anfaengt und endet | | **Mit Quelle** | Datei + Zeile + String-Resource-Key (`strings.xml:42 → R.string.paywall_unlimited_ai`) | | **Pro Sprache** | Wenn die App mehrsprachig ist, jeden Wortlaut in allen Sprachen zitieren | | **Keine Zusammenfassung** | Niemals "der Text sagt sinngemaess..." — IMMER der Original-Text | | **Plurals + Formate** | Auch `` und Format-Strings mit `%s`/`%d` werden so wie sie im Code stehen zitiert | **Verbotsliste:** - ❌ "Headline lautet etwa 'Premium starten'" - ❌ "Im Dialog steht eine Bestaetigungsfrage" - ❌ Nur den String-Key zitieren ohne den Wortlaut - ❌ Bei langen Texten kuerzen mit "..." **Verpflichtend:** - ✅ `Headline (paywall_title @ strings.xml:88): "Jetzt Premium starten und alle Vorteile sichern"` - ✅ `Bestaetigung (delete_confirm_title): "Wirklich loeschen?" / Body (delete_confirm_body): "Diese Aktion kann nicht rueckgaengig gemacht werden."` ## Wann triggern Frank sagt typischerweise Phrasen wie "Lass die BestJournal mal durchleuchten", "Roentgen-Audit fuer App XY", "Werbeaussagen-Pruefung fuer Paywall", "Was macht die App wirklich". Der Trigger ist absichtlich grosszuegig — lieber einmal zu oft als einmal zu wenig. Der Skill wird typischerweise vor einem Marketing-Audit oder vor einem Release ausgefuehrt, oder wenn die Frage aufkommt ob die App das wirklich macht was sie verspricht. ## Pflicht-Vorgehen: Die 7 Schichten der Durchleuchtung Reihenfolge ist wichtig. Jede Schicht baut auf der vorherigen auf. KEINE Schicht ueberspringen — sonst entstehen Luecken im Audit und der Roentgen-Effekt geht verloren. ### Schicht 1 — Manifest-Analyse: Was darf die App? Liest `app/src/main/AndroidManifest.xml` und extrahiert alles was deklariert ist: Permissions, Activities, Services, Receiver, ContentProvider, Intent-Filter, Deep-Links, Backup-Konfiguration. Jede Permission impliziert Features (CAMERA → Foto-Capture, RECORD_AUDIO → Voice-Input). → **Detail-Anleitung**: `references/layer-1-manifest.md` → **Permission-zu-Feature-Tabelle**: `references/permission-feature-map.md` ### Schicht 2 — Dependency-Analyse: Was kann die App technisch? Liest `build.gradle.kts`, `libs.versions.toml`, `settings.gradle.kts`. Jede Bibliothek impliziert Capabilities (firebase-messaging → Push, play-billing → Paywall, mlkit-* → KI/ML, room-runtime → Datenbank). Auch Pruefung ob Dependencies aktiv genutzt werden oder tot sind. → **Detail-Anleitung**: `references/layer-2-dependencies.md` ### Schicht 3 — Architektur-Inventar: Wie ist die App gebaut? Extrahiert alle ViewModels, Repositories, UseCases, Hilt-Module, Room-Entities, Workers (WorkManager). Das ergibt das Skelett der App: welche Daten existieren, welche Business-Logik laeuft, welche Background-Jobs gibt es. Jeder ViewModel = ein Feature-Cluster. → **Detail-Anleitung**: `references/layer-3-architecture.md` ### Schicht 4 — Bildschirm-Karte: Was sieht der Nutzer? Extrahiert jeden einzelnen Compose-Screen, jede Navigation-Route, jeden Click-Handler, jeden Side-Effect (LaunchedEffect mit Navigation), jeden Dialog, jedes Bottom-Sheet. Erzeugt eine Bildschirm-Karte als Mermaid-Diagramm UND als Baum. Fuer jeden Bildschirm wird dokumentiert: - Wie kommt der Nutzer dorthin (alle Entry-Points) - Welche Klicks/Aktionen sind moeglich - Wohin fuehrt jeder Klick - Welche Side-Effects gibt es - Welche State-Klassen existieren (sealed class XxxState) - **Alle 1:1-Wortlaute auf dem Screen** (siehe Schicht 4b) → **Detail-Anleitung**: `references/layer-4-screens-and-flows.md` ### Schicht 4b — Wortlaut-Mapping pro Bereich (PFLICHT — Grundlage fuer Rechtssicherheit) Fuer JEDEN Bereich der App werden die exakten Wortlaute extrahiert und einer Tabelle zugeordnet: Screens, Dialoge, Bottom-Sheets, Snackbars, Toasts, Error-States, Empty-States, Loading-States, Push-Notifications, Menues, Settings-Items. **Menues werden rekursiv aufgeloest, beliebige Tiefe.** Wenn Settings einen Eintrag "Konto" hat, der zu "Sicherheit" fuehrt, der wiederum "2FA" enthaelt mit Unter-Optionen "Backup-Codes" → JEDE dieser Ebenen bekommt eine eigene Wortlaut-Tabelle. Keine Abkuerzungen, kein "und so weiter". → **Detail-Anleitung**: `references/layer-4b-wortlaut-mapping.md` ### Schicht 4c — Translation-Context (PFLICHT — Grundlage fuer Uebersetzungs-Skill) Pro Wortlaut werden die Daten erfasst die ein Uebersetzer braucht, damit eine korrekte Lokalisierung moeglich ist: - **Slot-Laengen-Audit** — passt der Text in seinen UI-Slot, wird er nach der Uebersetzung noch passen? - **`translatable="false"`** — welche Strings sind explizit gesperrt (Markennamen, Versionen, URLs) - **`xliff:g`-Tags** — welche Inline-Teile sind nicht-uebersetzbar (Beispiele in Format-Strings) - **XML-Kommentare als Uebersetzer-Notizen** — `` - **CLDR-Plural-Vollstaendigkeit pro Sprache** — Russisch braucht `few`/`many`, Arabisch braucht `zero`/`two` - **HTML/CDATA-Inhalte** — werden bei Uebersetzung oft zerstoert - **Format-Argument-Semantik** — was bedeutet `%1$s`, was `%2$d` - **Glossar-Auto-Erkennung** — haeufige Begriffe die konsistent uebersetzt werden muessen - **Region-Differenzen** — pt-rBR vs pt-rPT, zh-rCN vs zh-rTW - **Du/Sie-Konsistenz** (Deutsch) — Mischanrede wird geflaggt → **Detail-Anleitung**: `references/layer-4c-translation-context.md` ### Schicht 4d — Legal-Text-Inventar (PFLICHT — Grundlage fuer Rechtssicherheits-Skill) 12 rechtlich obligatorische Wortlaut-Bereiche werden vollstaendig erfasst: - Permission-Rationale-Dialoge (pro Permission Title/Body/Allow/Deny-Verhalten) - Consent-Banner (Analytics, Tracking, Marketing — gleichrangige Akzeptieren/Ablehnen-Buttons?) - AGB-, Datenschutz- und Impressums-Links (mit Erreichbarkeit + Sprachvarianten) - Health-Disclaimer (bei Fitness-/Mental-Health-Apps) - AI-Disclaimer (EU AI Act + FTC) - Werbe-Markierungen (UWG §5a — Schleichwerbung) - Account-Deletion-Flow (DSGVO Art. 17 — Wort "unwiderruflich" Pflicht) - Newsletter-/Marketing-Opt-In (UWG §7 Double-Opt-In) - In-App-Kauf-Confirmation (Google Play Subscriptions Policy) - Widerrufsbelehrung (BGB §312g — sonst Frist 12 Monate) - Standort-Begruendung (Play Console seit 2024) - Altersfreigabe-Anzeige (USK/PEGI/IARC) → **Detail-Anleitung**: `references/layer-4d-legal-text-inventory.md` ### Schicht 4e — Externe Inhalte (ergaenzend — Audit ueber die App hinaus) Wortlaute die NICHT im Code-Repository leben aber genauso UWG-/Werberecht-relevant sind: - Google Play Store Listing (Title, Short/Long Description, Screenshot-Texte) — Frank-Aufgabe oder Fastlane-Metadata - Firebase Remote Config Defaults + Live-Werte - Cloud Functions Notification-Templates (Trial-End, Subscription-Status) - Email-Templates (Firebase Auth, Stripe, Sendgrid) - WebView-Inhalte (HTML in assets/ oder externe URLs) - PDF-Export-Vorlagen (oft DE-hardcoded) - Customer-Support-System (Intercom, Zendesk) - Marketing-Materialien (Webseite, Promo-Videos, Social-Media-Bios, Newsletter-Archiv) → **Detail-Anleitung**: `references/layer-4e-external-content.md` ### Schicht 5 — Paywall-Tiefenanalyse: Der WICHTIGSTE Bereich Hier wird mit besonderer Sorgfalt gearbeitet, weil Werbeaussagen rund um die Paywall am haeufigsten rechtlich problematisch sind. Jeder einzelne Subscription-State, jeder Abbruchpfad, jeder Trial-Schritt, jeder Promo-Code, jeder Win-Back-Flow wird dokumentiert. Ergebnis-Tabelle pro Paywall-Bildschirm: - Trigger (wo wird er ausgeloest) - Angezeigte Plaene (Monthly, Yearly, Promo, Trial) - Pflichtangaben (Preis, Laufzeit, Kuendigung, Auto-Renewal) — pro Bildschirm pruefen - Abbruchpfade und was bei jedem passiert - Welcher Subscription-State zeigt welche UI Auch alle 22 Real-Time-Developer-Notification-Typen werden dokumentiert mit ihrem UI-Verhalten. → **Detail-Anleitung**: `references/layer-5-paywall.md` → **Komplette Subscription-State-Machine**: `references/subscription-state-machine.md` ### Schicht 6 — Hidden Features aufdecken Background-Jobs (WorkManager-Worker), Widget-Provider, Quick-Tile-Services, App-Shortcuts, Accessibility-Services, Print-Adapter, NFC-Handler, Boot-Receiver, Notification-Channels, Debug-Menus (Long-Click-Trigger), Feature-Flags via Remote-Config, A/B-Test-Varianten, Account-Deletion-Flows (DSGVO-Pflicht). Diese werden oft in Audits uebersehen. Ohne sie ist das Inventar nicht vollstaendig. → **Detail-Anleitung**: `references/layer-6-hidden-features.md` ### Schicht 7 — Werbeaussagen-vs-Feature-Matrix Jetzt werden die Werbeaussagen aus diesen Quellen zusammengetragen: - `res/values/strings.xml` (alle User-facing Texte) - `res/values-*/strings.xml` (alle Sprachen) - Google Play Store Listing (Long Description, Short Description, Feature-Bullets) - Onboarding-Texte - Push-Notification-Templates - Settings-Texte Fuer jede Aussage wird gegen das Feature-Inventar geprueft. Output-Tabelle: | Aussage | Quelle | Code-Realitaet | Luecke | Risiko (UWG/EU/Google) | Fix-Vorschlag | Risiko-Stufen: KRITISCH / HOCH / MITTEL / NIEDRIG nach UWG §5, EU UCPD, Google Play Policy. → **Detail-Anleitung**: `references/layer-7-marketing-claim-audit.md` ## Master-Skript fuer den ersten Scan Statt alle Greppable-Patterns einzeln auszufuehren, gibt es ein Master-Skript das den ersten Scan automatisiert macht und einen strukturierten Initial-Bericht erzeugt: ```bash bash ~/.claude/skills/app-roentgen/scripts/feature-scan.sh ``` Das Skript schreibt einen Initial-Bericht ins App-Verzeichnis als `app-roentgen-initial-scan.md`. Dieser ist die Basis fuer die Tiefenanalyse durch Claude in den 7 Schichten. ## JSON-Schnittstelle fuer maschinelle Konsumenten Parallel zum Markdown-Bericht kann ein strukturierter JSON-Export erzeugt werden, den der Rechtssicherheits-Skill und der Uebersetzungs-Skill konsumieren koennen: ```bash python3 ~/.claude/skills/app-roentgen/scripts/export-json.py ``` Output: `/app-roentgen-export.json` mit Schema-Version 2.0. Der Export enthaelt: alle Strings mit Hash + Translatable-Flag + Format-Args + xliff:g-IDs + Slot-Laenge, Plurals mit CLDR-Vollstaendigkeitspruefung pro Sprache, Glossar, Du/Sie-Konsistenz, SDK-Erkennung (AI/Ads/Billing/Health/WebView/Firebase), Permission-Liste. Der JSON-Export ist optional — er wird nur erzeugt wenn der Konsument ihn explizit braucht. Das Markdown-Format reicht fuer den manuellen Audit. ## Output-Format des finalen Berichts Der finale Bericht wird in der App-Wurzel als `app-roentgen-AUDIT-YYYY-MM-DD.md` gespeichert. Die Struktur folgt dem Template `assets/audit-report-template.md`. Pflichtbestandteile: 1. **Zusammenfassung** (3-4 Saetze fuer Frank in einfachem Deutsch) 2. **Schicht 1-7 Detail-Berichte** mit allen extrahierten Daten 3. **Komplette Bildschirm-Karte** (Mermaid + Baum) 4. **Paywall-Bildschirm-Inventar** (sehr detailliert, eigener Hauptabschnitt) 5. **15-Kategorien-Feature-Inventar** (siehe `references/layer-7-marketing-claim-audit.md`) 6. **Werbeaussage-vs-Feature-Matrix** (sortiert nach Risiko) 7. **Don't-Miss-Checkliste** mit Haken pro Punkt (siehe `references/dont-miss-checklist.md`) 8. **Empfohlene naechste Schritte** (was muss vor Release gefixt werden) ## Vollstaendigkeits-Validierung (PFLICHT) Bevor der Bericht als fertig gilt, MUSS die `dont-miss-checklist.md` durchgegangen werden — alle 40 Punkte muessen geprueft sein. Jeder Punkt der nicht geprueft werden konnte wird mit "NICHT_VERIFIZIERT — Grund" markiert. Das ist die letzte Verteidigungslinie gegen unvollstaendige Audits. → **Liste**: `references/dont-miss-checklist.md` ## Verhalten bei Unklarheit Wenn ein Code-Pfad mehrdeutig ist und der Skill nicht eindeutig sagen kann was die App macht, MUSS das im Bericht als "UNKLAR — bitte manuell pruefen" markiert werden. Lieber ehrlich Luecken zugeben als fadenscheinige Vermutungen abgeben — der Audit ist die Basis fuer Rechtssicherheit, da darf nichts verfaelscht sein. ## Greppable-Patterns als Werkzeugkasten Alle systematischen Suchmuster sind in `references/greppable-patterns.md` gesammelt. Diese Datei ist die taktische Referenz — sie wird vom Master-Skript genutzt und kann auch manuell konsultiert werden wenn ein bestimmter Bereich noch tiefer untersucht werden soll. → **Patterns**: `references/greppable-patterns.md` ## Beispiel-Anwendung: BestJournalAndroid Der typische erste Anwendungsfall fuer Frank ist `~/proggs/BestJournalAndroid/`. Beim ersten Lauf werden die Ergebnisse in `~/proggs/BestJournalAndroid/app-roentgen-AUDIT-YYYY-MM-DD.md` geschrieben. Das ist die Vorlage fuer den nachfolgenden Werbeaussagen-Audit (Memory `project_bestjournal_paywall_marketing_audit.md`). ## Schreibstil im Bericht Da der Bericht spaeter als juristische Grundlage dienen kann, gilt: - **Praezise**: Keine Vermutungen ohne Beleg. Jede Aussage mit Datei + Zeilennummer belegen. - **Vollstaendig**: Lieber zu viele Details als zu wenige. - **Strukturiert**: Tabellen wo immer moeglich, damit der Leser scannen kann. - **Ehrlich**: Wenn etwas unklar ist, das ausdruecklich vermerken. - **Auf Deutsch fuer die Zusammenfassungs-Bloecke**, technische Bezeichner und Code-Snippets bleiben in Originalsprache. ## Zusammenspiel mit anderen Skills | Skill | Zusammenspiel | |-------|--------------| | `rechtssicherheit` | Liest Schicht 4b (Wortlaute) + Schicht 7 (Werbeaussagen-Matrix) und prueft gegen die Wissensbasis in `~/proggs/rechtssicherheit.md` | | `uebersetzung` | Liest Schicht 4b (Original-Wortlaute) + Schicht 4c (Translation-Context: Slot, Laenge, Plurals, Glossar, Argumente) als Uebersetzungs-Grundlage | | `string-extraktor` | Komplementaer zu Schicht 4c — der Extraktor findet hardcoded Strings, der Roentgen-Skill katalogisiert sie inklusive Slot-Zuordnung | | `app-monetizer` | Konsumiert die Paywall-Tiefenanalyse (Schicht 5) als Input | | `superintelligenz` | Bei sehr grossen Apps (>500 Kotlin-Dateien) parallele Researcher fuer einzelne Schichten spawnen | ## Was NIEMALS passieren darf - ❌ Audit als "fertig" markieren ohne die Don't-Miss-Checkliste durchgegangen zu sein - ❌ Werbeaussagen aus nur einer Sprache pruefen — IMMER alle uebersetzten strings.xml einbeziehen - ❌ Paywall-Bildschirme oberflaechlich abhaken — jeder Bildschirm bekommt eine eigene Sub-Tabelle - ❌ Vermutungen ohne Code-Beleg im Bericht stehen lassen - ❌ Versteckte Features (Feature-Flags, Debug-Menus, Background-Jobs) wegen Aufwand auslassen - ❌ Bei Unklarheit raten — stattdessen "UNKLAR" markieren und dem Benutzer melden - ❌ Wortlaute zusammenfassen, paraphrasieren oder kuerzen — IMMER 1:1 in `"..."` zitieren - ❌ Nur den String-Key nennen ohne den Wortlaut auszuschreiben - ❌ Menue-Tiefen abkuerzen mit "und weitere Untermenues" — JEDE Ebene komplett ausrollen, egal wie tief - ❌ Settings/Preferences als Sammelblock abhandeln — jedes Item bekommt eine eigene Zeile mit Label + Beschreibung + ggf. Switch-/Dropdown-Werten - ❌ Dialog-Texte nur teilweise zitieren (z.B. nur Title) — IMMER Title + Body + alle Buttons komplett - ❌ Plurals, Format-Strings (`%s`, `%d`) und Array-Resources ignorieren