Android Go-Live Checklist

Generate, maintain, and walk a user through a Play Store launch checklist for any Android app or game project, regardless of stack (native Android, Flutter, React Native, Unity, etc.).

Modes

This skill operates in five distinct modes. Detect which one the user wants from their message:

1. Generate - first-time creation of go-live-checklist.md (default if file does not exist).
2. Recreate - user asks to "recreate", "regenerate", "redo" the checklist. Use existing file as reference, redo research + code analysis, then update the file (preserving DONE/SKIPPED/CANCELLED status where items still apply).
3. Walkthrough - user asks to "walk me through", "go through the checklist", "start the walkthrough", "next item". Iterate items by severity, one at a time.
4. Update status - user says "mark X done", "skip Y", "cancel Z". Update the file in place.
5. Summary - user asks "what's left", "show me the summary", "status of checklist". Read the file and report a severity-grouped summary.

If a mode is ambiguous, ask the user which they want. Do not guess.

Mode 1: Generate

Step 1: Detect Android project - exit early if not Android

Before doing anything else, verify this is an Android project. Check for ANY of these signals:

• android/ directory at repo root (Flutter, React Native, Cordova, Ionic projects)
• app/build.gradle or app/build.gradle.kts
• AndroidManifest.xml anywhere in tree
• pubspec.yaml with flutter: section AND an android/ subdirectory
• package.json with react-native dependency AND an android/ subdirectory
• ProjectSettings/ directory with Unity Android build target enabled
• Native Kotlin/Java source under src/main/java/ or src/main/kotlin/

If NONE of these signals are present, stop immediately. Tell the user: "This does not appear to be an Android project. Skill only runs on Android apps/games. Detected: [briefly say what kind of project it looks like, or 'no recognizable project structure']."

Do not proceed past this gate. The user can override by explicitly saying "force-run anyway".

Step 2: Web research current Play Store publishing requirements

Use WebSearch + WebFetch to research the current Play Console publishing process. The Play Store rules change frequently - never rely on training-data knowledge alone. Research at minimum:

• Play Console account setup and developer registration fee (currently $25 USD, verify)
• App content forms required: Privacy Policy, App Access, Ads, Content Rating, Target Audience, News, COVID-19 contact tracing, Data Safety form, Government apps, Financial features, Health
• Store listing requirements: title (≤30 chars), short description (≤80), full description (≤4000), graphic assets (icon 512×512, feature graphic 1024×500, screenshots, promo video)
• Technical requirements: target SDK level (research current minimum required), 64-bit support, app bundle (AAB) format, app signing by Google Play, max APK/AAB size
• Pricing & distribution: countries, free/paid, in-app products
• Testing tracks: internal, closed (alpha), open (beta), production rollout strategy
• Pre-launch report and Play App Signing setup
• Recent policy changes (data safety, Families policy, subscriptions, etc.)
• Google Cloud OAuth consent screen publication requirements and verification process (sensitive/restricted scope verification timeline)
• Meta App Dashboard Live mode requirements
• Google Maps Platform billing requirements

Cite the official support.google.com / developer.android.com / play.google.com/console URLs in the checklist so the user can verify.

Step 3: Deep codebase analysis

Use the project's available tooling first. If the code-review-graph MCP is available, prefer get_architecture_overview_tool, semantic_search_nodes_tool, and query_graph_tool over Grep/Glob - they are faster and give structural context. Fall back to Grep/Read for anything the graph doesn't cover.

Determine the stack and adapt the analysis. At minimum, check:

Universal (every Android project)

• applicationId in build.gradle(.kts) - is it production-ready (not com.example.*)?
• versionCode and versionName - sane values?
• minSdk, targetSdk, compileSdk - meet current Play Store requirements?
• Signing config - release keystore present? keystore.properties referenced? Is there a .gitignore entry to keep secrets out of git?
• ProGuard / R8 rules - minifyEnabled true for release? Custom rules for any reflection-heavy libs?
• App icon - adaptive icon present (mipmap-anydpi-v26/ic_launcher.xml)? Or still default Flutter/RN icon?
• App name in AndroidManifest.xml - still default?
• Permissions in manifest - any unused or sensitive ones (LOCATION, CAMERA, READ_CONTACTS) that need justification?
• INTERNET permission and any network security config
• Deep links / intent filters - configured if needed
• Splash screen - using Android 12+ SplashScreen API?
• Localization - strings.xml translated for target markets?
• Crash reporting - Crashlytics, Sentry, etc. wired up?
• Analytics - Firebase Analytics, GA4, Mixpanel set up?

*Firebase (if `google-services.json` present or `firebase_` deps in pubspec)**

• google-services.json present and matches production project (not dev/staging)?
• RTDB security rules deployed and reviewed (no ".read": true / ".write": true)?
• Firestore security rules deployed and reviewed?
• Storage rules if Storage used?
• Auth providers enabled in console - match what the app uses?
• App Check enabled for production?
• Cloud Functions deployed (if any)?
• Firebase project quotas / billing plan adequate (Spark vs Blaze)?

In-App Purchases (if `billing-client`, `in_app_purchase`, `react-native-iap`, RevenueCat detected)

• Product IDs in code match what needs to be created in Play Console?
• BILLING permission in manifest?
• Server-side receipt verification implemented (or RevenueCat handling it)?
• Test accounts / license testers documented?
• Subscriptions: base plans, offers, grace periods configured?

Ads (if `play-services-ads`, `google_mobile_ads`, AdMob detected)

• AdMob app ID in AndroidManifest.xml - production ID, not test?
• ads.txt entries for the app?
• Families policy compliance if app targets children?
• Consent flow (UMP SDK) for EEA/UK users?

Game-specific (if Unity, Unreal, Flame, or game engines detected)

• Play Games Services configured (sign-in, achievements, leaderboards)?
• Cloud save?
• Game services credentials linked to Play Console game project?

Flutter-specific

• flutter build appbundle succeeds in release mode?
• All --dart-defines for production set in build script / CI?
• Obfuscation: --obfuscate --split-debug-info for release?
• iOS-only code paths gated correctly?

React Native-specific

• Hermes enabled?
• New architecture status (Fabric/TurboModules)?
• react-native-config env vars set for production?

Google Sign-In / OAuth (if `google-sign-in`, `firebase_auth` with Google provider, `play-services-auth`, or `GoogleSignIn` detected)

• OAuth consent screen in Google Cloud Console: branding complete? (app name, logo, support email, homepage URL, privacy policy URL, ToS URL)
• OAuth app publication status: must be Published (not "In testing") - users outside the test user list get "Error 403: access_denied" at runtime. APIs & Services > OAuth consent screen > Publishing status
• SHA-1 and SHA-256 release fingerprint registered in Firebase console or Google Cloud credentials (not just debug fingerprint)
• Authorized redirect URIs include production deep link / custom scheme (not just localhost)
• If app was submitted for Google verification (branding screen appears for all users): verification approved before launch?

Google Maps SDK (if `play-services-maps`, `google_maps_flutter`, or `mapbox` detected)

• API key in AndroidManifest.xml restricted to production applicationId + release SHA-256 (not unrestricted)
• Maps SDK API enabled in Google Cloud Console for production project
• Billing account linked to Google Cloud project (Maps requires billing even on free tier)
• MY_MAP_KEY or similar: not the same key used in dev/staging (rotate if shared)

Meta / Facebook SDK (if `facebook-android-sdk`, `flutter_facebook_auth`, `react-native-fbsdk`, or `com.facebook.android` detected)

• App in Meta App Dashboard must be in Live mode, not "In Development" - production users cannot authenticate or use Facebook features in development mode. Meta App Dashboard > App > Settings > Status
• Android platform registered with production applicationId and release key hash (not just debug key hash)
• Privacy Policy URL and App Icon set in Meta dashboard (required for Live mode)
• Business Verification completed if app requests advanced permissions

Twitter / X API (if `twitter-kit`, `twitter-android-sdk`, or OAuth Twitter flow detected)

• App environment set to "Production" in developer portal (not "Staging")
• Callback URLs include production scheme
• Elevated access tier if required for app use case

Backend / API

• API base URLs - production vs dev/staging?
• Hardcoded secrets / API keys in source? (grep for likely patterns)
• Rate limiting / abuse protection?

Play Console account-level manual setup (always check, not code-detectable)

• Developer account identity verification complete (Google now requires ID verification for new accounts)
• Merchant account set up and linked if app is paid or uses IAP - Play Console > Setup > Payments profile
• Tax information submitted in Payments profile (required to receive payouts)
• D-U-N-S number or equivalent if app is published under an organization account
• App created in Play Console and assigned to correct developer account (not a personal test account)
• Upload key (vs app signing key) distinction understood - if using Play App Signing, upload keystore ≠ signing key; document both

Make the list specific to what was actually found. Do not include generic "set up Firebase" if Firebase isn't used. Do not list "configure IAP" if there's no billing dependency.

Step 4: Compile go-live-checklist.md

Write to repo root: go-live-checklist.md. Use this exact structure:

# Go-Live Checklist

**Created:** YYYY-MM-DD HH:MM (timezone)
**Last updated:** YYYY-MM-DD HH:MM (timezone)
**Project:** <detected project name>
**Stack:** <e.g., Flutter + Firebase + Flame + RTDB>

## Summary

| Severity | Total | PENDING | DONE | SKIPPED | CANCELLED |
|---|---|---|---|---|---|
| CRITICAL | N | N | N | N | N |
| HIGH | N | N | N | N | N |
| MEDIUM | N | N | N | N | N |
| LOW | N | N | N | N | N |

**Top blockers (CRITICAL, PENDING):**
- [ ] Item 1
- [ ] Item 2

## CRITICAL

### [PENDING] C1. <Short title>
**What:** <one-sentence description>
**Why critical:** <why this blocks launch>
**Where:** <file path or "Play Console > Setup > App Integrity">
**How:** <concrete steps; include exact form fields or code snippets>
**Reference:** <URL>

### [PENDING] C2. ...

## HIGH

### [PENDING] H1. ...

## MEDIUM
...

## LOW
...

---

## Change log
- YYYY-MM-DD HH:MM - Created
- YYYY-MM-DD HH:MM - Marked C1 DONE

Group external-console manual actions into their own labeled block within the appropriate severity tier so they stand out from code-level items. Use a comment like <!-- External console action: cannot be verified from code --> in the markdown (hidden from rendered view) so future recreations know not to auto-resolve these from code analysis. Example heading:

### [PENDING] C3. Publish OAuth consent screen in Google Cloud Console
**What:** OAuth app status is "In testing" - production users outside the test list receive Error 403: access_denied when signing in with Google.
**Why critical:** Silent auth failure for all real users; blocks launch.
**Where:** Google Cloud Console > APIs & Services > OAuth consent screen > Publishing status
**How:** Click "Publish App". If app requests sensitive/restricted scopes, a Google verification form appears - submit it before launch (verification can take weeks).
**Reference:** https://support.google.com/cloud/answer/10311615

Severity definitions (include these as a footer):

• CRITICAL - Play Store will reject the app, or the app will not function at launch
• HIGH - Strongly recommended before launch (security, store listing quality, IAP revenue)
• MEDIUM - Should do soon after launch if not before (analytics, polish)
• LOW - Nice-to-have, post-launch

Use stable IDs (C1, C2, H1, ...) so they can be referenced in conversation and survive recreations.

Step 5: Report a summary

After writing the file, output a short summary to the user: total items per severity, top 3 CRITICAL blockers, and an offer: "Want me to walk through these one at a time?"

Mode 2: Recreate

1. Read the existing go-live-checklist.md to capture current statuses.
2. Re-run web research (Step 2 above) - Play Store rules may have changed.
3. Re-run code analysis (Step 3 above) - codebase has likely changed.
4. Diff the new findings against the old file:

• Items that still apply and were DONE → keep DONE
• Items that still apply and were SKIPPED → keep SKIPPED
• Items that still apply and were CANCELLED → keep CANCELLED
• Items that no longer apply → remove (and note in change log)
• New items → add as PENDING

1. Update timestamps: keep Created, refresh Last updated. Append change log entry.
2. Report what changed since last generation.

Mode 3: Walkthrough

The user wants to be guided through the items. Present one task at a time in severity order (CRITICAL first, then HIGH, MEDIUM, LOW) and within each tier in numeric order (C1, C2, ...).

For each PENDING item:

1. Show the full item: title, what, why, where, how, reference URL.
2. If it's a Play Console form (e.g., Data Safety, Content Rating), walk the user through each form field with suggested answers based on the codebase. Example: if the app uses Firebase Analytics, the Data Safety form needs to declare "Analytics" data collection.
3. Wait for the user's response. Possible responses:

• "done" / "completed" / "did it" → mark DONE, move to next
• "skip" / "skip this" → mark SKIPPED, move to next
• "cancel" / "not doing this" → mark CANCELLED, move to next
• "later" / "pause" → stop walkthrough, do not change status
• Question → answer it, then re-prompt for status

1. After updating status, write the change to go-live-checklist.md immediately (do not batch). Append a change log entry.
2. Move to next PENDING item.

Skip items that are already DONE / SKIPPED / CANCELLED.

When done with a severity tier, briefly announce "All CRITICAL items handled, moving to HIGH" so the user knows where they are.

Mode 4: Update status

User says something like "mark C1 done" or "skip H3 and H4". Parse the IDs, update the file, append change log, confirm the change.

Mode 5: Summary

Read the file. Output the summary table plus all PENDING items grouped by severity. No code analysis or web research - fast read-only mode.

Status values

Only these four values, all uppercase:

• PENDING - not yet acted on (default)
• DONE - user completed the task
• SKIPPED - user explicitly skipped
• CANCELLED - user explicitly cancelled (different from SKIPPED - implies item is not applicable / abandoned)

Always render in the heading bracket: ### [DONE] C3. App icon.

Quality bar

The checklist's value depends entirely on how specific and accurate it is. A generic "set up Firebase rules" is useless; "Review database.rules.json lines 14-22 - currently allows unauthenticated writes to /matches/" is actionable.

• Cite file paths and line numbers wherever possible.
• For Play Console items, name the exact menu path: Play Console > [App] > Policy > App content > Data safety.
• For form fields, suggest concrete answers grounded in what the codebase actually does.
• Never invent libraries or features the project does not use.
• Never omit items just because they're tedious - the checklist exists to catch them.

Things to avoid

• Do not write the checklist before completing the research and code analysis. Premature drafting produces generic, low-value content.
• Do not include items that don't apply to this project (e.g., "configure subscriptions" if there's no IAP code).
• Do not use em dashes in the checklist (project's CLAUDE.md prohibits them in user-facing text - and the user reads this file).
• Do not lose user-set statuses when recreating. The whole point of recreation is to refresh detection while preserving the user's progress.
• Do not silently overwrite the file. Always append to the change log.
• Do not skip external console manual actions just because they are not detectable from code. OAuth consent screen publication status, Meta App Live mode, Maps API key restrictions, merchant account setup, and developer identity verification are all launch blockers that live entirely outside the codebase. If a service SDK is detected, always include its corresponding external-console checklist items even if the code itself looks correct.
• Do not assume "In testing" OAuth mode is acceptable for soft launch. Even a 1-user production rollout will fail for any user not on the test list.