# app-store-preflight holds thirteen rejection rules in five categories and ten app type checklists, with no map between them > An agent skill that reads an Xcode project and its App Store Connect metadata looking for the patterns that get submissions rejected. It is four files and no code, it needs a third party's Homebrew installed CLI to fetch metadata at all, its path examples only match that CLI's JSON layout, and its last workflow step edits your project with no dry run described. **truongduy2611/app-store-preflight-skills** — AI agent skill to scan iOS/macOS projects for App Store rejection patterns before submission - Repository: https://github.com/truongduy2611/app-store-preflight-skills - Stars: 1,375 · Forks: 69 - Language: Unknown - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/truongduy2611-app-store-preflight-skills ## Nothing runs without a third party's Homebrew CLI The install is one line: ```bash npx skills add truongduy2611/app-store-preflight-skills ``` The runtime dependency is somebody else's tool. Step two of the workflow pulls metadata with `asc metadata pull --app "" --version "" --dir ./metadata`, and `asc` comes from a different author's repository, installed with `brew install asc`, with a second repository of that author's ASC CLI skills offered as an alternative for the same step. So the skill you install is the instructions plus the rules, and the thing that actually reaches App Store Connect is a separate binary from a separate maintainer. That is a reasonable split, since the credentials stay in the other tool. It is also a supply chain fact worth stating plainly: the preflight check depends on a CLI whose version, behaviour, and maintenance are outside this repository, and nothing on the page pins which version of it is expected. ## The rules only speak the asc metadata layout The page states its own compatibility limit in two sentences, which is rare and useful. Most metadata examples assume the canonical JSON layout written by `asc metadata pull`. If you are starting from fastlane metadata, the instruction is to adapt the path examples, or to pull the canonical `asc` layout first. In practice that means the rule files contain paths into a directory shape that only exists after the third party CLI has written it, so every metadata rule needs a manual translation if your project keeps its store listing in fastlane's format. The alternative, running the pull yourself into a scratch directory, works but means your real fastlane files are not what gets inspected. The page does not document the layout itself, so you cannot reconstruct the expected paths without either the CLI or reading the rule files one by one. ## Two rules cover the same guideline number and the same missing links Thirteen rule files are visible across five category directories, and each one names the guideline it enforces. Two of them collide. `subscription_metadata` sits in the metadata directory and is mapped to guideline 3.1.2, catching missing Terms of Service, EULA, and Privacy Policy links. `missing_tos_pp` sits in the subscription directory, is also mapped to 3.1.2, and catches no Terms or Privacy Policy in app or metadata. Same number, same subject, two files in two directories, which means one finding about a missing policy link can be produced by either rule and you have no way to tell from the report which one fired. One more mapping is looser than the rest: `china_storefront` is recorded against a bare guideline 5 rather than a numbered subsection, and its subject is OpenAI, ChatGPT, and Gemini references for the China storefront, which is a localisation concern carried in a general category. ## Severity is a two value enum, so the report cannot express anything else The rule template fixes the header fields at three: Guideline, Severity, and Category. Severity has exactly two legal values, `REJECTION | WARNING`, and Category has exactly five, matching the five rule directories, `metadata | subscription | privacy | design | entitlements`. Everything else in a rule is prose under four fixed headings: What to Check, How to Detect, Resolution, and Example Rejection. Requiring an example rejection in every single rule is the interesting constraint, because it means each file carries a model of the rejection text rather than only a detection heuristic. The two value severity scale is the practical limit: a warning that would actually block you and a rejection that is merely possible are the only two things the report can say, and nothing in the schema lets a rule mark a check as informational or as uncertain. ## The last workflow step edits your project The five steps are: identify the app type and load the matching checklist, pull the metadata, scan against the rules, report findings with severity, affected files, and resolution steps, and then autofix and validate by applying fixes and re-running the affected checks. That fifth step is the one to look at first, because it is the difference between a reader and an editor. Nothing in the description mentions a dry run, a preview, a patch file, or a confirmation prompt between the report and the write. The affected files named in step four suggest the report is precise about what it wants to change, which is the mitigating half, but precision in a report is not the same as consent to edit. Rules that touch metadata are the ones where this matters, since those files are usually shared across a team and usually tracked in version control. ## Ten checklists by app type, thirteen rules by category, and nothing joining them The guideline index holds a complete index of all 100+ Apple Review Guidelines plus ten app type specific checklists: universal for every submission, then subscriptions and in-app purchases, social and user generated content, kids, health fitness and medical, games, macOS, AI and generative AI, crypto finance and trading, and VPN and networking. The rules are organised on a completely different axis, by the kind of thing being checked rather than the kind of app. So the repository carries two taxonomies, ten app types and five rule categories, and there is no table anywhere mapping one to the other. Finding out whether the AI checklist is enforced by the `ai_apps` rules or by something else means reading both sides. For an app that sits in more than one bucket, a crypto app with an AI feature and user generated content, there is no documented way to combine the three checklists either. ## Four entries at the root, all the behaviour in one file, and one naming inconsistency The repository root holds four things: LICENSE, README.md, SKILL.md, and `references/`. Everything the agent does is in that single SKILL.md, which the page points to for the full instructions, and everything it knows is markdown underneath `references/`. There is no code, no package manifest, and no GitHub release, so there is no version to pin and the installed copy is whatever is on the branch, last pushed on 2026-05-29. The overview also claims the skill scans your Xcode project, source code, metadata, and configuration files, four inputs, while the documented workflow gives a concrete command for exactly one of them, the metadata pull. Nothing describes how the Xcode project and source files are read. And the naming drifts: the page title is App Store Preflight in the singular while the package and repository are `app-store-preflight-skills` in the plural. ## Conclusion Use this as a pre-submission read through rather than as a gate you trust blind. It is a checklist with Apple's own guideline numbers attached, which makes its findings auditable in a way most agent output is not, and the ten app type checklists are the more useful half because they match how you actually file. Two things to do first. Install the `asc` CLI it depends on, or step two of the workflow cannot run and you are left with static rules. And read step five before you let it near your tree: it applies fixes and re-runs checks, so run it on a clean branch and read the diff, because a rule that guesses wrong about your metadata will happily rewrite it. ## FAQ ### What does the app-store-preflight skill actually check? It flags patterns that commonly cause App Store rejection across metadata, subscriptions, privacy, design, and entitlements. Examples include incomplete review notes for new submissions, competitor brand names, missing PrivacyInfo.xcprivacy, asking for name or email after Sign in with Apple, WebView wrappers with fewer than three screens, and unused entitlements in the Xcode project. ### Does the preflight skill need any other tools installed? Yes. It integrates with the asc CLI, installed with brew install asc, to pull and inspect App Store Connect metadata, and it points at a separate repository of ASC CLI skills as an alternative for the metadata sync step. Without one of those, the metadata pull in the workflow cannot run. ### How do I install the app-store-preflight skill? With npx skills add truongduy2611/app-store-preflight-skills. The repository root contains LICENSE, README.md, SKILL.md, and a references directory, with no code and no published release. ### Can the preflight skill fix problems by itself? The last workflow step is autofix and validate, which applies fixes and re-runs the affected checks. The report before it names severity, affected files, and resolution steps, and no dry run or confirmation step is described between the report and the write. ### Which app type checklists does the preflight skill include? Ten, under references/guidelines/by-app-type: all apps for universal use, subscriptions and in-app purchases, social and user generated content, kids, health fitness and medical, games, macOS, AI and generative AI, crypto finance and trading, and VPN and networking. The rules themselves are filed by category instead, with no table joining the two lists. ### How are the rejection rules structured? Each rule is a markdown file with a fixed header of Guideline, Severity, and Category, then four fixed sections: What to Check, How to Detect, Resolution, and Example Rejection. Severity has two legal values, REJECTION and WARNING, and Category has five, matching the five rule directories. ## Sources - [Issues](https://github.com/truongduy2611/app-store-preflight-skills/issues) - [License: MIT](https://github.com/truongduy2611/app-store-preflight-skills/blob/main/LICENSE) - [README](https://github.com/truongduy2611/app-store-preflight-skills/blob/main/README.md) - [truongduy2611/app-store-preflight-skills on GitHub](https://github.com/truongduy2611/app-store-preflight-skills) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/truongduy2611-app-store-preflight-skills