GreenlightCAUTION

Pre-submission compliance scanner for the Apple App Store and Google Play. Scans code, privacy manifests, Android manifests, and IPA/APK/AAB binaries against the review guidelines. Offline, no account.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: greenlight
description: >
  Pre-submission compliance scanner for the Apple App Store and Google Play. Use this skill
  when reviewing iOS, macOS, tvOS, watchOS, visionOS, or Android app code (Swift, Objective-C,
  Kotlin, Java, React Native, Expo) to identify store rejection risks before submission, including
  Android manifest and Gradle policy checks and built APK/AAB inspection. Triggers on tasks
  involving app review preparation, compliance checking, App Store or Play submission readiness,
  target API level deadlines, restricted permissions, or when a user asks about App Store
  guidelines or Google Play Developer Program Policies.
---

# Greenlight — App Store Pre-Submission Scanner

You are an expert at preparing iOS apps for App Store submission. You have access to the `greenlight` CLI which runs automated compliance checks. Your job is to run the checks, interpret the results, fix every issue, and re-run until the app passes with GREENLIT status.

## Step 1: Run the scan

Run `greenlight preflight` immediately on the project root. Do NOT try to install greenlight — it is already available in PATH. Just run it:

```bash
greenlight preflight .
```

If the user has a built IPA, include it:
```bash
greenlight preflight . --ipa /path/to/build.ipa
```

If `greenlight` is not found, install it:
```bash
# Homebrew (macOS)
brew install revylai/tap/greenlight

# Go install
go install github.com/RevylAI/greenlight/cmd/greenlight@latest

# Build from source
git clone https://github.com/RevylAI/greenlight.git
cd greenlight && make build
# Binary at: build/greenlight
```

## Step 2: Read the output and fix every issue

Every finding has a severity, guideline reference, file location, and fix suggestion. Fix them in order:
1. **CRITICAL** — Will be rejected. Must fix.
2. **WARN** — High rejection risk. Should fix.
3. **INFO** — Best practice. Consider fixing.

When fixing issues:
- **Hardcoded secrets** → Move to environment variables (use `process.env.VAR_NAME` or Expo's `Constants.expoConfig.extra`)
- **External payment for digital goods** → Replace Stripe/PayPal with StoreKit/IAP for digital content. External payment is only OK for physical goods.
- **Social login without Sign in with Apple** → Add `expo-apple-authentication` alongside Google/Facebook login
- **Account creation without deletion** → Add a "Delete Account" option in settings
- **Platform references** → Remove mentions of "Android", "Google Play", "Windows", etc.
- **Placeholder content** → Replace "Lorem ipsum", "Coming soon", "TBD" with real content
- **Vague purpose strings** → Rewrite to explain specifically WHY the app needs the permission (not just "Camera needed" but "PostureGuard uses your camera to analyze sitting posture in real-time")
- **Hardcoded IPv4** → Replace IP addresses with proper hostnames
- **HTTP URLs** → Change `http://` to `https://`
- **Console logs** → Remove or gate behind `__DEV__` flag
- **Missing privacy policy** → Note that this needs to be set in App Store Connect

## Step 3: Re-run and repeat

After fixing issues, re-run the scan:
```bash
greenlight preflight .
```

**Keep looping until the output shows GREENLIT status (zero CRITICAL findings).** Some fixes can introduce new issues (e.g., adding a tracking SDK requires ATT). The scan runs in under 1 second so re-run frequently.

## Severity Levels

| Level | Label | Action Required |
|-------|-------|----------------|
| CRITICAL | Will be rejected | **Must fix** before submission |
| WARN | High rejection risk | **Should fix** — strongly recommended |
| INFO | Best practice | **Consider fixing** — improves approval odds |

The goal is always: **zero CRITICAL findings = GREENLIT status.**

## Step 4 (optional): Validate flow-dependent guidelines at runtime

GREENLIT means the *static* checks pass — but some guidelines can only be confirmed by
running the flow. Static analysis sees that a `deleteAccount` string exists and suppresses
the §5.1.1 warning; it cannot see that the button is wired to nothing. Apple tests these
flows manually, so a static pass here is a false sense of security.

If the project claims a flow-dependent feature (account creation, in-app purchases, or
social login), validate it on a cloud device with `greenlight verify`:

```bash
# See which flows the app claims and the exact tests that would run — no device needed:
greenlight verify . --dry-run

# Run them on a cloud device (needs the revyl CLI + `revyl auth login` + a registered build):
greenlight verify . --build-name "<your Revyl build>" \
  --var email=<test account> --var password=<test password>

# Have a local build that isn't on Revyl yet? Upload it as part of the run with
# --artifact. Revyl runs on cloud simulators, so pass a simulator .app (iOS) or
# an .apk (Android) — NOT a device .ipa. A new --build-name registers a new app.
greenlight verify . --build-name "<your Revyl build>" --artifact ./build/MyApp.app \
  --var email=<test account> --var password=<test password>
```

`verify` runs each claimed flow on-device via Revyl and reports:
- **VERIFIED** — the flow works.
- **FAILED** — the flow passed static analysis but broke at runtime (e.g. account-deletion
  dead-ends, Restore Purchases is a no-op, Sign in with Apple is a dead button). Fix the
  wiring — not just the presence of the string — and re-run.
- **SETUP** — could not run (not authenticated, no build, no device). Resolve and retry.
  If the build just isn't on Revyl yet but you have a local simulator `.app`/`.apk`,
  pass it with `--artifact` to upload and run in one step.

Treat a FAILED flow exactly like a CRITICAL: it will get the app rejected. The app is only
truly submission-ready when `preflight` is **GREENLIT** *and* `verify` reports no failed flows.

> `verify` is the only greenlight command that is not offline — it needs the `revyl` CLI and
> a Revyl account. If `revyl` isn't installed or the user hasn't set up a build, run the
> static checks (Steps 1–3) and note that runtime v

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (1)

Keep looping until the output shows GREENLIT status (zero CRITICAL findings).

Gates applied: no_behavioural_pass.

[![ModelsAtlas audit: Greenlight](https://modelsatlas.com/skills/revylai/greenlight/badge.svg)](https://modelsatlas.com/skills/revylai/greenlight/)

Not your listing, or something out of date? Claim or update your listing.