AnilBurcu Run a pre-release audit for $ARGUMENTS (default: both platforms). Verify in the actual project files; never assume. Output a pass/fail table with evidence, so the user can fix failures and rerun.
Check, with the eas-release skill as the rulebook:
- Versioning: user-facing version bumped since the last release tag; build numbers set to auto-increment or manually bumped; git tag plan stated.
- OTA fence: runtime version policy present; if any native dependency or config plugin changed since the last store build, flag that this release MUST be a store build and OTA publishing to old channels is forbidden until it ships.
- Permissions honesty: cross-check declared permissions and usage strings (Info.plist keys, Android permissions) against what the code actually imports. Camera/mic/location/notification strings present where used, and no leftover permissions from removed features, which reviewers flag.
- Secrets scan: grep the source and app config for things that must not ship: private API keys, service-role or server keys, live payment secrets, hardcoded backend admin URLs. Public/publishable keys are fine; call out anything ambiguous.
- Store hygiene: account deletion path exists if accounts exist; restore purchases reachable if IAP exists; sign-in options meet platform rules; privacy labels and data safety answers match the SDK list (list the SDKs that collect data so the user can compare).
- Config sanity: production build profile points at production backend; no debug flags, staging URLs or test paywalls behind release config; app icon and splash present for both platforms.
- Quality gates: typecheck, lint and tests pass; if there is a preview/QA build lane, confirm the release candidate went through it.
Rules of engagement: read-only plus running the project's own check commands. Findings come back as blocker vs warning, each with file evidence. End with a plain verdict: ready to submit, or the ordered list of what blocks it.