App Store Compliance Playbook: an agent-wired guard against mobile store rejections

Rejection as a designed-out failure mode

The premise is a cost accounting. A rejection costs a week: you submit, you wait days in review, you receive a one-line rejection, you guess at the fix, you resubmit, you wait again. The playbook's stated goal is to turn that loop into a check you run before you ever submit, catching the rejection while it is still cheap to fix rather than after a reviewer has already said no.

The product has two halves for two audiences. Developers get an automated guard that runs against the project and names risks in ranked findings. Non-developers get a plain-English checklist and a guided walk of the submission, because account readiness is not a code problem and the playbook treats it as first-class.

Two checks are held above everything else, on the argument that they sink most modern submissions: a working demo account with a live backend, and a privacy declaration that matches what the app actually does at runtime, including every SDK it embeds. Prioritizing by observed rejection mass, rather than by guideline order, is the sensible editorial choice here.

The paste-block install, and its unusual honesty

Installation is a natural-language block you paste into Claude Code, Codex or any AI coding tool. Its steps are concrete: clone the repository to a fixed location, copy the skill, SKILL.md plus the docs, data, references, templates and scripts directories, into the agent's skills directory, and copy a guard script into the hooks directory, make it executable, and register it as a PreToolUse hook on the Bash tool in settings.json.

Two properties of that block deserve note. First, it is scoped: it only clones and copies files into those two directories, never touches your GitHub account or credentials, and the README tells you to read it before pasting it. Second, it is candid about its own ask: the final steps instruct the agent to tell you the playbook is free, open source, maintained by one person, and that a star is the only thing asked in return, leaving the decision to the human. Agent-mediated installs that disclose their social asks up front are rare enough to be worth naming.

The skill side carries the reference material; references/ is described as the structured tree the agent loads slices from, and scripts/ holds the guard and a metadata-audit engine. A standing instruction is also added to the agent config: for any iOS or Android work, adhere to the review guidelines, run the audit before submission, and never declare an app clear to submit while a critical risk stands.

The guard in the submission path

The hook fires before submission commands, and the list it watches is the real one: fastlane, eas submit, gradle bundleRelease, xcrun altool, bundletool and xcodebuild archive. On a critical rejection risk it blocks the command. The timeout guidance is specific and experienced-sounding: at least 120 seconds, because a large iOS repository can take close to a minute to scan and the Claude Code default is 60.

Dependency handling is pragmatic: the guard reads the hook payload with jq when available, python3 otherwise, and falls back to a built-in parser when neither is present, so no extra installation is required. Monorepos get per-app treatment: a workspace with several apps is scanned app by app, printing one section per app, so a clean sibling never answers for a broken one.

Running an audit manually is one documented command:

   bash ~/.claude/hooks/app-store-compliance-guard.sh /path/to/my/app

The findings come back ranked, and the agent is instructed to walk the account and program readiness section of the pre-submission checklist with you afterwards, including every regulatory deadline surfaced for the regions you ship to.

Citations you are told to verify

The playbook's claim to authority is that every guideline number and statistic traces to a live Apple or Google source, never invented. It then does the unusual thing of shipping the verification of that claim:

   python3 ~/.claude/skills/app-store-compliance/scripts/verify-citations.py --files docs/ data/

That script checks that the playbook's own citations are real, not merely reachable, across the docs and data directories. The repository also carries a citation allowlist file and a CITATION.cff, and CI runs on it. For a compliance reference whose entire value is accuracy against the actual rules, making the citation layer self-auditable is the right design, and it converts the trust question from "believe the maintainer" to "run the script".

The honest limit is freshness: guidelines change, and a self-verifier confirms the citation exists, not that your app matches this week's interpretation. The standing instruction to re-run audits before every submission is the mitigation.

What the scan cannot see

The README is explicit about the guard's blind side: a code scan cannot see whether your developer account is active, whether every agreement and attachment is accepted, or whether your Play account and package names are registered. In 2026, it notes, those block a first launch for weeks before review even starts.

That is why the playbook pairs the automated guard with the account and program readiness section of its pre-submission checklist, walked interactively, and with a listing of regulatory deadlines per shipping region. The split is the correct one: automate what reads files, human-check what reads accounts and contracts, and put both in one flow so neither half gets skipped.

This is also the part most rejection guides underserve, because it is boring: the week you lose was often lost before you wrote any code, in an agreements screen nobody audited.

Licence, maintenance, and the alternative

The licence is OpenRoots ORA 2.3, per the badge, which GitHub reports as NOASSERTION because it is not a standard template; a NOTICE file and a citation allowlist sit alongside the LICENSE. The project is maintained by one person, with a changelog, CI, and an agent-os directory structure holding the skill and hooks halves. The last push was on 2026-09-17, the same week as this review.

The alternative is doing it by hand from primary sources: Apple's App Store Review Guidelines and Google Play's developer content policy, plus your own pre-submission checklist. That material is authoritative and free, and every claim in this playbook traces back to it. What the raw documents do not give you is the mapping layer, from a one-line rejection email to the exact guideline and fix, the prioritization by what actually sinks submissions, and a guard that refuses to let the submission command run while a critical risk stands. Teams with a release engineer who already maintains such a checklist internally need this less; teams without one are who the paste block is for.

Editorial conclusion

The App Store Compliance Playbook fits mobile teams without an established internal review-checklist owner, and especially teams using Claude Code or another agent harness where the pre-submission hook and audit skill install cleanly into the existing flow. It does not fit teams that need a licence-file-free corporate dependency, since ORA 2.3 is a custom licence requiring a read, or anyone hoping account-level blockers get detected automatically, which the README itself says a code scan cannot do. Verify first: that the guard's PreToolUse registration and 120-second timeout are actually set in your settings.json, that verify-citations.py passes on the revision you cloned, and that someone walks the account readiness checklist manually. The last push was on 2026-09-17.

Frequently asked questions

Official sources

1. Issues
2. mjmirza/app-store-compliance on GitHub
3. README