store-review-preflight
Skill4 starsChanged 3 months agoMITView on GitHub
Preflight a mobile app before App Store or Google Play submission. Audits the codebase, build config and store metadata against the Apple App Review Guidelines, Apple build requirements (privacy manifests, required-reason APIs, SDK signatures, Xcode/SDK minimums) and Google Play policies (Data safety, target API, account deletion, permissions, Families), then writes an evidence-backed rejection-risk report. Use when the user is about to submit, asks "will this pass review", "is the app ready for the App Store / Play", "check store compliance", got a rejection or an ITMS-/Play Console error, is preparing TestFlight external testing or a production release, or ships an Expo, React Native, Capacitor, Flutter or native iOS/Android app.
In this repository4 other files it gives its agents.
- ai-act-auditSkill
- privacy-auditSkill
- project-workshop-generatorSkill
- store-listingSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Conservative verdicts: Prefer 🟠 over a false 🟢 and over a false 🔴.
- Distinctive: line 30
Done when: all seven items are written down or listed as open questions, existing store/compliance documents are listed, and each …
- Very specific: line 34
Read references/01-signals.md.
- Distinctive: line 36
Done when: every capability row has a status and, if found, at least one path.
- Distinctive: line 42
Done when: every gate is 🟢, 🔴 or ❓-with-command.
- Distinctive: line 48
Done when: every found capability maps to rule IDs, and every not-found capability category is recorded as ⚪ with a reason.
- Distinctive: line 52
Read only the triggered files:
- Distinctive: line 64
Check each triggered row: pass / fail / uncertain, with evidence and citation.
- Distinctive: line 66
Done when: every triggered rule has a verdict, evidence and citation.
- Distinctive: line 72
Done when: every checklist row is verified, user-confirmed, or listed as unknown.
- Very specific: line 82
Read references/00-method.md first in every run: verdict scale, evidence classes, freshness protocol, triage matrix.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Store Review Preflight
Audit the app before the reviewer does. Every finding is a rule (a policy clause) or a gate (a binary build/upload requirement), backed by evidence from the repo, the build artifact, the store console or the listing.
Output: a report built from assets/report-template.md. The audit is read-only: never upload, submit, publish, or run store CLIs.
Ground rules
- Evidence or ❓. A verdict needs a file path and line, a command output, a user-confirmed console value, or a listing quote. No evidence → ❓ Unverified, with the exact thing to check.
- Cite the rule ID for every finding (
Apple 5.1.1(v),Play: User Data → Account deletion). - Respect confidence tags. Rows tagged
Tcome from training knowledge, not from a page read on 2026-11-05. Re-open the live source (URLs inreferences/00-method.md§4) before issuing 🔴 on aTrow. - Conservative verdicts. Prefer 🟠 over a false 🟢 and over a false 🔴. Never promise approval: reviewers apply judgement.
- Hand off depth. Privacy disclosures, consent and SDK data flows belong to the
privacy-auditskill when installed; this skill checks only that the disclosures exist, are consistent with the code, and satisfy the store rule.
Workflow
Step 1 — Frame the target
Record: platforms (iOS, Android, both), stack (see references/01-signals.md §1), first submission vs update, developer account type (individual vs organization: it changes Apple 5.1.1(ix) and the Google testing requirement), monetization model, audience age, regions. Ask the user for unknowns in one batch.
Then read what the project already has: docs/, store/, fastlane/, store and compliance notes, and scripts named like *check*, *store*, *review*. Treat documented mitigations as claims to verify, not as findings and not as proof (a fallback contact address, a feature flag, a pre-submission script that is never run automatically).
Feature flags and EXPO_PUBLIC_*/env switches decide which code ships. Their production values live in the build environment (K): list each flag that gates a store-relevant feature and ask the user for its production value.
Done when all seven items are written down or listed as open questions, existing store/compliance documents are listed, and each store-relevant flag has a value or an open question.
Step 2 — Inventory capabilities
Read references/01-signals.md. Search the repo for each capability signal and fill the capability table (found / not found + path).
Done when every capability row has a status and, if found, at least one path.
Step 3 — Run the gates
Gates fail uploads or builds regardless of reviewer opinion. Read references/apple-06-technical-gates.md for iOS and references/google-02-technical-gates.md for Android. Run the commands each gate lists; mark gates that need a build artifact as ❓ and hand the user the exact command.
Done when every gate is 🟢, 🔴 or ❓-with-command.
Step 4 — Triage rules
Open the triage matrix in references/00-method.md §5. For each capability found in Step 2, list the rule IDs it triggers and the reference files that hold them.
Done when every found capability maps to rule IDs, and every not-found capability category is recorded as ⚪ with a reason.
Step 5 — Assess triggered rules
Read only the triggered files:
| File | Covers |
apple-01-safety.md | Guideline 1: content, UGC, kids, health, developer info |
apple-02-performance.md | Guideline 2: completeness, metadata, hardware, software requirements |
apple-03-business.md | Guideline 3: In-App Purchase, subscriptions, other payment methods, crypto |
apple-04-design.md | Guideline 4: copycats, minimum functionality, spam, extensions, Sign in with Apple |
apple-05-legal.md | Guideline 5: privacy, data use, health, kids, location, IP, gambling, VPN |
google-01-policies.md | Play Developer Program Policy: content, user data, permissions, families, monetization, ads |
07-common-rejections.md | Field patterns behind most rejections, with the fix |
Check each triggered row: pass / fail / uncertain, with evidence and citation.
Done when every triggered rule has a verdict, evidence and citation.
Step 6 — Console and listing checklist
Code cannot show App Store Connect or Play Console state. Walk assets/console-checklist.md with the user (screenshots or exports are fine). Draft reviewer notes from assets/review-notes-template.md.
Done when every checklist row is verified, user-confirmed, or listed as unknown.
Step 7 — Report
Fill assets/report-template.md. Order the fix list: upload-blocking gates, then 🔴 rules, then 🟠, then metadata, then 🟡. Every 🔴 and 🟠 carries a concrete fix and an effort estimate (S/M/L).
Done when no 🔴/🟠 finding lacks a fix, and the report states what it could not verify.
Reference navigation
Read references/00-method.md first in every run: verdict scale, evidence classes, freshness protocol, triage matrix.
Stack-specific traps (Expo config plugins, Capacitor native projects, WebView wrappers, OTA updates) live in references/08-stack-notes.md. Non-store regulation that blocks a release (EU DSA trader status, US state age-assurance laws, accessibility) lives in references/09-regulatory-gates.md.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.